CA2218178A1 - Multi-purpose transaction card system - Google Patents
Multi-purpose transaction card system Download PDFInfo
- Publication number
- CA2218178A1 CA2218178A1 CA002218178A CA2218178A CA2218178A1 CA 2218178 A1 CA2218178 A1 CA 2218178A1 CA 002218178 A CA002218178 A CA 002218178A CA 2218178 A CA2218178 A CA 2218178A CA 2218178 A1 CA2218178 A1 CA 2218178A1
- Authority
- CA
- Canada
- Prior art keywords
- card
- value
- terminal
- message
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
- G06Q20/4093—Monitoring of device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
- G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
- G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Storage Device Security (AREA)
Abstract
Disclosed is a multi-purpose transaction card system comprising an issuer (101), one or more cards (102), one or more terminals (103), and optionally one or more acquirers (104), communicating using a variety of cryptographic confidentiality and authentication methods. Cards authenticate messages using public-key based cryptographic without themselves performing the extensive computations usually associated with such cryptography. Integrity of complex transaction sequences and plural card storage updates are maintained, even under intentionally generated interruptions and/or modifications of data transmitted between card and terminal. Cards do not reveal any information to the terminal which is not directly necessary for the transaction or any information to which the terminal should not have access, through externally measureable aspects of its behaviour. Transaction types supported include those suitable for off-line credit cards, in which the "open to buy" is maintained on the card.
Description
WO 96/25814 PCT~US9~0~76 _ 1 _ MULTI-PURPOSE TRANSACTION CARD SYSTEM
BACKGROUND OF THE INVENTION
1. FIELD OF THE INVENTION
This invention relates to transaction systems, and more specifically to secure trans-
BACKGROUND OF THE INVENTION
1. FIELD OF THE INVENTION
This invention relates to transaction systems, and more specifically to secure trans-
2 action systems involving tamper-resistant devices.
2. DESCRIPTION OF PRIOR ART.
2. DESCRIPTION OF PRIOR ART.
3 Reference is hereby made to P.C.T. publication WO 89/08957, E.P.O. filing 89905483.7, and U.S. patent 4,987,593 filed 3/16/88, titled "One-Show Blind Signature s Systems" by Chaum, which are incorporated herein by reference. Reference is also hereby s made to E.P.O. filing 90200207.0 and U.S. patent 5,131,039 filed 1/29/90, titled 7 "Optionally moderated transaction systems" by Chaum, which are incorporated herein by reference. Reference is also hereby made to U.S. patent 4,914,698 filed Jul. 24, 1989, titled 9 "One-show blind si~n~t--re systems" by Chaum and to U.S. patent 5,276,736, filed Jul 13, 10 1992, titled "Optionally moderated transaction systems" by Chaum, which are incorporated .. herein by reference.
2 A basic technique for "endorsing" a public key digital signature was disclosed in the 13 first above included reference and a related paper presented at Crypto '88. This technique ~ .. was used in the second above in~luded reference and also in other subsequent publications, 15 such as, for example, U.S. Patent 5,016,274 by Micali et al. related to a paper presented at lG Crypto '89 and CWI technical Report CS-R903S.
W O96/25814 PCT~US95/01765 ~ Endorsement schemes are simply one-time sign~t~lre schemes where the 2 ~llthenrication of the public key that is always needed in one time sign~ture schemes is done 3 using the very well know technique of a public key certificate.
2 A basic technique for "endorsing" a public key digital signature was disclosed in the 13 first above included reference and a related paper presented at Crypto '88. This technique ~ .. was used in the second above in~luded reference and also in other subsequent publications, 15 such as, for example, U.S. Patent 5,016,274 by Micali et al. related to a paper presented at lG Crypto '89 and CWI technical Report CS-R903S.
W O96/25814 PCT~US95/01765 ~ Endorsement schemes are simply one-time sign~t~lre schemes where the 2 ~llthenrication of the public key that is always needed in one time sign~ture schemes is done 3 using the very well know technique of a public key certificate.
4 Three efficiency improvements for the endorsement function, compared to that first s disclosed in the first above included reference, are known in the prior art. The first two 6 pertain to one-time sign~tllre schemes and the third improves the true public key digital 7 ~ ns~tlIres, 8 The first two improvements were made in the context of the well-know original one-time signatures called "Lamport" signatures that are disclosed and attributed to Lamport in ~o "New directions in cryptography," IEEE Transaction on Information Theory, pp. 644, 6~4, 1976, and are also subsequently described by Lamport in SRI technical report CSL 98.
12 Lamport signatures simply authenticate, as a public key, the output of a public one-way 13 function on a list of secret values; later release of a subset of the secret values allows ~~ anyone to confirm both that they correspond to the authenticated list and the message 15 signed by being encoded in the choice of subset.
.~ The first improvement is believed disclosed at least in IBM Technical Disclosure 17 Bulletin, vol. 28, no. 2, July 1985, pp. 603~04, titled "Matrix digital cign~hlre for use with ~s the data encryption algo~ l" and in the Procee-ling~ of Crypto '87 by Merkle in the 19 context of Lamport sign~t~res and was subsequently incorporated in the second above 20 included reference by Chaum. This first improvement reduces the size of the original list of 21 secret inputs to the one-way function. Instead of simply basing the sign~tllre on single 22 independent applications of one-way functions, the functions are composed or "chained" so 23 that the output of the previous function application in the chain serves as the input of the 24 next function application. Each chain can be thought of as ,eprese~-ti.~g one digit ofthe 25 numeric message signed by the one-time scheme. The radix is one plus the length of the 26 chain, with the original Lamport Sign~tllres having radix 2. This first improvement results in 27 economy of storage and tran~mi~ion, at the expense of an increase in computation.
2r The second efficiency improvement was also disclosed by Merkle, as cited above. It 29 applies techniques, believed known in the coding art, that reduce the number of"control"
30 digits needed. These digits prevent a signature from being ch~nged into a .sign~tllre on a 31 different message. The previous disclosures cited used one control digit per message digit, 32 with the control digit representing the additive inverse of the message digit. The 33 improvement works essentially by having only a few control digits that represent the -WO 96/2581~ PCl'ilUS9S~0176S
additive inverse of the sum of the message digits. Accordingly, the number of control digits 2 iS reduced from being linear in the number of message digits to being only logarithmic.
3 The third improvement applies to certain public key digital signature sçhemes. ~t was 4 disclosed first in U.S. Patent 4,g49,380, in a paper presented at Crypto '89, PCT
s publication US89/04662, and EPO application 89912051.3, all subst~nti~lly the same and all by Chaum. This improvement allows plural public key si~n~tures to be "intermingled" in 7 the space taken by one, so long as they are made with coprime public exponents. They can be signed in the intermingled form, stored in that form, and later separated for showing.
9 This technique also gives economy of storage (and communication), although potentially at ~o the expense of extra computation.
~- One commercially interesting use of endorsement schemes appears to be in the area 12 of"prepaid cards."
13 A prepaid smart card contains stored value which the person holding it can spend at 14 retail points of payment. A~er accepting stored value from cards, retailers are periodically .s reimbursed with actual money by system providers. A system provider receives money in 16 advance from people and stores corresponding value onto their cards. During each of these 17 three kinds of transactions, secured data representinP value is exchanged for actual money 18 or for goods and services. Telephone cards used in France and elsewhere are probably the ~~ best known prepaid smart cards (though some phone cards use optical or m~gnetic 20 techniques). National prepaid systems today typically aim to combine public telephones, 2~ merchants, vending, and public transportation. Automatic collection of road tolls may also 22 be included soon.
23 Growth in the prepaid smart card market appears to be rapid. For inct~nce, at the 24 time of this application it is believed that national prepaid chipcard schemes are rolling out 25 in Denmark, under construction in Portugal, and planned in Belgium, Spain, and France.
26 The MAC network, believed the largest ATM network in the United States, has announced 27 its entry, and systems are apparently already operational in South Africa and Switzerland.
28 In schemes based solely on conventional cryptography used by cards, secured 29 modules (sometimes called SAM's) are needed at every point of payment. The reason is 30 that transactions are consumm~ted without communication with external sites, to keep 31 transaction costs comm~nc~lrate with the low-value of payments, and that conventional 32 cryptographic authentication requires the communicants to share a common secret. Each 33 secure module is believed to require the ability to develop secret keys of all cards, which W O96125814 PCTrUS95/01765 gives some problems. If the cards of multiple system providers are to be accepted at the 2 same point of payment, all the points of payment must have secured modules containing 3 keys of every provider. This is believed to mean either a mutually trusted module 4 cont~ining the keys of multiple providers, which might be hard to achieve, or one module s per provider, which becomes impractical as the number of providers grows. Furthermore, in any such system, if a module is penetrated, not only may significant retailer fraud be 7 facilitated, but the entire card base may be compromised.
8 Endorsement schemes avoid these problems since they do not require such secured 9 modules. Equipment at points of payment needs no secret keys, only public ones, in order 10 to ~lth.onticate the endorsem~ntc, which act like guaranteed checks filled in with all the .. relevant details. These same endorsements can later be verified by the system provider for 12 reimbursement. (While these systems allow full end-to-end verification, tamper-resistant 13 aggregators can always be used for truncation.) They also allow the cards of any number of 14 issuers to be accepted at all retailers; retailers cannot cheat issuers, and issuers cannot cheat ~s each other.
~~ The size of the chip in the card is of substantial practical importance in such systems.
17 With a given technology, the more storage the more the chips cost to produce and the bigger they are. It is believed that in the industry larger chips are also thought to mean 1~ higher card production costs, and less reliable and durable cards. Cards announced so far 20 for such national prepaid systems use only conventional cryptographic ~uth~ontic~tion and 21 have only about one kilobyte of nonvolatile storage. For endorsement techniques to be a2 competitive, it is believed important that they can be fit into the same chips. Prior art 23 techniques do not allow enough endors~ments to be stored in such chips.
24 Furthermore, it is believed that ordinary credit card and/or debit card transactions 25 conc~mm~ted using a smart card would benefit from the additional security of an off-line 2~ public key endorsement of their transaction details.
27 Transaction systems using a tamper-resistant device are well known. Usually the 28 tamper-resistant device has the form of a smart card. Most smart card transaction systems 29 are targeted to fin~nci~l transactions, but many other transaction such as access control are 30 in use. In most smart card systems the smart card has one or more secret keys specific to 31 that smart card, while each terminal has one or more 'master keys' in a tamper-resistant ''2 device which allow the terminal to derive the secret keys of the smart cards. Once both ~3 parties in the transaction have a secret key in common, the security and authenticity of the WO96/25814 PCTnUS9~D~76 ~ transaction can be ensured using traditional cryptographic methods. The 'master keys' in 2 the terminal are a weak point in these systems, as any attack which succeeds in getting 3 these keys out of a terminal leads to a catastrophic breakdown of the security. Methods of solving this problem usually involve the application of some kind of public key s cryptography. Using smart cards with a public key cryptographic capability is one solution, s but such smart cards are more expensive than simple ones.
7 During a transaction a smart card will typically update one or more locations in non-volatile memory, which could for example consist of EEPROM. Present smart cards are 9 sometimes vulnerable to interruptions during the update which leads to security and .O reliability problems. Any faults in the non-volatile memory often lead to wrongful ~- transaction processing. Another weakness of smart cards using EEPROM memory is an 12 attack in which the smart card is irradiated using ultraviolet (UV) light. It is known that this 13 infl~ nc~s the data stored in the EEP~OM, and might thus be used to attack the security of 14 the system. Some types of transactions require several items in non-volatile memory to be ~s modified simultaneously, a requirement which is not supported in current smart cards.
~s The different actions which make up a transaction are mostly not bound together by ~, cryptographic means, making it harder to provide adequate security for complex ~8 transactions and often nec~5~ t illg the use of spe~ i7ed actions. Financial transaction 19 system smart cards which are used for payment purposes typically subtract the amount of the payment from the internally held balance before giving out the cryptographic proof to 21 the terminal that the payment has been made. Any interruption in the time between this 22 update and the sending of the proof can lead to a loss of money, unless special recovery 23 procedures are used.
2 Most smart cards willingly reveal a lot of information, often incllldinsg a unique card 2s identity number, directory structure etc. Although this information is usually not directly relevant to the security of the application, it can provide additional information to the 2~ terminal which might be used to invade the privacy of the owner of the smart card.
2s The tamper resist~nce of smart cards is typically used to allow the smart card to 29 execute processes using some secret information (e.g. secret cryptographic keys), and care iS taken in the design of transaction systems that the smart card does not reveal any of the 31 secret information to the terminal. However, a terminal might perform many more 32 measurements then just looking at the data that is sent by the card; it is our belief that many 33 existing systems are vulnerable to an attack which uses these additional measurements.
W O96/25814 PCTrUS95/01765 The recently published specifications for the EMV system "Integrated Circuit Card 2 Specifications for Payment Systems: Part 1, Electromechanical Characteristics, Logical 3 Interface, and Trancmiccion Protocols, version 1.1; Part 2, Data Elements and Comm~nds, 4 version 1. ., and Part 3, Transaction Proc~c~ing, version 1.0" all dated October 31, 1994 by s Europay International S.A., MasterCard International Incorporated, and Visa International Service Association define a system designed for credit card applications. They allow off-7 line processing of some credit card transactions. The specifications seem to envision a 8 setting where the terrninal does not have access to any secret keys, the specified off-line 9 transactions do not include any means for the terminal to verify the authenticity of the card .c and the transaction data in this setting. Furthermore, the specifications seem not to take full advantage of the capabilities of a smart card. The EMV specifications are envisioned to be .z used for several types of financial transactions, including credit card payments, direct 13 debiting of the user's account, pre-paid payments where the money resides in the card etc.
14 The specifications do not address the underlying similarity in structure for all of these 15 applications.
16 For some types of transactions, and specifically for financial ones, there is also a ~7 clearing process. In this process the terminals send information regarding the money they .~ collected to the acquirer and/or issuer. Current systems rely on either having the terminal 19 forward full transaction information to the acquirer, or having a tamper-resistant device 20 (often called SAM) in the terminal to do the truncation: the SAM accepts the transaction 21 data, verifies them, and keeps track of the necessary totals. This allows some or all of the 22 transaction data to be discarded, the necessary clearing information is forwarded by the 23 SAM to the acquirer and/or issuer and authenticated using some cryptographic scheme.
24 Forwarding all transaction information can be expensive and cumbersome, while having 25 SAMs in terminals can be expensive. When a single terminal has to deal with many dirrelen~
26 issuers/acquirers, the terminal either needs separate SAMs for each of the issuers/acquirers, 27 which is expensive, or a single SAM which is trusted by all the issuers/acquirers, which 28 leads to org~ni7~tional difficulties.
OBJECTS OF T~ rNVENTION
29 Accordingly, it is an object of the present invention to:
provide a secure, flexible, eff~cient and reliable multi-purpose transaction system;
WO 96125814 PCTI~S9SJû1765 provide a secure and efficient authentication capability for smart cards, which does 2 not rely on a capability of the smart card to performing public key cryptographic 3 computations in an adequate fashion;
4 provide a secure atomic update of the non-volatile memory in smart cards for one or s more modifications to the data in the memory, even under arbitrary interruptions and some 6 physical attacks;
provide proper cryptographic proofs and verifications that the dirrel enL actions that 8 make up a transaction are kept together and executed in order;
prevent the smart card from revealing any information to terminals that do not have ~O access to the appropriate keys;
~- prevent the smart card from revealing any information in addition to the inforrnation 12 communicated as part of the transaction, through any external behaviour, 13 provide clearing methods and systems that do not communicate all the transaction 14 data, without the use of one or more tamper-resistant devices in the terminal;
protect the terminals interest in off-line EMV transactions by adding a public key 16 based digital authentication to the transaction;
17 provide a general transaction structure that can be used for credit card transactions, . pre-paid transactions, direct debit transactions etc.; and 19 allow efficient, economical, and practical apparatus and methods fulfilling the other 20 objects of the invention.
21 Other objects, features, and advantages of the present invention will be appreciated 22 when the present description and appended claims are read in conjunction with the drawing 7 figures.
BRIEF DESCRIPTION OF THE DR~WING FIGURES
24 It will be appreciated that the figures 39, 42, 43, 44, 45 and 46 are part of the 25 description of a first p~efe-- ed embodiment and that all other figures are part of the tS description of a second preferred embodiment.
r 213 Fig. l shows a combination block and functional diagram of a preferred embodiment 29 of a multi-purpose transaction card system involving four groupings of parties, in 30 accordance with the tP~chingc ofthe present invention, W O96/25814 PCTrUS95101765 ~ Fig. ' shows a combination block and functional diagram of a one time sign~tl~re 2 structure called a house, in accordance with the teachings of the present invention;
.. Fig. 3 shows a combination block and functional diagram of a first preferred compact 4 endorsement signature structure called a town, in accordance with the teachings of the s present invention;
Fig. 4 shows a combination block and functional diagram of a second prefelled 7 compact endorsement signature structure called a town, in accordance with the te~hin~c 8 of the present invention, which is believed to allow an efficient implementation;
9 Fig. 5 shows a combination block and functional diagram of a prt:rel I ed exemplary 10 embodiment of a compact endorsement Sjgn~ture structure called a town, in accordance with the teachings of the present invention;
12 Fig. 6 is a block diagram showing exemplary data elements and control elements that 13 are signed using a one time sign~tllre structure of Fig. '~, in accordance with the te~çhingc 14 of the present invention, in a way which is believed to enhance security;
Fig. 7 shows a combination block and functional diagram of a public key verifying 16 party, in accordance with the teachings of the present invention;
17 Fig. 8 shows a flowchart of a preferred embodiment of a card cancel process in 1B accordance with the teachingc ofthe present invention, which, together with Fig. 13, 14, 19 15, 16, 17, 18 and 19 is believed to implement a secure data storage system of said card, 20 and which, in particular, when executed at the end of a session is believed to rollback all the 21 results on the card non-volatile memory of said session;
22 Fig. 9 shows a combination block and functional diagram of a pl ~rt;" ~d exemplary 23 embodiment of a one time sign~ture structure called a house in accordance with the 24 te~chingc of the present invention;
Fig. 10 shows a combination block and functional diagram of a public key issuing 26 party, in accordance with the teachings of the present invention;
27 Fig. 1 I shows a block and functional diagram of a non-volatile memory model in 2r. accordance with the te~chings of the present invention, which is believed to describe the ~ 29 write and erase behaviour of most types of non-volatile memory used in the art, in 3~ particular the write and erase behaviour of EEPROM;
31 Fig. 1'~ is a block diagram showing the use of volatile and non-volatile memory in a 32 preferred embodiment of a card in accordance with the te~chin~gc of the present invention;
-CA 022l8l78 l997-08-08 WO96/25814 PCTrUS9~J~1765 _g_ Fig. 13 shows a flowchart of a preferred embodiment of a card start update process, 2 in accordance with the teachingc of the present invention, which, together with Fig. 8, 14, 3 1 5, 16, 17, 18 and 19 is believed to implement a secure data storage system of said card;
4 Fig. 14 shows a flowchart of a preferred embodiment of a card delete frame[i]
s process in accordance with the te~ching~ of the present invention, which, together with Fig.
6 8, 13, 1~, 16, 17, 18 and 19 is believed to implement a secure data storage system of said 7 card;
8 Fig. 15 shows a flowchart of a p. ~fel, ed embodirnent of a card write 9 frame[t,access,data] process in accordance with the teaçhin~c of the present invention, .o which, together with Fig. 8, 13, 14, 16, 17, 18 and 19 is believed to implement a secure data storage system of said card;
12 Fig. 16 shows a flowchart of a preferred embodiment of a card reset process in 13 accordance with the te~chingc ofthe present invention, which, together with Fig. 8, 13, 14, 14 15, 17, 18 and 19 is believed to implement a secure data storage system of said card;
~s Fig. 17 shows a flowchart of a preferred embodiment of a card commit process in 6 accordance with the te~çhingc of the present invention, which, together with Fig. 8, 13, 14, ~7 15, 16, 18 and 19 is believed to implement a secure data storage system of said card;
8 Fig. 18 shows a flowchart of a p- ~fe, red embodiment of a card find frame[t] process 19 in accordance with the te~chingc of the present invention, which, together with Fig. 8, 13, zo 14, 15, 16, 17, and 19 is believed to implement a secure data storage system of said card;
21 Fig. 19 shows a flowchart of a pl efe, I ed embodiment of a card read frame[t] process Z2 in accordance with the te~hingc ofthe present invention, which, together with Fig. 8, 13, 23 14, 15, 16, 17, and 18 is believed to implement a secure data jtorage system of said card;
2~ Fig. 20 is a combination block and functional diagram showing mech~nicmc of 25 encrypting data with a session-state and çh~ining data in said session-state chain and 26 decrypting data with said session-state and chaininsg data in said session-state, in Z7 accordance with the teaçhingc ofthe present invention;
28 Fig. 21 is a combination block and functional diagram showing the mech~nism of 29 'crypting' data with a session-state and çh~ining data in said session-state as performed in 3~ the preferred embodiment of a card, and the mechanism of 'crypting' data with said 31 session-state and ~h~ining data in said session-state as performed in the ple~"ed 3Z embodiment of a terminal, in accordance with the t~achingc of the present invention, which 33 are believed to implement an encrypt decrypt pair, as shown in Fig. 20;
W O 96/25814 PC~r~US95/01765 Fig. '~'' is a combination block and fi~nctional diagram showing a preferred exemplary 2 impl~ment~tion of a mechanism of 'crypting' data with a session-state and chaining data in 3 said session-state as performed in a preferred embodiment of a card, in accordance with the ~ tç~chingc of the present invention. which, together with the rneçh~nicrn showed in Fig. 23, s are believed to implement the mech~nicmc as shown in Fig. 21;
Fig. 23 is a combination block and functional diagram showing a preferred exemplary 7 implementation ofthe meGh~nism of'cryptin~ data with a session-state and çh~inin~ data B in said session-state as performed in a preferred embodiment of a terminal, in accordance 9 with the teachings of the present invention, which, together with the meçh~nicm showed in .0 Fig. ~2, are believed to implement the mechanisms as shown in Fig. 21;
~. Fig. 24 shows a flowchart of a process called 'session' which involves a card and a 12 terminal in a preferred embodiment, in accordance with the teachings of the present 13 invention;
14 Fig. 25 shows a flowchart of a detail process called 'start session and proof keys', 15 involving actions by a terminal, actions by a card and communication between said card and .~ said terminal, in accordance with the teachings of the present invention, which, together 17 with Fig. 26 and 27 are believed to implement the process of Fig. 24;
lB Fig. 26 shows a flowchart of a detail process called 'command and exchange data', 19 involving actions by a terminal, actions by a card and communication between said card and 20 said terminal, in accordance with the teachings of the present invention, which, together 21 with Fig. 26 and ''7 are believed to implement the process of Fig. 24;
22 Fig. 27 shows a flowchart of a detail process called 'commit session and end session', 23 involving actions by a terminal, actions by a card and communication between said card and 2- said terminal, in accordance with the teaçhingc of the present invention, which, together 25 with Fig. 26 and 27 is believed to implement the process of Fig. 24;
2B Fig. ''8 shows a flowchart of an EMV transaction process, involving actions by a 27 terminal, actions by a card, actions by an issuer and communication between said card and 21~ said terminal and between said terminal and said issuer in a preferred embodiment, in 29 accordance with the teachingc of the present invention;
Fig. 29 is a flowchart showing all possible succ~ssfill executable series of comm~n~ls, 31 issued by a terminal and performed by a card in a preferred embodiment, in accordance 32 with the teachings of the present invention;
W O 96/25814 PC~nUS95/01765 Fig. 30 shows a flowchart of a Commit-Challenge-Response process involving 2 actions by a terminal, actions by a card and communication between said card and said 3 terminal, in accordance with the tearhingc of the present invention;
Fig. 31 shows a flowchart of a non single execution path process and a single execu-s tion path process, both acsivning values to variables depending on a conditional in accordance with the te~chingc of the present invention, which are believed to have the same 7 result on the assigned variables;
8 Fig. 32 shows a flowchart of a 'Get Proof' process in a preferred embodiment, 9 involving actions by a terminal, actions by a card and communication between said card and ~o said terminal, in accordance with the teachingc of the present invention;
Fig. 33 shows a flowchart of a process of performing a 'script' in a pr~re~ t;d embodi-2 ment, involving actions by a terminal, actions by a card and communication between said ~3 card and said terminal, in accordance with the teachingc of the present invention;
.4 Fig. 34 shows five detail flowcharts of processes called 'start session 1', 'start session 2', 'get frame', 'put frame' and 'kill frame' in a preferred embodiment, involving actions by ~~ a terminal, actions by a card and communication between said card and said terminal, in 17 accordance with the teachingc of the present invention in accordance with the teachingc of 18 the present invention;
lD Fig. 35 shows five detail flowcharts of processes called 'debit frame', 'redebit frame', 20 'public debit', 'commit' and 'done' in a preferred embodiment, involving actions by a 21 terminal, actions by a card and communication between said card and said terminal, in 22 accordance with the teachinQc of the present invention in accordance with the teachingc of 23 the present invention;
24 Fig. 36 shows five detail flowcharts of processes called 'get proof', 'select file', 25 'manage application 1', 'manage application '" and 'get data' in a prefe"ed embodiment, 26 involvin;, actions by a terminal, actions by a card and communication between said card and 27 said terminal, in accordance with the teac~lingc of the present invention in accordance with 2a the teachingc of the present invention;
29 Fig. 37 shows five detail flowcharts of processes called 'get file', 'generate AC 1', 30 'generate AC 2', 'external ~lthentic~te' and 'verify' in a p,ere"ed embodiment, involving 31 actions by a terminal, actions by a card and communication between said card and said 32 terminal, in accordance with the teachingc of the present invention in accordance with the 33 teachinsgc of the present invention;
CA 022l8l78 l997-08-08 W O96/25811 PCTrUS95/01765 Fig. 38 shows a detail flowchart of a process called 'get last AC' in a p, efel led 2 embodiment, involving actions by a terminal, actions by a card and communication between 3 said card and said terminal, in accordance with the te~chin~c of the present invention in 4 accordance with the teachingc of the present invention;
Fig. 39 shows a combination block and functional diagram of a preferred embodiment of a compact endorsement sign~t~re system involving four sets of parties in accordance 7 with the teachings of the present invention;
Fig. 40 shows the non-volatile memory contents in accordance with the te~chin~c of 9 the present invention of the preferred exemplary compact endorsement sign~t~lre structure o of Fig. 5 by means of a tabular arrangement of town values, notations and actions;
Fig. 41 shows the operational steps in accordance with the te~chin~c ofthe present 12 invention of the preferred exemplary compact endorsement signature structure of Fig. S by 13 means of a tabular arrangement of town values, notations and actions;
14 Fig. 4'' shows a combination block and functional diagram of an exemplary embodi-.s ment of an endorser party in accordance with the teachings of the present invention;
Fig. 43 shows a flowchart of a general endorsement scheme process in accordance 17 with the te~chingc of the present invention;
18 Fig. 44 shows an exemplary one-time signature structure in accordance with the 19 teachings of the present invention;
Fig. 45 shows a preferred exemplary endorsement structure in accordance with the 21 te~chingc of the present invention, in which Fig. 45a-45d are exemplary first level cascade 22 structures and Fig. 45e is an exemplary second level cascade structure;
23 Fig. 46 shows the operational steps in accordance with the te~chin~c of the present 24 invention of the exemplary structures of Fig. 45 by means of a tabular arrangement of 25 registers names and notations;
2~ Fig. 47 shows a combination block and functional diagram of the interaction between 27 a card and the issuer in the preferred embodiment of a system like Fig. 1, with details added 28 to card entity concerning some registers, and details added to the issuer entity concerning 29 m~int~ined databases in accordance with the te~chingc of the present invention;
3~ Fig. 4~ shows a block diagram of a plere. Ied embodiment of a record in a card 31 database of Fig 47 in accordance with the teachinSgc of the present invention;
32 Fig. 49 shows a block diagram of a p, erel I ed embodiment of a record in a event 33 ~t~bace of Fig 47 in accordance with the te~chingc of the present invention;
_ CA 022l8l78 l997-08-08 WO 96/2~814 PC'rJ~'S9SJ~)176S
~ Fig. 50 shows a flowchart of a preferred embodiment of a issuer process that mainly 2 synchronizes the issuers known balance with a card balance during an on-line transaction, 3 in accordance with the teachingc of the present invention;
Fig. 51 shows a flowchart of a prefe- ~ ed embodiment of a issuer process that mainly s synchronizes the issuers known balance with a card balance during the clearing process of off-line transactions, in accordance with the teachingc of the present invention;
7 Fig. 52 shows a flowchart of an exemplary implementation of the process Fig. 50, in 8 accordance with the teaçhin~ of the present invention; and g Fig. 53 shows a flowchart of an exemplary implçment~tion ofthe process Fig. 51, in .o accordance with the teaching of the present invention.
BRIEF SUMMARY OF THE rNVENTION
In accordance with the forgoing and other objects of the present invention, a brief .2 summary of some exemplary embodiments will now be presented. Some simplifications and 3 omissions may be made in this summary, which is intended to highlight and introduce some 4 aspects of ~h~ p~eser~ nti~n, b~t n~t t~ lim.~it~cop~r.~way. Detailed descr,ptions of prefe. . ed exemplary embodiments adequate tO allow those of ordinary skill in the art to 16 make and use the inventive concepts are provided later.
., An endorsement scheme that allows preferably hundreds of endorsements to be 8 stored in less than a thousand bytes on a simple microcontroller smart card would be 1~ commercially intel e~ g, but cannot be achieved by techniques known in the prior art. The present invention overcomes these limitations of the prior art.
21 The inventive concept provides hierarchical structuring of multiple one-time 22 Sipn~tures within a single public key sign~ture. The hierarchy is formed from comp~essillg 23 one-way functions, also sometimes known as hash or message digest functions, serving as 2~ the internal '~nodes" in a special tree structure. The tree's "leaves" are the one-time 2s signatures and its "edges" are values that are inputs and sometimes outputs of the compression functions. Thus the root represents the final compression of all the one-time 27 signatures in the structure, and the output of this compression is signed by the digital 28 siSJn~t~re technique.
29 Each endorsement involves a subset of the tree including the single one-time 30 sign~t~-re that is used in, and only in, that endorsement. Also in the subset is the public key W O96/2581~ PCT~US95/01765 ~ signature and a path of edges from the leaf to the root. The values represented by all edges 2 incident on the nodes of the path, apart from those edges on the path, are included.
3 The endorsements are made in an order that, in cooperation with the structuring, lets 4 the card use a relatively small number of non-volatile registers at each stage. Furthermore, s the amount of computation required between each endorsement is also limited to a small s amount. Moreover, stepping from the last one-time sign~tl~re in one digital cign~ture to the first ofthe next digital sign~tllre requires esslonti~lly only the same resources as stepping 8 between any two one-time signatures within the same digital signature.
9 One of the particular preferred embodiments, which is disclosed in detail later, uses a tO "c~cc~rle" of two-argument co,-" resshlg functions as a building block. The first ~- col"p, essing function in the cascade takes two inputs from outside the cascade. All 12 subsequent compresses in the cascade take one argument from the previous compress and 13 one from outside the cascade. Thus, with only an output of one compress in a cascade 14 along with all subsequent inputs to the c~scadto7 the output of the entire c~c~de can be ~s verified.
16 The cascades are structured into a low hierarchy, preferably only two high, although ~7 any hierarchy could be used. The c~cc~r~es at the low level, called "streets," take their .~ inputs directly from one-time signatures, called "houses." The cascades at the higher level, 19 called "towns," take their inputs from the outputs of the cascades at the lower level. Thus, 20 a complete ordering is imposed on the houses of a street and the streets of a town.
21 Roughly stated, in the pl ~r~l I ed embodiment, the endorsements may be thought of as zz proceeding from house to house in order. When a house is visited, its one-time sign~tl~re is 23 used in an endorsement. In addition to this "actual" traversal for endorsements, there are 2~ two "preparatory" traversals conducted in parallel.
The first preparatory traversal moves down the next street visiting almost all the zs houses. (If there is a next street in the current town ordering, this is traversed; if there are 27 no more streets in the current town, then the first street in the next town is traversed). The z~ purpose of the first preparatory traversal is to obtain and store the leaf edges for a street so 29 that they are ready when that street is entered and the first house is used in an endorsement.
The second preparatory traversal moves through the next town. The purpose of this 31 traversal is to obtain and store the edges coming from all the streets of the next town, 32 except the first street. These will be needed in endorsernçnt~ when the new town is initially 33 entered by the actual traversal and endorsements are coming from its first street.
WO 96/25811 PCTnUS9SJ~176S
Tamper resistant devices o~en store some information in non-volatile memory. The 2 preferred embodiment is capable of atomic multi-updates allowing several modifications in 3 the non-volatile memory to be done all at once, even under arbitrary interruptions. Secrecy 4 of critical data is m~int~ined under attacks involving UV irradiation of the smart card chip, s while at the same time allowing recovery in the case of technical failures.
Sessions are introduced which cryptographically link the actions that make up a 7 transaction, ensuring that the con.~titl~ont actions are all performed in order and without any 8 other actions in-between. The sessions also provide a single proof system for an entire 9 transaction, elimin~ting the need for speci~li7~d elementary actions for specific transactions.
~O Even under arbitrary interruption the sessions ensure that either the transaction is completed and the cryptographic proofs exchanged properly, or the transaction is not 12 executed at all.
13 In the preferred embodiment the tamper-resistant device does not reveal any informa-~~ tion to the terminal in addition to the information explicitly communicated with the 15 ter,ninal, even if the terminal performs any or all of a general set of additional ~ measurements on the card while it is in operation.
17 Several clearing methods are described which allow adequate clearing and settlement 18 of fin~nri~l and other transactions to occur without the need for a tamper-resistant device ~9 in the terminal or the need to communicate full transaction data form the terminal to the 20 acquirer/issuer.
21 The EMV system is extended and generalized. The terminal's interests are properly 22 protected by inrl~ding a proper off-line ~thentication of the transaction data. The EMV
. system is generalized to provide all the functions needed for implernent~tion of a wide 24 variety of payment applications.
DETAILED DESCRIPTION OF PE~EFERRED EMl~.ODIME~TS
The drawing figures and the detailed descriptions provided later make a number of 28 simplifying assumptions for concreteness and for clarity in exposition. It will be ~ appreciated, however, that these should not be taken to limit the scope of the invention.
28 Some lines and arrows in the drawing figures represent messages, which may be held 29 initially or delayed on their way, passed through various parties, encoded and decoded 30 cryptographically or otherwise to provide their authenticity and/or secrecy and/or error 31 detection and/or error recovery. Thus the particular means or methods whereby mçss~ges O96/25814 PCTrUS95/01765 ~ are transferred are not essential to the present invention, and it is anticipated that any 2 technique may be employed in this regard.
3 As will be appreciated, someone of ordinary skill in the art would be familiar with Bruce Schneier 1994 "Applied Cryptography, Protocols, Algorithms, and Source Code in s C" and with the references contained therein. As will also be appreciated, someone of
12 Lamport signatures simply authenticate, as a public key, the output of a public one-way 13 function on a list of secret values; later release of a subset of the secret values allows ~~ anyone to confirm both that they correspond to the authenticated list and the message 15 signed by being encoded in the choice of subset.
.~ The first improvement is believed disclosed at least in IBM Technical Disclosure 17 Bulletin, vol. 28, no. 2, July 1985, pp. 603~04, titled "Matrix digital cign~hlre for use with ~s the data encryption algo~ l" and in the Procee-ling~ of Crypto '87 by Merkle in the 19 context of Lamport sign~t~res and was subsequently incorporated in the second above 20 included reference by Chaum. This first improvement reduces the size of the original list of 21 secret inputs to the one-way function. Instead of simply basing the sign~tllre on single 22 independent applications of one-way functions, the functions are composed or "chained" so 23 that the output of the previous function application in the chain serves as the input of the 24 next function application. Each chain can be thought of as ,eprese~-ti.~g one digit ofthe 25 numeric message signed by the one-time scheme. The radix is one plus the length of the 26 chain, with the original Lamport Sign~tllres having radix 2. This first improvement results in 27 economy of storage and tran~mi~ion, at the expense of an increase in computation.
2r The second efficiency improvement was also disclosed by Merkle, as cited above. It 29 applies techniques, believed known in the coding art, that reduce the number of"control"
30 digits needed. These digits prevent a signature from being ch~nged into a .sign~tllre on a 31 different message. The previous disclosures cited used one control digit per message digit, 32 with the control digit representing the additive inverse of the message digit. The 33 improvement works essentially by having only a few control digits that represent the -WO 96/2581~ PCl'ilUS9S~0176S
additive inverse of the sum of the message digits. Accordingly, the number of control digits 2 iS reduced from being linear in the number of message digits to being only logarithmic.
3 The third improvement applies to certain public key digital signature sçhemes. ~t was 4 disclosed first in U.S. Patent 4,g49,380, in a paper presented at Crypto '89, PCT
s publication US89/04662, and EPO application 89912051.3, all subst~nti~lly the same and all by Chaum. This improvement allows plural public key si~n~tures to be "intermingled" in 7 the space taken by one, so long as they are made with coprime public exponents. They can be signed in the intermingled form, stored in that form, and later separated for showing.
9 This technique also gives economy of storage (and communication), although potentially at ~o the expense of extra computation.
~- One commercially interesting use of endorsement schemes appears to be in the area 12 of"prepaid cards."
13 A prepaid smart card contains stored value which the person holding it can spend at 14 retail points of payment. A~er accepting stored value from cards, retailers are periodically .s reimbursed with actual money by system providers. A system provider receives money in 16 advance from people and stores corresponding value onto their cards. During each of these 17 three kinds of transactions, secured data representinP value is exchanged for actual money 18 or for goods and services. Telephone cards used in France and elsewhere are probably the ~~ best known prepaid smart cards (though some phone cards use optical or m~gnetic 20 techniques). National prepaid systems today typically aim to combine public telephones, 2~ merchants, vending, and public transportation. Automatic collection of road tolls may also 22 be included soon.
23 Growth in the prepaid smart card market appears to be rapid. For inct~nce, at the 24 time of this application it is believed that national prepaid chipcard schemes are rolling out 25 in Denmark, under construction in Portugal, and planned in Belgium, Spain, and France.
26 The MAC network, believed the largest ATM network in the United States, has announced 27 its entry, and systems are apparently already operational in South Africa and Switzerland.
28 In schemes based solely on conventional cryptography used by cards, secured 29 modules (sometimes called SAM's) are needed at every point of payment. The reason is 30 that transactions are consumm~ted without communication with external sites, to keep 31 transaction costs comm~nc~lrate with the low-value of payments, and that conventional 32 cryptographic authentication requires the communicants to share a common secret. Each 33 secure module is believed to require the ability to develop secret keys of all cards, which W O96125814 PCTrUS95/01765 gives some problems. If the cards of multiple system providers are to be accepted at the 2 same point of payment, all the points of payment must have secured modules containing 3 keys of every provider. This is believed to mean either a mutually trusted module 4 cont~ining the keys of multiple providers, which might be hard to achieve, or one module s per provider, which becomes impractical as the number of providers grows. Furthermore, in any such system, if a module is penetrated, not only may significant retailer fraud be 7 facilitated, but the entire card base may be compromised.
8 Endorsement schemes avoid these problems since they do not require such secured 9 modules. Equipment at points of payment needs no secret keys, only public ones, in order 10 to ~lth.onticate the endorsem~ntc, which act like guaranteed checks filled in with all the .. relevant details. These same endorsements can later be verified by the system provider for 12 reimbursement. (While these systems allow full end-to-end verification, tamper-resistant 13 aggregators can always be used for truncation.) They also allow the cards of any number of 14 issuers to be accepted at all retailers; retailers cannot cheat issuers, and issuers cannot cheat ~s each other.
~~ The size of the chip in the card is of substantial practical importance in such systems.
17 With a given technology, the more storage the more the chips cost to produce and the bigger they are. It is believed that in the industry larger chips are also thought to mean 1~ higher card production costs, and less reliable and durable cards. Cards announced so far 20 for such national prepaid systems use only conventional cryptographic ~uth~ontic~tion and 21 have only about one kilobyte of nonvolatile storage. For endorsement techniques to be a2 competitive, it is believed important that they can be fit into the same chips. Prior art 23 techniques do not allow enough endors~ments to be stored in such chips.
24 Furthermore, it is believed that ordinary credit card and/or debit card transactions 25 conc~mm~ted using a smart card would benefit from the additional security of an off-line 2~ public key endorsement of their transaction details.
27 Transaction systems using a tamper-resistant device are well known. Usually the 28 tamper-resistant device has the form of a smart card. Most smart card transaction systems 29 are targeted to fin~nci~l transactions, but many other transaction such as access control are 30 in use. In most smart card systems the smart card has one or more secret keys specific to 31 that smart card, while each terminal has one or more 'master keys' in a tamper-resistant ''2 device which allow the terminal to derive the secret keys of the smart cards. Once both ~3 parties in the transaction have a secret key in common, the security and authenticity of the WO96/25814 PCTnUS9~D~76 ~ transaction can be ensured using traditional cryptographic methods. The 'master keys' in 2 the terminal are a weak point in these systems, as any attack which succeeds in getting 3 these keys out of a terminal leads to a catastrophic breakdown of the security. Methods of solving this problem usually involve the application of some kind of public key s cryptography. Using smart cards with a public key cryptographic capability is one solution, s but such smart cards are more expensive than simple ones.
7 During a transaction a smart card will typically update one or more locations in non-volatile memory, which could for example consist of EEPROM. Present smart cards are 9 sometimes vulnerable to interruptions during the update which leads to security and .O reliability problems. Any faults in the non-volatile memory often lead to wrongful ~- transaction processing. Another weakness of smart cards using EEPROM memory is an 12 attack in which the smart card is irradiated using ultraviolet (UV) light. It is known that this 13 infl~ nc~s the data stored in the EEP~OM, and might thus be used to attack the security of 14 the system. Some types of transactions require several items in non-volatile memory to be ~s modified simultaneously, a requirement which is not supported in current smart cards.
~s The different actions which make up a transaction are mostly not bound together by ~, cryptographic means, making it harder to provide adequate security for complex ~8 transactions and often nec~5~ t illg the use of spe~ i7ed actions. Financial transaction 19 system smart cards which are used for payment purposes typically subtract the amount of the payment from the internally held balance before giving out the cryptographic proof to 21 the terminal that the payment has been made. Any interruption in the time between this 22 update and the sending of the proof can lead to a loss of money, unless special recovery 23 procedures are used.
2 Most smart cards willingly reveal a lot of information, often incllldinsg a unique card 2s identity number, directory structure etc. Although this information is usually not directly relevant to the security of the application, it can provide additional information to the 2~ terminal which might be used to invade the privacy of the owner of the smart card.
2s The tamper resist~nce of smart cards is typically used to allow the smart card to 29 execute processes using some secret information (e.g. secret cryptographic keys), and care iS taken in the design of transaction systems that the smart card does not reveal any of the 31 secret information to the terminal. However, a terminal might perform many more 32 measurements then just looking at the data that is sent by the card; it is our belief that many 33 existing systems are vulnerable to an attack which uses these additional measurements.
W O96/25814 PCTrUS95/01765 The recently published specifications for the EMV system "Integrated Circuit Card 2 Specifications for Payment Systems: Part 1, Electromechanical Characteristics, Logical 3 Interface, and Trancmiccion Protocols, version 1.1; Part 2, Data Elements and Comm~nds, 4 version 1. ., and Part 3, Transaction Proc~c~ing, version 1.0" all dated October 31, 1994 by s Europay International S.A., MasterCard International Incorporated, and Visa International Service Association define a system designed for credit card applications. They allow off-7 line processing of some credit card transactions. The specifications seem to envision a 8 setting where the terrninal does not have access to any secret keys, the specified off-line 9 transactions do not include any means for the terminal to verify the authenticity of the card .c and the transaction data in this setting. Furthermore, the specifications seem not to take full advantage of the capabilities of a smart card. The EMV specifications are envisioned to be .z used for several types of financial transactions, including credit card payments, direct 13 debiting of the user's account, pre-paid payments where the money resides in the card etc.
14 The specifications do not address the underlying similarity in structure for all of these 15 applications.
16 For some types of transactions, and specifically for financial ones, there is also a ~7 clearing process. In this process the terminals send information regarding the money they .~ collected to the acquirer and/or issuer. Current systems rely on either having the terminal 19 forward full transaction information to the acquirer, or having a tamper-resistant device 20 (often called SAM) in the terminal to do the truncation: the SAM accepts the transaction 21 data, verifies them, and keeps track of the necessary totals. This allows some or all of the 22 transaction data to be discarded, the necessary clearing information is forwarded by the 23 SAM to the acquirer and/or issuer and authenticated using some cryptographic scheme.
24 Forwarding all transaction information can be expensive and cumbersome, while having 25 SAMs in terminals can be expensive. When a single terminal has to deal with many dirrelen~
26 issuers/acquirers, the terminal either needs separate SAMs for each of the issuers/acquirers, 27 which is expensive, or a single SAM which is trusted by all the issuers/acquirers, which 28 leads to org~ni7~tional difficulties.
OBJECTS OF T~ rNVENTION
29 Accordingly, it is an object of the present invention to:
provide a secure, flexible, eff~cient and reliable multi-purpose transaction system;
WO 96125814 PCTI~S9SJû1765 provide a secure and efficient authentication capability for smart cards, which does 2 not rely on a capability of the smart card to performing public key cryptographic 3 computations in an adequate fashion;
4 provide a secure atomic update of the non-volatile memory in smart cards for one or s more modifications to the data in the memory, even under arbitrary interruptions and some 6 physical attacks;
provide proper cryptographic proofs and verifications that the dirrel enL actions that 8 make up a transaction are kept together and executed in order;
prevent the smart card from revealing any information to terminals that do not have ~O access to the appropriate keys;
~- prevent the smart card from revealing any information in addition to the inforrnation 12 communicated as part of the transaction, through any external behaviour, 13 provide clearing methods and systems that do not communicate all the transaction 14 data, without the use of one or more tamper-resistant devices in the terminal;
protect the terminals interest in off-line EMV transactions by adding a public key 16 based digital authentication to the transaction;
17 provide a general transaction structure that can be used for credit card transactions, . pre-paid transactions, direct debit transactions etc.; and 19 allow efficient, economical, and practical apparatus and methods fulfilling the other 20 objects of the invention.
21 Other objects, features, and advantages of the present invention will be appreciated 22 when the present description and appended claims are read in conjunction with the drawing 7 figures.
BRIEF DESCRIPTION OF THE DR~WING FIGURES
24 It will be appreciated that the figures 39, 42, 43, 44, 45 and 46 are part of the 25 description of a first p~efe-- ed embodiment and that all other figures are part of the tS description of a second preferred embodiment.
r 213 Fig. l shows a combination block and functional diagram of a preferred embodiment 29 of a multi-purpose transaction card system involving four groupings of parties, in 30 accordance with the tP~chingc ofthe present invention, W O96/25814 PCTrUS95101765 ~ Fig. ' shows a combination block and functional diagram of a one time sign~tl~re 2 structure called a house, in accordance with the teachings of the present invention;
.. Fig. 3 shows a combination block and functional diagram of a first preferred compact 4 endorsement signature structure called a town, in accordance with the teachings of the s present invention;
Fig. 4 shows a combination block and functional diagram of a second prefelled 7 compact endorsement signature structure called a town, in accordance with the te~hin~c 8 of the present invention, which is believed to allow an efficient implementation;
9 Fig. 5 shows a combination block and functional diagram of a prt:rel I ed exemplary 10 embodiment of a compact endorsement Sjgn~ture structure called a town, in accordance with the teachings of the present invention;
12 Fig. 6 is a block diagram showing exemplary data elements and control elements that 13 are signed using a one time sign~tllre structure of Fig. '~, in accordance with the te~çhingc 14 of the present invention, in a way which is believed to enhance security;
Fig. 7 shows a combination block and functional diagram of a public key verifying 16 party, in accordance with the teachings of the present invention;
17 Fig. 8 shows a flowchart of a preferred embodiment of a card cancel process in 1B accordance with the teachingc ofthe present invention, which, together with Fig. 13, 14, 19 15, 16, 17, 18 and 19 is believed to implement a secure data storage system of said card, 20 and which, in particular, when executed at the end of a session is believed to rollback all the 21 results on the card non-volatile memory of said session;
22 Fig. 9 shows a combination block and functional diagram of a pl ~rt;" ~d exemplary 23 embodiment of a one time sign~ture structure called a house in accordance with the 24 te~chingc of the present invention;
Fig. 10 shows a combination block and functional diagram of a public key issuing 26 party, in accordance with the teachings of the present invention;
27 Fig. 1 I shows a block and functional diagram of a non-volatile memory model in 2r. accordance with the te~chings of the present invention, which is believed to describe the ~ 29 write and erase behaviour of most types of non-volatile memory used in the art, in 3~ particular the write and erase behaviour of EEPROM;
31 Fig. 1'~ is a block diagram showing the use of volatile and non-volatile memory in a 32 preferred embodiment of a card in accordance with the te~chin~gc of the present invention;
-CA 022l8l78 l997-08-08 WO96/25814 PCTrUS9~J~1765 _g_ Fig. 13 shows a flowchart of a preferred embodiment of a card start update process, 2 in accordance with the teachingc of the present invention, which, together with Fig. 8, 14, 3 1 5, 16, 17, 18 and 19 is believed to implement a secure data storage system of said card;
4 Fig. 14 shows a flowchart of a preferred embodiment of a card delete frame[i]
s process in accordance with the te~ching~ of the present invention, which, together with Fig.
6 8, 13, 1~, 16, 17, 18 and 19 is believed to implement a secure data storage system of said 7 card;
8 Fig. 15 shows a flowchart of a p. ~fel, ed embodirnent of a card write 9 frame[t,access,data] process in accordance with the teaçhin~c of the present invention, .o which, together with Fig. 8, 13, 14, 16, 17, 18 and 19 is believed to implement a secure data storage system of said card;
12 Fig. 16 shows a flowchart of a preferred embodiment of a card reset process in 13 accordance with the te~chingc ofthe present invention, which, together with Fig. 8, 13, 14, 14 15, 17, 18 and 19 is believed to implement a secure data storage system of said card;
~s Fig. 17 shows a flowchart of a preferred embodiment of a card commit process in 6 accordance with the te~çhingc of the present invention, which, together with Fig. 8, 13, 14, ~7 15, 16, 18 and 19 is believed to implement a secure data storage system of said card;
8 Fig. 18 shows a flowchart of a p- ~fe, red embodiment of a card find frame[t] process 19 in accordance with the te~chingc of the present invention, which, together with Fig. 8, 13, zo 14, 15, 16, 17, and 19 is believed to implement a secure data storage system of said card;
21 Fig. 19 shows a flowchart of a pl efe, I ed embodiment of a card read frame[t] process Z2 in accordance with the te~hingc ofthe present invention, which, together with Fig. 8, 13, 23 14, 15, 16, 17, and 18 is believed to implement a secure data jtorage system of said card;
2~ Fig. 20 is a combination block and functional diagram showing mech~nicmc of 25 encrypting data with a session-state and çh~ining data in said session-state chain and 26 decrypting data with said session-state and chaininsg data in said session-state, in Z7 accordance with the teaçhingc ofthe present invention;
28 Fig. 21 is a combination block and functional diagram showing the mech~nism of 29 'crypting' data with a session-state and çh~ining data in said session-state as performed in 3~ the preferred embodiment of a card, and the mechanism of 'crypting' data with said 31 session-state and ~h~ining data in said session-state as performed in the ple~"ed 3Z embodiment of a terminal, in accordance with the t~achingc of the present invention, which 33 are believed to implement an encrypt decrypt pair, as shown in Fig. 20;
W O 96/25814 PC~r~US95/01765 Fig. '~'' is a combination block and fi~nctional diagram showing a preferred exemplary 2 impl~ment~tion of a mechanism of 'crypting' data with a session-state and chaining data in 3 said session-state as performed in a preferred embodiment of a card, in accordance with the ~ tç~chingc of the present invention. which, together with the rneçh~nicrn showed in Fig. 23, s are believed to implement the mech~nicmc as shown in Fig. 21;
Fig. 23 is a combination block and functional diagram showing a preferred exemplary 7 implementation ofthe meGh~nism of'cryptin~ data with a session-state and çh~inin~ data B in said session-state as performed in a preferred embodiment of a terminal, in accordance 9 with the teachings of the present invention, which, together with the meçh~nicm showed in .0 Fig. ~2, are believed to implement the mechanisms as shown in Fig. 21;
~. Fig. 24 shows a flowchart of a process called 'session' which involves a card and a 12 terminal in a preferred embodiment, in accordance with the teachings of the present 13 invention;
14 Fig. 25 shows a flowchart of a detail process called 'start session and proof keys', 15 involving actions by a terminal, actions by a card and communication between said card and .~ said terminal, in accordance with the teachings of the present invention, which, together 17 with Fig. 26 and 27 are believed to implement the process of Fig. 24;
lB Fig. 26 shows a flowchart of a detail process called 'command and exchange data', 19 involving actions by a terminal, actions by a card and communication between said card and 20 said terminal, in accordance with the teachings of the present invention, which, together 21 with Fig. 26 and ''7 are believed to implement the process of Fig. 24;
22 Fig. 27 shows a flowchart of a detail process called 'commit session and end session', 23 involving actions by a terminal, actions by a card and communication between said card and 2- said terminal, in accordance with the teaçhingc of the present invention, which, together 25 with Fig. 26 and 27 is believed to implement the process of Fig. 24;
2B Fig. ''8 shows a flowchart of an EMV transaction process, involving actions by a 27 terminal, actions by a card, actions by an issuer and communication between said card and 21~ said terminal and between said terminal and said issuer in a preferred embodiment, in 29 accordance with the teachingc of the present invention;
Fig. 29 is a flowchart showing all possible succ~ssfill executable series of comm~n~ls, 31 issued by a terminal and performed by a card in a preferred embodiment, in accordance 32 with the teachings of the present invention;
W O 96/25814 PC~nUS95/01765 Fig. 30 shows a flowchart of a Commit-Challenge-Response process involving 2 actions by a terminal, actions by a card and communication between said card and said 3 terminal, in accordance with the tearhingc of the present invention;
Fig. 31 shows a flowchart of a non single execution path process and a single execu-s tion path process, both acsivning values to variables depending on a conditional in accordance with the te~chingc of the present invention, which are believed to have the same 7 result on the assigned variables;
8 Fig. 32 shows a flowchart of a 'Get Proof' process in a preferred embodiment, 9 involving actions by a terminal, actions by a card and communication between said card and ~o said terminal, in accordance with the teachingc of the present invention;
Fig. 33 shows a flowchart of a process of performing a 'script' in a pr~re~ t;d embodi-2 ment, involving actions by a terminal, actions by a card and communication between said ~3 card and said terminal, in accordance with the teachingc of the present invention;
.4 Fig. 34 shows five detail flowcharts of processes called 'start session 1', 'start session 2', 'get frame', 'put frame' and 'kill frame' in a preferred embodiment, involving actions by ~~ a terminal, actions by a card and communication between said card and said terminal, in 17 accordance with the teachingc of the present invention in accordance with the teachingc of 18 the present invention;
lD Fig. 35 shows five detail flowcharts of processes called 'debit frame', 'redebit frame', 20 'public debit', 'commit' and 'done' in a preferred embodiment, involving actions by a 21 terminal, actions by a card and communication between said card and said terminal, in 22 accordance with the teachinQc of the present invention in accordance with the teachingc of 23 the present invention;
24 Fig. 36 shows five detail flowcharts of processes called 'get proof', 'select file', 25 'manage application 1', 'manage application '" and 'get data' in a prefe"ed embodiment, 26 involvin;, actions by a terminal, actions by a card and communication between said card and 27 said terminal, in accordance with the teac~lingc of the present invention in accordance with 2a the teachingc of the present invention;
29 Fig. 37 shows five detail flowcharts of processes called 'get file', 'generate AC 1', 30 'generate AC 2', 'external ~lthentic~te' and 'verify' in a p,ere"ed embodiment, involving 31 actions by a terminal, actions by a card and communication between said card and said 32 terminal, in accordance with the teachingc of the present invention in accordance with the 33 teachinsgc of the present invention;
CA 022l8l78 l997-08-08 W O96/25811 PCTrUS95/01765 Fig. 38 shows a detail flowchart of a process called 'get last AC' in a p, efel led 2 embodiment, involving actions by a terminal, actions by a card and communication between 3 said card and said terminal, in accordance with the te~chin~c of the present invention in 4 accordance with the teachingc of the present invention;
Fig. 39 shows a combination block and functional diagram of a preferred embodiment of a compact endorsement sign~t~re system involving four sets of parties in accordance 7 with the teachings of the present invention;
Fig. 40 shows the non-volatile memory contents in accordance with the te~chin~c of 9 the present invention of the preferred exemplary compact endorsement sign~t~lre structure o of Fig. 5 by means of a tabular arrangement of town values, notations and actions;
Fig. 41 shows the operational steps in accordance with the te~chin~c ofthe present 12 invention of the preferred exemplary compact endorsement signature structure of Fig. S by 13 means of a tabular arrangement of town values, notations and actions;
14 Fig. 4'' shows a combination block and functional diagram of an exemplary embodi-.s ment of an endorser party in accordance with the teachings of the present invention;
Fig. 43 shows a flowchart of a general endorsement scheme process in accordance 17 with the te~chingc of the present invention;
18 Fig. 44 shows an exemplary one-time signature structure in accordance with the 19 teachings of the present invention;
Fig. 45 shows a preferred exemplary endorsement structure in accordance with the 21 te~chingc of the present invention, in which Fig. 45a-45d are exemplary first level cascade 22 structures and Fig. 45e is an exemplary second level cascade structure;
23 Fig. 46 shows the operational steps in accordance with the te~chin~c of the present 24 invention of the exemplary structures of Fig. 45 by means of a tabular arrangement of 25 registers names and notations;
2~ Fig. 47 shows a combination block and functional diagram of the interaction between 27 a card and the issuer in the preferred embodiment of a system like Fig. 1, with details added 28 to card entity concerning some registers, and details added to the issuer entity concerning 29 m~int~ined databases in accordance with the te~chingc of the present invention;
3~ Fig. 4~ shows a block diagram of a plere. Ied embodiment of a record in a card 31 database of Fig 47 in accordance with the teachinSgc of the present invention;
32 Fig. 49 shows a block diagram of a p, erel I ed embodiment of a record in a event 33 ~t~bace of Fig 47 in accordance with the te~chingc of the present invention;
_ CA 022l8l78 l997-08-08 WO 96/2~814 PC'rJ~'S9SJ~)176S
~ Fig. 50 shows a flowchart of a preferred embodiment of a issuer process that mainly 2 synchronizes the issuers known balance with a card balance during an on-line transaction, 3 in accordance with the teachingc of the present invention;
Fig. 51 shows a flowchart of a prefe- ~ ed embodiment of a issuer process that mainly s synchronizes the issuers known balance with a card balance during the clearing process of off-line transactions, in accordance with the teachingc of the present invention;
7 Fig. 52 shows a flowchart of an exemplary implementation of the process Fig. 50, in 8 accordance with the teaçhin~ of the present invention; and g Fig. 53 shows a flowchart of an exemplary implçment~tion ofthe process Fig. 51, in .o accordance with the teaching of the present invention.
BRIEF SUMMARY OF THE rNVENTION
In accordance with the forgoing and other objects of the present invention, a brief .2 summary of some exemplary embodiments will now be presented. Some simplifications and 3 omissions may be made in this summary, which is intended to highlight and introduce some 4 aspects of ~h~ p~eser~ nti~n, b~t n~t t~ lim.~it~cop~r.~way. Detailed descr,ptions of prefe. . ed exemplary embodiments adequate tO allow those of ordinary skill in the art to 16 make and use the inventive concepts are provided later.
., An endorsement scheme that allows preferably hundreds of endorsements to be 8 stored in less than a thousand bytes on a simple microcontroller smart card would be 1~ commercially intel e~ g, but cannot be achieved by techniques known in the prior art. The present invention overcomes these limitations of the prior art.
21 The inventive concept provides hierarchical structuring of multiple one-time 22 Sipn~tures within a single public key sign~ture. The hierarchy is formed from comp~essillg 23 one-way functions, also sometimes known as hash or message digest functions, serving as 2~ the internal '~nodes" in a special tree structure. The tree's "leaves" are the one-time 2s signatures and its "edges" are values that are inputs and sometimes outputs of the compression functions. Thus the root represents the final compression of all the one-time 27 signatures in the structure, and the output of this compression is signed by the digital 28 siSJn~t~re technique.
29 Each endorsement involves a subset of the tree including the single one-time 30 sign~t~-re that is used in, and only in, that endorsement. Also in the subset is the public key W O96/2581~ PCT~US95/01765 ~ signature and a path of edges from the leaf to the root. The values represented by all edges 2 incident on the nodes of the path, apart from those edges on the path, are included.
3 The endorsements are made in an order that, in cooperation with the structuring, lets 4 the card use a relatively small number of non-volatile registers at each stage. Furthermore, s the amount of computation required between each endorsement is also limited to a small s amount. Moreover, stepping from the last one-time sign~tl~re in one digital cign~ture to the first ofthe next digital sign~tllre requires esslonti~lly only the same resources as stepping 8 between any two one-time signatures within the same digital signature.
9 One of the particular preferred embodiments, which is disclosed in detail later, uses a tO "c~cc~rle" of two-argument co,-" resshlg functions as a building block. The first ~- col"p, essing function in the cascade takes two inputs from outside the cascade. All 12 subsequent compresses in the cascade take one argument from the previous compress and 13 one from outside the cascade. Thus, with only an output of one compress in a cascade 14 along with all subsequent inputs to the c~scadto7 the output of the entire c~c~de can be ~s verified.
16 The cascades are structured into a low hierarchy, preferably only two high, although ~7 any hierarchy could be used. The c~cc~r~es at the low level, called "streets," take their .~ inputs directly from one-time signatures, called "houses." The cascades at the higher level, 19 called "towns," take their inputs from the outputs of the cascades at the lower level. Thus, 20 a complete ordering is imposed on the houses of a street and the streets of a town.
21 Roughly stated, in the pl ~r~l I ed embodiment, the endorsements may be thought of as zz proceeding from house to house in order. When a house is visited, its one-time sign~tl~re is 23 used in an endorsement. In addition to this "actual" traversal for endorsements, there are 2~ two "preparatory" traversals conducted in parallel.
The first preparatory traversal moves down the next street visiting almost all the zs houses. (If there is a next street in the current town ordering, this is traversed; if there are 27 no more streets in the current town, then the first street in the next town is traversed). The z~ purpose of the first preparatory traversal is to obtain and store the leaf edges for a street so 29 that they are ready when that street is entered and the first house is used in an endorsement.
The second preparatory traversal moves through the next town. The purpose of this 31 traversal is to obtain and store the edges coming from all the streets of the next town, 32 except the first street. These will be needed in endorsernçnt~ when the new town is initially 33 entered by the actual traversal and endorsements are coming from its first street.
WO 96/25811 PCTnUS9SJ~176S
Tamper resistant devices o~en store some information in non-volatile memory. The 2 preferred embodiment is capable of atomic multi-updates allowing several modifications in 3 the non-volatile memory to be done all at once, even under arbitrary interruptions. Secrecy 4 of critical data is m~int~ined under attacks involving UV irradiation of the smart card chip, s while at the same time allowing recovery in the case of technical failures.
Sessions are introduced which cryptographically link the actions that make up a 7 transaction, ensuring that the con.~titl~ont actions are all performed in order and without any 8 other actions in-between. The sessions also provide a single proof system for an entire 9 transaction, elimin~ting the need for speci~li7~d elementary actions for specific transactions.
~O Even under arbitrary interruption the sessions ensure that either the transaction is completed and the cryptographic proofs exchanged properly, or the transaction is not 12 executed at all.
13 In the preferred embodiment the tamper-resistant device does not reveal any informa-~~ tion to the terminal in addition to the information explicitly communicated with the 15 ter,ninal, even if the terminal performs any or all of a general set of additional ~ measurements on the card while it is in operation.
17 Several clearing methods are described which allow adequate clearing and settlement 18 of fin~nri~l and other transactions to occur without the need for a tamper-resistant device ~9 in the terminal or the need to communicate full transaction data form the terminal to the 20 acquirer/issuer.
21 The EMV system is extended and generalized. The terminal's interests are properly 22 protected by inrl~ding a proper off-line ~thentication of the transaction data. The EMV
. system is generalized to provide all the functions needed for implernent~tion of a wide 24 variety of payment applications.
DETAILED DESCRIPTION OF PE~EFERRED EMl~.ODIME~TS
The drawing figures and the detailed descriptions provided later make a number of 28 simplifying assumptions for concreteness and for clarity in exposition. It will be ~ appreciated, however, that these should not be taken to limit the scope of the invention.
28 Some lines and arrows in the drawing figures represent messages, which may be held 29 initially or delayed on their way, passed through various parties, encoded and decoded 30 cryptographically or otherwise to provide their authenticity and/or secrecy and/or error 31 detection and/or error recovery. Thus the particular means or methods whereby mçss~ges O96/25814 PCTrUS95/01765 ~ are transferred are not essential to the present invention, and it is anticipated that any 2 technique may be employed in this regard.
3 As will be appreciated, someone of ordinary skill in the art would be familiar with Bruce Schneier 1994 "Applied Cryptography, Protocols, Algorithms, and Source Code in s C" and with the references contained therein. As will also be appreciated, someone of
5 ordinary skill in the art would be familiar with Donald E. Knuth 1981, "The art of computer 7 programming" parts 1 "Fundamental algorithms" and '"'Seminumerical algorithms", and with the references contained therein.
9 Some background on the parameter values that are believed to apply, as will be O appreciated, serves as a basis for some of the tradeoffs made in the preferred embodiment.
A typical user transaction should, it is believed, not introduce more than roughly a 12 second of delay if it is to be perceived as acceptably fast. Of course, highway-speed road 13 tolls, and even mass transit situations, may require substantially faster transactions. The 14 endorsement signatures are well suited to such high-speed transaction, as has been illustrated in the second above included reference.
16 An RSA signature today is minim~lly 64 bytes. Other digital cign~tl~res might be one 17 third the size. The output of a co",pressing one-way or hash function is typically 16 bytes.
~ A one-way function input or output can typically be 8 bytes. A smart card of one kilobyte 19 non-volatile memory, already mentioned as a currently commercially interesting target for 20 the invention, typically has various competing uses for its non-volatile storage. It is 21 believed that less than the whole amount would be available for storage of Cign~tllres and 22 other values needed in endorsement. Examples include identification data related to 23 m~nl-f~ct--ring and distribution, cryptographic keys for securing communication with an .1 issuer, registers to hold card balance(s), transaction records, public key certificates of the 25 issuer, key validity data, and so forth.
A blocl;cipher operation that might typically be used in constructing a one-way 27 function can, it is believed, typically be done by a smart-card microcontroller between 100 25 and 400 times per second, depending on a variety of factors. At least several applications of 29 such a blockcipher are anticipated to be required to implement a hash or compression 0 function. A reading device can use special circuitry to compute blockciphers, it is believed, 31 about two orders of m~~nitude faster.
WO 9612C.81~ PC'r~US95~0~765 Transmission of data between a smart card and the reading device is believed 2 typically to be at about 1000 bytes per second, but can be sped up by at least a factor of 4 3 under some standard protocols.
Some general notions regarding cryptographic tech liques will now be pres.onted s Assigning a variable a "random" value performs the function of creating a value that
9 Some background on the parameter values that are believed to apply, as will be O appreciated, serves as a basis for some of the tradeoffs made in the preferred embodiment.
A typical user transaction should, it is believed, not introduce more than roughly a 12 second of delay if it is to be perceived as acceptably fast. Of course, highway-speed road 13 tolls, and even mass transit situations, may require substantially faster transactions. The 14 endorsement signatures are well suited to such high-speed transaction, as has been illustrated in the second above included reference.
16 An RSA signature today is minim~lly 64 bytes. Other digital cign~tl~res might be one 17 third the size. The output of a co",pressing one-way or hash function is typically 16 bytes.
~ A one-way function input or output can typically be 8 bytes. A smart card of one kilobyte 19 non-volatile memory, already mentioned as a currently commercially interesting target for 20 the invention, typically has various competing uses for its non-volatile storage. It is 21 believed that less than the whole amount would be available for storage of Cign~tllres and 22 other values needed in endorsement. Examples include identification data related to 23 m~nl-f~ct--ring and distribution, cryptographic keys for securing communication with an .1 issuer, registers to hold card balance(s), transaction records, public key certificates of the 25 issuer, key validity data, and so forth.
A blocl;cipher operation that might typically be used in constructing a one-way 27 function can, it is believed, typically be done by a smart-card microcontroller between 100 25 and 400 times per second, depending on a variety of factors. At least several applications of 29 such a blockcipher are anticipated to be required to implement a hash or compression 0 function. A reading device can use special circuitry to compute blockciphers, it is believed, 31 about two orders of m~~nitude faster.
WO 9612C.81~ PC'r~US95~0~765 Transmission of data between a smart card and the reading device is believed 2 typically to be at about 1000 bytes per second, but can be sped up by at least a factor of 4 3 under some standard protocols.
Some general notions regarding cryptographic tech liques will now be pres.onted s Assigning a variable a "random" value performs the function of creating a value that
6 should not be readily determined by at least some party. Many means and methods are
7 known in the art for generating such unpredictable quantities, often called keys. Some are
8 based on physical phenomena, such as noise in semiconductors, or patterns detected in
9 h~ nc pushing buttons, or possibly deterministic cryptographic techniques sometimes
10 called pseudorandom generators. It is well known in the art that these various techniques
11 can often be combined, and that post-processing can often improve the results. Thus the
12 particular means or methods whereby random values are derived is not esse~tti~l to the
13 present invention, and it is anticipated that any technique may be employed in this regard.
14 A "compression" function, as has already described, is an example of a technique .s very well known in the art as a hash or message digest function. Such a function takes an 16 input larger than its output. It is believed computationally prohibitive, given the output, to 17 find back any input that would yield it, even if some of the inputs are known.
18 The term "party" is used herein to indicate an entity with control over at least the 19 secrecy of some information, usually at least one key. It is anticipated that a plurality of 20 people may each know all or in effect part of some key, and they might be thought of 21 collectively as a party. In other cases, a key may be substantially unknown to people, and 22 reside in some physical device, and then the device itself or those who control it from time a to time may be regarded as parties.
2~ The method or means whereby information is Ll ~naçell ed between parties is not 25 essenti~l to the present invention, and may be accomplished in any suitable way. For 26 instance, output and input means may be brought into physical proximity with each other, 27 or they may communicate remotely by any kind of communication network or technique.
28 The information may be encoded in various forms, some of them cryptographic, and 29 decoded and transformed between coding on its way. Similarly the information may be 30 stored and/or det~inecl in various forms and by various parties along the way.
31 The choice of party names, forms, and the number of parties are examples of choices 32 made for clarity and convenience. Naturally, the inventive concepts disclosed here should WO96/25814 CA 02218178 1997-~8-~8 PCT/US95/0176~i ~ not be interpreted as limited to a particular type, grouping, or multiplicity of parties nor 2 should there be any other implications of naming conventions or the like.
3 Turning now to figure 39, general descriptions of the interconnections and~ cooperation of the conctit-lent parts of some exemplary embodiments of the inventive s concepts will now be presented.
s Signature issuer party 3941, referred to for simplicity as the issuer, has at least a 7 private key. A corresponding public key is made known at least to endorsee 3943 (as will 8 be more fully described) and to any additional verifiers 3944.
9 Signature transporter and endorser party 3942, herein referred to simply as endorser, .0 receives the signatures from issuer 3941 as shown by line 3951. Endorsee and verifier .. 3943, referred to for simplicity as endorsee 3943, receives an endorsement from endorser 12 3942 as indicated by line 3952. Additional verifier 3944 may also verify the endorsement, t3 shown for simplicity as coming form endorsee over line 3953.
~~ As will be appreciated, but is not shown for clarity, there may be plural instances of each party type. For example, there may be multiple endorsers, each endorsing signatures ~~ issued by the same issuer. There may be multiple endorsees, each capable of receiving an 17 endorsement from any one of plural endorsers. There may be multiple additional verifiers, 1~ any one of which may be capable of verifying endorsements received from plural endorsees 19 or others. Moreover, there may be plural issuers, some of which are capable of issuing 20 identical signatures as well as others of which that are not.
21 Each signature is related to a message, the origin of which is not essential to the 22 inventive concepts. Messages could, for example, come from the issuer 3941, the endorser 23 3942, endorsee 3943, or verifier 3944, random sources, external events, or co.,.binations of 24 these. Any of the aforementioned parties may be aware of the message before they 25 cooperate in an endorsement, or one or the other of them may supply all or parts of the 2~ message to the other, which is not being shown for clarity.
2't Turning now to figure 42, general descriptions of the interconnections and a cooperation of the constituent parts of some exemplary embodiments of the inventive 29 concepts will now be presented for endorser 3942.
WO 96/25814 PCTnUS9~76 t A smart card 4200 or other portable data carrier, as will be appreciated, may perform 2 the role of endorser 3941. It may be considered to be composed of several interconnected 3 parts. The i/o interface 4201 communicates with the outside world, such as issuer 3941 and endorsee 3943 through interface link 4206~ which may be galvanic contacts or contactless 5 technology, as are well known in the smart card art. Also there may be special circuits or firrnware for computing cryptographic functions 4204. Furthermore, control means 4202 7 manages the operation and coordination of the other parts. Most important for the present purposes are registers 4203 for storing values. These may be regarded as of two types, 9 nonvolatile and temporary. All these components may cooperate together and/or with the ~o i/o interface ~1201, through mutual interconnection means shown for simplicity as bus 4205.
An example embodiment would be in the Motorola SC-24 smart card chip, or near ~z equivalents m~nllf~ctured by Thompson Semiconductors for inct~ncP, and these may be 13 embedded in industry standard smart cards.
14 Turning now to figure 43, general descriptions of the function and process steps of ~s some exemplary embodiments of the inventive concepts will now be given.
~6 The first step, as shown by flowchart box 4301, is the issuing of a compact endorse-~7 ment signature by the issuer 3941 to the endorser 3942. This entails creating in turn all the ~8 houses and the edges. Then a digital signature is formed on the root output as already 9 described. Although not shown explicitly for clarity, it will be understood that blind Sign~tllre techniques could be used in the issuing process. For instance, it will be readily - understood by those of skill in the art, an intermediary party not shown for clarity could 22 form the one-time signatures and compression tree, provide it to a signer in a blinded form, 3 and supply an unblinded form of the result to the endorser. Related techniques are also 24 disclosed in the second above included reference.
Dashed box 4302 shows the endorse function. One component is box 4321 which forms a one-time sipn~t~re that corresponds to the message. This is done by developing 27 each digit to the point in the c~cc~rle required to encode the part of the message or the ~ control, as is well known in the one-time signature art and as will also be described in more 29 detail with reference to figure 44. This signature is given from the endorser to the endorsee 30 3943 for verification. The transfer of at least the edges needed to verify the signature, as -W O96/25814 PCTrUS95/01765 already mentioned, is shown in box 4322. The digital signature is also provided from the 2 endorser to the endorsee as shown in box 4323.
3 Dashed box 4303 represents the verification function performed by the endorsee on 4 the compact endorsement signature provided as a result of the already mentioned dashed s box 4302. First the one-time signature is shown as expanded in box 4331, which would for 5 instance be the form with the most applications of the one-way function(s) applied. The 7 result of this can then be used together with the edges supplied in box 4322, already 8 mentioned, to traverse by application of compression function nodes all the way to the 9 root. This results in the value upon which the digital signature mentioned already with ~O reference to box 4321iS checked, as shown in box 4333. The signature need not be the ~~ type known in the art as that allowing "message recovery," since the edges of the 12 compression tree are provided. Of course if the signature verifies, then the endorsee 13 accepts it, otherwise not.
14 Dashed box 4304 depicts the preparation process. It may involve substantial
18 The term "party" is used herein to indicate an entity with control over at least the 19 secrecy of some information, usually at least one key. It is anticipated that a plurality of 20 people may each know all or in effect part of some key, and they might be thought of 21 collectively as a party. In other cases, a key may be substantially unknown to people, and 22 reside in some physical device, and then the device itself or those who control it from time a to time may be regarded as parties.
2~ The method or means whereby information is Ll ~naçell ed between parties is not 25 essenti~l to the present invention, and may be accomplished in any suitable way. For 26 instance, output and input means may be brought into physical proximity with each other, 27 or they may communicate remotely by any kind of communication network or technique.
28 The information may be encoded in various forms, some of them cryptographic, and 29 decoded and transformed between coding on its way. Similarly the information may be 30 stored and/or det~inecl in various forms and by various parties along the way.
31 The choice of party names, forms, and the number of parties are examples of choices 32 made for clarity and convenience. Naturally, the inventive concepts disclosed here should WO96/25814 CA 02218178 1997-~8-~8 PCT/US95/0176~i ~ not be interpreted as limited to a particular type, grouping, or multiplicity of parties nor 2 should there be any other implications of naming conventions or the like.
3 Turning now to figure 39, general descriptions of the interconnections and~ cooperation of the conctit-lent parts of some exemplary embodiments of the inventive s concepts will now be presented.
s Signature issuer party 3941, referred to for simplicity as the issuer, has at least a 7 private key. A corresponding public key is made known at least to endorsee 3943 (as will 8 be more fully described) and to any additional verifiers 3944.
9 Signature transporter and endorser party 3942, herein referred to simply as endorser, .0 receives the signatures from issuer 3941 as shown by line 3951. Endorsee and verifier .. 3943, referred to for simplicity as endorsee 3943, receives an endorsement from endorser 12 3942 as indicated by line 3952. Additional verifier 3944 may also verify the endorsement, t3 shown for simplicity as coming form endorsee over line 3953.
~~ As will be appreciated, but is not shown for clarity, there may be plural instances of each party type. For example, there may be multiple endorsers, each endorsing signatures ~~ issued by the same issuer. There may be multiple endorsees, each capable of receiving an 17 endorsement from any one of plural endorsers. There may be multiple additional verifiers, 1~ any one of which may be capable of verifying endorsements received from plural endorsees 19 or others. Moreover, there may be plural issuers, some of which are capable of issuing 20 identical signatures as well as others of which that are not.
21 Each signature is related to a message, the origin of which is not essential to the 22 inventive concepts. Messages could, for example, come from the issuer 3941, the endorser 23 3942, endorsee 3943, or verifier 3944, random sources, external events, or co.,.binations of 24 these. Any of the aforementioned parties may be aware of the message before they 25 cooperate in an endorsement, or one or the other of them may supply all or parts of the 2~ message to the other, which is not being shown for clarity.
2't Turning now to figure 42, general descriptions of the interconnections and a cooperation of the constituent parts of some exemplary embodiments of the inventive 29 concepts will now be presented for endorser 3942.
WO 96/25814 PCTnUS9~76 t A smart card 4200 or other portable data carrier, as will be appreciated, may perform 2 the role of endorser 3941. It may be considered to be composed of several interconnected 3 parts. The i/o interface 4201 communicates with the outside world, such as issuer 3941 and endorsee 3943 through interface link 4206~ which may be galvanic contacts or contactless 5 technology, as are well known in the smart card art. Also there may be special circuits or firrnware for computing cryptographic functions 4204. Furthermore, control means 4202 7 manages the operation and coordination of the other parts. Most important for the present purposes are registers 4203 for storing values. These may be regarded as of two types, 9 nonvolatile and temporary. All these components may cooperate together and/or with the ~o i/o interface ~1201, through mutual interconnection means shown for simplicity as bus 4205.
An example embodiment would be in the Motorola SC-24 smart card chip, or near ~z equivalents m~nllf~ctured by Thompson Semiconductors for inct~ncP, and these may be 13 embedded in industry standard smart cards.
14 Turning now to figure 43, general descriptions of the function and process steps of ~s some exemplary embodiments of the inventive concepts will now be given.
~6 The first step, as shown by flowchart box 4301, is the issuing of a compact endorse-~7 ment signature by the issuer 3941 to the endorser 3942. This entails creating in turn all the ~8 houses and the edges. Then a digital signature is formed on the root output as already 9 described. Although not shown explicitly for clarity, it will be understood that blind Sign~tllre techniques could be used in the issuing process. For instance, it will be readily - understood by those of skill in the art, an intermediary party not shown for clarity could 22 form the one-time signatures and compression tree, provide it to a signer in a blinded form, 3 and supply an unblinded form of the result to the endorser. Related techniques are also 24 disclosed in the second above included reference.
Dashed box 4302 shows the endorse function. One component is box 4321 which forms a one-time sipn~t~re that corresponds to the message. This is done by developing 27 each digit to the point in the c~cc~rle required to encode the part of the message or the ~ control, as is well known in the one-time signature art and as will also be described in more 29 detail with reference to figure 44. This signature is given from the endorser to the endorsee 30 3943 for verification. The transfer of at least the edges needed to verify the signature, as -W O96/25814 PCTrUS95/01765 already mentioned, is shown in box 4322. The digital signature is also provided from the 2 endorser to the endorsee as shown in box 4323.
3 Dashed box 4303 represents the verification function performed by the endorsee on 4 the compact endorsement signature provided as a result of the already mentioned dashed s box 4302. First the one-time signature is shown as expanded in box 4331, which would for 5 instance be the form with the most applications of the one-way function(s) applied. The 7 result of this can then be used together with the edges supplied in box 4322, already 8 mentioned, to traverse by application of compression function nodes all the way to the 9 root. This results in the value upon which the digital signature mentioned already with ~O reference to box 4321iS checked, as shown in box 4333. The signature need not be the ~~ type known in the art as that allowing "message recovery," since the edges of the 12 compression tree are provided. Of course if the signature verifies, then the endorsee 13 accepts it, otherwise not.
14 Dashed box 4304 depicts the preparation process. It may involve substantial
15 computation between each endorsement, but it may also involve no computation, as
16 indicated by the straight through return path. One aspect of preparation, indicated by box
17 4341, entails evaluating houses. These may for instance, and as already mentioned, be in ~~ the next street or town. When houses are fully evaluated the results will serve as input 19 edges to conl})res~ion nodes, as already mentioned. Box 4342 depicts the com~,ression of 20 edges and the saving in registers of the results, which may free up the need to store 21 involved input registers or house outputs. Also as non-volatile storage becomes available to 22 store new values, the old values should be erased or at least written over by the new values, 23 as indicated by box 4343.
24 As would be appreciated by those of ordinary skill in the art, these various 25 plt:palaLion steps could be performed at various times and in various orders without 25 departing from the spirit of the present invention. For inct~rlc~7 in some settings the 27 preparation may produce exactly what is needed for the next endorsement; in other cases, 28 some preparation for a number of future endorsements may be made whenever there is time 29 to do so. ~Ithough such preparation for future endorsements is not shown explicitly for 30 clarity, it will be understood that employing some extra registers and storing in them the 31 values that would be calculated some steps in advance, allows for such steps to be taken 32 without requiring pl epal alion~
W O 96/25814 PCTnDS~S~1765 Preparation may be made just before an endorsement or jUSt a~cer an endorsement or 2 during an endorsement or while the endorser is idle. Another possibility, without 3 attempting to be exhaustive, may occur subst~nti~lly soon after a signature issuing, or at 4 another time when no preparation is needed and the whole pl el)a, a~ion dashed box may be s passed through.
With reference to the above mentioned application of credit/debit card transactions 7 and the like, some novel extensions to the operàtion shown in figure 43 just described will now be disclosed that are not shown for clarity but that will be understood by those of skill D in the art.
~o Both on-line and off-line transactions are considered here. In a first type of on-line .. transaction, there may be at least a challenge issued on-line to an endorser and a response 12 back on-line from the endorser, the concept of such challenge response protocols being ~3 well known in the art. The endorser might typically be a smart card.
~~ In a second type of on-line application a transaction may comprise a single mecs~ge sent on-line from the terminal receiving the endorsing card and a single corresponding ~~ response received by the terminal on-line from a server. In this second type of transaction, 7 it will be understood by those of skill in the art that the message endorsed should contain a 8 challenge value and that this challenge value is preferably derived from a "challenge seed"
1~ subst~nti~lly at least influenced by a "modifier" sent in the subst~nti~lly previous on-line zo transaction. The seed as will be understood, could for inct~nce be ecsçnti~lly a stored value z- of the same type as would be used as a challenge in the first type of application, in which 22 case the modifier would be simply a stored challenge. Or, it could also be a value that is 23 updated in various ways, such as cryptographically, depending on the seed modifier(s) sent.
2J The seed thus allows the terminal to develop a valid challenge that would be unpredictable 25 even to someone with access to the terminal's inner workings.
2~S In either type of on-line transaction, the response should depend on the challenge and 2~ could be the endorsement as described here. Or the response could be a conventional 2D cryptographic ~uth~ontication, as are well known in the art, and the full endorsement could 29 be stored at the terminal for later forwarding or audit.
In off-line transactions, a challenge value is believed preferable that is similarly 31 unpredictable as with an on-line transaction. A terrninal that goes on-line sometimes7 it will PCT~US95/01765 096/2581~
be understood, can update its challenge seed at those times and advance its challenge 2 values through a sequence at least depending on this challenge seed. The result, it will be 3 understood, is a sequence of challenge values that is unpredictable at least across on-line transactions.
s While it is believed that the notation of figure 44 and figure 45 would be clear to 6 those of ordinary skill in the art, it is first reviewed here for definiteness. Several symbols 7 are used: circles stand for register values; house shaped blocks to be described with reference to figure 44 int1iç~te one-time signatures; round-corner rectangles symbolize 9 compression cascades; and diamond boxes are used to represent public key digital ~o signatures. The lines and arrows show the edges that define the flow of outputs to inputs;
arrows entering or leaving a diagram of course show the inputs or outputs, respectively, of 2 the diagram.
3 The notation of figure 46 is a tabular arrangement of numbers and special symbols, the meaning of which will be described later with reference to that figure.
Turning now to figure 44, a plefe.. ed embodiment of a one-time signature structure 6 will now be described in detail.
7 House shaped box 4401 shows the one-time signature itself. Its shape is used in 8 figure 45, to be described, as an icon for the one-time signature. The particular dimensional 9 parameters, 4 inputs and 3 internal stages, are chosen as illustrations for clarity and definiteness, but such choices are not intended to limit possible values or to imply the need 1 for such a rect~ngul~r structure. Some embodiments may use smaller parameter values and 22 others larger parameter values such as, for instance, 8 by 8. There are four input values, 23 4471 through 4474. Each input is mapped by a one way function, 4411* through 4414*, to ~ produce an intermediate value 4411 through 4414, respectively. The next stage uses these s values, 4411-4414, as inputs to the one-way functions 4421* ~~42-1*, respectively, whose ~ outputs define values 4421-4424, res~cc~ ely. The final stage of one-way functions, 27 4431*-4434*, takes the values 4421-4424 as inputs and produces values 4431-4434, 28 respectively.
29 The outputs of the final stage of one-way functions are shown being compressed by a ~ hierarchy of two-input compressors for definiteness, although any suitable compressing 31 structure might be used. Values 4431 and 4432 are compressed by compressor 4451, WO 96/25814 PCTJlJS9SJ0176S
whose output feeds compressor 44~3; values 4433 and 4434 are compressed by 2 COnlpreSSOr 1452, whose output feeds the other input of col,.~),essor 4453. The output of 3 compressor 4-153 is shown as the final output 4481 of the one-time signature.
Two types of operations are performed on houses. One operation is computing there s output by tal;ing the input values 4471~474 through the chains of one-way filnctions and through the compression hierarchy just described to produce output value 4481. The other 7 operation is forming the one-time sign~ture, as depicted in box 4321 already mentioned.
a The message to be signed is taken as a set of digits, as is well known in the art, and the one-way function chain corresponding to each digit is evaluated to a depth corresponding ~o to the value of that digit. The output values corresponding to these one-way functions, one per digit, are the one-time signature.
12 Turning now to figure 45, a prefe- I ~d embodiment of a compact endorsement 13 sisgn~ture will now be described in detail. The particular dimensional parameters, 4 streets 14 each of 4 houses, has been chosen for clarity in exposition and definiteness, but such 15 choices are not intended to limit possible parameters or to imply the need for such a regular
24 As would be appreciated by those of ordinary skill in the art, these various 25 plt:palaLion steps could be performed at various times and in various orders without 25 departing from the spirit of the present invention. For inct~rlc~7 in some settings the 27 preparation may produce exactly what is needed for the next endorsement; in other cases, 28 some preparation for a number of future endorsements may be made whenever there is time 29 to do so. ~Ithough such preparation for future endorsements is not shown explicitly for 30 clarity, it will be understood that employing some extra registers and storing in them the 31 values that would be calculated some steps in advance, allows for such steps to be taken 32 without requiring pl epal alion~
W O 96/25814 PCTnDS~S~1765 Preparation may be made just before an endorsement or jUSt a~cer an endorsement or 2 during an endorsement or while the endorser is idle. Another possibility, without 3 attempting to be exhaustive, may occur subst~nti~lly soon after a signature issuing, or at 4 another time when no preparation is needed and the whole pl el)a, a~ion dashed box may be s passed through.
With reference to the above mentioned application of credit/debit card transactions 7 and the like, some novel extensions to the operàtion shown in figure 43 just described will now be disclosed that are not shown for clarity but that will be understood by those of skill D in the art.
~o Both on-line and off-line transactions are considered here. In a first type of on-line .. transaction, there may be at least a challenge issued on-line to an endorser and a response 12 back on-line from the endorser, the concept of such challenge response protocols being ~3 well known in the art. The endorser might typically be a smart card.
~~ In a second type of on-line application a transaction may comprise a single mecs~ge sent on-line from the terminal receiving the endorsing card and a single corresponding ~~ response received by the terminal on-line from a server. In this second type of transaction, 7 it will be understood by those of skill in the art that the message endorsed should contain a 8 challenge value and that this challenge value is preferably derived from a "challenge seed"
1~ subst~nti~lly at least influenced by a "modifier" sent in the subst~nti~lly previous on-line zo transaction. The seed as will be understood, could for inct~nce be ecsçnti~lly a stored value z- of the same type as would be used as a challenge in the first type of application, in which 22 case the modifier would be simply a stored challenge. Or, it could also be a value that is 23 updated in various ways, such as cryptographically, depending on the seed modifier(s) sent.
2J The seed thus allows the terminal to develop a valid challenge that would be unpredictable 25 even to someone with access to the terminal's inner workings.
2~S In either type of on-line transaction, the response should depend on the challenge and 2~ could be the endorsement as described here. Or the response could be a conventional 2D cryptographic ~uth~ontication, as are well known in the art, and the full endorsement could 29 be stored at the terminal for later forwarding or audit.
In off-line transactions, a challenge value is believed preferable that is similarly 31 unpredictable as with an on-line transaction. A terrninal that goes on-line sometimes7 it will PCT~US95/01765 096/2581~
be understood, can update its challenge seed at those times and advance its challenge 2 values through a sequence at least depending on this challenge seed. The result, it will be 3 understood, is a sequence of challenge values that is unpredictable at least across on-line transactions.
s While it is believed that the notation of figure 44 and figure 45 would be clear to 6 those of ordinary skill in the art, it is first reviewed here for definiteness. Several symbols 7 are used: circles stand for register values; house shaped blocks to be described with reference to figure 44 int1iç~te one-time signatures; round-corner rectangles symbolize 9 compression cascades; and diamond boxes are used to represent public key digital ~o signatures. The lines and arrows show the edges that define the flow of outputs to inputs;
arrows entering or leaving a diagram of course show the inputs or outputs, respectively, of 2 the diagram.
3 The notation of figure 46 is a tabular arrangement of numbers and special symbols, the meaning of which will be described later with reference to that figure.
Turning now to figure 44, a plefe.. ed embodiment of a one-time signature structure 6 will now be described in detail.
7 House shaped box 4401 shows the one-time signature itself. Its shape is used in 8 figure 45, to be described, as an icon for the one-time signature. The particular dimensional 9 parameters, 4 inputs and 3 internal stages, are chosen as illustrations for clarity and definiteness, but such choices are not intended to limit possible values or to imply the need 1 for such a rect~ngul~r structure. Some embodiments may use smaller parameter values and 22 others larger parameter values such as, for instance, 8 by 8. There are four input values, 23 4471 through 4474. Each input is mapped by a one way function, 4411* through 4414*, to ~ produce an intermediate value 4411 through 4414, respectively. The next stage uses these s values, 4411-4414, as inputs to the one-way functions 4421* ~~42-1*, respectively, whose ~ outputs define values 4421-4424, res~cc~ ely. The final stage of one-way functions, 27 4431*-4434*, takes the values 4421-4424 as inputs and produces values 4431-4434, 28 respectively.
29 The outputs of the final stage of one-way functions are shown being compressed by a ~ hierarchy of two-input compressors for definiteness, although any suitable compressing 31 structure might be used. Values 4431 and 4432 are compressed by compressor 4451, WO 96/25814 PCTJlJS9SJ0176S
whose output feeds compressor 44~3; values 4433 and 4434 are compressed by 2 COnlpreSSOr 1452, whose output feeds the other input of col,.~),essor 4453. The output of 3 compressor 4-153 is shown as the final output 4481 of the one-time signature.
Two types of operations are performed on houses. One operation is computing there s output by tal;ing the input values 4471~474 through the chains of one-way filnctions and through the compression hierarchy just described to produce output value 4481. The other 7 operation is forming the one-time sign~ture, as depicted in box 4321 already mentioned.
a The message to be signed is taken as a set of digits, as is well known in the art, and the one-way function chain corresponding to each digit is evaluated to a depth corresponding ~o to the value of that digit. The output values corresponding to these one-way functions, one per digit, are the one-time signature.
12 Turning now to figure 45, a prefe- I ~d embodiment of a compact endorsement 13 sisgn~ture will now be described in detail. The particular dimensional parameters, 4 streets 14 each of 4 houses, has been chosen for clarity in exposition and definiteness, but such 15 choices are not intended to limit possible parameters or to imply the need for such a regular
18 structure. It is believed, however, that a roughly equal number of streets and houses does 17 represent a good tradeoff. Larger parameter values, such as 8 streets of 8 houses, are 18 believed also be a suitable choice in some circumct,.nc~os.
19 The two level approach is believed best for the intended use. However, other struc-
20 tures can readily be derived from the inventive concepts disclosed here. Just to give one
21 further exemplary embodiment, although not shown explicitly for clarity, it will be
22 understood by those of skill in the art how a cascade can be split in two by a single
23 compress inserted above it, without changing substantially the computation or register
24 requirements, This would, for instance, allow the number of edPes transferred to be
25 reduced substantially.
zg Round-corner box al ** in figure 45A denotes a part of the structure referred to 27 again in figure 45e, and may be called a street of 4 houses all* through al4*, having 28 output values all through al4, respectively. Each house stands for a one-time ci~n~tllre, 21~ as has already been described with reference to figure 44. Compressor bl I * takes its inputs 30 from values all and al2 and produces output value bll. Compressor bl2* takes value 31 bll and value al3 as inputs and produces output bl2. Similarly compressor al* takes W O96125814 PCTrUS95/01765 value bl2 and al4 as inputs and produces output value to be further described with 2 reference to figure 45E.
3 In like manner, round-corner box a2** in figure 45B denotes a part ofthe structure referred to again in figure 45E, and may be called a street of 4 houses a21* through a24*, s having output values a21 through a24, respectively. Each house stands for a one-time si~n~hlre, as has already been described with reference to figure 44. Compressor b21*
takes its inputs from values a21 and a22 and produces output value b21. Compressor b22*
takes value b21 and value a23 as inputs and produces output b22. Similarly compressor 9 a2* takes value b22 and a24 as inputs and produces output value to be further described ~o with reference to figure 45E.
~- Again in the same way, round-corner box a3** in figure 45C denotes a part of the 12 structure referred to again in figure 45E, and may be called a street of 4 houses a31*
13 through a34*, having output values a31through a34, respectively. Each house stands for a ~~ one-time signature, as has already been described with reference to figure 44. Compressor 15 b31* takes its inputs from values a31 and a32 and produces output value b31. Compressor ~~ b32* takes value b31 and value a33 as inputs and produces output b32. Similarly 17 compressor a3* takes value b32 and a34 as inputs and produces output value to be further 1e described with reference to figure 45E.
19 For the final similar street, round-corner box a4** in figure 45D denotes a part of the 20 structure referred to again in figure 45E, and may be called a street of 4 houses a41*
21 through a44*, having output values a41 through a44, respectively. Each house stands for a 22 one-time sign~tllre~ as has already been described with reference to figure 44. Co~-~plessor 23 b41* takes its inputs from values a41 and a42 and produces output value b41. Co~plessor 24 b42* takes value b41 and value a43 as inputs and produces output b42. Similarly 25 compressor a4* takes value b42 and a44 as inputs and produces output value to be further 2tS described with reference to figure 45E.
27 In figure 45E, the four round-corner boxes al** through a4**, with their corre-28 sponding output values al through a4, respectively, are shown as inputs to a compression 29 tree. The first conl~r~;ssorbl* takes its input from values al and a2; its output is value bl.
Colllpressorb2* takes this output bl and combines it with value a3 to produce value b2.
31 In like fashion, compressor b3* transforms this output value b~ and value a4 into output CA 022l8l78 l997-08-08 W O96/25814 PCTnUS95J~1765 - 2~ -b3*. Finally, this output value b3 serves as message input to public key digital sign~h~re 2 producer b~* to produce compact endorsement cignAtllre b4.
3 Turning now to figure 46, the exemplary inventive structure already described with 4 reference to figure 45 will now be provided with an operational description.
s Each row of the table shown in figure 46 corresponds to a single endorsement. The s rows of the table are numbered outside the table. Each colurnn in the table corresponds to preferably nonvolatile register locations used to store values between endo- ~e~ c. The o carrot symbol "~" marks entries whose value has changed from the last row. A dot "."
9 marks the entry whose value is the output of the house used in the endorsement .0 corresponding to that row.
As will be appreciated, the first 4 columns are for clarity and convenience used to ~2 store the street edge values always in their street order positions. Only the part of the row t3 from the entry marked by the dot up until and including the fourth column are needed for 14 Ihe currem and any subsequent endorsements based on houses from the current street, ~s except for a single output from any previous endorsement of the current street. The entries .~ prece~ing the one marked by a dot are therefore largely available, are sometimes used to 17 hold intermediate values, and are ultimately prepared with the values that they will need to tB contain when the next street is entered.
~Y The last four entries in each row are used to hold the town edge values needed for 20 the current endorsement. These values, as will be appreciated, are also always stored in 2t order positions. As the streets are traversed, the early town edge values corresponding to 22 the streets currently and previously traversed no longer need to be stored. The entries that Z3 they oc~uFied ma~be used as ~er~pc~ary ~.ls f~r ~eve~,~ng and ulti-llately ho;ding ~he 24 town edge values that will be needed when the next town is entered.
For clarity in exposition, the town shown in the first rows has lower-case letters in its 2~5 reference numbers, corresponding directly with the notation of figure 45. The second town 27 shown appearing in later rows has all letters in the reference numerals shown in upper case.
2B Row I begins by showing the complete set of values for the first endorsement. Since 2~ the dot is on al 1, the first house on the first street is used in the one-time signature. As will 30 be apparent, the edge value for the first street, al, is not needed since the first street is 31 used; the hyphen symbol "-" indicates the lack of significant value held in this entry.
.
PCTrUS9S/01765 W 096/2~81~
zg Round-corner box al ** in figure 45A denotes a part of the structure referred to 27 again in figure 45e, and may be called a street of 4 houses all* through al4*, having 28 output values all through al4, respectively. Each house stands for a one-time ci~n~tllre, 21~ as has already been described with reference to figure 44. Compressor bl I * takes its inputs 30 from values all and al2 and produces output value bll. Compressor bl2* takes value 31 bll and value al3 as inputs and produces output bl2. Similarly compressor al* takes W O96125814 PCTrUS95/01765 value bl2 and al4 as inputs and produces output value to be further described with 2 reference to figure 45E.
3 In like manner, round-corner box a2** in figure 45B denotes a part ofthe structure referred to again in figure 45E, and may be called a street of 4 houses a21* through a24*, s having output values a21 through a24, respectively. Each house stands for a one-time si~n~hlre, as has already been described with reference to figure 44. Compressor b21*
takes its inputs from values a21 and a22 and produces output value b21. Compressor b22*
takes value b21 and value a23 as inputs and produces output b22. Similarly compressor 9 a2* takes value b22 and a24 as inputs and produces output value to be further described ~o with reference to figure 45E.
~- Again in the same way, round-corner box a3** in figure 45C denotes a part of the 12 structure referred to again in figure 45E, and may be called a street of 4 houses a31*
13 through a34*, having output values a31through a34, respectively. Each house stands for a ~~ one-time signature, as has already been described with reference to figure 44. Compressor 15 b31* takes its inputs from values a31 and a32 and produces output value b31. Compressor ~~ b32* takes value b31 and value a33 as inputs and produces output b32. Similarly 17 compressor a3* takes value b32 and a34 as inputs and produces output value to be further 1e described with reference to figure 45E.
19 For the final similar street, round-corner box a4** in figure 45D denotes a part of the 20 structure referred to again in figure 45E, and may be called a street of 4 houses a41*
21 through a44*, having output values a41 through a44, respectively. Each house stands for a 22 one-time sign~tllre~ as has already been described with reference to figure 44. Co~-~plessor 23 b41* takes its inputs from values a41 and a42 and produces output value b41. Co~plessor 24 b42* takes value b41 and value a43 as inputs and produces output b42. Similarly 25 compressor a4* takes value b42 and a44 as inputs and produces output value to be further 2tS described with reference to figure 45E.
27 In figure 45E, the four round-corner boxes al** through a4**, with their corre-28 sponding output values al through a4, respectively, are shown as inputs to a compression 29 tree. The first conl~r~;ssorbl* takes its input from values al and a2; its output is value bl.
Colllpressorb2* takes this output bl and combines it with value a3 to produce value b2.
31 In like fashion, compressor b3* transforms this output value b~ and value a4 into output CA 022l8l78 l997-08-08 W O96/25814 PCTnUS95J~1765 - 2~ -b3*. Finally, this output value b3 serves as message input to public key digital sign~h~re 2 producer b~* to produce compact endorsement cignAtllre b4.
3 Turning now to figure 46, the exemplary inventive structure already described with 4 reference to figure 45 will now be provided with an operational description.
s Each row of the table shown in figure 46 corresponds to a single endorsement. The s rows of the table are numbered outside the table. Each colurnn in the table corresponds to preferably nonvolatile register locations used to store values between endo- ~e~ c. The o carrot symbol "~" marks entries whose value has changed from the last row. A dot "."
9 marks the entry whose value is the output of the house used in the endorsement .0 corresponding to that row.
As will be appreciated, the first 4 columns are for clarity and convenience used to ~2 store the street edge values always in their street order positions. Only the part of the row t3 from the entry marked by the dot up until and including the fourth column are needed for 14 Ihe currem and any subsequent endorsements based on houses from the current street, ~s except for a single output from any previous endorsement of the current street. The entries .~ prece~ing the one marked by a dot are therefore largely available, are sometimes used to 17 hold intermediate values, and are ultimately prepared with the values that they will need to tB contain when the next street is entered.
~Y The last four entries in each row are used to hold the town edge values needed for 20 the current endorsement. These values, as will be appreciated, are also always stored in 2t order positions. As the streets are traversed, the early town edge values corresponding to 22 the streets currently and previously traversed no longer need to be stored. The entries that Z3 they oc~uFied ma~be used as ~er~pc~ary ~.ls f~r ~eve~,~ng and ulti-llately ho;ding ~he 24 town edge values that will be needed when the next town is entered.
For clarity in exposition, the town shown in the first rows has lower-case letters in its 2~5 reference numbers, corresponding directly with the notation of figure 45. The second town 27 shown appearing in later rows has all letters in the reference numerals shown in upper case.
2B Row I begins by showing the complete set of values for the first endorsement. Since 2~ the dot is on al 1, the first house on the first street is used in the one-time signature. As will 30 be apparent, the edge value for the first street, al, is not needed since the first street is 31 used; the hyphen symbol "-" indicates the lack of significant value held in this entry.
.
PCTrUS9S/01765 W 096/2~81~
- 26 -Row '7 shows that no changes in the register values are needed for this endorsement.
2 All column entries except the second, which corresponds to the one-time signatures used in 3 the endorsement, are explicitly transmitted by the endorser to the endorsee.
Row 3, the third endorsement, entails two changed register values, as indicated by s the carrots. The first is bl 1, which is calculated as the corllpl~s of al I and al2. Such B compressions, as will occur later as well, may be taken as example of the "advance edges"
7 function/step 4342 already described with reference to figure 43. The second, a22, is 8 preparatory for the next street, and is calculated from the second house on the next street, as also shown in figure 45B.
~o Row 4 is the final endorsement for the first street. It requires a compress of bl 1 and ~- al3 to obtain bl2. Also the value of a23 is computed from the house a23*.
t2 Row 5 is the first endorsement of the second street. The edge value a21 is shown as ~3 computed. Since an endorsement with house a21 is made, less computation is needed to 14 complete the value of this edge. This extra efficiency is the reason that the first entry is left ~s to be filled in last. The edge value al or the first street is needed at this point and it is easily ~~ calculated as the col-lpress of bl2 and al4. The value of register a24 is computed from the ~7 corresponding house. As endorsement has now moved to the second street, a2 is no longer 8 needed.
~9 Row 6 indicates evaluation but not nonvolatile storage of two houses, A21 and A22, and compressing the resulting two edge values to form B21 shown as stored.
21 Row 7 forms b21 as the con.press of a21 and a22 and stores the result in the first 22 house column. The second house column gets the edge value computed from the second 23 house on the third street. The value of B22 is computed in preparation for the second town.
2~ First the value of the third house in the second street of the second town is computed and then this is used together with the first edge value of the second street of the new town, mentioned in row 6 above, to form by compression the value B22.
2 All column entries except the second, which corresponds to the one-time signatures used in 3 the endorsement, are explicitly transmitted by the endorser to the endorsee.
Row 3, the third endorsement, entails two changed register values, as indicated by s the carrots. The first is bl 1, which is calculated as the corllpl~s of al I and al2. Such B compressions, as will occur later as well, may be taken as example of the "advance edges"
7 function/step 4342 already described with reference to figure 43. The second, a22, is 8 preparatory for the next street, and is calculated from the second house on the next street, as also shown in figure 45B.
~o Row 4 is the final endorsement for the first street. It requires a compress of bl 1 and ~- al3 to obtain bl2. Also the value of a23 is computed from the house a23*.
t2 Row 5 is the first endorsement of the second street. The edge value a21 is shown as ~3 computed. Since an endorsement with house a21 is made, less computation is needed to 14 complete the value of this edge. This extra efficiency is the reason that the first entry is left ~s to be filled in last. The edge value al or the first street is needed at this point and it is easily ~~ calculated as the col-lpress of bl2 and al4. The value of register a24 is computed from the ~7 corresponding house. As endorsement has now moved to the second street, a2 is no longer 8 needed.
~9 Row 6 indicates evaluation but not nonvolatile storage of two houses, A21 and A22, and compressing the resulting two edge values to form B21 shown as stored.
21 Row 7 forms b21 as the con.press of a21 and a22 and stores the result in the first 22 house column. The second house column gets the edge value computed from the second 23 house on the third street. The value of B22 is computed in preparation for the second town.
2~ First the value of the third house in the second street of the second town is computed and then this is used together with the first edge value of the second street of the new town, mentioned in row 6 above, to form by compression the value B22.
27 Row 8 begins by taking the first column from b21 to b''2 by colllpressil1g b21 2~ together with a73. Then a33 is computed from its house. Finally the value of edge A2 is 29 developed, first from computing A24 from its house and then con.pressillg this with B22.
Row 9 fills the first register with the edge formed from the first house on the third street. The fourth column gets the value computed from the fourth house on the third 32 street. The edge needed for sl;ipping the first two streets, bl, is formed by first , -W 096/25814 PCT~US9S~D~765 ~ compressing b22 and a24 to obtain a2 and then compressing this with al. Because 2 endorsement is now in the fourth street, a3 is no longer needed.
3 Row 10 involves constructing only the value B31 for the next town. This is the ~ compress of A31 and A32 that are each computed from their respective houses.
s Row 11 first takes the first column forward from a31 to b31 by co.. lpressi"g the former with a32. Then a42 is computed from its house and replaces the second column value. In preparation for the next town, B31 is move forward to B32 by con~pl~ssi~1g with the value of A33 computed from its house.
9 Row 1'' begins by taking b31 into b32 in the first column by compressing with a33 10 already stored. Also a43 is computed from its house and stored. Also A3 is col--p-essed ~- from B32 stored and A34 computed from its house.
12 Row 13 initially sets the first column to the value of house a41. Also house value a44 13 is put in place. To move b l to b2, first a3 is compressed from b3'' and a34, both stored and 1G then this result is compressed with b 1. Since endorsement is now in the fourth street, a4 is 15 freed.
~~ Row 14 only entails computing B41 from two values, A41 and A42, that are com-~7 puted directly from their respective houses.
8 Row 15 starts out updating a41 into b41 by colllplessing the former with a42 stored.
19 The second column is given the value of A12 computed directly. To progress B41 into B42, the value of A43 is computed directly from its house and then compressed with B41.
21 Row 16 also updates its first column by compressing the former value b41 with a43 22 stored to yield b42. By computing directly from the house, A13 is obtained. To compress 23 B42 into A4, the value of A44 is computed directly from its house.
24 Row 17 is the first endorsement from the second town. The value of A11 is computed through the endorsement and stored in the first column. And A14 is computed
Row 9 fills the first register with the edge formed from the first house on the third street. The fourth column gets the value computed from the fourth house on the third 32 street. The edge needed for sl;ipping the first two streets, bl, is formed by first , -W 096/25814 PCT~US9S~D~765 ~ compressing b22 and a24 to obtain a2 and then compressing this with al. Because 2 endorsement is now in the fourth street, a3 is no longer needed.
3 Row 10 involves constructing only the value B31 for the next town. This is the ~ compress of A31 and A32 that are each computed from their respective houses.
s Row 11 first takes the first column forward from a31 to b31 by co.. lpressi"g the former with a32. Then a42 is computed from its house and replaces the second column value. In preparation for the next town, B31 is move forward to B32 by con~pl~ssi~1g with the value of A33 computed from its house.
9 Row 1'' begins by taking b31 into b32 in the first column by compressing with a33 10 already stored. Also a43 is computed from its house and stored. Also A3 is col--p-essed ~- from B32 stored and A34 computed from its house.
12 Row 13 initially sets the first column to the value of house a41. Also house value a44 13 is put in place. To move b l to b2, first a3 is compressed from b3'' and a34, both stored and 1G then this result is compressed with b 1. Since endorsement is now in the fourth street, a4 is 15 freed.
~~ Row 14 only entails computing B41 from two values, A41 and A42, that are com-~7 puted directly from their respective houses.
8 Row 15 starts out updating a41 into b41 by colllplessing the former with a42 stored.
19 The second column is given the value of A12 computed directly. To progress B41 into B42, the value of A43 is computed directly from its house and then compressed with B41.
21 Row 16 also updates its first column by compressing the former value b41 with a43 22 stored to yield b42. By computing directly from the house, A13 is obtained. To compress 23 B42 into A4, the value of A44 is computed directly from its house.
24 Row 17 is the first endorsement from the second town. The value of A11 is computed through the endorsement and stored in the first column. And A14 is computed
28 from its house value.
27 Row 18 requires not register changes. It is identical to row 2, except that it is for the 2~ second town Thus the process between the first and second towns is ready to repeat again
27 Row 18 requires not register changes. It is identical to row 2, except that it is for the 2~ second town Thus the process between the first and second towns is ready to repeat again
29 between the second and third towns.
W O96/2581~ PCT~US95/0176 OVERV~EW
An overview of a second preferred embodiment is given in figure I . Only a single 2 issuer 101, card 102, terminal 103 and acquirer 104 are shown, but the system can contain 3 a plurality of issuers, cards, terminals and acquirers, which are not shown for clarity.
There are four entities in the system: the issuer 101, the card 102, the terminal 103 and the acquirer 104. The issuer is an org~ni7~tion, or a conglomerate of org~ni7~tions that s issues the cards and guarantees the correct operation of the card to the other participants, 7 for example, but without limitation, a bank. The card is a tamper-resistant computer device 8 that is trusted by the issuer, for example, but without limitation, a smart card. The terminal 9 iS a computing device capable of communicating with a card. The acquirer 104 is an org~ni7~tion which helps to collect the data from the terminals. The acquirer, if it is a ~- distinct entity from the issuer, typically works in close cooperation with the issuer.
12 When a card is first produced, it is typically initialized by, or on behalf of, the issuer.
13 This is called personalization, and is done using a data channel 110, 111. The ~. personalization might for example, but without limitation, involve giving the card a set of cryptographic keys and system configuration parameters. Once personalized, the card can ~s be used to perform transactions.
17 Before a transaction is made, a data channel 112, 113 is established between the card ~~ and the terminal. There are various transactions that can be performed. Many of them do ~~ not require that the card or the terminal communicate with either the issuer or the acquirer 2c during the transaction. We call those transactions "off-line". Some transactions require the 21 terminal to communicate with the issuer during the transaction. These kinds of transactions 22 are called "on-line". For these transactions a communication channel 118, 119 between the 23 terminal and the issuer is used. Some examples, without limitation, of transactions are: data 24 reading by the terminal, data writing by the terminal, payment from the card to the terminal, 2s reloading of the card with more electronic money, etc.
2s The acquirer 104 is an entity that collects information from one or more terminals, 27 and optionally handles some or all of the clearing and settlement of the transactions. For 2s this purpose, the acquirer communicates with the terminal through the communication 29 channel 114, 115, and with the issuer through communication channel 116, 117. Some
W O96/2581~ PCT~US95/0176 OVERV~EW
An overview of a second preferred embodiment is given in figure I . Only a single 2 issuer 101, card 102, terminal 103 and acquirer 104 are shown, but the system can contain 3 a plurality of issuers, cards, terminals and acquirers, which are not shown for clarity.
There are four entities in the system: the issuer 101, the card 102, the terminal 103 and the acquirer 104. The issuer is an org~ni7~tion, or a conglomerate of org~ni7~tions that s issues the cards and guarantees the correct operation of the card to the other participants, 7 for example, but without limitation, a bank. The card is a tamper-resistant computer device 8 that is trusted by the issuer, for example, but without limitation, a smart card. The terminal 9 iS a computing device capable of communicating with a card. The acquirer 104 is an org~ni7~tion which helps to collect the data from the terminals. The acquirer, if it is a ~- distinct entity from the issuer, typically works in close cooperation with the issuer.
12 When a card is first produced, it is typically initialized by, or on behalf of, the issuer.
13 This is called personalization, and is done using a data channel 110, 111. The ~. personalization might for example, but without limitation, involve giving the card a set of cryptographic keys and system configuration parameters. Once personalized, the card can ~s be used to perform transactions.
17 Before a transaction is made, a data channel 112, 113 is established between the card ~~ and the terminal. There are various transactions that can be performed. Many of them do ~~ not require that the card or the terminal communicate with either the issuer or the acquirer 2c during the transaction. We call those transactions "off-line". Some transactions require the 21 terminal to communicate with the issuer during the transaction. These kinds of transactions 22 are called "on-line". For these transactions a communication channel 118, 119 between the 23 terminal and the issuer is used. Some examples, without limitation, of transactions are: data 24 reading by the terminal, data writing by the terminal, payment from the card to the terminal, 2s reloading of the card with more electronic money, etc.
2s The acquirer 104 is an entity that collects information from one or more terminals, 27 and optionally handles some or all of the clearing and settlement of the transactions. For 2s this purpose, the acquirer communicates with the terminal through the communication 29 channel 114, 115, and with the issuer through communication channel 116, 117. Some
30 examples, but without limitation, of the functions of the acquirer are: gathering information
31 about the transactions the terminal participated in, collecting the cryptographic proofs of
32 payments from the terminals, updating system parameters in the terminals, forwarding WO 96/25814 PCTnUS95101765 ~ information regarding the fin~nci~l transactions to the issuer, collecting the money for these 2 transactions from the issuer, distributing the money received to the owners of the 3 respective terminals.
COMPACT ENDORSEMENT SIGNATURES
4 Compact endorsement signatures use disposable cryptographic elements which are 5 called "houses". Each house is used only once to sign or a~th~onticate a m~sS~e Several such houses are combined into a "town" for reasons of efficiency.
A HOUSE
7 The basic construction of a 'house' in the "ler~l I ed embodiment is shown in figure 2.
n A house consists of a starting value called the house origin 201, a set of expansion functions 202, a set of iterated oneway functions 203, an iterative cryptographic hash O function 204 and a house result value 230.
~- A house contains a plurality of columns, two of which are shown explicitly in figure 12 2. The first one consists of items 210, 211, 212, 213, 21~, 215, 216, and the second one of 13 items 220, 221, 222, 223, 224, 225, 226. The l~ J columns are represented by 208 14 and are not shown in detail for clarity.
Considering the first column, this starts with a cryptographic oneway function 210 ~~ that takes the house origin 201 as input and yields the first value in the column 211 as 17 output. This is then used as input to a chain of oneway functions. Each chain contains one 18 or more oneway functions. Only two oneway functions of the chain are shown in figure 2, 19 the rem~ining steps of the columns are not shown for clarity, and are represented by 209.
0 The first oneway function 212 takes the first column value 211 as input and yields the 21 second column value 213, which is the input to the next oneway function, etc. The last 22 oneway function in the chain 214 yields the last column value 215.
23 The iterative cryptographic hash function 204 consists of a publicly known starting 24 value 205 and a sequence of compression functions, one for each column. The starting 25 value 205 is one ofthe inputs to the conl~)lession function ofthe first column 216 that ~ takes the last column value of the last column 215 as the other input and yields the first 27 intermediate hash value. Each subsequent column ends with a co...plession function similar 28 to 216 that takes the previous intermediate hash value as one input, the last column value 9 of that column as the other input and yields the next intermediate hash value.
O96t2~814 PCTrUS95/01765 ~ The last column, consisting of 220, 221, 222, 223, 209, 224, 225, 226 is built in a 2 similar way as the first column, these items corresponding to 210, 211, 212, 213, 209, 214, 3 21S, 216 respectively. The compression function 226 of the last column takes the next to 4 last intermediate hash value as one input, the last column value of the last column 225 as s the other input and yields the final hash value 230, which is called the house result value.
s An exemplary house is shown in figure 9. The house origin value 901 corresponds to 7 value 201. The set of expansion functions 902 consists of cryptographic oneway functions 8 910, 920, 930, 940, 950, 960, 970 all of which use the house origin value 901 as an input, 9 and which yield the first value in the columns 903 (corresponding to 203): 911, 921, 931, ~o 941, 9Sl, 961 and 971 respectively. These values are used as inputs to the first oneway functions in the chains 912, 922, 932, 942, 952, 962, 972 respectively, which yield the ~2 second column values 913, 923, 933, g43, 9S3, 963, 973 respectively. These are then the 3 input values for the second oneway functions in each chain 914, 924, 934, 941, 9S4, 964, ~~ 974 respectively, which yield the third column values 91S, 925, 93S, 94S, 9SS, 965, 97S
15 respectively. These are then used as input values for the third oneway functions in each ~s column chain 916, 926, 936, 946, 9S6, 966, 976 respectively which yield the last column ~7 values 917, 927, 937, 947, 957, 967, 977 respectively. These last column values form the 8 input to the cryptographic hash function 904 (corresponding to 204), which starts with a ~9 publicly known starting value 90S which is an input to the first compression function 918 which also takes the value 917 as an input and which yields the first intermediate hash value 1 919 as a result. The first intermediate hash value 919 and the final column value of the 22 second column 927 are the inputs to the second co..")ression function 928 which yields the 23 second intermediate hash value 929. This chain continues in the same fashion with items ~ 938, 939, 948, 949, 958, 9S9, 968, 969, 978, 979 respectively. The last value 979 is the s house result value which corresponds to item 230.
26 All the cryptographic oneway functions that start a column (such as 910, g20, 930, z7 940, 9S0, 960, 970) are different, so that they yield different result values even though they ~ have the same input value. As will be described more fully later, several houses may all use 29 the same house origin value. Within a set of houses that use the same house origin value, all the cryptographic oneway functions that start a column are typically different. Furthermore, - these oneway functions are such that it is believed to be impractical to reconstruct the 32 house origin value given all the output values of these oneway functions. Such functions WO 96/25814 Pcr~ss5J0176S
are used in other systems, among others in cryptographically strong pseudo-random 2 generators, well known in the art.
3 In the preferred embodiment, the oneway functions in the column chains (such as 4 912, 914, 916, 922 etc. to 976) are all different within a house. Furthermore, within a set of s houses that use the same house origin value, all the oneway functions in the column chains are d,~-enl. Each ofthe co~ ression functions such as 918, 928, 938 etc. differs within a 7 set of houses that use the same house origin value. As will be obvious to a person B ordinarily skilled in the art, these functions can be made different in many ways, for 9 example, but without limitation, they can be made dependent on a counter which is 10 incr~omented at every fimction application, or the exact position within a house or set of ll houses could be used to differentiate the different functions. It is believed that using 12 different functions in different positions improves the security of the system.
13 The height of a column is the number of column values, which is one more then the 14 number of oneway function in the chain.
~s The house result 230 depends on the house origin 201. Even though it might involve ~~ a large number of interrnedi~te results, the result 230 can still be computed from the house 17 origin using only a fixed amount of memory, irrespective of the number of columns or the 18 height of each column. This is achieved by computing through each of the columns in turn, .~ and applying the compression function to the final value of each column before starting on 20 the next column. The details of this computation will be obvious to someone ordinarily 21 skilled in the art.
A TOWN
22 As will be described later, the house output value will be signed using a digital 23 signature scheme and the card will store that signature. To reduce the storage requi~c.l,~
24 several houses may be combined into a town, as shown in figure 3.
A town consists of a plurality of houses, three are shown in figure 3 as 321, 322, 323;
25 the rem~ining houses are not shown for clarity and are represented by 302. Each of the 27 conctituent houses of a town has a house origin value (corresponding to 201 in figure 2);
2A 311, 312, 313 are the house origin values of 321, 322, 323 respectively. Each ofthe houses 29 also has a house result value, corresponding to 230 in figure 2; 331, 332, 333 are the house 30 result values of 321, 322, 323 respectively. All the house result values are used as inputs to 31 a cryptographic hash function 340 that yields the town result value 341.
CA 022l8l78 l997-08-08 WO 96/25814 PCT/US9!j/01765 In the preferred embodiment all the houses in a town are of the same architecture:
2 they have the same number of columns, the same height for each column etc. It is believed 3 that this gives the easiest implementation.
The construction of a town in the preferred embodiment may be described recursively, as shown in figure 4. A singleton town 403 has a single constituent house 461.
6 The town origin value 460 is used as the house origin value (corresponding to 201 in figure 7 2) of the house 461. The house result value (corresponding to 230 in figure '') is the town a result value 462.
9 A general town 401 has a plurality of constituent towns, three of which are shown as o 421,422,423; the rPm~ininsg are not shown for clarity and are represented by 402. Each of the constituent towns is either a general town or a singleton town. The town origin value 2 411 is used as the town origin value for each ofthe constituent towns. A sequence of 3 compression functions is used to combine the town result values of the constituent towns ~4 and yield the town result value of the general town 453.
The town result value ofthe first constituent town 431 is the first input to a compres-6 sion function 442 that takes the town result value of the second town 432 as a second input 7 and yields the first intermediate value 452. This intermediate value is then used as the first input to the next compression function, which takes the result value of the next constituent town as a second input and yields the next intermediate value. This chain continues until the ~ last constituent town where compression function 443 takes the previous interrnediate 1 value as a first input and the town result value of the last conctit~lent town 433 as a second 22 input and yields the town result value of the general town 4S3.
23 The compression functions such as 442 and 443 are chosen in such a way that the 24 result of the chain of compress fi~nctions is a cryptographic hash function. Such iterative 25 hash functions are well known in the art.
26 In the preferred embodiment, the recursion depth used in each of the constituent 27 towns is always the same, and the number of constituent towns in a general town only 29 depends on the recursion depth. It is believed that this results in the most practical 29 implementation. Each recursion level is called a dimension, and a town with n recursion 30 levels is called an n-dimensional town. For example: a general town whose constituent - towns are all singleton towns is a one-dimensional town. A general town whose constituent 32 towns are all one-dimensional towns is a two-dimensional town, etc. This also allows an
COMPACT ENDORSEMENT SIGNATURES
4 Compact endorsement signatures use disposable cryptographic elements which are 5 called "houses". Each house is used only once to sign or a~th~onticate a m~sS~e Several such houses are combined into a "town" for reasons of efficiency.
A HOUSE
7 The basic construction of a 'house' in the "ler~l I ed embodiment is shown in figure 2.
n A house consists of a starting value called the house origin 201, a set of expansion functions 202, a set of iterated oneway functions 203, an iterative cryptographic hash O function 204 and a house result value 230.
~- A house contains a plurality of columns, two of which are shown explicitly in figure 12 2. The first one consists of items 210, 211, 212, 213, 21~, 215, 216, and the second one of 13 items 220, 221, 222, 223, 224, 225, 226. The l~ J columns are represented by 208 14 and are not shown in detail for clarity.
Considering the first column, this starts with a cryptographic oneway function 210 ~~ that takes the house origin 201 as input and yields the first value in the column 211 as 17 output. This is then used as input to a chain of oneway functions. Each chain contains one 18 or more oneway functions. Only two oneway functions of the chain are shown in figure 2, 19 the rem~ining steps of the columns are not shown for clarity, and are represented by 209.
0 The first oneway function 212 takes the first column value 211 as input and yields the 21 second column value 213, which is the input to the next oneway function, etc. The last 22 oneway function in the chain 214 yields the last column value 215.
23 The iterative cryptographic hash function 204 consists of a publicly known starting 24 value 205 and a sequence of compression functions, one for each column. The starting 25 value 205 is one ofthe inputs to the conl~)lession function ofthe first column 216 that ~ takes the last column value of the last column 215 as the other input and yields the first 27 intermediate hash value. Each subsequent column ends with a co...plession function similar 28 to 216 that takes the previous intermediate hash value as one input, the last column value 9 of that column as the other input and yields the next intermediate hash value.
O96t2~814 PCTrUS95/01765 ~ The last column, consisting of 220, 221, 222, 223, 209, 224, 225, 226 is built in a 2 similar way as the first column, these items corresponding to 210, 211, 212, 213, 209, 214, 3 21S, 216 respectively. The compression function 226 of the last column takes the next to 4 last intermediate hash value as one input, the last column value of the last column 225 as s the other input and yields the final hash value 230, which is called the house result value.
s An exemplary house is shown in figure 9. The house origin value 901 corresponds to 7 value 201. The set of expansion functions 902 consists of cryptographic oneway functions 8 910, 920, 930, 940, 950, 960, 970 all of which use the house origin value 901 as an input, 9 and which yield the first value in the columns 903 (corresponding to 203): 911, 921, 931, ~o 941, 9Sl, 961 and 971 respectively. These values are used as inputs to the first oneway functions in the chains 912, 922, 932, 942, 952, 962, 972 respectively, which yield the ~2 second column values 913, 923, 933, g43, 9S3, 963, 973 respectively. These are then the 3 input values for the second oneway functions in each chain 914, 924, 934, 941, 9S4, 964, ~~ 974 respectively, which yield the third column values 91S, 925, 93S, 94S, 9SS, 965, 97S
15 respectively. These are then used as input values for the third oneway functions in each ~s column chain 916, 926, 936, 946, 9S6, 966, 976 respectively which yield the last column ~7 values 917, 927, 937, 947, 957, 967, 977 respectively. These last column values form the 8 input to the cryptographic hash function 904 (corresponding to 204), which starts with a ~9 publicly known starting value 90S which is an input to the first compression function 918 which also takes the value 917 as an input and which yields the first intermediate hash value 1 919 as a result. The first intermediate hash value 919 and the final column value of the 22 second column 927 are the inputs to the second co..")ression function 928 which yields the 23 second intermediate hash value 929. This chain continues in the same fashion with items ~ 938, 939, 948, 949, 958, 9S9, 968, 969, 978, 979 respectively. The last value 979 is the s house result value which corresponds to item 230.
26 All the cryptographic oneway functions that start a column (such as 910, g20, 930, z7 940, 9S0, 960, 970) are different, so that they yield different result values even though they ~ have the same input value. As will be described more fully later, several houses may all use 29 the same house origin value. Within a set of houses that use the same house origin value, all the cryptographic oneway functions that start a column are typically different. Furthermore, - these oneway functions are such that it is believed to be impractical to reconstruct the 32 house origin value given all the output values of these oneway functions. Such functions WO 96/25814 Pcr~ss5J0176S
are used in other systems, among others in cryptographically strong pseudo-random 2 generators, well known in the art.
3 In the preferred embodiment, the oneway functions in the column chains (such as 4 912, 914, 916, 922 etc. to 976) are all different within a house. Furthermore, within a set of s houses that use the same house origin value, all the oneway functions in the column chains are d,~-enl. Each ofthe co~ ression functions such as 918, 928, 938 etc. differs within a 7 set of houses that use the same house origin value. As will be obvious to a person B ordinarily skilled in the art, these functions can be made different in many ways, for 9 example, but without limitation, they can be made dependent on a counter which is 10 incr~omented at every fimction application, or the exact position within a house or set of ll houses could be used to differentiate the different functions. It is believed that using 12 different functions in different positions improves the security of the system.
13 The height of a column is the number of column values, which is one more then the 14 number of oneway function in the chain.
~s The house result 230 depends on the house origin 201. Even though it might involve ~~ a large number of interrnedi~te results, the result 230 can still be computed from the house 17 origin using only a fixed amount of memory, irrespective of the number of columns or the 18 height of each column. This is achieved by computing through each of the columns in turn, .~ and applying the compression function to the final value of each column before starting on 20 the next column. The details of this computation will be obvious to someone ordinarily 21 skilled in the art.
A TOWN
22 As will be described later, the house output value will be signed using a digital 23 signature scheme and the card will store that signature. To reduce the storage requi~c.l,~
24 several houses may be combined into a town, as shown in figure 3.
A town consists of a plurality of houses, three are shown in figure 3 as 321, 322, 323;
25 the rem~ining houses are not shown for clarity and are represented by 302. Each of the 27 conctituent houses of a town has a house origin value (corresponding to 201 in figure 2);
2A 311, 312, 313 are the house origin values of 321, 322, 323 respectively. Each ofthe houses 29 also has a house result value, corresponding to 230 in figure 2; 331, 332, 333 are the house 30 result values of 321, 322, 323 respectively. All the house result values are used as inputs to 31 a cryptographic hash function 340 that yields the town result value 341.
CA 022l8l78 l997-08-08 WO 96/25814 PCT/US9!j/01765 In the preferred embodiment all the houses in a town are of the same architecture:
2 they have the same number of columns, the same height for each column etc. It is believed 3 that this gives the easiest implementation.
The construction of a town in the preferred embodiment may be described recursively, as shown in figure 4. A singleton town 403 has a single constituent house 461.
6 The town origin value 460 is used as the house origin value (corresponding to 201 in figure 7 2) of the house 461. The house result value (corresponding to 230 in figure '') is the town a result value 462.
9 A general town 401 has a plurality of constituent towns, three of which are shown as o 421,422,423; the rPm~ininsg are not shown for clarity and are represented by 402. Each of the constituent towns is either a general town or a singleton town. The town origin value 2 411 is used as the town origin value for each ofthe constituent towns. A sequence of 3 compression functions is used to combine the town result values of the constituent towns ~4 and yield the town result value of the general town 453.
The town result value ofthe first constituent town 431 is the first input to a compres-6 sion function 442 that takes the town result value of the second town 432 as a second input 7 and yields the first intermediate value 452. This intermediate value is then used as the first input to the next compression function, which takes the result value of the next constituent town as a second input and yields the next intermediate value. This chain continues until the ~ last constituent town where compression function 443 takes the previous interrnediate 1 value as a first input and the town result value of the last conctit~lent town 433 as a second 22 input and yields the town result value of the general town 4S3.
23 The compression functions such as 442 and 443 are chosen in such a way that the 24 result of the chain of compress fi~nctions is a cryptographic hash function. Such iterative 25 hash functions are well known in the art.
26 In the preferred embodiment, the recursion depth used in each of the constituent 27 towns is always the same, and the number of constituent towns in a general town only 29 depends on the recursion depth. It is believed that this results in the most practical 29 implementation. Each recursion level is called a dimension, and a town with n recursion 30 levels is called an n-dimensional town. For example: a general town whose constituent - towns are all singleton towns is a one-dimensional town. A general town whose constituent 32 towns are all one-dimensional towns is a two-dimensional town, etc. This also allows an
33 easy characterization of a town configuration. For example, a 7x4x5 town is a three-WO96/25814 PCTMS9S~0~765 dimensional town that contains 7 constituent two-dimensional towns, each of which 2 contains 4 conct~ ent one-dimensional towns, each of which contains 5 con.ctit~lent 3 singleton towns, each of which is made up of a single house. Thus, the total number of ~ houses in this town is 7x4xS=140. The number of conctituerlt towns in a general town at s each recursion level is called the size of that dimension. The singleton town is often 8 ignored, and we will say that a one-(lirnencional town contains a plurality of con.ctit~lent 7 houses. In the preferred embodiment, the sizes of the dimensions are all the same, or differ r. by at most one. It is believed that this gives the most efficient implem~nt~tion.
9 A pl efe- lt;d exemplary 3x4 town is shown in figure 5. The two-dimensional general ~o town 501 contains three constituent one-dimensional towns 502, 503, 504, each of which ~- contains four constituent houses. The town origin 505 is used as the house origin of each of 2 the houses in the town S60, 561, S62, 563, 530, 531, 532, 533, 510, 511, S12, 513. These ~3 houses each produce a house output value namely 564, S65, 566, 567, 534, 535, 536, 537, ~~ 514, 415, 516, 517 respectively. The house result values of the first one-dimensional town ~5 504 are combined by a chain of compress functions 568, 570, 572 that generates the ~ intermediate values 569 and 571 and the town result value 573 of town 504. The house 7 result values of the other one-dimensional towns are combined in a similar way, as shown 8 by 538, 540, 542, 539, 541, 518, 520, 522, 519, 521 which results in the town result values 9 543, 523 of towns 503, 502 respectively. The town result values 573, 543, 523 of the one-20 ~imencjonal towns 504, 503, 502 are combined in a similar way by functions 581, 583 and - intermediate value 582 which results in the town result value 584 of town 501.
TOWN CREATION
22 For the description of the processes that involve a town we will use the example as 23 shown in figure S. How these processes extend and generalize to a general town will be ~ obvious to someone ordinarily skilled in the art.
A town is created by choosing a town origin 505 and computing the town result 584 ~ from that. The town result is computed using a straightforward, although extensive, 27 computation involving the origin. As an example, but without limitation, an elegant way of 28 computing the town result 584 is shown in the figure 41. The houses are computed in the 29 order shown in the first column. The second column shows which values will be in memory 30 a~cer the house in the first column was computed. The last column shows which values are 31 in memory after applying any coll.p,ession functions whose input values are both in W O96125814 PCTrUS95/01765 memory. Af'Ler applying any compression functions, the next house is computed as shown 2 in the first column of the next row. The generalization to a general town is best described 3 recursively. It is believed that a singleton town like 403 can be computed with a fixed amount of memory, as it basically only involves computing a house. To compute the general town 401, we first recursively compute town 421, store the value 431, recursively compute town 422 with result 432, combine values 432 and 431 using co,l,piession 7 function 442 to value 452, compute the next town recursively etc. It is believed that by D interleaving the applications of the compression function with the computation of the 9 constituent towns, each recursion level uses a fixed amount of storage independent of the l0 number of constituent towns, so that the storage required to compute an entire town is only proportional to the number of dimensions of a town.
12 Once the town result 584 has been computed, the issuer signs this result using a 13 public key digital signature scheme. There are several ways in which this can be 14 accomplished. If the issuer is creating the town, then he just computes the digital Cign~ture 15 on the town result. This is shown in figure 10. The signing process 1002 takes two inputs .s namely the message to be signed 1001, and the secret key used to create a digital sign~h~re 7 1004. The output value ofthe signing process 1003 is called the digital sign~ture By using ~~ the town result 584 as the message input value 1001, the issuer can compute the digital 19 signature on the town result, which we call the town sign~t-lre. The town origin 505 and 20 the town si ,n~ture are then sent to the card 102 where they are stored in non-volatile 21 memory. It is anticipated that other data can also be included in the message being signed 22 as the town signature.
23 There are several other ways in which the town might be created. For example, but 24 without limitation, the card could choose a random town origin 505, compute the 25 corresponding town result 584, and send the town result to the issuer together with a 25 cryptographic authentication that convinces the issuer that the town result he receives was 27 computed by a valid card. The issuer then signs the town result to get the town ci~?n~tllre~
2~1 and sends the town signature back to the card. The card stores the town origin 505 and the 29 town sign~tllre in non-volatile memory. A blind Sjgn~tl~re scheme might also be used, 3C where the card first blinds the town result 584 before sending it to the issuer. Using a blind 31 digital sign~tllre scheme the issuer can sign the town result without ever learning the actual 32 value of the town result.
=
W O96/25X14 PCTnUS9001765 - 3~ -Using some or all of these creation techniques, the card can acquire one or more 2 towns, each of which consists of a town origin 50~ and a town signature. Reloading a card 3 with more towns would typically be one of the transactions which the terrninal might J perform with a card.
HOUSE SPENDING
s The process of using the houses is called spending. In this process the card uses a 6 house to sign or ~uthenticate a message, for example, but without limitation, the card can 7 use a house tO create a message to the terminal which represents a certain amount of money, which the terminal can verify for validity without having access to any secret cryptographic keys.
~o The basic spending process is described in figure 30. This process is an example of a ~- wide class of cryptographic protocols known as commit-challenge-response protocols.
12 These are well known in the art, and have been used in a variety of zero-knowledge 13 protocols, identification protocols, signature schemes etc. Some examples of such protocols are the Guillou-Quisquater protocol, Feige-Fiat-Shamir protocol etc. A commit-15 challenge-response protocol starts with one party (the prover) sending a commit mPcs~ge 1~ to the other party (verifier). The verifier then chooses a challenge which it sends back to .7 the prover. Finally, the prover sends a response to the verifier. The prover will ~ypica!ly use 18 the commit value, the challenge value and some other (secret) data to compute the 19 response. The verifier will typically be able to verify that the response is correct based on 20 the commit value and the challenge value. It will typically be the case that a ch~ting prover 21 can provide correct commit and response rness~ges if he can guess the value of the 22 challenge in advance. The number of dirrel en~ possible challenge values is thus an important 23 aspect of these kind of protocols. If the number of different challenge values is small, then a 24 single execution of the protocol process will not convince the verifier very much, and the 25 execution will have to be repeated to fully convince the verifier. This is used on many zero-2B knowledge protocols. If the number of different challenge values is large, then the protocol 27 can be converted to a ~ign~tllre scheme by defininSg the challenge to be chosen as the 2~S cryptographic hash of the message to be signed and the commit value sent by the prover.
2S~ This ~limin~tes the need for interaction and allows the prover to send all the data in a single 30 message to the verifier. This conversion is again well known in the art, and is for example 31 used in the Fiat-Shamir sign~tllre scheme. In several schemes the amount of computational W O96/25814 PCTrUS95/01765 work increases when the number of possible challenge values is increased, making it 2 desirable to keep the number of challenge values to a minimurn The spending process will 3 now be described, which is a specific embodiment of a comrnit-challenge-response protocol in which the card is the prover and the terminal is the verifier.
s The process in figure 30 starts at step 3000 at the card which sends a commit value to the terminal in message 3001. The purpose of the comrnit value is to fix the house the 7 card will use in the spending. For example, but without limitation, the commit value could o consist of the town .cign~ture, the town result value and an iclentific~tion of the house 9 within the town. When message 3001 is received by the terrninal, the terrninal starts ~o execution of process step 3002. The terminal stores the commit value, and chooses a random challenge c. As the last action of step 3002 the terminal sends the challenge c to the 12 card in message 3003. The terminal might use various means to generate the random 13 challenge c For example, but without limitation, this could include a real random number 14 generator, a pseudo-random number generator etc. The challenge chosen could also ~o depend on information sent by the acquirer or issuer to the terminal, thus taking away some ~o freedom from the terminal which is believed to make some attacks harder to perform.
~7 When message 3003 is received by the card, it starts execution of process step 3004 in ,~ which the card computes the response associated sends the response to the terminal in 19 message 3005. When message 3005 is received by the terminal, it starts execution of 20 process step 3006 in which the terminal verifies that the response matches with the commit 21 value and the challenge.
22 The commit value must uniquely identify and authenticate the house that will be used 2~ by the card in this process. This typically involves identif~ing the town and the house within z~ the town. The town is authenticated by the town signature. To properly ~uth~nticate the 25 house, several intermediate values in the town must also be sent to the terminal, either in 215 the commit message or in the response message. For example, in figure 5 if house 532 is 27 used, the following values are sent to the terminal: S36, 539, S37, 573, S23. (Value S36 is 20 not strictly necessary as it can be computed from other response data, but in the preferred 29 implementation it is sent as it is believed that this is easier.) Using these values, the terminal 30 can verify that the house with house result value 536 is indeed a constituent house of the 31 town 501. The terminal applies the various compression functions to compute the town 32 result value 58~, and then verifies the town sign~tllre using a sign~ture verification process.
33 The ciPn~ture verification process is shown in figure 7. The verification function 712 takes _ W~ 961258~4 PCT~US9~J~176S
t three inputs: the sigJn~t~lre 711, the message 710, and the public key 714, and yields a single 2 bit result 713. The result indicates whether the digital signature was indeed the signature on 3 message 710 with respect to the public key 71 ~.
4 Having ~thenticated the house, the house can now be used. We will use the house in s figure 9 as an example. The response data that the card sends includes exactly one value in 6 each ofthe columns. In the first column, that is one ofthe values 911, 913, 915, or 917. In 7 all the other columns, one of the four column values is inrh~ded in the response data. The 8 terrninal receives these column values, and applies the necessary oneway functions to 9 compute the final column values in each of the columns 917, 927, 937, 947, 957, 967, 977.
10 The compression function 904 is then applied to these values which yields the house result ~- value 979. The terrninal verifies that this matches the house result value used earlier to 12 authenticate the house in the town, or uses the house result value to authenticate the house 13 in the town. The choice of which value in each column is sent encodes the challenge c. For 14 ease of reference, each of the column values has an associated di it value. The digit value ~s of the last column value is 0, the digit value of the next to last column value is 1 etc.. In 8 figure 9 the first column value has a digit value of 3, in the actual preferred embodiment the 7 column height is 8, so that the digit values 0, l, 2, 3, 4, 5, 6, 7 are used. It is believed that 18 using a power of two for the column height allows easier encoding/decoding of actual data ~9 into the column digit values. The challenge c is thus converted into a sequence of digits, which indicate the column values included in the response data. In this way a card can use a 21 house to perform a commit-challenge-response protocol with the terrninal. It is believed 22 that this protocol by itself convinces the terminal of the fact that the card is genuine in the 23 sense that it has a valid town, which was originally signed by the issuer, which only gives 24 such valid towns to genuine cards.
2s ~igure ~ sllows a number or digit vaiues (digits) which are used to encode c and any 28 extensions which we will describe fully later. Each square, such as 600, 602, 604, 606, 608, 27 610, and 612 represents a single digit, with 603, 607 and 611 representinv any number of 28 additional digits. The boundaries 601, 605 and 609 separate the digits into di~.t;l~L fields 2~ which will be discussed fully later. A (sub)sequence of digits usually encodes an integer, using the standard encoding of integers into digits of the appropriate radix, well known in 31 the art. If the columns are of din'erenL heights, then the maximum digit value varies over the 32 digit position. In this case a mixed radix encoding of the integers is used, which is also well 33 known in the art.
W O96125814 PCTrUS95/01765 For each of the column values given to the terminal, the terminal can of course 2 compute the subsequent column values. This corresponds to a lowering of the 3 corresponding digit value. This would allow the terrninal to modify the digits unless 4 precautions were taken. The control value is used to protect against this. A subset of the s columns (and thus of the digits) are designated as the protected columns (digits).The 6 control value, seen as an integer, encodes some constant minus the sum of all the digit 7 values in the protected columns. The control value itself is also coded into some columns.
8 For example, but without limitation, the control value could be coded into digits 610, 611, 9 612 and the protected digits could consist of 600, 602, 603, 604, 606, 607, and 6~8. The ~o terminal can only apply more oneways to a column chain and thus only lower the value of any one digit. If the terminal tries to lower the value in any of the protected digits, then the t2 control value increases, which means that at least one of the encoding digits of the control 13 value increases. This would require the terrninal to invert one of the oneway functions in 14 the column of the increasing control digit, which is presumed to be impractical. In the ~s preferred embodiment the range of control values is fixed at 0-63, which allows for 9 16 protected columns. (All columns have height 8, so each protected digit has a value of at 17 most 7, so 9 columns lead to a maximum sum of 63. Using 63 as the constant to subtract 18 from gives exactly the range 0 to 63 to the control value, which can be encoded in two 19 digits of radix 8.) It is believed that the most significant control digit is the most attractive 20 digit to try to increase by inverting the appropriate oneway function, as increasing this digit 21 gives a lot of flexibility in ch~nging the protected columns. The most significant digit of the 22 control value is therefore duplicated in two separate columns, for a total of three control 23 columns. It is believed that the double encoding of the most significant digit provides extra 2~ security against an attack which attempts to invert a oneway function with the aim of 25 increasing one of the control digits. It is furthermore believed that the number of control 2~; columns increases only loga,ilhl"ically with the number of protected columns.
27 The spending protocol implements a commit-challenge-response protocol between 28 the card and the terminal in which the number of different challenge values depends on the 29 number of columns in a house and the height of each column. The challenge value is 30 encoded in the protected columns, and the control columns are added as described above.
31 This can now be used to sign messages. For short messages where there are at most as 32 many possible messages as there are challenge values, the message itself can be used 33 instead of the challenge value. However, most applications need to sign larger messages CA 022l8l78 l997-08-08 YCTlUSsSl01765 WO 96/2~81 1 then would be practical here, among others tO prevent replay attacks. This method of using 2 a commit-challenge-response protocol is well known in the art.
3 A more general scheme is the direct conversion of the commit-challenge-response 4 protocol to a signature protocol by choosing the challenge to be the hash of the commit s message and the ~ness~e to be signed. This requires a challenge value of approximately 128 bits or more, which can be achieved using 43 protected columns of height 8 plus 3 7 control columns for a total of 46 columns This method of using a commit-ch~llen~e response protocol is well known in the art. It is believed that inclu~in~ the commit m.occ~e 9 in the hash used to compute the challenge is not even necessary for these house based lO systems.
A commit-challenge-response protocol can also be used to authenticate messages in 2 those cases where the effective contents of the message to be authenticated is small. By 13 effective contents we mean the data in the message except for the data that is used to ~4 prevent playback attacks etc. For example, but without limitation, in payment systems the ~s only important piece of the message being signed is the amount of the payment. The ~~ challenge can now be chosen in two parts, the first part being the message that is 17 ~llthenticated, and the second part being a value chosen by the verifier in a manner not 18 predictable by the prover It is believed that this method provides full auth~-ntication of the .~ message and at the same time protects the verifier from playback attacks. This use of the 20 commit-challenge-response protocol will be referred to as signing a short m~ss~e. A
z- typical exemplary application is the case of payments (i.e. payments from the card to the 22 terminal). The challenge c is divided into 4 sequences of digits, as shown by the separators 23 601~ 605 and 609 in figure 6. The first digit 600 encodes the currency ofthe payment. The 24 digits 602, 603, and 604 encode the amount of the payment. The digits 606, 607, 608 are 25 chosen randomly by the terminal, and finally digits 610, 611, and 612 encode the control 25 value. The protected digits are 600, 606, 607, and 608 A typical configuration has I
27 currency column, 5 amount columns, 7 random columns and 3 control columns, which 28 accommodates 8 currencies, 15 bits resolution of the amount of the payment and 21 25~ random bits. Using an ordinary digital cign~tllre~ the '~1 random bits would not be enough 30 to protect the terminal from playback attacks. However, it is believed that in a commit-31 challenge-response protocol, and in this specific inct~nce of a commit-challenge-response 32 protocol in particular, this does protect from such attacks, as the card must commit to the 33 house to be used in the first messaoe, and cannot change that based on the value of the w 096n5814 PCTrUS95/01765 ~ random part of the challenge. The amount digits are not included in the protected digits, 2 which allows the terminal to arbitrarily decrease any of the amount digits. It is believed that 3 this only decreases the amount encoded in the signature, which is not in the interest of the 4 terminal.
s Another method allows the use of commit-challenge-response protocols with a small 6 set of possible challenge values to be used to ~uthenticate arbitrarily long messages. This is 7 done by choosing the challenge value as a uniformly distributed function of the 8 cryptographic hash of the message where the message is extended with a number that was 9 ~enerated in a mutually random fashion (also known as a fair coin flip). Such a mutually ~o random number is a number which is constructed in a cooperative process between two ~- parties in such a way that both parties are ensured that the number is in fact random. At the 12 start of the process in figure 30, both the card and the terminal know the message m to be 13 signed. In process step 3000 the card generates a random number a, and computes a 14 commit value A on it, for example, but without limitation, A can be formed by hashing a .s and a large enough random string of bits. In message 3001 the card sends A to the terminal, .~ along with the rest ofthe commit message. The purpose of A is for the card to show the 17 terminal that it has fixed it's choice of a without revealing a to the terminal. Such bit 18 commitment schemes are well known in the art. The terminal then chooses a random 19 number b in process step 3002, and sends b to the card in message 3003. In step 3004 the 20 card computes the mutually random number d as a function of a and b, for example, but 21 without limitation, d can be computed as the exclusive or of a and b. The actual challenge 22 value c is then computed by first computing a cryptographic hash of the message m 23 concatenated with d, and then applying a function that maps the hash value uniformly to the 24 set of possible challenge values, for example, but without limitation, the challenge c could 25 be chosen as the least significant bits of the actual hash value. The value c is then coded 26 into the protected digits of a house, the control digits are added and the card sends the 27 response data associated with those digits to the terminal in message 3005. The card also 28 includes the value a plus any information necess~ry to verif~ the commit value A in meSs~ge 29 300~ which allows the terminal to reconstruct d and thus c, and also allows the terminal to 30 verify that a is indeed the value committed to by the card in message 3001 by checking that 31 the values a and A are consistent with each other. This use of a commit-challenge-response 32 protocol will be referred to as authenticating an arbitrarily long message. The message m 33 does not have to be known by both parties at the start of the process, but can also be , CA 022l8l78 l997-08-08 PCT~JS95J~2 76*
WO 96/2~;814 inC~ e~ in messa~ge 3001 to the terminal. It is anticipated that part of the message might 2 also be chosen by the terminal in step 3002 and comml-nir~tecl to the card in step 3004, in 3 which case the card has the choice of accepting that part of the mecs~e or replacing it by a fixed value. It is believed that this authentication method provides authentication of the s message to the terminal. It is believed that the probability of succecsfully çhe~tin~ the A terminal is in the order of one over the number of possible çh~llerlge values.
7 It is believed that compact endorsement cign~hlreS provide a high degree of 8 flexibility; using a large house, the card can sign any message, using a more ~offir.i~nt smaller house, the card can sign a small message, or authenticate an a,b~ ily long message.
~o When the house is used to authenticate an arbitrarily large message to the terminal, ?l the card can at the same time send a secret-key authentication on the message for use by 12 the issuer. (As the issuer originally produced the card, we assume that the card and the 13 issuer have a secret key in common.) The secret-key a-lthentication is first appended to the .. message, and the combination of the two is then authenticated to the terminal using a house. It is believed that this provides the benefit of a public-key siSgn~ture to the tenninal, ~~ with the speed and storage advantage of a secret key sisgn~tllre to the issuer. The terminal 17 can namely discard the house and all associated data and only store the message and the 18 secret-key authentication.
TOWN PRECOMPUTATION
~~ The card must send several intermediate values of the town to the terminal during the spending process. To save computations these values are precomputed. As an example we 21 will use the town of figure 5, the pfeco"1putation steps are shown in figure 40. The 22 precomputations schedule shown in figure 40 are believed to be suboptimal in the sense 23 that they require more storage on the card then the optimal precomputations schedule, but 2- iii3 aiso beiieved that this schedule yields the easiest implementation.
Figure 40 shows the values stored in memory at any step. The first column contains 2r the number of the house in the town that is being spent, the second column the set of values 27 that is precomputed in the current town (called A), the third column the set of values that is 28 p.eco."puted in the next town (called B). The next town is the town that will be used a~er 29 the current town has been exhausted, in the sense that all the constituent houses have been 30 used. For clarity all items referring to the next town are shown in slanted font in figure 40.
W O96125814 PCTrUS95/0176S
The fourth column the set of values needed for the authenticating the house indicated in the 2 first column within the town and the last column the number of values stored in memory.
3 The first row of figure 40 shows that when house 560 is being spent, the values 523, 4 543, 564, 565, 566, S67 are being used in the spending process. (As mentioned before the s house result value of the current house is used in the p~ ere" ed embodiment. Although this is not n~cesc~, y from a functional point of view, it is believed that this provides for the 7 easiest implementation.) The value 534 is computed (by computing the house result value of house S30) and stored.
9 The second row of figure 40 shows the situation when the next house 561 is spent.
10 The same values as in the previous step are being used, and one more value is precomputed ~- namely 535. When, in the third row, house 562 is being spent, the values 564 and 565 are 12 no longer necessary for the spending process, but are combined using the compression 13 function into value 569. This saves a storage space, which is used to precompute the next 14 value 536. The next line shows a repeat of this process when house 563 is being spent: the .s values 569 and 566 are combined into value 571 and the free storage space is used to .~ compute value 537. When spending house 530, the values 571 and 567 are combined into 17 573, the value 543 is no longer necessaly and is replaced with the already precomputed .~ values 534, 535, 536 and ~37 which are now used in the spending process. The value 514 19 iS precomputed in this step. This is also the point in which we start precomputing the next 20 town. When all houses in the current town (A) have been spent, we obviously need the 21 intermediate values of the next town (B) that are needed for the spending process for the 22 first house in B. At this point we precompute value 534 in town B by computing the house 23 530 in town B which is the first step in computing 543 of town B. When spending house 24 531 the same set of values is used for the spending, the value 515 is precomputed, and in 25 town B the house value 535 is precomputed, combined with the already stored value 534 to 2~ yield value 539. Only value 539 of town B is stored. This process continues as shown in the 27 table. When spending house 533 the values 523, 541, 537 and 573 are being used, the 2~ values 514, 515, 516, and 517 have been precomputed in town A. In town B the value 537 29 iS computed, combined with the value 541 which was already precomputed in town B and 30 the result value 543 stored. When the next house 510 is being spent, the values 573 and 31 541 and 537 in town A are no longer necess~ry, they are combined using the appro~-iate 3_ compression functions into value 582. The values 514, 515, 516 and 517 which had already 33 been precomputed in town A are now being used. Two new values are plecoll-p-lted in WO 96/25814 PCT/US9S~01 76S
town B namely 514 and 564. In the next rows the spending situations for houses S11, ~12 2 and 513 is shown. The original values that were used for the spending 514, 515, 516, and 3 517 are step by step combined to S21 and S17 for the spending of the last house 513. The 4 precomputations in town B involve precomputing 565, 566 and 567, and the p,~col."~.~tation of value 523 in steps with interrne~ te values 519 and 521. After the last house 513 has been spent, we switch to the next town. What used to be called town B now 7 becomes town A. The values that were precomputed in town B during the spending of a town A are exactly those necessary for the spending of the first house 560 in town B as 9 sho~,vn by the next row of the table. Of course, the r~ ~ values 521, 517 and 582 of ~0 the old town A are discarded as they are no longer needed. When all houses in a town have been spent, the town origin and the town signature are also discarded, as they will not be 2 used again.
., It is believed that this method of preco",putations requires storage space proportional .~ to the sum of the sizes of each of the dimensions of a town. Furthermore, it is believed that 15 the precomputation involves computing at most as many houses as there are dimensions if multiple towns are used. and one less if only a single town is used. In figure 40 at most 2 houses are precomputed at any step, and of these at least one is in town B. If town A were ~8 to contain enough houses so that a second town is not nec~ss~ry, then no precomputations 18 in the next town need to be done. It is believed that this further reduces the necess~ry 20 precomputations. It is believed that it is possible to load additional towns into the card.
21 These can either be without any precomputation (e.g. the next town after town B), with 22 (partial) precomputations (e.g. add a town B with the correct preco",putations to an 23 already existing town A), or existing towns and precomputations can be discarded and 2~ replaced with new town(s) with the right precomputations. These extensions will be 25 obvious to someone ordinarily skilled in the art.
2a The precomputations mentioned above can of course be done by the card itself. An 27 alternative is for the terminal to do manage the precomputations. The house result values in 28 a town are not secret, so the card can compute those on dem~nA and send the result to the 20 terminal. A refinement is to let the card not compute the house result value, but just the last 30 value in each column, send those column values to the terminal and let the terminal 31 combine them to get the house value. The terminal can now manage the precomputations, 32 reading, writing and deleting the necessary values in the card's memory. For example, but 33 without limitation, when spending house 562 (see figure 40, third row) the terminal can ask W O96/2581~ PCTrUS95/01765 the card to compute the house result value S36. The card can either store this as a 2 precomputed value by itself, or send it to the terminal which then stores it back in the card 3 as a precomputed value. The terminal furthermore reads the values 564 and 565 which are 4 stored in the card's memory, deletes those values in the card's memory, computes the value s 569 form the values 564 and 56~; and writes the value 569 in the card as a pl ecol~-l)uted 8 value. In a similar manner all the other precomputation actions can be managed by the 7 terminal. The terminal might do all these actions itself, or might contain a tamper-resistant o device which performs and manages the precomputations. It is believed that this 9 pl eco...putation management system simplifies the implement~tion of the card. It is believed ~o that any error by the terminal in m~n~ging or performing the p- ecol--putations does not lead ~- to a security weakness, but can at most lead to a failure to properly authenticate a house in 2 a town, thereby rendering the compact endorsement signature scheme ineffective until a 3 recovery has been performed. It is believed that a terminal that detects an inconsistent 4 precomputation state in a card can rec~ver the card and bring it in to a consistent state with s respect to the precomputations.
SECURE DATA STORAGE
Figure 12 shows the basic layout of the non-volatile and volatile memory of the card 7 in the preferred embodiment.
8 The volatile memory 1240 holds the variable 1241, called VNIU, which is described 19 in detail below. Field 1242 holds the volatile memory variables that are not part of the Secure Data Storage. These are not shown for clarity.
21 The non-volatile memory 1200 is divided into three areas. Area 1201 is used to store 22 the global non-volatile variables. Area 1203is set aside for other applications or purposes, 23 as known in the art. Area 1201is shown in more detail as 1230, the dotted lines denoting 24 an enlargement. The fields 1231,1232,1233,1234tl235 and 1236 are global non-volatile 2s variables called N~U, COM, NDONE, NBROK, CLCOM and CLCAN respectively, and 2~ are described in more detail below. Part 1237 are global non-volatile variables that are not 27 part of the Secure Data Storage system, which have not been shown for clarity. The 28 ND ONE variable is used in the session proofs, which will be described more fully later.
29 Area 1202is shown in more detail as 1210, the dotted lines denoting an enlargement.
3c This area is divided into a plurality of fixed-size smaller areas called frame slots. All frame 31 slots have the same size and the same internal organization. One ofthe frame slots 1211 is WO96/25814 PC~JUS9SJD176S
~ showed enlarged as ~220, the dotted lines denoting an enlargement. Each frameslot 2 consists of four fields, each of which can store a variable. The field 1221 is called the tag 3 field, and holds a variable called 'tag'. Field 1222 is called the access field, and holds a variable called access'. Field 1223 is called the data field and holds a variable called 'data'.
s Finally, field 1224 is called the checkc~-m field and holds a value (called the ~hec~cllm) that 6 serves as a checksum over the other three fields. The function to compute the chec~cllm 7 from the other three fields can be chosen in many ways, for example, but without limitation, 8 it can be chosen as the number of zero bits which occurs in the other three fields, coded as 9 a binary number. The four values tag, access, data and çhec~sllm are together ~~fel-~d to as .c a 'frame'.
The tag functions much like a filename in ordinary computers. It is used as a unique 12 name to refer to the frame. All frame slots are the same size, thus the a frame fits in any of 13 the frame slots. The inte~relalion of the data in a frame slot is solely dependent on the lG value of the tag field, and not on the position in the non-volatile memory the frame appears 1S in. Whenever information about specific frame is needed, the non-volatile memory is ~g searched for a frame slot with the proper tag value in the tag field. The other fields of that 17 frame slot contain the other data of that frame. A value of zero in the tag field is used to 18 indicate that a frame slot does not contain any valid frame data, and is therefore empty.
19 Thus, a frame slot is the actual location where a frame is stored in the non-volatile memory.
20 A frame is a set of values which is stored somewhere in the frame slots, which is identified 21 by its tag value.
22 The access field is used to store data regarding the conditions that should be met 23 before the data of the ~rame can be acc~ssed. This corresponds with access rights 24 associated with files in many operating systems. The data field contains data for the 25 applications, the interpretation and formatting of this data depends on the applications.
In the plefel,ed embodiment, the tag field is '~ bytes long, the access field 1 byte long, 27 the data field i 6 bytes long and the checksum field 1 byte long.
~ A MODEL FOR NON-VOLATILE MEMORY.
28 For reliable and secure operations the card would typically require a reliable and 29 secure non-volatile memory system. A typical smart card uses EEPROM technology for 30 non-volatile storage of data. Inherent in this technology, and in many other non-volatile 31 storage technologies, is that writing data is not i~ct~nt~neous. There are two basic W O9612581~ PCT~US9S/01765 processes for EEPROM memory: writing and wiping. During wiping, a block of bits is 2 cleared to the default position, which we will without loss of generality denote by a binary 3 O(although in some implementations wiped bits read as l's). The block size for wiping is impl~m~nt"tion dependent and might actually be 1, but typical minimum block sizes are 8 s or 32 bits. This means that it is often not possible to wipe individual bits but only blocks of bits.
Writing is also done in blocks, but usually allows individual bits to be set to I (in our representation). In a typical implement~tion, when writing data to a memory block the bits g that are written with a 0 value are not affected while those that are written with a I value ~o are set to 1.
lt Both the writing and wiping process take time, typically on the order of a few ~z milliseconds. If the operation is aborted for some reason within this time, the results are 3 usually unspecified. It is believed that irradiating the EEPROM memory with W light has 14 similar effects as a partial or full wipe of the bits that are irradiated.
A functional model of a typical EEPROM memory is shown in figure 11. This figure~~ gives the state diagram for a single bit of EEPROM memory. Each bit has three possible 17 states labeled 1100, 1101, 1102. The state 1100 is what we call the 0 state. In this state the , bit has a stable zero value, and will always be read as a zero. In state 1101, also called the I
19 state, the bit has a stable one value, and will always be read as a one. In state 1102 the bit is 2r in an intermediate state, called the ? state. In this state the value of the bit is not defined, 2~ and the result of a read operation is undefined. Although most implementations will at any 22 specific read attempt return either a zero or a one value, we assume that it is not possible to 23 predict what value is returned. As the value returned might also depend on other factors, 24 including factors external to the card, such as temperature, supply voltage etc., we make no 2s assumptions whatsoever about the values returned by read attempts.
2~ The state transitions are also shown in figure 11. A bit in the 0 state 1100 will 27 transition to the ? state 1102 through state transition 1110 at the start of a write operation 2~ which attempts to write a I into this bit. The bit remains in the ? state for the duration of 29 the write operation. A bit in the ? state 1102 will transition to the I state 1101 via transition 30 1111 at the end of a write operation which attempts to write a 1 into this bit. A bit in the I
~- state 1101 transitions to the ? state 1102 via transition 1112 at the start of a wipe operation 32 on a block of bits that contains this bit. A bit in the ? state 1102 transitions to the 0 state 3~ 1100 via transition 1113 at the end of a wipe operation on a block of bits that contains this WO 96/25814 PCT~US9SlD~76S
~ bit If the write or wipe operation is interrupted for any reason, the transitions 1111 and 2 1113 respectively are not made and the bit remains in the ? state 1102.
3 Under influence of W radiation, any bit in the I state 1101 can also transition via 4 1112 to the ? state 1102, and from the ? state 1102, via 1113, to the 0 state 1100.
s As will be obvious to someone ordinarily skilled in the art, this model applies, or can be applied to a wide variety of non-volatile memory technologies.
BROKEN MODE
7 In the prer~ ed embodiment, the card has two basic modes, which we call 'broken' 8 and 'not brolcen'. This mode is indicated by the NBROK variable 1234. This is a single-bit variable in non-volatile memory which occupies a whole block of bits so that it can be ~o wiped without influencing any other variables in memory. Under normal circum~t~ncec, the ~- card is in the 'not broken' mode, and the NBROK variable 1234 contains a value of 1.
12 During the personalization of the card, this variable is set to a I value. The 'broken' mode 13 when the NBROK variable 1234 is zero will described more fully later.
MULTI-UPDATES
14 The variables CLCOM (1235) and CLCAN (1236) each consists of an array of bits, ~s one bit for every frame slot on the non-volatile memory. In the default state all the bits are ~~ O. The variables N~U (1231) and COM (1232) are both single-bit variables which occupy 17 an entire block of bits so that they can be individually written and wiped. The VNIU (1241) 18 variable is a single bit variable in volatile memory.
19 Figure 18 shows the process of finding a frame in the p, ere, red embodiment. At the start 1800 the variable 't' contains the value ofthe tag ofthe frame to be found in the non-21 volatile storage. First, in step 1801 two new variables are initi~li7ed: a counter 'nr_found' 22 which indicates how many frames were found, which is initi~1i7ed to zero, and an index 23 counter 'idx' which will run over all frame slot indexes, which is initi~li7ed with the index 2- value ofthe first frame. Next is a loop, comprising items lg02, 1803, 1804, 1805 which 2s searches for frame slots with a ta, value equal to 't', for which the associated bit in the 2B CLCOM variable is 0. First, in step 1802 the frame slot with index 'idx' is inspected to see 27 if the tag field contains the value 't', and whether the bit associated with that frame slot in 28 the variable CLCOM is 0. If this is not the case, the process continues at item 1804. If this 2~ iS the case, a frame slot has been found and the process continues at item 1803. At step 30 1803 the counter 'nr_found' is incremented by one, and the current value of 'idx' is O96125814 PCTrUS9510176S
~ assigned to a variable called 'store_idx', after which the process continues at step 1804.
2 Step 1804 checks whether the frame just inspected by step 1802 was the last frame. If this 3 iS the case, the process continues at step 1810, otherwise it continues at step 1805. At step 180S the 'idx' variable is incremented by one to the next index value, and processing s continues at step 1802. The result of the process so far is that the variable 'nr_found' contains the number of frame slots that exist in the non-volatile memory whose tag value is 7 equal to 't' and whose representative bit in the CLCOM variable is zero. If the 'nr_found' e variable is greater then zero, then the 'store idx' variable contains the index of one of the 9 frame slots found.
~o Steps 1810,1811,1820,1830,1810 decide which action should be taken based on ~- the results of the earlier loop. In step 1810, the counter 'nr_found' is checked for a zero 12 value. If 'nr_found' is zero, the process continues at step 1820 which sets the return value 13 to indicate that no frame was found. If step 1810 determines that 'nr_found' is not zero, 14 the process continues at step 1811 which checks whether 'nr_found' is greater then one ~s and 't' is unequal to zero. If this is the case, the process continues at step 1$40 which 16 wipes the NBROK variable to 0 to enter the 'broken' mode, and jumps to the reset process 17 for proper 'broken' mode processing. If in step 1811 the condition is false, the process ~o continues at step 1830 which sets the return value to indicate that a frame was found. The 9 process of finding a frame is terminated at step 1850 which occurs after either step 1820 or 20 step 1830.
21 The process of reading a frame in the preferred embodiment is shown in figure 19. At 22 the start 1900 the variable 't' contains the frame to be read. The first step 1901 consists of 23 executing the find frarne process (as shown in figure 18) to search for a frame with tag 't'.
24 Next, step 1902 determines whether a frame was found. If no frame was found, the process 25 continues at step 1910 which sets the return value to indicate that no frame was found. If 25 step 1902 determines that a frame was found, the process continues at step 1903. This step 27 retrieves the data from the frame slot, using the variable 'store_idx' which was set by the 28 'find frame' process of step 1901 to locate the proper frame slot. It then checks whether 29 the checl~cllm field has the right value. If this is not the case, the process continues at step 30 1930 which wipes the NBROK variable to 0 to enter the 'broken' mode, and jumps to the 31 reset process for proper 'broken' mode processinp If step 1903 finds the right chec~ m 32 value, the process continues with step 1920 which sets the return value to the frame data CA 022l8l78 l997-08-08 WO 96/25814 PCT~US9~.J~176 and indicates that the frame was found. The process of reading a frame is terrninated at step z 1940 which occurs after either step 1910 or 1920.
3 Figure I ~ shows the process of starting an update sequence in the preferred embodi-4 ment. At the start of this process 1300 another update can already be in progress, in that s case both updates are combined into a single multi-update. In step 1301 the variable VN~U
is inspected. If it is not equal to 1, then another update is already in progress, and no new 7 update needs to be initi~li7ed; the process continues at step 1310. If step 1301 finds that a the variable VNIU has a value of 1, it continues processing at step 1302. Step 1302 sets 9 both NrU and VNIU to zero, a~er which it continues with step 1310. Step 1310 terminates c the process.
~1 Figure 14 shows the process of deleting a frame in a frame slot in the pre~,led embodiment. At the start 1400 the variable 'i' contains the slot index number ofthe frame slot in which the frame to be deleted resides. The first action 1401 is to execute the 'start update' process as shown in figure 13 to be sure an update is in progress. In next step 1402 the i'th bit of the CLCOM variable is set to 1, after which the process terminates in step ~~ 1410.
Figure 15 shows the process of writing data in a frame in the p,~:~" ed embodiment.
At the start lS00 the variable 't' contains the tag value of the frame to be written, the 9 variable 'access' contains the access control code for the frame to be written, and the zo variable 'data' contains the data for the frame to be written. The first step 1501 executes l the 'start update' process shown in figure 13. The next step 1502 executes the 'find frame' z process of figure 18 to locate any existing frame with the same tag value. The next step z3 1503 inspects the return value of the 'find frame' process to determine whether a frame z4 was found. If this is not the case, the process continues with step 1506. If step 1503 s determines that a frame was found, the process continues with step 1505. Step 1'.05 z6 executes the 'delete frame' process for the frame slot which contains the frame that was 7 found in step 1502. The index value of the frame slot that was found was stored in the z~ variable 'store_idx' by the 'find frame' process and is used here as an input to the 'delete z~ frame' process to indicate which frame slot should be deleted. A~er step 1505 the process continues at step 1506. Step 1506 consists ofthe 'find frame' process of figure 18 to 1 search for a frame slot with a tag field value of zero. The next step 1507 inspects the result z of step 1506 to determine if such a frame slot was found. If no frame slot was found, the 3 process continues with step 1520 which jumps to the cancel process of figure 8, which will CA 02218178 1997-08-08 PCTrUS95/01765 be described more fully later. If step 1507 determines that a frame slot was found, the 2 process continues with step 1508. In step 1508 the bit corresponding to the frame slot that 3 was found by step 1~06 is set in the CLCAN variable. The index number of the frame that 4 was found by step 1506 was stored in the 'store_idx' variable, which is now used to set the s proper bit. The next step 1509 writes new data in the frame slot which was found by step . lS06 The tag field, access field and data field are written with the value of the 't' variable, 7 'access' variable and 'data' variable respectively. The cher~ m field of the frame slot is 9 written with the proper checksum value. The next step 15~2 tc.~-~h.ales the process.
9 Figure 17 shows the 'commit' process in the preferred embodiment. The process ~o starts at step 1700 and continues at step 1701 which determines whether the VNIU variable ~- is equal to 1. If this is the case, the process continues at step 1730. ~f step 1701 finds V~IU
12 to be equal to zero, the process continues at step 1710. In step 1710 the first action is to 13 set the COM variable to 1. The CLCAN variable is then wiped to 0. Next, for each bit in ~~ the CLCOM variable which is equal to 1, the frame slot that is associated with that bit is ~s cleared. Clearing a frame slot consists of wiping the tag field to a 0 value. Subsequently, 16 the CLCOM variable is wiped to 0, after which the COM variable is reset to 0. Processing ~7 the continues at step 1721 which sets the NIU variable to 1. The next step 1722 sets the 18 VNIU variable to 1, and the process continues at step 1730. Step 1730 terminates the 19 commit process.
Figure 8 shows the 'cancel' process in the preferred embodiment. The process starts 21 at step 1750. The next step 1751 deterrnines whether the V~IU variable is equal to 1. If 22 this is the case, the process continues at step 1770. If step 1751 determines that VNIU is x. not equal to 1, it continues at step 1751. In step 17S1, the first action is to wipe the COM
24 variable to 0. Then the CLCOM variable is wiped to 0. Next, for each bit in the CLCAN
25 variable which is equal to 1, the frame slot that is associated with that bit is cleared.
26 Clearing a frame slot consists of wipina the tag field to a 0 value. The last action in step 27 17Sl is wiping the CLCAN variable to 0. After step 1751 the NIU variable is set to 1 in 25 step 1761. The next step is 1762 where the VNIU variable is set to 1. The process then 29 continues at step 1770. In step 1770 the 'cancel' process is terminated.
30 Figure 16 shows the ~reset' process in the preferred embodiment. The process starts 31 at 1600. The next step 1601 inspects the NBROK variable to determine whether its value is 32 equal to 1. If this is not the case, the process continues with step 1610 in which the ~3 NBROK variable is wiped to zero. A~er step 1610 the next step is 1611 which sends all CA 022l8l78 l997-08-08 PCTfUS9S~01 76S
WO 96~25814 ~ public data in the non-volatile memory to the terminal. After step 1611 the process 2 continues again at step ' 611 in an infinite loop. If step 1601 determines that NBROK is 3 equal to 1, the process continues at step 1602. Step 1602 inspects the NrU variable to determine whether it is equal to 1. If this is the case, the process continues at step 1641. If s step 1602 finds that NrU is not equal to 1 the process continues at step 1603. Step 1603 inspects the COM variable to determine whether it is equal to 1. If this is the case, the 7 process continues at step 1630. If this is not the case, the process continues at step 1620.
8 In step 1620 the first action is to wipe the COM variable to 0. Then, the CLCOM variable 9 iS wiped to 0, aRer which all ~rame slots whose representative bit in the CLCAN variable ~0 are 1 are cleared. Clearing a frame slot consists of wiping the tag field to a 0 value. A~er ~- this, the CLCAN variable is wiped to zero, and the process continues at step 1640. In step 2 1630 the first action is to set the COM variable to 1. Then, the CLCAN variable is wiped to .3 0, after which all frame slots whose representative bit in the CLCOM variable are 1 are 4 cleared. Next the CLCOM variable is wiped to 0, and finally the CQM variable is wiped to 0. The process continues at step 1610. In step 16'~0 the variable NrU is set to 1, and the 16 process continues at step 1641. In step 1641 the variable VNIU is set to 1, after which the ~7 process is termin~ted in step 16S0. The 'reset' process functions either as a 'cancel' ~~ process if no commit was in progress, or as a 'commit' process if a commit was in .~ progress.
The 'commit', 'cancel' and 'reset' processes together also keep counters which 21 indic~te how many times a 'commit' process was completed, and how many times a 22 'cancel' process was completed. These counters are stored in a frame, which is updated 23 after each 'commit' or 'cancel' process (this includes the 'commit' and 'cancel' parts ofthe 24 'reset' process). The details of these counters and thelr updates have not been shown for 2s clarity. The counters are used to generate unique challenges.
26 In the preferred embodiment, the 'reset' process is executed after any interruption.
27 For example, but without limitation, when the card is powered up, or after a reset of the 2B card. A multi-update typically consists of a sequence of 'read frame', 'delete frame' and 29 'write frame' processes in any order. A multi-update is usually terminated with a 'commit' - 3~ process or a 'cancel' process. If the card is interrupted during a multi-update, it will resume 3. with the 'reset' process after the interruption.
32 It is believed that the processes shown in figures 8, 13, 14, 15, 16, 17, 18, and 19 33 together provide the following functionality: Frames can be read using the 'read frame' WO96/25814 PCTrUS95/01765 ~ process at any time. The data returned will always be the data that was last written with 2 that tag value. The first 'delete frame' or 'write frame' process starts a multi-update. A~er 3 a 'delete frame' process, the frame that was deleted can no longer be read using the 'read 4 frame' process. A~er a 'write frame' process, the data returned by the 'read frame' process s is the data last written with that tag value. If a 'cancel' process is executed, all modifications done in the multi-update are reversed. The 'read frame' process will now 7 return the same information as it did before the start of the multi-update. If the multi-update is interrupted, then the 'reset' process which is executed after each interruption has the same effect as a 'cancel' process would have had before the interruption: all lc modifications to the data in the storage system are reversed. If a multi-update is termin~ted ~- with a 'commit' process, then all modifications are retained, and it is no longer possible to t2 reverse the modifications. If a 'reset' process is executed a~er a 'commit' process, the t3 modifications are all retained. ~c~llming a non-volatile memory model as shown in figure 14 I 1, if the card is (possibly repeatedly) interrupted at arbitrary moments during the .s processes mentioned, it is believed that the effect will either be that of a 'commit' process ~~ at the end of a multi-update, or that of a 'cancel' process at the end of the multi-update.
t7 Furthermore, unless the 'commit' process was already started, the effect will always be that ~~ of a 'cancel' process. This provides what is usually called an atomic update of a d~t~b~ce.
t9 Either all the changes are made, or none of the changes are made. This property is retained 20 even under arbitrary interruptions.
2t It is believed that the effects of W erasing as shown in figure 1 1 are limited to the 22 following effects. Frames can be erased, and in any multi-update the update of any one 23 frame can be prevented. This implies that the atomic update property is lost under W
24 erasing. However, it is believed that any practical UV erasing will result with high 25 probability in the card entering the 'broken' mode. It is filrthermore believed that UV
26 erasing can never be used to create new frames, or alter the data of a frame SESSIONS
27 The basic structure of a session as implemented in the prere" ed embodiment is 2~ shown in figure 24. A session starts of with a 'start session & proof keys' process 2401.
29 Then follows one or more 'command & data exchange' processes 2402, after which the 30 session is terminated by a 'commit session & end session' process 2403. Both the card and 31 the terminal are involved in a session. Each of these participants keeps a session state as CA 022l8l78 l997-08-08 WO 96/25814 PCTnUS9SI01~6 will be described more fully later. Throughout the session, the session states kept by the 2 card and the terminal should be identical. As will be described more fully later, the session 3 states on both sides are updated using a chaining function which has been chosen in such a 4 way that it implements an iterative cryptographic hash function. The purpose of a session is s to link several independent actions together in such a way that they behave as a single indivisable action. An independent action can be any type of action, and could even be a 7 session itself. Typically an independent action would be a fairly simple actions, such as 8 reading or writing a frame, but it is believed that some applications require the use of fairly 9 complex independent actions.
.o The 'start session & proof keys' process as implemented in the preferred embodiment ~- is shown in figure 25. This process involves the terminal 103 which executes steps 2501 12 and 2505, and the card 102 which executes steps 2503 and 2507. The process starts at step 13 2S01. The terrninal selects which keys will be used in the session, and chooses a terrninal .~ challenge value. As the last action of step 2S01 the terminal sends the terrninal challenge lS value and the choice of keys to the card in message 2502. When message 2502 is received 16 by the card, the card starts execution of process step 2503. The first action in step 2503 is 17 to choose a card challenge. Next the session state is initialized to a known value to start the ~~ chain. Next, all the keys selected by the terminal in step 2501 and indicated in mess~ge 19 2502 are chained. As described more fully later~ the ch~ining involves using a ch~ining 20 function to update the session state based on the other data (in this case the keys). The next 21 action is to chain the terminal challenge, and then the card challenge. As the last action of 22 step 2503 the card sends the card challenge in messaoe 2504 to the terminal. When 23 message 2504 is received by the terminal, the terminal starts execution of process step 2~ 2505. In step 2505 the first action is to initialize the session state to the same starting value 25 as used by the card to initiali7e the session state. Next, all the keys selected in step 2501 are 2tl ch~ined, the terminal challenge is ch~ineri. and the card challenge is chained. This should 27 result in the session state of the terminal having the same value as the session state of the 28 card at the completion of step 2503. The ne~;t action in step 2505 is to encrypt an 29 a~thPntication code which functions as proof that the terminal has indeed chained the ~ 30 proper keys. The last action in step 2505 is for the terrninal to send the proof in message 31 2506 to the card. When the card receives message 2506 it starts execution of step 2507 of 32 the process. The card decrypts the proof sent by the terminal and verifies it against the 33 current sessions state. If this verification fails, the process is aborted. If the verification is .
W O96/25814 PCTrUS95/0176~
~ successful, the card sets a state indicator 'in session', and the process is terminated. The 2 card retains the information regarding which keys were chained during this process, so that 3 it can be used to determine access rights to different frames in this session. The terminal 4 and card challenge values will typically vary over time and can, for example, but without s limitation, be chosen using a random generator. In the preferred embodiment the card challenge consists ofthe 'cancel' counter and the 'commit' counter.
7 The keys mentioned above are stored in frames in the card. Each frame that contains 8 a key is partitioned into two halves. The first half usually contains a diversification number, 9 the second half contains the secret key data. The frame can be read using the standard 'read 10 frame' process, provided the terminal has access as specified by the access field of the ~. frame. When a frame cont~ininsg a key is read, the part cont~ining the secret key is replaced 12 by zeroes, preventing the secret key data from being read. For some applications, the key is 13 diversified: the secret key used by the card (and stored in the second half of the key frame) 14 iS a function of a master key and the diversification number stored in the first half of the 15 frame. A terminal with access to the master key first reads the diversification number by reading the key frame, computes the secret key used by the card and can thus start a 17 session with this key. Note that access to the diversification number can be protected by 18 another key by setting the access field of the key frame to a proper value.
19 The 'command & exchange data' process as implemented in the plefel-ed 20 embodiment is shown in figure 26. Each 'command & exchange data' process consists of z- an elementary function, for example, but without limitations, reading a frame and writing a 22 frame. The first step ofthe process 2601 is executed by the terminal. The first action is for 23 the terminal to select a command. The last action of step 2601 is for the terminal to send 24 the command data to the card in message 2602. When message 2602 is received by the 25 card, it start execution of process step 2603. The first action in this step is for the card to 25 check whether it is in a session. If this check fails, the process is aborted, otherwise the 27 process continues with the next action. The command data received in message 2602 is 28 chained (thus updating the session state) and the command is executed. Execution of the 2~ command can involve several actions, for example, but without limitation, the reading, 30 deleting and writing offrames, as shown in figures 19, 14, and 15. Any response data from 31 the card to the terminal is then chained. As the last action of step 2603 the card sends the 32 response data in message 260~ to the terminal. Upon reception of message 2604 the 33 terminal starts execution of process step 2605. The first action is to chain the command WO 96/25814 PC7'nJS9SJl~76~5 ~ data originally sent to the card. The next action is to chain the response data of the card.
2 The process is then termin~te~ The command data and the response data are also 3 encrypted using the then-current session state as a key, but this is not shown for clarity. If 4 the command involves access to frames, then the card verifies whether the key which is s required for that operation was used in the 'start session & proof keys' process of this session. For example, if the terminal reads a frame, the card ensures that the keys used to 7 create the session state allow read access to the frame using the 'access' field of the frame.
8 A similar verification is made for writing and deleting frames.
9 The 'commit session & end session' process as implem~nted in the pl~f~lled embodi-~o ment is shown in figure 27. In the first step of this process 2701 the terminal chains the ~- command code for this process. It then encrypts a proof using the current session state. As ~2 a last action in step 2701 the terminal sends the proof to the card in message 2702. Upon 13 reception of message 2702 the card starts execution of process step 2703. The card also ~4 chains the command code for this process, and the decrypts the proof sent by the card in ~s message 2702. If the proof is invalid, the process is aborted, otherwise it is co~tinlle~l The 18 card then increments a commit counter and encrypts a second proof using the session state.
~7 Optionally the card also creates a public proof'proofP', and stores these proofs in non-18 volatile memory. The last action in step 2703 is to send a message 2704 to the terminal ~9 indicating the card is ready to commit to the session. Upon reception of message 2704 the 20 card starts execution of process step 2705. The only action in this step is for the terminal to 21 send a message 2706 to the card indicating it should commit to the session. Upon reception 22 of message 2706 the card starts execution of process step 2707. The first action is to set 23 the COM variable to one. This is in fact the first action of step 2710 in figure 17 which 24 shows the 'commit' process, all other actions already explained in figure 17 not being 25 shown for clarity. At the same time the NDONE variable is set to one, indicating that the 26 proof of this session has not successfully been sent to the terminal. Setting the NDONE
27 variable and the COM variable should be atomic, which is achieved by setting the NDONE
28 variable in the 'commit' process, in the 'reset' process if it finds the COM variable to be 29 one. The NDONE bit is set to zero during the 'cancel' process and the 'reset' process if it 30 finds the COM variable to be zero. The card then sends the second proof, and optionally 3- the public proof to the terminal in message 2708, after which the card completes the 32 'commit' process of figure 17. Upon reception of message 2708 the terminal starts 33 execution of process step 2709. This involves decrypting the second proof, and optionally W O96/2581~ PCTrUS95/01765 the public proof. If the proofs are satisfactory, the terminal sends a message 2710 to the 2 card. Upon reception of message 2710 the card starts execution of process step 2711 3 which clears the NDONE bit to 0. As will be obvious to someone ordinarilly skilled in the 4 art, the NDONE bit can also be stored in a frame which is always updated during a session.
This automatically solves the problem of setting the NDONE and COM variables at the same time.
7 This process is only relevant for sessions in which a frame was written or deleted. An 8 update of the frame system, as described earlier, will start at the first write or delete g operation. The 'commit session ~ end session' process is the usual way in which the ~o 'commit' process of figure 17 is executed which then terminates the update.
As long as the NDONE bit is one, the terminal can ask the card to re-send the second 12 proof, and optionally the public proof, both of which are still retained by the card. This is 13 shown in figure 32. The process starts at step 3200 in which the terminal sends the 'Get 14 Proof' command to the card in message 3201. Upon reception of message 3201 the card 15 starts execution of process step 3202. If the NDONE bit is still one, and thus the proofs are .~ still available, the card sends the proofs to the terminal in message 3203. If the ~DONE bit .7 is zero, then no proofs are sent. When the terminal receives message 3203 it starts lB execution of process step 3204 in which it verifies the proofs and sends the 'Done' 19 command to the card in message 3205. Upon reception of message 3205 the card starts 20 execution of process step 3206 in which it sets the NDONE bit to zero. This implies that 21 the proofs can no longer be read by the terminal.
22 It is believed that step 2705 and the messages 2704 and 2706 allow the terminal to 23 bring the card to the very edge of the commit without actually doing it. It is believed that if 24 at this point the terminal resets the card, then all frames revert to the value they had before 25 the session, as the COM variable has not yet been set. It is believed that the additional step 2~ 2705 decreases the amount of time between the final message from the terminal to the card, 27 and the sending of the proof in message 2708. It is believed that the setting of the COM bit 28 in step 2707 has the result of both updating all the frames to their new value and enabling 29 the proof to be sent.
The session state, which is maintained both by the card and the eerminal, is used to 31 link all the actions in a session together. Figure ''0 shows the basic idea. Suppose the 32 terminal wants to read a specific frame from the card in a 'command & exchange data' 33 process of figure 26. The actions of the card are shown in as item 2000 and the actions of =
PCTrUS95/01765 ~ the terminal are shown as item 2020 The card takes the existing session state 2011 and the 2 data read from the frame 2013 as inputs to a function 2010. This fi~nction combines the 3 existing session state 2011 with the data 2013 and yields a new session state 2012. The ., same two inputs are also combined in a ~lirre-el-t way to yield the encrypted data 2014 s which the card sends to the terrninal. The terrninal has a similar process in which the 6 existing session state of the terminal 2031 and the encrypted data just received from the 7 card 2033 are used as inputs to a function 2030 which yields both a new session state 2032 and the decrypted data 2034. These functions are chosen in such a way that if the ~istin~
session states 2011, and 2031 are identiç~l, then the two new session states 2012, and 2032 ~o are identical, and the decrypted data 2034 is identical to the original data input 2013. When .. the terminal sends data to the card, the same system with the roles reversed is used. The 2 updating ofthe session state is the chaining referred to earlier. The functions 2010 and 13 2030 are chosen in such a way that they implement an iterative cryptographic hash function .~ on the data that passes through them, the session state being the hash output.
In figure 20 there are two functions 2010 and 2030. As the card can be both sender .~ and recipient, it would need an implementation of both functions. To simplify this, the 17 ptere"ed embodiment uses the solution in figure ''1. The card has an imple.nentaLion ofthe 18 function 2110, and the terrninal an implementation of box 2130. The existing session state .~ is still used as inputs 2111 and 2131 to the functions, and both yield the new session state 20 2112 and 2132 as outputs. When the card wants to send data to the terrninal, it uses the 21 data input value 2113. Function 2110 updates the session state, and encrypts the data 22 depending on the session state and outputs the encrypted data as 2114. This value is sent to a the terrninal, which uses it as input 2133 to function 2130 which also updates the session 24 state and decrypts the data to provide output value 2134. Functions 2130 and 2110 are ~s ~u~ktha~, if the existing session states 2111 and 2131 are identical, the output data 2134 is 2~ equal to the input data 2113, and the new session states 2112 and 2132 are also identical. If 27 the terrninal wants to send data to the card, it uses the data as input 2133, and the existing 28 session state as input 2131. The function 2130 has two output values, 2132 which is the 29 new session state, and 2134 which is the encrypted data. The terminal sends the encrypted ~ 30 data to the card, which uses it as input 2113 to function 2110 (which takes the existing 31 session state as input 2111). Function 2110 yields two outputs, the new session state 2112 32 and the decrypted data 2114. Functions 2110 and 2130 are such that in this case too, if the W O96/2581~ PCTrUS95/01765 ~ existing session states 2111 and 2131 are identical, then the data output 2114 is equal to 2 the data input 2133, and the new session states 2112 and 2132 are also identical. Thus, the 3 same function is used for both sending and receiving.
4 The construction offunction 2110 in the preferred embodiment is shown in fi~ure ''2.
s Item 2200 corresponds to function 2110. It tal;es two inputs, the existing session state 6 2201 and the data input 2202, and yields two result values, the new session state 2204 and 7 the data output 2203. The session state 2201 is used as input to a cryptographic oneway u function 2210 marked 'ksb' which produces the encryption/decryption value 2211. This is xorred with the data input 2202 by function 2212 which yields the data output value 2203.
~o The data output value 2203 and the existing session state 2201 are then used as input to the chain function 2213 which yields the new session state 2204 as an output. In the preferred 12 embodiment, both the oneway function 2210 and the chain function 2213 are different 13 functions every time this function is computed in a session.
1~ The construction offunction 2130 in the preferred embodiment is shown in figure 23.
15 Item 2300 corresponds to function 2130. It tal;es two input values, the existing session ~~ state 2301 and the data input 2302 and yields two result values: the new session state 2304 17 and the data output 2303. The existing session state 2301 is used as input to a 18 cryptographic oneway function 2310 marked 'ksb' which yields the encryption/decryption 19 value 2311 which is xorred with the data input 2302 by function 2312, yielding the data 20 output 2303. The existing session state 2301 and the data input 2302 are used as input to 2- the chain function 2313, which yields the new session state 230~ as output. The constituent 22 building blocl;s of function 2300 and 2200 are identical in their functionality.
23 It is believed that the session system provides the following functionality: The 24 terminal can only start sessions with a keyset for which the terminal has access to all those 25 keys. If the terminal does not have access to the keys, the verification in step 2507 will fail 26 with high probability. If an adversary that has access to only a proper subset of the keys in 27 use tries to eavesdrop, she will not be able to read the actual data being exchanged between 2e the card and the terminal as the data is all encrypted using the session state. It is believed to 29 be impractical for the attacker mentioned before to reconstruct the session state without 30 access to all of the keys used. If an attacker tries to add certain commands to a session, 31 then the session state of the card and the terminal will no longer be the same. This results 32 with high probability in a failed proof in step 2703, which in turn results in an aborted 33 transaction. This automatically results in a cancellation of any multi-update that is in WO 96/2581~ PCTAUS95101765 progress. The session system links all actions together, and ensures that if any data in the 2 card is modified, it is done by exactly the commands chosen by the terminal, and that the 3 comm~n~lC are executed in order. The terminal can still choose in step 270S whether to complete the session and commit to all the updates, or to abort the session, and thereby the s associated multi-update. If the card is interlllpted at any point during a session, the G associated multi-update has not finished which results in the card reverting back to its 7 original state. If the card is interrupted after setting the COM variable to I in step 2707, for 8 example by an inadvertent power down, then the terminal can still recover the second proof 9 (called 'proo~~' in figure 27) and the optional public proof. If the card is interrupted before ~o the COM variable was set, the proofs cannot be retrieved from the card. This implies that, even under arbitrary interruptions of the card, either the multi-update happens and the 12 terminal can read the proofs, or the multi-update is canceled and the terminal does not get 13 the proofs.
1< It is anticipated that the card can store data about past transactions. This hlfo.l,ldLion 15 can later be used for many purposes, for example, but without limitation, for accounting and testing purposes, or to possibly reverse the effects of a completed transaction.
SECRET KEY DEBIT/REDEBIT
17 Apart from reading and writing frames, the preferred implemPnt~tion also supports a 18 debit/redebit process which makes for an easier implementation of a pre-paid card for 19 payments. This allows a balance register (sometimes called a balance) stored in a frame to 20 be decreased (debited) by a specific amount using a different access key then the key used Zl to write that frame. The redebit process allows the terminal to decrease the previous value 22 of the register if, and only if, that terminal was the last one to perform a debit or redebit 23 process on that register, this being protected by some simple ~uthentication codes. During a 2~ redebit process the terminal must send the session state that was in use during the previous 25 debit/redebit process on that balance register. As the debit/redebit process usually uses the 26 session proof as a proof that the debit was performed, the usual arrangement is for the 27 terminal to have a tamper-resistant device which has the keys necessary for this process, 28 which keeps track of the total amount that has been debited in this way, and which securely 29 stores the temporary key which allows the terminal to execute a redebit process with the 30 card. A typical application for the redebit function would be for a coffee m~clline Once the 31 user has selected the required drink, the terminal debits the card for the amount of the drink CA 022l8l78 l997-08-08 W O 96/2581~ PCTAUS95/0~76 ~ and starts the machine. If the machine fails to provide the drinl; (for example due to a 2 malfunction) the terminal can do a redebit command with a 0 decrement effectively giving 3 the money back to the owner of the card. As both the debit and the redebit process require ~ a different access key then the write-frame process requires, the terminal in the coffee m~chine does not need to have access to a key which would also allow the terminal to increase the value of a card. The details of this process are not shown, and will be obvious 7 to someone ordinarily skilled in the art.
CONSTANT TIMING
The main use of tamper resistant computational devices, such as the card in our 9 system, is to keep certain data secret and to securely execute some processes. Even if the ~o function is only to execute some processes securely, the only way for the outside world to .. know that the card actually performed the process and that the results are genuine is for the 2 card to authenticate the results of the process. This is generally done using cryptographic 3 authentication systems, which require the storage and use of some secret key information.
Most designs take proper care to ensure that the secret keys are kept secret and not sent ~s out by the card. However, most designs are done on the level of the communication ~~. between the card and the interfacing device (terminal).
7 For this section we will assume that the terminal is trying to extract additional 8 information from the card by any means. Apart from the standard communication, the 19 terrninal can measure several other things, such as the time between a command and its reply, or the power supply current that the card draws at any moment. These measurements 21 have the potential of revealing more information about the internal operations in the card.
22 It is believed that at least one actual implementation of a smart card suffers from a these problems. The card in question has a special co-processor on chip to allow it to do 2- RSA signatures. It is believed that the terminal can determine when the co-processor is 2s being used by measuring the power supply current as a function of time and the electro-26 magnetic field around the smart card chip. The RSA algorithm involves an exponentiation 27 with a secret exponent. The exponentiation is, in this implementation, done using a square-28 and-multiply algorithm well known in the art. This algorithm involves a large number of 29 squarings interlaced with a smaller number of multiplications. Measuring the activation times of the co-processor allows the terminal to deduce whether the next step is a 31 multiplication or a squaring. With this knowledge the actual secret key used by the card in 32 creating the RSA Cipn~tllre can easily be recovered.
WO 96/25814 PCTrUS95)D~765 It is believed that public-key algorithms are generally more susceptible to this kind of 2 attack then secret key algorithms. but many secret key based systems still suffer from these 3 attacks. If, for example, a PIN verification routine in a smart card co~ al es each digit in 4 sllcc~ssion and aborts the comparison as soon as a micm, tch is found, then the time s between the start of the verification command and the 'PIN incorrect' response reveals which of the digits is wrong. It is believed that this reduces the average number of attempts 7 that have to be made before the right PIN is found in an attack from 5000 to less then 40 8 for a 4-digit decimal PIN. Similar attacks are believed to work against certain secret-key 9 based impleme~t~tions. An obvious solution is to ensure that all processes which might ~o reveal additional information to the terminal are executed in a fixed amount of time. It is ~- believed that this can be achieved by inserting properly timed delay loops at appropriate 12 places.
13 It is believed that many existing smart card implementations will reveal the presence 14 of a file or directory on the card by the timing differences of the responses. Even in cases t6 where the terminal does not have access to said file or directory, the timing of the response ~ will differ depending on whether the file or directory exists or whether it does not exist.
17 Furthermore, several smart card impl~mtont~tions will reveal the presence of files and/or 18 directories to any terminal, even if the terminal has no access to the related smart card 19 application. It is believed that it is standard practice for a smart card to reveal its identity 20 number to any terminal. It is believed that terminals might use this information to invade 21 the privacy of the owner of the smart card.
22 It is believed that for least one specific smart card chip it is possible to determine 23 which instruction is being executed by detailed measurements of the power supply current 24 as a function of time, allowing the terminal to determine which half of an IF st~tPment was 25 executecl, even if the time taken for both branches was the same. As is usual in the art of 26 cryptography, we always assume that the actual code used in the card is known to any 27 ~tt,.cl~er. It is a well established principle of cryptography and security systems that the 28 security should only rely on the secrecy of key material, and not on the secrecy of the 29 processes applied to the keys.
In the preferred implementation the card is careful not to reveal any additional 31 information under these attacks. To ensure security against these attacks the card uses a 32 single execution path. This means that for any process involving information which is not 33 already known to the terminal, and to which the terminal might not have access, the same W O96/25814 PCTrUS9S/0176 sequence of instructions is always used. For example, in the computation of a house such as 2 figure 9, the architecture (number of columns and height of each column) is not secret from 3 the terminal, but the actual values are. For any given ar~hitectllre, the card always uses the 4 same sequence of instructions to compute the house result value 979 from the house origin s value 901, independent of the value of the house origin 901.
6 An example of how this is achieved is given in figure 31. The first process consisting 7 of steps 3100, 3101, 3102 and 3103 show a typical conditional execution sequence.
Starting at 3100 the first step 3101 verifies a certain condition 'cond'. If this condition is 9 false the process continues at step 3103, otherwise it continues at step 3102. In step 3102 a 10 counter 'cnt' is incremented, and two variables 'savel' and 'save'" are assigned with ~1 values 'x' and 'y' respectively. After step 3102, processing continues in step 3103 where 12 the process is terrninated. The second process consisting of steps 3110, 3111, 3112 shows 13 a functionally equivalent process which does not use a conditional execution construction.
1~ After the process start in step 3110, the first action in step 3111 is to convert the condition 15 'cond' to an integer value which is 0 if the condition is false, and 1 if the condition is true.
16 There are standard techniques for converting conditions to such an integer value which are 17 widely used in certain higher-level language implementations. In step 3111 the value 'cond' is used to represent this value. The counter increment is now replaced by an addition: the ,~ value 'cond' is added to the counter. This has the same effect as incrementing the counter 20 only if 'cond' equals 1. If the condition was false, then 'cond' is 0 and the operation has no 21 effect. If the condition was true, 'cond' has a value of I and the addition adds exactly one 22 to the value of 'cnt'. The action 'savel=x' is converted to a more complex action 23 'savel=cond*x+(1-cond)*savel'. If the condition was false, then 'cond' is equal to 0, and 2'~ thus 'cond*x' is also equal to zero. At the same time '(l-cond)' is equal to 1, and thus '(1-25 cond)*savel ' is equal to 'savel '. The sum of both expressions is equal to 'savel ', so that 25 the assignment has no effect. This is of course equivalent to the skipping of this action in 27 the first process. If the condition is true, then 'cond' is equal to 1 and '(l-cond)' is equal 28 to 0, so that the right hand side of the acsignment has a value equal to 'x'. This is of course 29 equivalent to the action 'savel=x' in the first process which is only executed if the 30 condition is true. The third action shows another equivalent formulation, the variable ~1 'save'~' is replaced by an array with indexes '0' and ' I '. The value of 'y' is assigned to 32 'save''[cond]', which implies that if the condition is true then 'y' is assigned to 'save~[l]' 33 and if the condition is false then 'y' is assigned to 'save2[0~'. If the original 'save2' variable _ CA 022l8l78 l997-08-08 W O96/25~14 PCTnUS95101~65 is put in the new 'save'~[l]' and save~[0]' is discarded after the process, then 'save2[1]' 2 will have the same value as the variable 'save~' had after their respective processes, 3 ~ssumin~ an equivalent starting state. These new actions in step 3111 are called 4 functionally equivalent to the actions in step 3102 which are only executed if the condition s 'cond' is true. The process terminates in step 3112.
As a more detailed example we will discuss figure 18 which shows the 'find frame' 7 process rliccussed before. In the preferred implementation, this is one of the processes that 8 uses a fixed execution path. The loop consisting of steps 1802,1803,1804, and 180~is executed a fixed number of times, namely once for each frame slot. The number of frame 10 slots is not a secret, so no special care has to be taken. However, the conditional execution ~1 by steps 1802 and 1803 might reveal if and where in the memory the frame was found, 2 while this data might not always be available to the terminal. Thus, steps 1802 and 1803 are 3 implemented in a single execution path using the techniques shown in figure 31. Steps ~4 1810,1811,1820 and 1830 are also implemented using a single execution path, this involves rewriting the actions of steps 1820 and 1830 into a single sequence of actions .~ which depends on the values of two conditionals. This is a simple generalization of the ~~ techniques shown in figure 31 and as will be obvious to someone ordinarily skilled in the 18 art. The jump to step 1840is not done within the single execution path. This enters ~9 'broken' mode, which basically prevents any further normal proc~ssin~ It is believed that it iS unnecessary to hide this fact from the terminal, as it will be quite obvious to the terminal 21 that the card has entered 'broken' mode.
22 In the preferred embodiment the single execution path is used for all processes for 23 which the execution path taken might reveal any information to the terminal which the 24 terminal would otherwise not learn. It is believed that this provides the best security against 2s any of the attacks mentioned above. Obviously the single execution path does not imply 28 that the same data is always being used in the actions. It is believed that no implementation 27 using secret keys can be protected against an attacker which is able to determine both the 28 execution path, and the data being used in the process.
EMV
The preferred embodiment includes an implementation of the EMV system. It is 30 appreciated that someone of ordinary skill in the art would be familiar with the 31 specifications of the EMV system which were referenced earlier. The preferred W O96125814 PCTrUS9S/0176S
embodiment implements the EMV system and incorporates several improvements, among z others a dynamic off-line authentication of the data sent by the card to the terminal.
3 The preferred embodiment is shown in figure 28. The process starts at the terrninal in 4 step 2800, which is followed by step 2801 in which the terminal asks the card for the s application data. This request is coded into message 2802. When message 2802 is received s by the card, it starts execution of process step 2803. In step 2803 the card sends the 7 application data requested to the terrninal in message 2804. In the EMV system and in the 8 preferred embodiment this sending of application data is actually achieved using several 9 requests in sequence, these are not shown for clarity. Upon reception of message 2804 the 10 terminal starts execution of process step 2805. Execution of steps 2805, 2807, 2808, 2809, 2811, 2812, 2814, 2816, and 2817 occurs only when the transaction is conducted on-line.
12 In the off-line case these steps are omitted (see EMV specifications for more detail). It 13 constructs an authorization request and sends it to the issuer, or a representative of the 1~ issuer in message 2806. When message 2806 is received by the issuer~ it starts execution of 15 step 2807, in which it processes the authorization request. The next step 2808 consists of 1G the creation of a valid script for the terminal, after which both the authorization response 17 and the script are sent in step 2809 to the terminal in message 2810. When message 2810 is 18 received by the terminal it start processing of step 2811. In step 2811 the terrninal 19 processes the script it received from the issuer, this involves sending the commands and 20 data given in the script to the card and awaiting any response. The EMV specifications 21 allows the script to be executed before or after the external authentication in steps 2812, 22 2814 and 2815. Both possibilities are shown in figure 28, and a simple extension would 23 allow two scripts to be used. Our p,efe-,~d embodiment typically executes the script in step 24 2811. ~er step 2811 the terminal in step 2812 sends the authorization code to the card in 25 message 2813. The card verifies the code in step 281'1 and sends the result ofthe 26 verification to the terminal in messa~e 2815. Upon reception of message 2815 the terminal 27 executes process step 2816 in which it verifies the response. The next step 2817 is again 28 the execution of a script with the card (see comments for step 2811). All actions described 29 SO far are an embodiment ofthe EMV specifications. In step 2818 the terminal requests a 30 payment proofofthe card, which it sends in message 2819. Upon reception of message 31 2819 the card executes step 2820 in which it computes the appropriate payment proofand 32 sends the result to the terminal in message 2821. Upon reception of message 2821 the CA 022l8l78 l997-08-08 terminal starts execution of process step 2822 in which it verifies the proof of payment, 2 after which processing terminates at step 2823.
3 Most of the steps described above correspond directly to actions specified in the EMV specs. The ~), ere. ~ed embodiment adds a dynamic authentication to the EMV
s specifications. In the EMV system there is no provision for convincing the terminal of the 6 53llth.onticity of the card and the messages the card sends in the off-line case. The proof of 7 payment of step 2820 (called TC in EMV) is based on a secret key proof, and it is believed 8 that it is not the intention to let the terminal verify the TC. Therefore, in the off-line case in 9 EMV the terminal is susceptible to replay attacks, as are well known in the art. The ~o pl efe., ed embodiment uses the compact endorsement signatures to rectify this. In step ~. 2820 a second element is added to the payment proof. The TC is still sent, but in addition ~2 the card ~llthenticates all the data it sent to the terminal during the transaction using a 3 compact endorsement sign~tllre in the variant that can authenticate an arbitrarily long 1- message, as described earlier. If message 2821 is lost during transmission then the terminal 15 can ask the card to retransmit the daea, in the same manner as the proof(s) of a session can 16 be retransmitted, as shown in figure 32. It is believed that the terminal can verify the ., compact endorsement Cign~ture and thus be assured of the authenticity of the data sent by .~ the card, and therefore also of the correctness of the TC.
~~ The script that the issuer creates can be used to securely perform a variety of func-tions, a typical application would be the increasing of a balance of some form. The scripts 21 are just a set of comm~nrlc which the terminal sends to the card. These are chosen in such a 22 way by the issuer that they constitute a session, as described earlier. A direct session 23 between the card and the issuer to increase a balance would involve more then 2 messages 2~ between the terminal and the issuer: the start session process alone would require 2 2s messages between the card and the issuer (and therefore between the terminal and the 26 issuer). The old limit would have to be read, and then the new limit written requiring more 27 messages. Most existing networks for financial transaction authorization are built upon a 2 2~ message authorization, adding additional messages could lead to complications. The 29 plef~:l I ed embodiment uses the sessions in a different way, allowing the increase to occur using the existing sessions and using only 2 messages between the terminal and the issuer.
3- As mentioned before, the card challenge consists of some counters. These counter values 32 are included in the data sent in messages 2804 and 2806. The issuer now has enough 33 information to simulate the behaviour of the card in the session, specifically it knows the O96/25814 PCTrUS9S/01765 ~ card challen~e that the card will use. This allows the issuer to generate all necessary 2 messages for the succescfill completion of a session. ~nstead of a special 'add amount to 3 balance' function, the pr~fe,led embodiment uses the standard read frame and write frame functions. To this end, the current value of the balance is also included in mess~g~c 2804 s and 2806. The issuer includes a 'read frame' function in the script. The issuer already 6 knows the answer, but the answer is also chained into the session state, as described earlier.
7 If the balance was changed to a different value before the execution of the script, this will result in a different chain state in the card, which results in a failed proof in the 'commit 9 session & end session' process. As an example, but without limitation, a complete script 10 would consist of a ~start session & proof keys' command, a 'read frame' on the balance, a 'write frame' on the balance, and a 'commit session & end session' comm~nd To prevent 12 the terminal from withholding the script, the authorization code sent in message 2813 13 depends on the data of the script, so that the authorization will fail if the terminal does not 14 execute the script. As will be obvious to someone ordinarilly skilled in the art, the ~s authorization code can also be used to notify the card that a script is to be performed in 16 step 2817.
17 The process of performing a script is shown in more detail in figure 33. The process 0 begins at step 3300 at the terminal and continues at step 3301 where the terrninal sets an 19 index variable 'n' to zero. The next step 3302 checks whether the 'n'th command in the C script exists. If the 'n'th command does not exist, processing continues at step 3309. If the 21 'n'th command does exist, processing continues at step 3303. In step 3303 the terrninal 22 sends the command and associated data of the 'n'th command in the script to the terminal 23 in message 3304. Upon reception of message 3304 the card starts processing of step 3305 ~ in which it performs the actions associated with the command and sends the response to the 25 terminal in message 3306. Upon reception of message 3306 the terminal starts processing 25 of step 3307, in which it checks the response message for an error code. If the card 27 reported an error, processing continues at step 3310. ~fthe card did not report an error, the 28 process continues at step 3308, in which the terminal increments the ~n' variable by one.
29 The process then continues at step 3302. In step 3309 the terminal signals a successfill ~ completion ofthe script process. In step 3310 the terminal signals a failure in the script 31 process. In either case the process continues with step 3311 where the process is 32 terrninated.
~ The EMV specifications include some unspecified 'risk management' which the card 2 performs, some specific 'risk management' which the terminal performs, an unspecified 3 authorization process which the issuer performs for on-line transactions. The plef~, I ed embodiment uses a general structure which can be used to implement both credit card s transactions, pre-paid debit card transactions, ATM card transactions etc. The card keeps a 6 balance representin~ the amount that can still be spent using that application. In every 7 succescfill payment, the card decreases this balance by the amount of the payment. The 8 card will refuse an off-line payment for an amount that exceeds the balance in the card, and 9 will request an on-line transaction. To increase the balance of the card, the issuer can send ~o the appropriate comm~nrls in the script which increase the balance. In the preferred embodiment the card increases the ATC (Application Transaction Counter) only for 12 succeccfi-lly completed transactions.
13 In the prefe"ed embodiment, once the the card has issued an ARQC and thus asked for an on-line transaction, the card will not perform any off-line transactions until a 15 successful on-line transaction has been completed.
In the preferred embodiment the issuer keeps a database of all on-line requests, and ~7 of all the payment data it receives from the terminals (possibly through the acquirer) 8 relating to off-line payments. For any off-line or on-line payment, the ATC value of the 19 card is included in the data that reaches the issuer. For on-line transactions, the balance of the card is included in the data that is sent to the issuer. The information related to different 21 transactions might reach the issuer in a non-chronological order. As the card increases the 22 ATC only for successful transactions, the issuer knows exactly how many 'previous' 23 transactions it can still expect. Specifically, in any on-line transaction, the issuer leams the 24 current ATC of the card, and therefore knows how many off-line transactions the card 2s made since the previous on-line transaction. The issuer also learns the current balance of 2~ the card, and can thus determine the total amount of the off-line transactions since the 27 previous on-line transaction. It is beiieved that this provides adequate information to the 28 issuer to make the necessary decisions for the on-line transaction, and any possible script to 29 increase the balance on the card.
The interaction between the card and the issuer are shown in figure 47. This shows 3- the card 4700, the temminal 4704 and the issuer 4706. The card has a balance (CB) 4701, a 32 cryptogram counter (ATC) 4702 and some card counters 4703. In the preferred 33 embodiment there are two counters, one of them is incremented for each 'commit' process, W 096/2581~ PCTrUS95/01765 ~ the other is incremented during each 'commit' or 'cancel' process. These counters are used 2 as the card challenge in the sessions. The card and terminal communicate over 3 communication channel 4720; the terrninal and the issuer communicate over 4 communication channel 4721. During a transaction the terminal typically sends a single s message to the issuer, which replies with a single message. The issuer uses three d~t~bases:
the card base 4708, the event base 4709 and the terminal base 4710, and comrnunicates 7 with those data bases using communication channel 4722. The terminal base contains data associated with each terminal, and is not shown in detail for clarity. Figure 48 shows the 9 data fields of a record in the card base. The first field 4800 contains the primary account .c number (PAN) and the sequence number. This is a unique identification of the card, the primary account number usually corresponds to the credit card number, or bank account 12 number, while the sequence number distinguishes several cards that use the same PAN, for t3 example, but without limitation, two credit cards on the same account. The next field 4801 ~~ contains information about the card status and configuration, which is not shown in detail for clarity. In field 4802 the highest known ATC of the card is stored. Field 4803 stores the 6 ATC value of the last completed on-line transaction, that is, for which the issuer has 7 received the corresponding TC. In field 4804 the issuer stores the ATC value for the last ARQC it received. In field 4805 the issuer m~int~in~ the known card balance KCB, which 1~ is the issuers best approximation of the current balance of the card. The last field 4806 20 contains a settling amount SA, which is the amount the issuer plans to add to the card's 21 balance in the next on-line transaction. Figure 49 shows the fields of a record of the event 22 base, each record representing an event. The first field 4900 contains the PAN and 23 sequence number, which uniquely identifies the card. The field 4901 contains the ATC of 24 the event, field 4902 the status of the event, field 4903 the amount of the event, field 4904 25 the card counter values for the ever,t, field 4905 the card's balance during the event, and 2~S finally field 4906 the settling data for the event.
27 Figure 50 shows a global overview of the issuer processing during an on-line transac-28 tion. In the first step 5000 the issuer receives the authorization request for the transaction, 2i~ inclu~in~ terrninal data and card data. The terminal data typically includes the terminal 30 identity; the card data typically includes the PAN and sequence number, the amount of the 31 transaction, the current value of the card counters, the card balance, the current atc etc. In 32 the next step 5001 the issuer makes some elementary checks on the validity of the data 33 received. In step 5002 the issuer updates the known balance KCB based on the actual carc _ O96125814 PCTrUS9510176S
~ balance CB. In step 5004 the issuer checks for a settling amount for the card, and adds it to 2 the script amount. In step ~005 the issuer decides whether or not to accept the transaction, 3 and finally in step 5006 the issuer sends the authorization for the transaction to the 4 terminal, with an optional script to perform any necessary adjustments of the balance.
s Figure ~ l shows a global overview of the issuer processing when it receives the transaction B data relating to an off-line transaction from a terminal. In the first step 5100 the issuer 7 receives the transaction data, which typically includes a terminal identifier, card data, the 8 amount and a transaction cryptogram. In the next step 5101 the issuer checks the validity 9 of the terminal and card data. In step 5102 the issuer checks the validity of the transaction, ~o among other things it checks that the cryptogram is correct. In the final step 5103 the .. issuer updates the known card balance KCB based on the card balance given with the 2 transaction.
~3 Figure 52 is in two parts, shown as figure 52A and figure 52B. It shows a more ~4 detailed description of the issuer processing during an on-line transaction shown in less ~s detail in figure 50. Some steps of this processing are not shown for clarity. The first step ~ 5200 is the start of the process. At this point the issuer has already received the 17 authorization request, incl~lrling the card identity, the terminal identity, the ATC, the ~ ARQC, the amount, the card counters, the card balance CB etc. In the next step 5201 the 19 issuer sets a variables called 'script amount' to zero, and a variable called 'temp kcb' to the 20 given card balance CB. The 'script amount' variable will contain the amount for which a 21 script will be generated, the 'temp kcb' is used to update the KCB stored by the issuer. The 22 issuer looks up the record for the card in question in the card base, and also the record for 23 the terminal in question in the terminal base. The issuer verifies that the ARQC cryptogram ~ is valid, that the terminal is valid, that the card is valid, that the card has not exceeded its 25 expiration date and that the card has not been blocked. In the next step 5202 the issuer 26 checks whether the HATC (highest known atc) is less then the current ATC. If this is not 27 the case the process continues at step 5213, as indicated by the labels 5250 and 5212. In S this case the ATC of the card is lower then the highest l;nown ATC from that card, so the 29 card's ATC must have decreased. A proper functioning card never decreases the ATC,so 30 this is classified as an 'card fraud detect', an attempted fraud by the card, which is practice 31 means that the tamper-resistance of the card must have been broken, that the card must :!12 have malfunctioned, or that something else in the system is wrong. If the condition in step 3 5202 is true, the process continues at step 5203. In step 5203 the issuer checks whether the W 096/2581~ PCTrUS95/01765 ATC is equal tO the ATC of the last authorization request. ~f this is the case, procPscing 2 continues at step 5204, if this is not the case processing continues at step 5214. If the ATC
is equal to the LAATC, then the last transaction was not completed successfully, as the 4 ATC would have increased had it completed succecsfi~lly. Thus, getting a second s authorization request with the same ATC value implies that the previous transaction was not completed. It is, however, possible that the script was executed but the transaction 7 didn't complete. As all scripts in the preferred embodiment modify the card balance, the 6 issuer can detect whether the script was performed or not. It is anticipated that for scripts 9 that do not modify the b~l~nce, some other value will be used for this function. In the o pler~lled embodiment, the card will not perform an off-line transaction after a failed on-line transaction, so no off-line transactions can occur between a failed on-line transaction and 2 the next on-line transaction. In step 5204 the issuer checks whether a script was issued 13 during the last authorization request, by looking up the recorded events in the event base. If 14 no script was issued, and thus no update of the CB is still outstanding, the process ~s continues at step 5205, otherwise it continues at step 5206. In step 5205 the issuer checks whether the balance recorded in the event base for the last authorization request is the same 17 as the current card balance. If this is not the case, processing continues at step 5213 (via 18 5210 and 5212). Otherwise, processing continues at step 5223 (via 5211 and 5222). In step 19 5206 the issuer checks whether the CB is equal to the balance recorded in the event base 20 during the previous authorization request. If this is the case, processing continues at step 2- 5208, otherwise it continues at step 5207. In step 5207 the issuer checks whether the card 22 balance is the sum of the balance recorded for the previous authorization request and the 23 update amount of the script issued during that authorization process. If this is not the case, 24 the card balance has changed in an inexplicable way, and processing continues at step 5213 2s (via 5210 and 5212), otherwise processing continues at step 5209. In step 5208, the issuer 26 knows that the script of the previous on-line transaction was not completed, and adds the 27 update amount of that script to the 'script amount' variable. In the next step 5209 the 26 issuer marks the record in the event base that contained the information about the script of 29 the previous on-line transaction as either 'completed' or 'incompleted'. That script is then 30 no longer outstanding. After step 5209 processing continues at step 5223 (via 5211 and ,- 5222). In step 5213 the process stops and has detected an error. In step 5214 the issuer 32 checks whether the last authorization request atc LAATC is equal to - 1. If this is the case, ,3 processing continues at step 5219, otherwise it continues at step 5215. The value -1 is used CA 022l8l78 l997-08-08 W O 96/2581~ ~T~US95JD1765 to indicate that the last authorization request was part of a succ~ssfi~l transaction. In step 2 5215 the issuer checks in the event base whether there is still an outstanding script to 3 update the CB. If this is the case, processing continues at step S217, otherwise it continues at step 5216 where the ~temp kcb' variable is set to the value of the balance during the last s authorization request. In step S217 the 'temp kcb' variable is set to the sum of the balance 6 during the last authorization request and the amount of the update of the outs~n~iing 7 script. In the next step 5218 the script in question is marked as 'completed', thus removing it from the 'outct~nf~ing~ state. In steps 5217 and 5218 there was an Oll~ script, and 9 now a new ATC is seen by the issuer, thus the previous authorization transaction was 10 s~lccessfillly completed. At the start of step 5219 the 'temp kcb' variable is an upper bound on the current balance of the card, and in step 5219 the issuer checks whether the card ~2 balance CB is larger then 'temp kcb'. If this is the case, processing continues at step 5213 13 (via 5220 and 5212), otherwise it continues at step 5223 (via 5221 and 5222). In step 5223 4 the issuer checks whether the settling amount is positive. If this is not the case, processing ~s continues at step 5225, otherwise it continues at step 5224 where the settling amount is ~s added to the 'script amount' variable, a~er which processing continues at step 5225. In ~, step 5225 the issuer first verifies that the amount of the transaction is at most the sum of lB the current card balance BC and the 'script amount' variable. If this is not the case, the card 19 balance is insufficient and the issuer does not give an authorization for the transaction. Next 20 the issuer checks whether the script amount is not zero. If this is not the case, processing 21 continues at step 5227, otherwise it continues at step 5226 in which the issuer creates a 22 script for the card using the data available, adds the essPnti~l script inform~tion to the event 23 base, and sets the settling amount in the card base to zero, after which processing continues 2~ at step 5227. In step 5227 the issuer checks whether LAATC is not equal to - 1, and 25 whether ATC is greater then LAATC. If this not the is the case, processing continues at 2~ step 5229, otherwise the process continues at step 5228 where the LOATC value is set to 27 the LAATC a~er which processing continues at step 5229. In step 5229 the issuer adds a 28 record to the event base cont~ining the essenti~i information about this transaction. In the 29 next step 5230 the issuer updates the LAATC value to ATC, the HATC to ATC- 1 and the ~ 30 KCB value to CB, after which the process is terminated in step 5231. A~er the process the 31 issuer sends a reponse to the terminal, cont~ining the authorization cryptogram, the 32 optional script etc.
WO96/25814 PCTrUS95/01765 ~ Figure 53 shows a more detailed description of the issuer processing when it receives 2 the transaction data of an off-line transaction, which was shown in less detail in figure 51.
3 Before the start of the process, the issuer receives the transaction data, typically including the card PAN and sequence number, the amount, the terminal id, the ATC, the card balance s etc The issuer retrieves the record associated with that card from the card base. The issuer verifies the validity of the various identities, and checks that the transaction cryptogram TC
7 iS valid. The issuer looks up the PAN/sequence number/ATC combination in the event base 8 to check that this transaction number has not occurred before. The process starts at step 9 5300. In the next step 5301 the issuer checks whether ATC is greater than HATC the 10 issuer has for that card. If this is not the case, the process continues at step 5303, otherwise it continues at step 5302 in which the HATC value is set to the ATC value, after which the 12 process continues at step 5303. These steps ensure that the HATC value is m~int~ined as 13 the largest ATC value for which a valid TC was received. In step 5303 the issuer checks .~ whether LAATCis equal to - I and ATC is greater or equal to LAATC. If this is not the ~s case, the process continues at step 5309, otherwise it continues at step 530~. In step 5304 the issuer sets the LOATC to LAATC, and sets the LAATC to -1. This serves to m~int~in 17 the LOATC value, which is defined as the last ATC value for which the issuer knows an 18 on-line transaction was successful with that card. In the next step 5305 the issuer checks 10 whether a script was issued during the last on-line transaction by lool;ing in the event base.
20 If this is the case, processing continues at step 5307, otherwise it continues at step 5306. In 21 step 5306 the issuer sets the KCB value to the card balance that the issuer received during 22 the last authorization request, and continues at step 5309. This is an upper limit to the 23 current card balance. In step 5307 the issuer sets the KCB value to the sum of the card 24 balance during the last authorization request and the amount of the update value used in the Z5 script of that request. This again is an upper limit to the current card balance. In the next 2~5 step 5308 the issuer marks the event record associated with that script as 'completed'. In 27 step 5309 the issuer checks whether ATC is greater or equal to LOATC, if this is the case 28 then the amount of the transaction is substracted from the KCB value in step 5310. The 29 process terminates in step 5311.
It is believed that the processes shown in figures 52 and 53 implement a secure 31 method for m~n~ging the card balances, ensuring that the card does not get a higher 32 balance than intended, and that any attempted increases in the balance of the card are 33 completed.
WO 96/2581~ PCTJIJS9SJ1~1765 ~ The processes shown in figures 52 and 53 are fairly specific to the card as imple-2 mented in the preferred embodiment. Depending on various implem~nt~tion details, the 3 exact order and type of actions in the issuer processes might vary, as will be obvious to someone ordinarilly skilled in the art.
s For a credit card application the balance would be the OTB (Open To Buy). This is 6 the amount of money that the user can charge to the credit card before a tr~nc~ctiQn will be 7 refused. It is believed that most current credit cards have such an OTB limit (sometim~s called the credit limit). It is believed that having the card m, int~in the OTB allows off-line 9 tr~n~ctions to occur without the risk of excee~lin~ the OTB. Under some circ~lm~t~ncec .o the OTB should be increased, a typical example of such a circumstance is when the user has .. paced an outstanding credit card bill: the amount paid can be added to the OTB. Typically 12 this will not be communicated to the card directly, as there is no communication link 13 available. The card continues to use its old OTB value, until an on-line transaction occurs.
14 One of the possible reasons for an on-line transaction is that the OTB in the card is 15 e~ch~ ted. During that transaction the issuer can send a script to the card increasing the OTB tc~ the new val~-~ a~ ~ wi~ furth~r ~ tr~r.s2Gti~n to o~CIlF. It is be~e~ed that 17 the p-efe,led embodiment can be used in this way with only a small fraction ofthe 18 transactions being on-line, and without compromising security. The credit card might also 19 be used to perform traditional credit card transactions, not using the EMV system. This 20 might result in the OTB being decreased without the card's knowledge. It is believed that 21 the issuer can use the script to reduce the OTB in the card. As will be obvious to someone 22 ordinarilly skilled in the art the issuer might also split the 'real' OTB of the credit card, and 23 give part of it to the card for use in off-line transactions, while keeping the other part in at 24 the issuer for use in traditional credit card transactions. It is believed that using the script, 25 the issuer can in such a setting increase or decrease the card's OTB depending on the OTB
2G rem~ining at the issuer, thus balancing the two OTBs in case one of them is depleted more 27 then the other.
28 For a pre-paid debit application the balance would, eprese,ll the amount of money 29 stored on the card. During payments this amount typically decreases. Again the card can do 30 an arbitrary number of off-line transactions until the balance has been e~h,.usted. In an on-31 line transaction, the issuer can increase the balance using a script. In pre-paid applications 32 this would require the user to pay the issuer for the additional money that it puts on the 33 card. This might for example, but without limitation, be accomplished by integrating a bank W O96/25814 PCT~US95/0176 account withdrawal (similar to the cash withdrawals at current ATMs). During an on-line 2 transaction, the card has already been authenticated. The EMV specifications already allow 3 a cardholder verification procedure to be included, such as the entry of a PIN code. The 4 card authentication and the PrN code entry provide the same functionality as current cash 5 withdrawals at ATMs, and could possibly be used in a pre-paid withdrawal where the 8 cardholders bank account is debited, and the balance on the card is credited. In the preferred embodiment the card has an option to require a PIN during a transaction, in that D case the card will not complete a transaction without a valid PIN, such a m~ncl~tory PIN
9 enforced by the card is not included in the EMV specifications. As will be obvious to ~o someone ordinarilly skilled in the art, such mandatory verifications enforced by the card can also be applied to any other cardholder verification method.
12 For an on-line debit application the balance itself is not really necessary. The balance 13 can be rendered ineffective by various means, amonn others giving it a very large value.
14 The card authentication and the cardholder verification mentioned above can be used to ~s directly debit the cardholders banliaccount in an on-line transaction, which might also credit .~ the terminal owner's bankaccount at the same time.
17 It will be obvious to a person of ordinary skill in the art that a single card can contain 18 several EMV compatible applications, and can thus be used for several of these ~~ applications.
CARD ~NSTRUCTIONS
In the preferred embodiment the card is a smart card, and communicates with termi-21 nals using the ISO 7816 standard protocol. In this protocol the terminal issuer a sequence 22 of comm~n~ls to the card. Every command consists of a command header sent from the 23 terrninal to the card, some optional data transfer from the terminal to the card and an 2J optional data transfer from the card to the terminal, and finally a result code sent by the 25 card to the terminal. An overview of the sequence in which the commands are meant to be 26 used is shown in figure 29. The card does not allow any other sequence. At any point in 27 time the terrninal can start at step 2900, follow the arrows and issue the comm~nds in the 28 order encountered. After step 2900 the terminal continues either at 2901, 2920, 29tl or 29 2930.
In step 2901 the terminal sends the first of two command that together implement the 31 start session process of figure ''5. Subsequently in step 2902 it sends the second command CA 022l8l78 l997-08-08 WO96/2~814 PCTnUS9~01765 ~ of the start session process. The terminal then sends one or more commands from the set 2 'get frame' 2903, 'put frame' 2904, 'debit frame' 2905, 'redebit frame' 2906, 'kill frame' 3 2907 and 'public debit' 2908. After this sequence of comm~n-ls the terminal sends a 4 'commit' command which termin~t~s the session, and executes the 'commit' process s described earlier. After a session the terminal can start again and issue the 'get proof' COll~"~a~ld 2920 to get the proofs from the previous session, and the 'done' command 2921 7 when the proof has been sl-cceccfully read. The commands mentioned so far implement the 8 basic card functionality.
The EMV implement~tion is largely separate and conforms to the EMV specifications 10 mentioned above. It starts at step 2930 in which the terminal sends a 'select file' comm~ntl which is repeated any number of times. To start a new transaction, the terrninal continues 2 with step 2931, to get the transaction proof of the last transaction again the terminal issues 3 the 'get last AC' command 2940 after step 2930. In step 2931 the terminal issues the 1~ 'manageapplication 1' co,.""~n~ afterwhichitentersaloopinwhichitexecuteseitherof ~s the comm~n-lc ~get file' 2932 and 'get data' 2933 one or more times. Af~Ler this loop, the i~ te~ninal send~ ~he 'veriry' ~ommand 2934 one or more times. ~xecution of the veri~,~
17 command is optional under some circumstances, but this is not shown here for clarity.) The 18 next step is for the terrninal to send the 'generate AC 1' command. For an off-line 19 transaction the terrninal continues at step 2939, for an on-line transaction the terminal 20 continues at step 2936 in which it sends a sequence of commands from a script to the card.
21 The comm~nds that can appear here in 2936 are exactly those that appear in the dotted 22 frame 2910 and are not shown in detail for clarity. Execution of step 2936 is optional. The 23 next command is 'external authenticate' 2937, after which the terminal sends the 'generate 24 AC 2' command in step 2938. Command 2937 and 2938 are optionally. Finally the terminal 25 sends a 'manage application 2' comm~nd.
2~3 For an off-line transaction, the correspondence between figures 28 and 29 are as 27 follows: The steps 2930 and 2931 are administrative and not shown in figure 28. The steps 28 2801 and 2803 are implemented using the commands 2932 and 2933. Command 2934 is 29 not shown in figure ''8 for clarity. For an off-line transaction, steps 2805 till 2817 are not 30 exec~lted. Steps 2818 and 2820 correspond to command 2935, the next col,l"~and the 31 terminal issues is 2939 which is not shown in figure 28 for clarity.
32 For an on-line transaction the correspondence between figures 28 and 29 are as 33 follows: The steps 2930 and 2931 are administrative and not shown in figure 28.
W O96/25814 PCTrUS95/0176'.
~ Com m~n-l~ 2932, 2933 and 2935 together implement steps 2801 and 2803, the command 2 2934 not being shown in figure 28 for clarity. The script of step 2811 corresponds to 3 com m~ntlc 2936 which basically involves an arbitrary session. The external ~-t'rl~nticate 4 command 2937 corresponds to steps 2812, 2814, 2816. Step 2817 is not supported in the s command set shown in figure 29. Steps 2818 and 2820 are implemented by command 6 2938, while command 2939 is not included in figure 28 for clarity.
7 Figures 34, 35, 36, 37 and 38 show the detailed steps of all the comm~n-lc Every 8 command consists of three steps, we will use the 'start session 1 ' command as an example.
The first step 3400 is executed by the terminal. The terminal sends a message 3401 to the lo card which includes a command code to tell the card which command is being executed, ~- and which might include some other data. When the card receives the message 3401 it 12 starts execution of the second step 3402. This involves the card sending a message 3403 13 back to the terminal. This message consists of some optional data, plus a result code. When 14 the message 3403 is received by the terminal, the terminal starts execution of the third step ~s 3404. No action is taken in the third step apart form the analyses of the contents of the last 16 message. Each command corresponds to a single APDU, but might be implemented as two 17 T=0 commands as described in the ISO 7816 standard. This same structure is repeated for 18 each ofthe comrr~ncis. The same structure is repeated for all commands, the items (3400, ~~ 3401, 3402, 3403, 3~S04) corresponding with (3410, 3411, 3412, 3413, 3414), (3420, 20 3421, 3422, 3423, 3~24), (3430, 3431, 3432, 3~33, 3~34), (3500, 3501, 3502, 3503, 21 3504), (3510, 3511, 3512, 3513, 3514), (3520, 3521, 3522, 3523, 352~), (3530, 3531, 22 3532, 3533, 3534), (3600, 3601, 3602, 3603, 3604), (3610, 3611, 3612, 3613, 3614), 23 (3620, 3621, 3622, 3623, 3624), (3630, 3631, 3632, 3633, 3634), (3700, 3701, 3702, 24 3703, 370~), (3710, 3711, 3712, 3713, 3714), (3720, 3721, 3722, 3723, 3724), ~3730, 25 3731, 3732, 3733, 3734), (3800, 3801, 3802, 3803, 3804), (3810, 3811, 3812, 3813, 2t; 3814), (3820, 3821, 3822, 3823, 3824), (3830, 3831, 3832, 3833, 3834), and (3930, 3931, 27 3932, 3933, 3934) respectively. We will refer to any one of these commands by the number 28 of their first step Z9 In the 'start session 1' command 3400 the terminal sends a bitmask which indicates 30 which keys will be used in the session, and the terminal challenge. This corresponds to step 31 2501 in figure ''5. The card sends the card challenge back, corresponding to step 2503. In 32 the 'start session 2' command 3 l lO the terminal sends the card the proof that it knows the 33 keys, corresponding to step 2505. The card responds with onlv a response code. In the 'get W O 96~2581~ PCTnUS9~D~765 ~ 7_ frame' command 3420 the terminal sends the tag field of the frame to be read to the card, 2 and the card replies with the (encrypted) card data, plus an authentication (proof) of this 3 data. In the 'put frame' command 3~30 the terminal sends the tag, the access field value, the data and an al~thentic~tion proof to the card. The card sends a response code. In the s 'kill frame' command 3500 the terminal sends the tag of the frame to be removed, and an 6 ~llthentication proofto the card. The card responds with a response code. In the 'debit 7 frame' command 3510 the terminal sends an identifier of the balance to be debited, and an a amount to be debited. The card subtracts the given amount from the balance indicated and 9 sends a response code. In the 'redebit frame' command 3520 the terminal sends an ~0 identifier of the balance to be redebited, the amount of the redebit, and the redebit key. The .. card replies with a response code. In the 'public debit' command 3530, the terminal sends 12 the balance indicator, the amount of the payment, and the random challenge to the card.
13 The card replies with a response code. In the 'commit' command 3600 the terminal sends 14 the session proof to the card. the card replies with a response code. In the 'done' command ~s 3610 no additional data is exchanged. In the 'get proof command 3620 the terminal sends .~ oniy the command header to the card. The card replies with the session proof, and 17 optionally the public proof. In the 'select file' command 3630 the terminal sends an AID or 18 RID to the card which replies with an FCI. In the 'manage application 1' command 3700, ~~ the terminal sends an 'init' code to the card which replies with a response code. In the 20 'manage application 2' command 3710 the terminal sends an 'exit' code to the card, which 21 replies with a response code. In the 'get data' command 3720 the terminal sends a data 22 object tag to the card, which replies with the data object. In the 'get file' command 3730 a the terrninal sends the file number and the record number to the card, which replies with the 24 requested record. In the 'generate AC 1' command 3800 the terminal sends the requested 25 AC type and the TDOL values to the card, which replies with an AC type, the AC and the 26 ATC. In the 'generate AC 2' command 3810 the terminal sends the requested AC type and 27 the card replies with the AC type, the AC and the ATC. In the 'external authenticate' 28 command 3820 the terminal sends the authentication proof to the card, and the card replies 2~ with a response code. In the 'verify' command 3830 the terminal sends the CVM method 30 and the CVM data to the card which replies with a response code. In the 'get last AC' 31 command 3930 the terminal sends only the command code to the card, which replies with 32 the AC type, the AC and the ATC.
W O96/25814 PCTrUS9S/01765 CLEA~niG l~IETHO DS
Once the transaction between the card and the terminal has been completed, there can 2 be a clearing process in which the information from different transactions are collected and 3 combined. The example of clearing we will use to describe the processes is the clearing of 4 financial payments. The card is used to perform payments to the terminal. One example of a s clearing system is for the terminal to send all the transaction data regarding the payments to 6 the acquirer/issuer which adds the amounts and credits the terminal's account with the total sum. The role ofthe acquirer lW is to collect information from several terminals, and B reimburse the terrninals in 'real' money for the payments they received. As the issuer hands o out the money and the acquirer receives it, there must be some kind of settlement between ~o the issuer and the acquirer. Typically the issuer and acquirer will be parts of the same ~- or~ni7~tion, or organizations that work closely together. We will describe several different 12 clearing methods that can be used under different circumstances.
13 Full data. One of the simplest clearing methods is for the terminal to retain all the 14 relevant data from the payment transaction with the card. During clearing the terminal ~s sends all data to the acquirer which verifies every transaction certificate and then credits the 16 terminal. This gives the acquirer access to all transaction details, at the cost of h~ndlin~
17 every transaction in full.
18 Truncating SAM. The terminal can also be equipped with a secure application 19 module (SAM). This is a tamper-resistant device made by the acquirer. The function of the 20 SAM is to verify the transaction data and add the value of all the received payments. The 21 transaction data is then discarded. This process is usually called truncation. During the 22 clearing process, the SAM informs the acquirer of the total amount received, and 23 cryptographically signs a message to this effect for the acquirer.
24 Truncating SAM with some individual payments. The terminal is again equipped 25 with a SA~I. As in the truncating SAM option, the SAM verifies the transaction data and 25 keeps the totals. However, not all transaction data is discarded, but some or all of the 27 transaction data for some of the transactions is kept. During the clearing process this data 21~ iS also sent to the acquirer. The selection process that chooses for which transactions 29 transaction data is retained can be performed in various ways, by the terminal, by the SAM, 30 or by a combination of the two.
31 Truncating SAM with skeleton transactions. A SAM in the terrninal is used to 32 verify all transactions. For each transaction, only skeleton transaction information is WO96/2581~ PC~rUS95J01765 ~ retained by the terminal. This would typically include the amount, date, time, card identity 2 (if available) etc. The skeleton data is sent to the acquirer during the clearing process. The 3 SA M ensures that the skeleton data sent to the acquirer is correct (by signing it using a 4 digital signature scheme), and mi~,ht optionally keep totals of the transactions and transfer s them separately to the acquirer.
Skeleton transactions with statistic~l checking. In this solution the terminal retains 7 all transaction data for all transactions. During the clearing process the terminal first sends 8 skeleton information for every transaction. This would typically include the amount and D some information which uniquely fixes the rest of the transaction data, such as a .o cryptographic hash on the rest of the transaction data. The acquirer then asks for the full tl transaction data for some of the transactions, which the terrninal sends to the acquirer. The 12 acquirer then verifies these transactions.
13 Binary h~sh tree with St~tiStiC:ll checking. This method is similar to the previous 14 one in that the terminal retains all transaction data Instead of sending skeleton information ~s about all the transactions, the terminal now sends only a fixed amount of data to the 1~ acquirer after which the acquirer can choose a subset of the transactions to inspect for 17 proper h~nclling The terminal builds a binary tree, where each node contains two values:
lB the amount and the hash. There is one leaf for every transaction, which contains the amount 1~ of the transaction, and the hash of the transaction data. The amount at each non-leaf node 20 iS the sum of the amounts in the subnodes. The hash value at each non-leaf node is a 21 cryptographic hash of all the data in the subnodes. The terminal sends the number of 22 transactions (which also determines the structure of the tree), plus the amount and hash 23 value of the root of the tree to the acquirer. The acquirer then selects a subset of the 24 transactions, and sends the selection to the terminal. The terminal responds by slontlin~ the 25 transaction data of the selected transactions, plus the amount and hash values at some of 25 the nodes. The choice of which nodes to send depends on the selection by the acquirer. The 27 nodes selected are those that are the root of a maximal subtree that does not contain a leaf 2~ of a selected transaction. In other words, those nodes whose hash does not depend on any 29 selected transaction, but whose parent node does depend on a selected transaction. Given 3~ these values the acquirer can verify the selected transactions, and verify those parts of the 31 binary tree that are on a path from the root to any one of the selected transactions.
32 In some of the clearing systems the issuer can keep track of all transactions that have 33 occurred. Although cards are tamper-resistant they are not tamper-proof. One attack is to _ W O96/25814 PCTrUS95/01765 'brea'~;' a card, extract all secret information from it and create many duplicate cards, this 2 attack is also called cloning. If each transaction has a unique number which the cards use in 3 sequence, then the issuer can detect the cloning as the cloned cards will either reuse old ~ transaction numbers, or they will use the numbers out of order. As long as the transaction s numbers are all sent to the issuer, this allows detection of this fraud. Once the fraud has been detected, the issuer can blacklist the cloned card.
7 If the card uses a general digital signature scheme, or a secret key based 3 authentication system, it is easy to include a transaction counter in the data being 9 authenticated. Most systems currently built and/or proposed actually have such transaction ~o counters. The compact endorsement signatures disclosed above do not have an inherent numbering, but this can be added. The houses in a town have already a number, and are t2 always used in the same order. The issuer can add a sequence number to each town it gives 13 to the card, and include this sequence number in the town signature. (This way, the town 14 signature is a signature on the sequence number and the town result value.) ~s The full data clearing system does not require a SAM but might lead to a large 15 amount of data being tr~ncmitted from the terminal to the acquirer. This can be costly 17 depending on the communication system used.
18 The SAM-based systems all need a SAM, which by itself can be an expensive piece of 19 equipment. In an environment with multiple issuers, either all issuers have to trust the same 20 SAM or each terminal needs a SAM for every issuer.
21 The last two clearing systems do not require a SAM, but let the terminal do most of 22 the truncation. If a terminal tries to defraud the acquirer/issuer then the terminal will be 23 caught with a certain probability by the statistical checking. Depending on the amount of 24 checking and the selection methods used by the acquirer the expected amount of successful 25 fraud by a terminal before being caught by the acquirer can be fixed. For example, but 2~ without limitation, if the terminal sends skeleton data for each transaction to the acquirer, 27 the acquirer can use the following algorithm to select transactions for fi~ll review. If the 28 amount of the transaction $100 or more then the transaction is selected. If the amount of 29 the transaction x is less then $100, then the transaction is selected with probability x%.
30 Thus, a transaction of $5 would be selected with a ~% probability. It is believed that using 31 this selection method the acquirer is ensured that the expected amount of succ~s.cfill fraud 32 by a terminal before being detected by the acquirer is $100.
WO 96/25814 PCTIUS95~0176 ~ As would be obvious to those of ordinary skill in the art, there are many çssenti~lly z equivalent ways to realize the inventive concepts disclosed. The particular choices that 3 have been made here are merely for clarity in exposition and are sometimes arbitrary. For 4 in~t~nce, without attempting to be exhaustive, there are many one-time signature structures, compression structures, hierarchical structurings, possible parameter values, and a so on.
7 It will also be obvious to those of ordinary skill in the art how parts of the inventive 8 concepts and protocols herein disclosed can be used to advantage without nec~s~ g the 9 complete preferred embodiment. This may be more fully appreciated in light of some ~o examples, where in some uses of the inventive concepts, multiple parties may be combined, ~- simple authorizations instead of actual messages may be used, implementations may involve 12 various hardware forms and memory types, and so forth.
13 Certain variations and substitutions may be apparent to those of ordinary skill in the 14 art. For example: most practical self-authenticating digital signature techniques could be .s applied instead of the RSA systems used as an example; compression functions may take 6 more than two inputs; hierarchies of compression functions may take any other treelike 7 form; and register re-use patterns that more evenly distribute certain types of access may be 1a ~lef~"ed for certain technologies.
19 While these descriptions of the present invention have been given as examples, it will be 20 appreciated by those of ordinary skill in the art that various modifications, alternate 21 configurations and equivalents may be employed without departing from the spirit and 22 scope of the present invention.
,
9 A pl efe- lt;d exemplary 3x4 town is shown in figure 5. The two-dimensional general ~o town 501 contains three constituent one-dimensional towns 502, 503, 504, each of which ~- contains four constituent houses. The town origin 505 is used as the house origin of each of 2 the houses in the town S60, 561, S62, 563, 530, 531, 532, 533, 510, 511, S12, 513. These ~3 houses each produce a house output value namely 564, S65, 566, 567, 534, 535, 536, 537, ~~ 514, 415, 516, 517 respectively. The house result values of the first one-dimensional town ~5 504 are combined by a chain of compress functions 568, 570, 572 that generates the ~ intermediate values 569 and 571 and the town result value 573 of town 504. The house 7 result values of the other one-dimensional towns are combined in a similar way, as shown 8 by 538, 540, 542, 539, 541, 518, 520, 522, 519, 521 which results in the town result values 9 543, 523 of towns 503, 502 respectively. The town result values 573, 543, 523 of the one-20 ~imencjonal towns 504, 503, 502 are combined in a similar way by functions 581, 583 and - intermediate value 582 which results in the town result value 584 of town 501.
TOWN CREATION
22 For the description of the processes that involve a town we will use the example as 23 shown in figure S. How these processes extend and generalize to a general town will be ~ obvious to someone ordinarily skilled in the art.
A town is created by choosing a town origin 505 and computing the town result 584 ~ from that. The town result is computed using a straightforward, although extensive, 27 computation involving the origin. As an example, but without limitation, an elegant way of 28 computing the town result 584 is shown in the figure 41. The houses are computed in the 29 order shown in the first column. The second column shows which values will be in memory 30 a~cer the house in the first column was computed. The last column shows which values are 31 in memory after applying any coll.p,ession functions whose input values are both in W O96125814 PCTrUS95/01765 memory. Af'Ler applying any compression functions, the next house is computed as shown 2 in the first column of the next row. The generalization to a general town is best described 3 recursively. It is believed that a singleton town like 403 can be computed with a fixed amount of memory, as it basically only involves computing a house. To compute the general town 401, we first recursively compute town 421, store the value 431, recursively compute town 422 with result 432, combine values 432 and 431 using co,l,piession 7 function 442 to value 452, compute the next town recursively etc. It is believed that by D interleaving the applications of the compression function with the computation of the 9 constituent towns, each recursion level uses a fixed amount of storage independent of the l0 number of constituent towns, so that the storage required to compute an entire town is only proportional to the number of dimensions of a town.
12 Once the town result 584 has been computed, the issuer signs this result using a 13 public key digital signature scheme. There are several ways in which this can be 14 accomplished. If the issuer is creating the town, then he just computes the digital Cign~ture 15 on the town result. This is shown in figure 10. The signing process 1002 takes two inputs .s namely the message to be signed 1001, and the secret key used to create a digital sign~h~re 7 1004. The output value ofthe signing process 1003 is called the digital sign~ture By using ~~ the town result 584 as the message input value 1001, the issuer can compute the digital 19 signature on the town result, which we call the town sign~t-lre. The town origin 505 and 20 the town si ,n~ture are then sent to the card 102 where they are stored in non-volatile 21 memory. It is anticipated that other data can also be included in the message being signed 22 as the town signature.
23 There are several other ways in which the town might be created. For example, but 24 without limitation, the card could choose a random town origin 505, compute the 25 corresponding town result 584, and send the town result to the issuer together with a 25 cryptographic authentication that convinces the issuer that the town result he receives was 27 computed by a valid card. The issuer then signs the town result to get the town ci~?n~tllre~
2~1 and sends the town signature back to the card. The card stores the town origin 505 and the 29 town sign~tllre in non-volatile memory. A blind Sjgn~tl~re scheme might also be used, 3C where the card first blinds the town result 584 before sending it to the issuer. Using a blind 31 digital sign~tllre scheme the issuer can sign the town result without ever learning the actual 32 value of the town result.
=
W O96/25X14 PCTnUS9001765 - 3~ -Using some or all of these creation techniques, the card can acquire one or more 2 towns, each of which consists of a town origin 50~ and a town signature. Reloading a card 3 with more towns would typically be one of the transactions which the terrninal might J perform with a card.
HOUSE SPENDING
s The process of using the houses is called spending. In this process the card uses a 6 house to sign or ~uthenticate a message, for example, but without limitation, the card can 7 use a house tO create a message to the terminal which represents a certain amount of money, which the terminal can verify for validity without having access to any secret cryptographic keys.
~o The basic spending process is described in figure 30. This process is an example of a ~- wide class of cryptographic protocols known as commit-challenge-response protocols.
12 These are well known in the art, and have been used in a variety of zero-knowledge 13 protocols, identification protocols, signature schemes etc. Some examples of such protocols are the Guillou-Quisquater protocol, Feige-Fiat-Shamir protocol etc. A commit-15 challenge-response protocol starts with one party (the prover) sending a commit mPcs~ge 1~ to the other party (verifier). The verifier then chooses a challenge which it sends back to .7 the prover. Finally, the prover sends a response to the verifier. The prover will ~ypica!ly use 18 the commit value, the challenge value and some other (secret) data to compute the 19 response. The verifier will typically be able to verify that the response is correct based on 20 the commit value and the challenge value. It will typically be the case that a ch~ting prover 21 can provide correct commit and response rness~ges if he can guess the value of the 22 challenge in advance. The number of dirrel en~ possible challenge values is thus an important 23 aspect of these kind of protocols. If the number of different challenge values is small, then a 24 single execution of the protocol process will not convince the verifier very much, and the 25 execution will have to be repeated to fully convince the verifier. This is used on many zero-2B knowledge protocols. If the number of different challenge values is large, then the protocol 27 can be converted to a ~ign~tllre scheme by defininSg the challenge to be chosen as the 2~S cryptographic hash of the message to be signed and the commit value sent by the prover.
2S~ This ~limin~tes the need for interaction and allows the prover to send all the data in a single 30 message to the verifier. This conversion is again well known in the art, and is for example 31 used in the Fiat-Shamir sign~tllre scheme. In several schemes the amount of computational W O96/25814 PCTrUS95/01765 work increases when the number of possible challenge values is increased, making it 2 desirable to keep the number of challenge values to a minimurn The spending process will 3 now be described, which is a specific embodiment of a comrnit-challenge-response protocol in which the card is the prover and the terminal is the verifier.
s The process in figure 30 starts at step 3000 at the card which sends a commit value to the terminal in message 3001. The purpose of the comrnit value is to fix the house the 7 card will use in the spending. For example, but without limitation, the commit value could o consist of the town .cign~ture, the town result value and an iclentific~tion of the house 9 within the town. When message 3001 is received by the terrninal, the terrninal starts ~o execution of process step 3002. The terminal stores the commit value, and chooses a random challenge c. As the last action of step 3002 the terminal sends the challenge c to the 12 card in message 3003. The terminal might use various means to generate the random 13 challenge c For example, but without limitation, this could include a real random number 14 generator, a pseudo-random number generator etc. The challenge chosen could also ~o depend on information sent by the acquirer or issuer to the terminal, thus taking away some ~o freedom from the terminal which is believed to make some attacks harder to perform.
~7 When message 3003 is received by the card, it starts execution of process step 3004 in ,~ which the card computes the response associated sends the response to the terminal in 19 message 3005. When message 3005 is received by the terminal, it starts execution of 20 process step 3006 in which the terminal verifies that the response matches with the commit 21 value and the challenge.
22 The commit value must uniquely identify and authenticate the house that will be used 2~ by the card in this process. This typically involves identif~ing the town and the house within z~ the town. The town is authenticated by the town signature. To properly ~uth~nticate the 25 house, several intermediate values in the town must also be sent to the terminal, either in 215 the commit message or in the response message. For example, in figure 5 if house 532 is 27 used, the following values are sent to the terminal: S36, 539, S37, 573, S23. (Value S36 is 20 not strictly necessary as it can be computed from other response data, but in the preferred 29 implementation it is sent as it is believed that this is easier.) Using these values, the terminal 30 can verify that the house with house result value 536 is indeed a constituent house of the 31 town 501. The terminal applies the various compression functions to compute the town 32 result value 58~, and then verifies the town sign~tllre using a sign~ture verification process.
33 The ciPn~ture verification process is shown in figure 7. The verification function 712 takes _ W~ 961258~4 PCT~US9~J~176S
t three inputs: the sigJn~t~lre 711, the message 710, and the public key 714, and yields a single 2 bit result 713. The result indicates whether the digital signature was indeed the signature on 3 message 710 with respect to the public key 71 ~.
4 Having ~thenticated the house, the house can now be used. We will use the house in s figure 9 as an example. The response data that the card sends includes exactly one value in 6 each ofthe columns. In the first column, that is one ofthe values 911, 913, 915, or 917. In 7 all the other columns, one of the four column values is inrh~ded in the response data. The 8 terrninal receives these column values, and applies the necessary oneway functions to 9 compute the final column values in each of the columns 917, 927, 937, 947, 957, 967, 977.
10 The compression function 904 is then applied to these values which yields the house result ~- value 979. The terrninal verifies that this matches the house result value used earlier to 12 authenticate the house in the town, or uses the house result value to authenticate the house 13 in the town. The choice of which value in each column is sent encodes the challenge c. For 14 ease of reference, each of the column values has an associated di it value. The digit value ~s of the last column value is 0, the digit value of the next to last column value is 1 etc.. In 8 figure 9 the first column value has a digit value of 3, in the actual preferred embodiment the 7 column height is 8, so that the digit values 0, l, 2, 3, 4, 5, 6, 7 are used. It is believed that 18 using a power of two for the column height allows easier encoding/decoding of actual data ~9 into the column digit values. The challenge c is thus converted into a sequence of digits, which indicate the column values included in the response data. In this way a card can use a 21 house to perform a commit-challenge-response protocol with the terrninal. It is believed 22 that this protocol by itself convinces the terminal of the fact that the card is genuine in the 23 sense that it has a valid town, which was originally signed by the issuer, which only gives 24 such valid towns to genuine cards.
2s ~igure ~ sllows a number or digit vaiues (digits) which are used to encode c and any 28 extensions which we will describe fully later. Each square, such as 600, 602, 604, 606, 608, 27 610, and 612 represents a single digit, with 603, 607 and 611 representinv any number of 28 additional digits. The boundaries 601, 605 and 609 separate the digits into di~.t;l~L fields 2~ which will be discussed fully later. A (sub)sequence of digits usually encodes an integer, using the standard encoding of integers into digits of the appropriate radix, well known in 31 the art. If the columns are of din'erenL heights, then the maximum digit value varies over the 32 digit position. In this case a mixed radix encoding of the integers is used, which is also well 33 known in the art.
W O96125814 PCTrUS95/01765 For each of the column values given to the terminal, the terminal can of course 2 compute the subsequent column values. This corresponds to a lowering of the 3 corresponding digit value. This would allow the terrninal to modify the digits unless 4 precautions were taken. The control value is used to protect against this. A subset of the s columns (and thus of the digits) are designated as the protected columns (digits).The 6 control value, seen as an integer, encodes some constant minus the sum of all the digit 7 values in the protected columns. The control value itself is also coded into some columns.
8 For example, but without limitation, the control value could be coded into digits 610, 611, 9 612 and the protected digits could consist of 600, 602, 603, 604, 606, 607, and 6~8. The ~o terminal can only apply more oneways to a column chain and thus only lower the value of any one digit. If the terminal tries to lower the value in any of the protected digits, then the t2 control value increases, which means that at least one of the encoding digits of the control 13 value increases. This would require the terrninal to invert one of the oneway functions in 14 the column of the increasing control digit, which is presumed to be impractical. In the ~s preferred embodiment the range of control values is fixed at 0-63, which allows for 9 16 protected columns. (All columns have height 8, so each protected digit has a value of at 17 most 7, so 9 columns lead to a maximum sum of 63. Using 63 as the constant to subtract 18 from gives exactly the range 0 to 63 to the control value, which can be encoded in two 19 digits of radix 8.) It is believed that the most significant control digit is the most attractive 20 digit to try to increase by inverting the appropriate oneway function, as increasing this digit 21 gives a lot of flexibility in ch~nging the protected columns. The most significant digit of the 22 control value is therefore duplicated in two separate columns, for a total of three control 23 columns. It is believed that the double encoding of the most significant digit provides extra 2~ security against an attack which attempts to invert a oneway function with the aim of 25 increasing one of the control digits. It is furthermore believed that the number of control 2~; columns increases only loga,ilhl"ically with the number of protected columns.
27 The spending protocol implements a commit-challenge-response protocol between 28 the card and the terminal in which the number of different challenge values depends on the 29 number of columns in a house and the height of each column. The challenge value is 30 encoded in the protected columns, and the control columns are added as described above.
31 This can now be used to sign messages. For short messages where there are at most as 32 many possible messages as there are challenge values, the message itself can be used 33 instead of the challenge value. However, most applications need to sign larger messages CA 022l8l78 l997-08-08 YCTlUSsSl01765 WO 96/2~81 1 then would be practical here, among others tO prevent replay attacks. This method of using 2 a commit-challenge-response protocol is well known in the art.
3 A more general scheme is the direct conversion of the commit-challenge-response 4 protocol to a signature protocol by choosing the challenge to be the hash of the commit s message and the ~ness~e to be signed. This requires a challenge value of approximately 128 bits or more, which can be achieved using 43 protected columns of height 8 plus 3 7 control columns for a total of 46 columns This method of using a commit-ch~llen~e response protocol is well known in the art. It is believed that inclu~in~ the commit m.occ~e 9 in the hash used to compute the challenge is not even necessary for these house based lO systems.
A commit-challenge-response protocol can also be used to authenticate messages in 2 those cases where the effective contents of the message to be authenticated is small. By 13 effective contents we mean the data in the message except for the data that is used to ~4 prevent playback attacks etc. For example, but without limitation, in payment systems the ~s only important piece of the message being signed is the amount of the payment. The ~~ challenge can now be chosen in two parts, the first part being the message that is 17 ~llthenticated, and the second part being a value chosen by the verifier in a manner not 18 predictable by the prover It is believed that this method provides full auth~-ntication of the .~ message and at the same time protects the verifier from playback attacks. This use of the 20 commit-challenge-response protocol will be referred to as signing a short m~ss~e. A
z- typical exemplary application is the case of payments (i.e. payments from the card to the 22 terminal). The challenge c is divided into 4 sequences of digits, as shown by the separators 23 601~ 605 and 609 in figure 6. The first digit 600 encodes the currency ofthe payment. The 24 digits 602, 603, and 604 encode the amount of the payment. The digits 606, 607, 608 are 25 chosen randomly by the terminal, and finally digits 610, 611, and 612 encode the control 25 value. The protected digits are 600, 606, 607, and 608 A typical configuration has I
27 currency column, 5 amount columns, 7 random columns and 3 control columns, which 28 accommodates 8 currencies, 15 bits resolution of the amount of the payment and 21 25~ random bits. Using an ordinary digital cign~tllre~ the '~1 random bits would not be enough 30 to protect the terminal from playback attacks. However, it is believed that in a commit-31 challenge-response protocol, and in this specific inct~nce of a commit-challenge-response 32 protocol in particular, this does protect from such attacks, as the card must commit to the 33 house to be used in the first messaoe, and cannot change that based on the value of the w 096n5814 PCTrUS95/01765 ~ random part of the challenge. The amount digits are not included in the protected digits, 2 which allows the terminal to arbitrarily decrease any of the amount digits. It is believed that 3 this only decreases the amount encoded in the signature, which is not in the interest of the 4 terminal.
s Another method allows the use of commit-challenge-response protocols with a small 6 set of possible challenge values to be used to ~uthenticate arbitrarily long messages. This is 7 done by choosing the challenge value as a uniformly distributed function of the 8 cryptographic hash of the message where the message is extended with a number that was 9 ~enerated in a mutually random fashion (also known as a fair coin flip). Such a mutually ~o random number is a number which is constructed in a cooperative process between two ~- parties in such a way that both parties are ensured that the number is in fact random. At the 12 start of the process in figure 30, both the card and the terminal know the message m to be 13 signed. In process step 3000 the card generates a random number a, and computes a 14 commit value A on it, for example, but without limitation, A can be formed by hashing a .s and a large enough random string of bits. In message 3001 the card sends A to the terminal, .~ along with the rest ofthe commit message. The purpose of A is for the card to show the 17 terminal that it has fixed it's choice of a without revealing a to the terminal. Such bit 18 commitment schemes are well known in the art. The terminal then chooses a random 19 number b in process step 3002, and sends b to the card in message 3003. In step 3004 the 20 card computes the mutually random number d as a function of a and b, for example, but 21 without limitation, d can be computed as the exclusive or of a and b. The actual challenge 22 value c is then computed by first computing a cryptographic hash of the message m 23 concatenated with d, and then applying a function that maps the hash value uniformly to the 24 set of possible challenge values, for example, but without limitation, the challenge c could 25 be chosen as the least significant bits of the actual hash value. The value c is then coded 26 into the protected digits of a house, the control digits are added and the card sends the 27 response data associated with those digits to the terminal in message 3005. The card also 28 includes the value a plus any information necess~ry to verif~ the commit value A in meSs~ge 29 300~ which allows the terminal to reconstruct d and thus c, and also allows the terminal to 30 verify that a is indeed the value committed to by the card in message 3001 by checking that 31 the values a and A are consistent with each other. This use of a commit-challenge-response 32 protocol will be referred to as authenticating an arbitrarily long message. The message m 33 does not have to be known by both parties at the start of the process, but can also be , CA 022l8l78 l997-08-08 PCT~JS95J~2 76*
WO 96/2~;814 inC~ e~ in messa~ge 3001 to the terminal. It is anticipated that part of the message might 2 also be chosen by the terminal in step 3002 and comml-nir~tecl to the card in step 3004, in 3 which case the card has the choice of accepting that part of the mecs~e or replacing it by a fixed value. It is believed that this authentication method provides authentication of the s message to the terminal. It is believed that the probability of succecsfully çhe~tin~ the A terminal is in the order of one over the number of possible çh~llerlge values.
7 It is believed that compact endorsement cign~hlreS provide a high degree of 8 flexibility; using a large house, the card can sign any message, using a more ~offir.i~nt smaller house, the card can sign a small message, or authenticate an a,b~ ily long message.
~o When the house is used to authenticate an arbitrarily large message to the terminal, ?l the card can at the same time send a secret-key authentication on the message for use by 12 the issuer. (As the issuer originally produced the card, we assume that the card and the 13 issuer have a secret key in common.) The secret-key a-lthentication is first appended to the .. message, and the combination of the two is then authenticated to the terminal using a house. It is believed that this provides the benefit of a public-key siSgn~ture to the tenninal, ~~ with the speed and storage advantage of a secret key sisgn~tllre to the issuer. The terminal 17 can namely discard the house and all associated data and only store the message and the 18 secret-key authentication.
TOWN PRECOMPUTATION
~~ The card must send several intermediate values of the town to the terminal during the spending process. To save computations these values are precomputed. As an example we 21 will use the town of figure 5, the pfeco"1putation steps are shown in figure 40. The 22 precomputations schedule shown in figure 40 are believed to be suboptimal in the sense 23 that they require more storage on the card then the optimal precomputations schedule, but 2- iii3 aiso beiieved that this schedule yields the easiest implementation.
Figure 40 shows the values stored in memory at any step. The first column contains 2r the number of the house in the town that is being spent, the second column the set of values 27 that is precomputed in the current town (called A), the third column the set of values that is 28 p.eco."puted in the next town (called B). The next town is the town that will be used a~er 29 the current town has been exhausted, in the sense that all the constituent houses have been 30 used. For clarity all items referring to the next town are shown in slanted font in figure 40.
W O96125814 PCTrUS95/0176S
The fourth column the set of values needed for the authenticating the house indicated in the 2 first column within the town and the last column the number of values stored in memory.
3 The first row of figure 40 shows that when house 560 is being spent, the values 523, 4 543, 564, 565, 566, S67 are being used in the spending process. (As mentioned before the s house result value of the current house is used in the p~ ere" ed embodiment. Although this is not n~cesc~, y from a functional point of view, it is believed that this provides for the 7 easiest implementation.) The value 534 is computed (by computing the house result value of house S30) and stored.
9 The second row of figure 40 shows the situation when the next house 561 is spent.
10 The same values as in the previous step are being used, and one more value is precomputed ~- namely 535. When, in the third row, house 562 is being spent, the values 564 and 565 are 12 no longer necessary for the spending process, but are combined using the compression 13 function into value 569. This saves a storage space, which is used to precompute the next 14 value 536. The next line shows a repeat of this process when house 563 is being spent: the .s values 569 and 566 are combined into value 571 and the free storage space is used to .~ compute value 537. When spending house 530, the values 571 and 567 are combined into 17 573, the value 543 is no longer necessaly and is replaced with the already precomputed .~ values 534, 535, 536 and ~37 which are now used in the spending process. The value 514 19 iS precomputed in this step. This is also the point in which we start precomputing the next 20 town. When all houses in the current town (A) have been spent, we obviously need the 21 intermediate values of the next town (B) that are needed for the spending process for the 22 first house in B. At this point we precompute value 534 in town B by computing the house 23 530 in town B which is the first step in computing 543 of town B. When spending house 24 531 the same set of values is used for the spending, the value 515 is precomputed, and in 25 town B the house value 535 is precomputed, combined with the already stored value 534 to 2~ yield value 539. Only value 539 of town B is stored. This process continues as shown in the 27 table. When spending house 533 the values 523, 541, 537 and 573 are being used, the 2~ values 514, 515, 516, and 517 have been precomputed in town A. In town B the value 537 29 iS computed, combined with the value 541 which was already precomputed in town B and 30 the result value 543 stored. When the next house 510 is being spent, the values 573 and 31 541 and 537 in town A are no longer necess~ry, they are combined using the appro~-iate 3_ compression functions into value 582. The values 514, 515, 516 and 517 which had already 33 been precomputed in town A are now being used. Two new values are plecoll-p-lted in WO 96/25814 PCT/US9S~01 76S
town B namely 514 and 564. In the next rows the spending situations for houses S11, ~12 2 and 513 is shown. The original values that were used for the spending 514, 515, 516, and 3 517 are step by step combined to S21 and S17 for the spending of the last house 513. The 4 precomputations in town B involve precomputing 565, 566 and 567, and the p,~col."~.~tation of value 523 in steps with interrne~ te values 519 and 521. After the last house 513 has been spent, we switch to the next town. What used to be called town B now 7 becomes town A. The values that were precomputed in town B during the spending of a town A are exactly those necessary for the spending of the first house 560 in town B as 9 sho~,vn by the next row of the table. Of course, the r~ ~ values 521, 517 and 582 of ~0 the old town A are discarded as they are no longer needed. When all houses in a town have been spent, the town origin and the town signature are also discarded, as they will not be 2 used again.
., It is believed that this method of preco",putations requires storage space proportional .~ to the sum of the sizes of each of the dimensions of a town. Furthermore, it is believed that 15 the precomputation involves computing at most as many houses as there are dimensions if multiple towns are used. and one less if only a single town is used. In figure 40 at most 2 houses are precomputed at any step, and of these at least one is in town B. If town A were ~8 to contain enough houses so that a second town is not nec~ss~ry, then no precomputations 18 in the next town need to be done. It is believed that this further reduces the necess~ry 20 precomputations. It is believed that it is possible to load additional towns into the card.
21 These can either be without any precomputation (e.g. the next town after town B), with 22 (partial) precomputations (e.g. add a town B with the correct preco",putations to an 23 already existing town A), or existing towns and precomputations can be discarded and 2~ replaced with new town(s) with the right precomputations. These extensions will be 25 obvious to someone ordinarily skilled in the art.
2a The precomputations mentioned above can of course be done by the card itself. An 27 alternative is for the terminal to do manage the precomputations. The house result values in 28 a town are not secret, so the card can compute those on dem~nA and send the result to the 20 terminal. A refinement is to let the card not compute the house result value, but just the last 30 value in each column, send those column values to the terminal and let the terminal 31 combine them to get the house value. The terminal can now manage the precomputations, 32 reading, writing and deleting the necessary values in the card's memory. For example, but 33 without limitation, when spending house 562 (see figure 40, third row) the terminal can ask W O96/2581~ PCTrUS95/01765 the card to compute the house result value S36. The card can either store this as a 2 precomputed value by itself, or send it to the terminal which then stores it back in the card 3 as a precomputed value. The terminal furthermore reads the values 564 and 565 which are 4 stored in the card's memory, deletes those values in the card's memory, computes the value s 569 form the values 564 and 56~; and writes the value 569 in the card as a pl ecol~-l)uted 8 value. In a similar manner all the other precomputation actions can be managed by the 7 terminal. The terminal might do all these actions itself, or might contain a tamper-resistant o device which performs and manages the precomputations. It is believed that this 9 pl eco...putation management system simplifies the implement~tion of the card. It is believed ~o that any error by the terminal in m~n~ging or performing the p- ecol--putations does not lead ~- to a security weakness, but can at most lead to a failure to properly authenticate a house in 2 a town, thereby rendering the compact endorsement signature scheme ineffective until a 3 recovery has been performed. It is believed that a terminal that detects an inconsistent 4 precomputation state in a card can rec~ver the card and bring it in to a consistent state with s respect to the precomputations.
SECURE DATA STORAGE
Figure 12 shows the basic layout of the non-volatile and volatile memory of the card 7 in the preferred embodiment.
8 The volatile memory 1240 holds the variable 1241, called VNIU, which is described 19 in detail below. Field 1242 holds the volatile memory variables that are not part of the Secure Data Storage. These are not shown for clarity.
21 The non-volatile memory 1200 is divided into three areas. Area 1201 is used to store 22 the global non-volatile variables. Area 1203is set aside for other applications or purposes, 23 as known in the art. Area 1201is shown in more detail as 1230, the dotted lines denoting 24 an enlargement. The fields 1231,1232,1233,1234tl235 and 1236 are global non-volatile 2s variables called N~U, COM, NDONE, NBROK, CLCOM and CLCAN respectively, and 2~ are described in more detail below. Part 1237 are global non-volatile variables that are not 27 part of the Secure Data Storage system, which have not been shown for clarity. The 28 ND ONE variable is used in the session proofs, which will be described more fully later.
29 Area 1202is shown in more detail as 1210, the dotted lines denoting an enlargement.
3c This area is divided into a plurality of fixed-size smaller areas called frame slots. All frame 31 slots have the same size and the same internal organization. One ofthe frame slots 1211 is WO96/25814 PC~JUS9SJD176S
~ showed enlarged as ~220, the dotted lines denoting an enlargement. Each frameslot 2 consists of four fields, each of which can store a variable. The field 1221 is called the tag 3 field, and holds a variable called 'tag'. Field 1222 is called the access field, and holds a variable called access'. Field 1223 is called the data field and holds a variable called 'data'.
s Finally, field 1224 is called the checkc~-m field and holds a value (called the ~hec~cllm) that 6 serves as a checksum over the other three fields. The function to compute the chec~cllm 7 from the other three fields can be chosen in many ways, for example, but without limitation, 8 it can be chosen as the number of zero bits which occurs in the other three fields, coded as 9 a binary number. The four values tag, access, data and çhec~sllm are together ~~fel-~d to as .c a 'frame'.
The tag functions much like a filename in ordinary computers. It is used as a unique 12 name to refer to the frame. All frame slots are the same size, thus the a frame fits in any of 13 the frame slots. The inte~relalion of the data in a frame slot is solely dependent on the lG value of the tag field, and not on the position in the non-volatile memory the frame appears 1S in. Whenever information about specific frame is needed, the non-volatile memory is ~g searched for a frame slot with the proper tag value in the tag field. The other fields of that 17 frame slot contain the other data of that frame. A value of zero in the tag field is used to 18 indicate that a frame slot does not contain any valid frame data, and is therefore empty.
19 Thus, a frame slot is the actual location where a frame is stored in the non-volatile memory.
20 A frame is a set of values which is stored somewhere in the frame slots, which is identified 21 by its tag value.
22 The access field is used to store data regarding the conditions that should be met 23 before the data of the ~rame can be acc~ssed. This corresponds with access rights 24 associated with files in many operating systems. The data field contains data for the 25 applications, the interpretation and formatting of this data depends on the applications.
In the plefel,ed embodiment, the tag field is '~ bytes long, the access field 1 byte long, 27 the data field i 6 bytes long and the checksum field 1 byte long.
~ A MODEL FOR NON-VOLATILE MEMORY.
28 For reliable and secure operations the card would typically require a reliable and 29 secure non-volatile memory system. A typical smart card uses EEPROM technology for 30 non-volatile storage of data. Inherent in this technology, and in many other non-volatile 31 storage technologies, is that writing data is not i~ct~nt~neous. There are two basic W O9612581~ PCT~US9S/01765 processes for EEPROM memory: writing and wiping. During wiping, a block of bits is 2 cleared to the default position, which we will without loss of generality denote by a binary 3 O(although in some implementations wiped bits read as l's). The block size for wiping is impl~m~nt"tion dependent and might actually be 1, but typical minimum block sizes are 8 s or 32 bits. This means that it is often not possible to wipe individual bits but only blocks of bits.
Writing is also done in blocks, but usually allows individual bits to be set to I (in our representation). In a typical implement~tion, when writing data to a memory block the bits g that are written with a 0 value are not affected while those that are written with a I value ~o are set to 1.
lt Both the writing and wiping process take time, typically on the order of a few ~z milliseconds. If the operation is aborted for some reason within this time, the results are 3 usually unspecified. It is believed that irradiating the EEPROM memory with W light has 14 similar effects as a partial or full wipe of the bits that are irradiated.
A functional model of a typical EEPROM memory is shown in figure 11. This figure~~ gives the state diagram for a single bit of EEPROM memory. Each bit has three possible 17 states labeled 1100, 1101, 1102. The state 1100 is what we call the 0 state. In this state the , bit has a stable zero value, and will always be read as a zero. In state 1101, also called the I
19 state, the bit has a stable one value, and will always be read as a one. In state 1102 the bit is 2r in an intermediate state, called the ? state. In this state the value of the bit is not defined, 2~ and the result of a read operation is undefined. Although most implementations will at any 22 specific read attempt return either a zero or a one value, we assume that it is not possible to 23 predict what value is returned. As the value returned might also depend on other factors, 24 including factors external to the card, such as temperature, supply voltage etc., we make no 2s assumptions whatsoever about the values returned by read attempts.
2~ The state transitions are also shown in figure 11. A bit in the 0 state 1100 will 27 transition to the ? state 1102 through state transition 1110 at the start of a write operation 2~ which attempts to write a I into this bit. The bit remains in the ? state for the duration of 29 the write operation. A bit in the ? state 1102 will transition to the I state 1101 via transition 30 1111 at the end of a write operation which attempts to write a 1 into this bit. A bit in the I
~- state 1101 transitions to the ? state 1102 via transition 1112 at the start of a wipe operation 32 on a block of bits that contains this bit. A bit in the ? state 1102 transitions to the 0 state 3~ 1100 via transition 1113 at the end of a wipe operation on a block of bits that contains this WO 96/25814 PCT~US9SlD~76S
~ bit If the write or wipe operation is interrupted for any reason, the transitions 1111 and 2 1113 respectively are not made and the bit remains in the ? state 1102.
3 Under influence of W radiation, any bit in the I state 1101 can also transition via 4 1112 to the ? state 1102, and from the ? state 1102, via 1113, to the 0 state 1100.
s As will be obvious to someone ordinarily skilled in the art, this model applies, or can be applied to a wide variety of non-volatile memory technologies.
BROKEN MODE
7 In the prer~ ed embodiment, the card has two basic modes, which we call 'broken' 8 and 'not brolcen'. This mode is indicated by the NBROK variable 1234. This is a single-bit variable in non-volatile memory which occupies a whole block of bits so that it can be ~o wiped without influencing any other variables in memory. Under normal circum~t~ncec, the ~- card is in the 'not broken' mode, and the NBROK variable 1234 contains a value of 1.
12 During the personalization of the card, this variable is set to a I value. The 'broken' mode 13 when the NBROK variable 1234 is zero will described more fully later.
MULTI-UPDATES
14 The variables CLCOM (1235) and CLCAN (1236) each consists of an array of bits, ~s one bit for every frame slot on the non-volatile memory. In the default state all the bits are ~~ O. The variables N~U (1231) and COM (1232) are both single-bit variables which occupy 17 an entire block of bits so that they can be individually written and wiped. The VNIU (1241) 18 variable is a single bit variable in volatile memory.
19 Figure 18 shows the process of finding a frame in the p, ere, red embodiment. At the start 1800 the variable 't' contains the value ofthe tag ofthe frame to be found in the non-21 volatile storage. First, in step 1801 two new variables are initi~li7ed: a counter 'nr_found' 22 which indicates how many frames were found, which is initi~1i7ed to zero, and an index 23 counter 'idx' which will run over all frame slot indexes, which is initi~li7ed with the index 2- value ofthe first frame. Next is a loop, comprising items lg02, 1803, 1804, 1805 which 2s searches for frame slots with a ta, value equal to 't', for which the associated bit in the 2B CLCOM variable is 0. First, in step 1802 the frame slot with index 'idx' is inspected to see 27 if the tag field contains the value 't', and whether the bit associated with that frame slot in 28 the variable CLCOM is 0. If this is not the case, the process continues at item 1804. If this 2~ iS the case, a frame slot has been found and the process continues at item 1803. At step 30 1803 the counter 'nr_found' is incremented by one, and the current value of 'idx' is O96125814 PCTrUS9510176S
~ assigned to a variable called 'store_idx', after which the process continues at step 1804.
2 Step 1804 checks whether the frame just inspected by step 1802 was the last frame. If this 3 iS the case, the process continues at step 1810, otherwise it continues at step 1805. At step 180S the 'idx' variable is incremented by one to the next index value, and processing s continues at step 1802. The result of the process so far is that the variable 'nr_found' contains the number of frame slots that exist in the non-volatile memory whose tag value is 7 equal to 't' and whose representative bit in the CLCOM variable is zero. If the 'nr_found' e variable is greater then zero, then the 'store idx' variable contains the index of one of the 9 frame slots found.
~o Steps 1810,1811,1820,1830,1810 decide which action should be taken based on ~- the results of the earlier loop. In step 1810, the counter 'nr_found' is checked for a zero 12 value. If 'nr_found' is zero, the process continues at step 1820 which sets the return value 13 to indicate that no frame was found. If step 1810 determines that 'nr_found' is not zero, 14 the process continues at step 1811 which checks whether 'nr_found' is greater then one ~s and 't' is unequal to zero. If this is the case, the process continues at step 1$40 which 16 wipes the NBROK variable to 0 to enter the 'broken' mode, and jumps to the reset process 17 for proper 'broken' mode processing. If in step 1811 the condition is false, the process ~o continues at step 1830 which sets the return value to indicate that a frame was found. The 9 process of finding a frame is terminated at step 1850 which occurs after either step 1820 or 20 step 1830.
21 The process of reading a frame in the preferred embodiment is shown in figure 19. At 22 the start 1900 the variable 't' contains the frame to be read. The first step 1901 consists of 23 executing the find frarne process (as shown in figure 18) to search for a frame with tag 't'.
24 Next, step 1902 determines whether a frame was found. If no frame was found, the process 25 continues at step 1910 which sets the return value to indicate that no frame was found. If 25 step 1902 determines that a frame was found, the process continues at step 1903. This step 27 retrieves the data from the frame slot, using the variable 'store_idx' which was set by the 28 'find frame' process of step 1901 to locate the proper frame slot. It then checks whether 29 the checl~cllm field has the right value. If this is not the case, the process continues at step 30 1930 which wipes the NBROK variable to 0 to enter the 'broken' mode, and jumps to the 31 reset process for proper 'broken' mode processinp If step 1903 finds the right chec~ m 32 value, the process continues with step 1920 which sets the return value to the frame data CA 022l8l78 l997-08-08 WO 96/25814 PCT~US9~.J~176 and indicates that the frame was found. The process of reading a frame is terrninated at step z 1940 which occurs after either step 1910 or 1920.
3 Figure I ~ shows the process of starting an update sequence in the preferred embodi-4 ment. At the start of this process 1300 another update can already be in progress, in that s case both updates are combined into a single multi-update. In step 1301 the variable VN~U
is inspected. If it is not equal to 1, then another update is already in progress, and no new 7 update needs to be initi~li7ed; the process continues at step 1310. If step 1301 finds that a the variable VNIU has a value of 1, it continues processing at step 1302. Step 1302 sets 9 both NrU and VNIU to zero, a~er which it continues with step 1310. Step 1310 terminates c the process.
~1 Figure 14 shows the process of deleting a frame in a frame slot in the pre~,led embodiment. At the start 1400 the variable 'i' contains the slot index number ofthe frame slot in which the frame to be deleted resides. The first action 1401 is to execute the 'start update' process as shown in figure 13 to be sure an update is in progress. In next step 1402 the i'th bit of the CLCOM variable is set to 1, after which the process terminates in step ~~ 1410.
Figure 15 shows the process of writing data in a frame in the p,~:~" ed embodiment.
At the start lS00 the variable 't' contains the tag value of the frame to be written, the 9 variable 'access' contains the access control code for the frame to be written, and the zo variable 'data' contains the data for the frame to be written. The first step 1501 executes l the 'start update' process shown in figure 13. The next step 1502 executes the 'find frame' z process of figure 18 to locate any existing frame with the same tag value. The next step z3 1503 inspects the return value of the 'find frame' process to determine whether a frame z4 was found. If this is not the case, the process continues with step 1506. If step 1503 s determines that a frame was found, the process continues with step 1505. Step 1'.05 z6 executes the 'delete frame' process for the frame slot which contains the frame that was 7 found in step 1502. The index value of the frame slot that was found was stored in the z~ variable 'store_idx' by the 'find frame' process and is used here as an input to the 'delete z~ frame' process to indicate which frame slot should be deleted. A~er step 1505 the process continues at step 1506. Step 1506 consists ofthe 'find frame' process of figure 18 to 1 search for a frame slot with a tag field value of zero. The next step 1507 inspects the result z of step 1506 to determine if such a frame slot was found. If no frame slot was found, the 3 process continues with step 1520 which jumps to the cancel process of figure 8, which will CA 02218178 1997-08-08 PCTrUS95/01765 be described more fully later. If step 1507 determines that a frame slot was found, the 2 process continues with step 1508. In step 1508 the bit corresponding to the frame slot that 3 was found by step 1~06 is set in the CLCAN variable. The index number of the frame that 4 was found by step 1506 was stored in the 'store_idx' variable, which is now used to set the s proper bit. The next step 1509 writes new data in the frame slot which was found by step . lS06 The tag field, access field and data field are written with the value of the 't' variable, 7 'access' variable and 'data' variable respectively. The cher~ m field of the frame slot is 9 written with the proper checksum value. The next step 15~2 tc.~-~h.ales the process.
9 Figure 17 shows the 'commit' process in the preferred embodiment. The process ~o starts at step 1700 and continues at step 1701 which determines whether the VNIU variable ~- is equal to 1. If this is the case, the process continues at step 1730. ~f step 1701 finds V~IU
12 to be equal to zero, the process continues at step 1710. In step 1710 the first action is to 13 set the COM variable to 1. The CLCAN variable is then wiped to 0. Next, for each bit in ~~ the CLCOM variable which is equal to 1, the frame slot that is associated with that bit is ~s cleared. Clearing a frame slot consists of wiping the tag field to a 0 value. Subsequently, 16 the CLCOM variable is wiped to 0, after which the COM variable is reset to 0. Processing ~7 the continues at step 1721 which sets the NIU variable to 1. The next step 1722 sets the 18 VNIU variable to 1, and the process continues at step 1730. Step 1730 terminates the 19 commit process.
Figure 8 shows the 'cancel' process in the preferred embodiment. The process starts 21 at step 1750. The next step 1751 deterrnines whether the V~IU variable is equal to 1. If 22 this is the case, the process continues at step 1770. If step 1751 determines that VNIU is x. not equal to 1, it continues at step 1751. In step 17S1, the first action is to wipe the COM
24 variable to 0. Then the CLCOM variable is wiped to 0. Next, for each bit in the CLCAN
25 variable which is equal to 1, the frame slot that is associated with that bit is cleared.
26 Clearing a frame slot consists of wipina the tag field to a 0 value. The last action in step 27 17Sl is wiping the CLCAN variable to 0. After step 1751 the NIU variable is set to 1 in 25 step 1761. The next step is 1762 where the VNIU variable is set to 1. The process then 29 continues at step 1770. In step 1770 the 'cancel' process is terminated.
30 Figure 16 shows the ~reset' process in the preferred embodiment. The process starts 31 at 1600. The next step 1601 inspects the NBROK variable to determine whether its value is 32 equal to 1. If this is not the case, the process continues with step 1610 in which the ~3 NBROK variable is wiped to zero. A~er step 1610 the next step is 1611 which sends all CA 022l8l78 l997-08-08 PCTfUS9S~01 76S
WO 96~25814 ~ public data in the non-volatile memory to the terminal. After step 1611 the process 2 continues again at step ' 611 in an infinite loop. If step 1601 determines that NBROK is 3 equal to 1, the process continues at step 1602. Step 1602 inspects the NrU variable to determine whether it is equal to 1. If this is the case, the process continues at step 1641. If s step 1602 finds that NrU is not equal to 1 the process continues at step 1603. Step 1603 inspects the COM variable to determine whether it is equal to 1. If this is the case, the 7 process continues at step 1630. If this is not the case, the process continues at step 1620.
8 In step 1620 the first action is to wipe the COM variable to 0. Then, the CLCOM variable 9 iS wiped to 0, aRer which all ~rame slots whose representative bit in the CLCAN variable ~0 are 1 are cleared. Clearing a frame slot consists of wiping the tag field to a 0 value. A~er ~- this, the CLCAN variable is wiped to zero, and the process continues at step 1640. In step 2 1630 the first action is to set the COM variable to 1. Then, the CLCAN variable is wiped to .3 0, after which all frame slots whose representative bit in the CLCOM variable are 1 are 4 cleared. Next the CLCOM variable is wiped to 0, and finally the CQM variable is wiped to 0. The process continues at step 1610. In step 16'~0 the variable NrU is set to 1, and the 16 process continues at step 1641. In step 1641 the variable VNIU is set to 1, after which the ~7 process is termin~ted in step 16S0. The 'reset' process functions either as a 'cancel' ~~ process if no commit was in progress, or as a 'commit' process if a commit was in .~ progress.
The 'commit', 'cancel' and 'reset' processes together also keep counters which 21 indic~te how many times a 'commit' process was completed, and how many times a 22 'cancel' process was completed. These counters are stored in a frame, which is updated 23 after each 'commit' or 'cancel' process (this includes the 'commit' and 'cancel' parts ofthe 24 'reset' process). The details of these counters and thelr updates have not been shown for 2s clarity. The counters are used to generate unique challenges.
26 In the preferred embodiment, the 'reset' process is executed after any interruption.
27 For example, but without limitation, when the card is powered up, or after a reset of the 2B card. A multi-update typically consists of a sequence of 'read frame', 'delete frame' and 29 'write frame' processes in any order. A multi-update is usually terminated with a 'commit' - 3~ process or a 'cancel' process. If the card is interrupted during a multi-update, it will resume 3. with the 'reset' process after the interruption.
32 It is believed that the processes shown in figures 8, 13, 14, 15, 16, 17, 18, and 19 33 together provide the following functionality: Frames can be read using the 'read frame' WO96/25814 PCTrUS95/01765 ~ process at any time. The data returned will always be the data that was last written with 2 that tag value. The first 'delete frame' or 'write frame' process starts a multi-update. A~er 3 a 'delete frame' process, the frame that was deleted can no longer be read using the 'read 4 frame' process. A~er a 'write frame' process, the data returned by the 'read frame' process s is the data last written with that tag value. If a 'cancel' process is executed, all modifications done in the multi-update are reversed. The 'read frame' process will now 7 return the same information as it did before the start of the multi-update. If the multi-update is interrupted, then the 'reset' process which is executed after each interruption has the same effect as a 'cancel' process would have had before the interruption: all lc modifications to the data in the storage system are reversed. If a multi-update is termin~ted ~- with a 'commit' process, then all modifications are retained, and it is no longer possible to t2 reverse the modifications. If a 'reset' process is executed a~er a 'commit' process, the t3 modifications are all retained. ~c~llming a non-volatile memory model as shown in figure 14 I 1, if the card is (possibly repeatedly) interrupted at arbitrary moments during the .s processes mentioned, it is believed that the effect will either be that of a 'commit' process ~~ at the end of a multi-update, or that of a 'cancel' process at the end of the multi-update.
t7 Furthermore, unless the 'commit' process was already started, the effect will always be that ~~ of a 'cancel' process. This provides what is usually called an atomic update of a d~t~b~ce.
t9 Either all the changes are made, or none of the changes are made. This property is retained 20 even under arbitrary interruptions.
2t It is believed that the effects of W erasing as shown in figure 1 1 are limited to the 22 following effects. Frames can be erased, and in any multi-update the update of any one 23 frame can be prevented. This implies that the atomic update property is lost under W
24 erasing. However, it is believed that any practical UV erasing will result with high 25 probability in the card entering the 'broken' mode. It is filrthermore believed that UV
26 erasing can never be used to create new frames, or alter the data of a frame SESSIONS
27 The basic structure of a session as implemented in the prere" ed embodiment is 2~ shown in figure 24. A session starts of with a 'start session & proof keys' process 2401.
29 Then follows one or more 'command & data exchange' processes 2402, after which the 30 session is terminated by a 'commit session & end session' process 2403. Both the card and 31 the terminal are involved in a session. Each of these participants keeps a session state as CA 022l8l78 l997-08-08 WO 96/25814 PCTnUS9SI01~6 will be described more fully later. Throughout the session, the session states kept by the 2 card and the terminal should be identical. As will be described more fully later, the session 3 states on both sides are updated using a chaining function which has been chosen in such a 4 way that it implements an iterative cryptographic hash function. The purpose of a session is s to link several independent actions together in such a way that they behave as a single indivisable action. An independent action can be any type of action, and could even be a 7 session itself. Typically an independent action would be a fairly simple actions, such as 8 reading or writing a frame, but it is believed that some applications require the use of fairly 9 complex independent actions.
.o The 'start session & proof keys' process as implemented in the preferred embodiment ~- is shown in figure 25. This process involves the terminal 103 which executes steps 2501 12 and 2505, and the card 102 which executes steps 2503 and 2507. The process starts at step 13 2S01. The terrninal selects which keys will be used in the session, and chooses a terrninal .~ challenge value. As the last action of step 2S01 the terminal sends the terrninal challenge lS value and the choice of keys to the card in message 2502. When message 2502 is received 16 by the card, the card starts execution of process step 2503. The first action in step 2503 is 17 to choose a card challenge. Next the session state is initialized to a known value to start the ~~ chain. Next, all the keys selected by the terminal in step 2501 and indicated in mess~ge 19 2502 are chained. As described more fully later~ the ch~ining involves using a ch~ining 20 function to update the session state based on the other data (in this case the keys). The next 21 action is to chain the terminal challenge, and then the card challenge. As the last action of 22 step 2503 the card sends the card challenge in messaoe 2504 to the terminal. When 23 message 2504 is received by the terminal, the terminal starts execution of process step 2~ 2505. In step 2505 the first action is to initialize the session state to the same starting value 25 as used by the card to initiali7e the session state. Next, all the keys selected in step 2501 are 2tl ch~ined, the terminal challenge is ch~ineri. and the card challenge is chained. This should 27 result in the session state of the terminal having the same value as the session state of the 28 card at the completion of step 2503. The ne~;t action in step 2505 is to encrypt an 29 a~thPntication code which functions as proof that the terminal has indeed chained the ~ 30 proper keys. The last action in step 2505 is for the terrninal to send the proof in message 31 2506 to the card. When the card receives message 2506 it starts execution of step 2507 of 32 the process. The card decrypts the proof sent by the terminal and verifies it against the 33 current sessions state. If this verification fails, the process is aborted. If the verification is .
W O96/25814 PCTrUS95/0176~
~ successful, the card sets a state indicator 'in session', and the process is terminated. The 2 card retains the information regarding which keys were chained during this process, so that 3 it can be used to determine access rights to different frames in this session. The terminal 4 and card challenge values will typically vary over time and can, for example, but without s limitation, be chosen using a random generator. In the preferred embodiment the card challenge consists ofthe 'cancel' counter and the 'commit' counter.
7 The keys mentioned above are stored in frames in the card. Each frame that contains 8 a key is partitioned into two halves. The first half usually contains a diversification number, 9 the second half contains the secret key data. The frame can be read using the standard 'read 10 frame' process, provided the terminal has access as specified by the access field of the ~. frame. When a frame cont~ininsg a key is read, the part cont~ining the secret key is replaced 12 by zeroes, preventing the secret key data from being read. For some applications, the key is 13 diversified: the secret key used by the card (and stored in the second half of the key frame) 14 iS a function of a master key and the diversification number stored in the first half of the 15 frame. A terminal with access to the master key first reads the diversification number by reading the key frame, computes the secret key used by the card and can thus start a 17 session with this key. Note that access to the diversification number can be protected by 18 another key by setting the access field of the key frame to a proper value.
19 The 'command & exchange data' process as implemented in the plefel-ed 20 embodiment is shown in figure 26. Each 'command & exchange data' process consists of z- an elementary function, for example, but without limitations, reading a frame and writing a 22 frame. The first step ofthe process 2601 is executed by the terminal. The first action is for 23 the terminal to select a command. The last action of step 2601 is for the terminal to send 24 the command data to the card in message 2602. When message 2602 is received by the 25 card, it start execution of process step 2603. The first action in this step is for the card to 25 check whether it is in a session. If this check fails, the process is aborted, otherwise the 27 process continues with the next action. The command data received in message 2602 is 28 chained (thus updating the session state) and the command is executed. Execution of the 2~ command can involve several actions, for example, but without limitation, the reading, 30 deleting and writing offrames, as shown in figures 19, 14, and 15. Any response data from 31 the card to the terminal is then chained. As the last action of step 2603 the card sends the 32 response data in message 260~ to the terminal. Upon reception of message 2604 the 33 terminal starts execution of process step 2605. The first action is to chain the command WO 96/25814 PC7'nJS9SJl~76~5 ~ data originally sent to the card. The next action is to chain the response data of the card.
2 The process is then termin~te~ The command data and the response data are also 3 encrypted using the then-current session state as a key, but this is not shown for clarity. If 4 the command involves access to frames, then the card verifies whether the key which is s required for that operation was used in the 'start session & proof keys' process of this session. For example, if the terminal reads a frame, the card ensures that the keys used to 7 create the session state allow read access to the frame using the 'access' field of the frame.
8 A similar verification is made for writing and deleting frames.
9 The 'commit session & end session' process as implem~nted in the pl~f~lled embodi-~o ment is shown in figure 27. In the first step of this process 2701 the terminal chains the ~- command code for this process. It then encrypts a proof using the current session state. As ~2 a last action in step 2701 the terminal sends the proof to the card in message 2702. Upon 13 reception of message 2702 the card starts execution of process step 2703. The card also ~4 chains the command code for this process, and the decrypts the proof sent by the card in ~s message 2702. If the proof is invalid, the process is aborted, otherwise it is co~tinlle~l The 18 card then increments a commit counter and encrypts a second proof using the session state.
~7 Optionally the card also creates a public proof'proofP', and stores these proofs in non-18 volatile memory. The last action in step 2703 is to send a message 2704 to the terminal ~9 indicating the card is ready to commit to the session. Upon reception of message 2704 the 20 card starts execution of process step 2705. The only action in this step is for the terminal to 21 send a message 2706 to the card indicating it should commit to the session. Upon reception 22 of message 2706 the card starts execution of process step 2707. The first action is to set 23 the COM variable to one. This is in fact the first action of step 2710 in figure 17 which 24 shows the 'commit' process, all other actions already explained in figure 17 not being 25 shown for clarity. At the same time the NDONE variable is set to one, indicating that the 26 proof of this session has not successfully been sent to the terminal. Setting the NDONE
27 variable and the COM variable should be atomic, which is achieved by setting the NDONE
28 variable in the 'commit' process, in the 'reset' process if it finds the COM variable to be 29 one. The NDONE bit is set to zero during the 'cancel' process and the 'reset' process if it 30 finds the COM variable to be zero. The card then sends the second proof, and optionally 3- the public proof to the terminal in message 2708, after which the card completes the 32 'commit' process of figure 17. Upon reception of message 2708 the terminal starts 33 execution of process step 2709. This involves decrypting the second proof, and optionally W O96/2581~ PCTrUS95/01765 the public proof. If the proofs are satisfactory, the terminal sends a message 2710 to the 2 card. Upon reception of message 2710 the card starts execution of process step 2711 3 which clears the NDONE bit to 0. As will be obvious to someone ordinarilly skilled in the 4 art, the NDONE bit can also be stored in a frame which is always updated during a session.
This automatically solves the problem of setting the NDONE and COM variables at the same time.
7 This process is only relevant for sessions in which a frame was written or deleted. An 8 update of the frame system, as described earlier, will start at the first write or delete g operation. The 'commit session ~ end session' process is the usual way in which the ~o 'commit' process of figure 17 is executed which then terminates the update.
As long as the NDONE bit is one, the terminal can ask the card to re-send the second 12 proof, and optionally the public proof, both of which are still retained by the card. This is 13 shown in figure 32. The process starts at step 3200 in which the terminal sends the 'Get 14 Proof' command to the card in message 3201. Upon reception of message 3201 the card 15 starts execution of process step 3202. If the NDONE bit is still one, and thus the proofs are .~ still available, the card sends the proofs to the terminal in message 3203. If the ~DONE bit .7 is zero, then no proofs are sent. When the terminal receives message 3203 it starts lB execution of process step 3204 in which it verifies the proofs and sends the 'Done' 19 command to the card in message 3205. Upon reception of message 3205 the card starts 20 execution of process step 3206 in which it sets the NDONE bit to zero. This implies that 21 the proofs can no longer be read by the terminal.
22 It is believed that step 2705 and the messages 2704 and 2706 allow the terminal to 23 bring the card to the very edge of the commit without actually doing it. It is believed that if 24 at this point the terminal resets the card, then all frames revert to the value they had before 25 the session, as the COM variable has not yet been set. It is believed that the additional step 2~ 2705 decreases the amount of time between the final message from the terminal to the card, 27 and the sending of the proof in message 2708. It is believed that the setting of the COM bit 28 in step 2707 has the result of both updating all the frames to their new value and enabling 29 the proof to be sent.
The session state, which is maintained both by the card and the eerminal, is used to 31 link all the actions in a session together. Figure ''0 shows the basic idea. Suppose the 32 terminal wants to read a specific frame from the card in a 'command & exchange data' 33 process of figure 26. The actions of the card are shown in as item 2000 and the actions of =
PCTrUS95/01765 ~ the terminal are shown as item 2020 The card takes the existing session state 2011 and the 2 data read from the frame 2013 as inputs to a function 2010. This fi~nction combines the 3 existing session state 2011 with the data 2013 and yields a new session state 2012. The ., same two inputs are also combined in a ~lirre-el-t way to yield the encrypted data 2014 s which the card sends to the terrninal. The terrninal has a similar process in which the 6 existing session state of the terminal 2031 and the encrypted data just received from the 7 card 2033 are used as inputs to a function 2030 which yields both a new session state 2032 and the decrypted data 2034. These functions are chosen in such a way that if the ~istin~
session states 2011, and 2031 are identiç~l, then the two new session states 2012, and 2032 ~o are identical, and the decrypted data 2034 is identical to the original data input 2013. When .. the terminal sends data to the card, the same system with the roles reversed is used. The 2 updating ofthe session state is the chaining referred to earlier. The functions 2010 and 13 2030 are chosen in such a way that they implement an iterative cryptographic hash function .~ on the data that passes through them, the session state being the hash output.
In figure 20 there are two functions 2010 and 2030. As the card can be both sender .~ and recipient, it would need an implementation of both functions. To simplify this, the 17 ptere"ed embodiment uses the solution in figure ''1. The card has an imple.nentaLion ofthe 18 function 2110, and the terrninal an implementation of box 2130. The existing session state .~ is still used as inputs 2111 and 2131 to the functions, and both yield the new session state 20 2112 and 2132 as outputs. When the card wants to send data to the terrninal, it uses the 21 data input value 2113. Function 2110 updates the session state, and encrypts the data 22 depending on the session state and outputs the encrypted data as 2114. This value is sent to a the terrninal, which uses it as input 2133 to function 2130 which also updates the session 24 state and decrypts the data to provide output value 2134. Functions 2130 and 2110 are ~s ~u~ktha~, if the existing session states 2111 and 2131 are identical, the output data 2134 is 2~ equal to the input data 2113, and the new session states 2112 and 2132 are also identical. If 27 the terrninal wants to send data to the card, it uses the data as input 2133, and the existing 28 session state as input 2131. The function 2130 has two output values, 2132 which is the 29 new session state, and 2134 which is the encrypted data. The terminal sends the encrypted ~ 30 data to the card, which uses it as input 2113 to function 2110 (which takes the existing 31 session state as input 2111). Function 2110 yields two outputs, the new session state 2112 32 and the decrypted data 2114. Functions 2110 and 2130 are such that in this case too, if the W O96/2581~ PCTrUS95/01765 ~ existing session states 2111 and 2131 are identical, then the data output 2114 is equal to 2 the data input 2133, and the new session states 2112 and 2132 are also identical. Thus, the 3 same function is used for both sending and receiving.
4 The construction offunction 2110 in the preferred embodiment is shown in fi~ure ''2.
s Item 2200 corresponds to function 2110. It tal;es two inputs, the existing session state 6 2201 and the data input 2202, and yields two result values, the new session state 2204 and 7 the data output 2203. The session state 2201 is used as input to a cryptographic oneway u function 2210 marked 'ksb' which produces the encryption/decryption value 2211. This is xorred with the data input 2202 by function 2212 which yields the data output value 2203.
~o The data output value 2203 and the existing session state 2201 are then used as input to the chain function 2213 which yields the new session state 2204 as an output. In the preferred 12 embodiment, both the oneway function 2210 and the chain function 2213 are different 13 functions every time this function is computed in a session.
1~ The construction offunction 2130 in the preferred embodiment is shown in figure 23.
15 Item 2300 corresponds to function 2130. It tal;es two input values, the existing session ~~ state 2301 and the data input 2302 and yields two result values: the new session state 2304 17 and the data output 2303. The existing session state 2301 is used as input to a 18 cryptographic oneway function 2310 marked 'ksb' which yields the encryption/decryption 19 value 2311 which is xorred with the data input 2302 by function 2312, yielding the data 20 output 2303. The existing session state 2301 and the data input 2302 are used as input to 2- the chain function 2313, which yields the new session state 230~ as output. The constituent 22 building blocl;s of function 2300 and 2200 are identical in their functionality.
23 It is believed that the session system provides the following functionality: The 24 terminal can only start sessions with a keyset for which the terminal has access to all those 25 keys. If the terminal does not have access to the keys, the verification in step 2507 will fail 26 with high probability. If an adversary that has access to only a proper subset of the keys in 27 use tries to eavesdrop, she will not be able to read the actual data being exchanged between 2e the card and the terminal as the data is all encrypted using the session state. It is believed to 29 be impractical for the attacker mentioned before to reconstruct the session state without 30 access to all of the keys used. If an attacker tries to add certain commands to a session, 31 then the session state of the card and the terminal will no longer be the same. This results 32 with high probability in a failed proof in step 2703, which in turn results in an aborted 33 transaction. This automatically results in a cancellation of any multi-update that is in WO 96/2581~ PCTAUS95101765 progress. The session system links all actions together, and ensures that if any data in the 2 card is modified, it is done by exactly the commands chosen by the terminal, and that the 3 comm~n~lC are executed in order. The terminal can still choose in step 270S whether to complete the session and commit to all the updates, or to abort the session, and thereby the s associated multi-update. If the card is interlllpted at any point during a session, the G associated multi-update has not finished which results in the card reverting back to its 7 original state. If the card is interrupted after setting the COM variable to I in step 2707, for 8 example by an inadvertent power down, then the terminal can still recover the second proof 9 (called 'proo~~' in figure 27) and the optional public proof. If the card is interrupted before ~o the COM variable was set, the proofs cannot be retrieved from the card. This implies that, even under arbitrary interruptions of the card, either the multi-update happens and the 12 terminal can read the proofs, or the multi-update is canceled and the terminal does not get 13 the proofs.
1< It is anticipated that the card can store data about past transactions. This hlfo.l,ldLion 15 can later be used for many purposes, for example, but without limitation, for accounting and testing purposes, or to possibly reverse the effects of a completed transaction.
SECRET KEY DEBIT/REDEBIT
17 Apart from reading and writing frames, the preferred implemPnt~tion also supports a 18 debit/redebit process which makes for an easier implementation of a pre-paid card for 19 payments. This allows a balance register (sometimes called a balance) stored in a frame to 20 be decreased (debited) by a specific amount using a different access key then the key used Zl to write that frame. The redebit process allows the terminal to decrease the previous value 22 of the register if, and only if, that terminal was the last one to perform a debit or redebit 23 process on that register, this being protected by some simple ~uthentication codes. During a 2~ redebit process the terminal must send the session state that was in use during the previous 25 debit/redebit process on that balance register. As the debit/redebit process usually uses the 26 session proof as a proof that the debit was performed, the usual arrangement is for the 27 terminal to have a tamper-resistant device which has the keys necessary for this process, 28 which keeps track of the total amount that has been debited in this way, and which securely 29 stores the temporary key which allows the terminal to execute a redebit process with the 30 card. A typical application for the redebit function would be for a coffee m~clline Once the 31 user has selected the required drink, the terminal debits the card for the amount of the drink CA 022l8l78 l997-08-08 W O 96/2581~ PCTAUS95/0~76 ~ and starts the machine. If the machine fails to provide the drinl; (for example due to a 2 malfunction) the terminal can do a redebit command with a 0 decrement effectively giving 3 the money back to the owner of the card. As both the debit and the redebit process require ~ a different access key then the write-frame process requires, the terminal in the coffee m~chine does not need to have access to a key which would also allow the terminal to increase the value of a card. The details of this process are not shown, and will be obvious 7 to someone ordinarily skilled in the art.
CONSTANT TIMING
The main use of tamper resistant computational devices, such as the card in our 9 system, is to keep certain data secret and to securely execute some processes. Even if the ~o function is only to execute some processes securely, the only way for the outside world to .. know that the card actually performed the process and that the results are genuine is for the 2 card to authenticate the results of the process. This is generally done using cryptographic 3 authentication systems, which require the storage and use of some secret key information.
Most designs take proper care to ensure that the secret keys are kept secret and not sent ~s out by the card. However, most designs are done on the level of the communication ~~. between the card and the interfacing device (terminal).
7 For this section we will assume that the terminal is trying to extract additional 8 information from the card by any means. Apart from the standard communication, the 19 terrninal can measure several other things, such as the time between a command and its reply, or the power supply current that the card draws at any moment. These measurements 21 have the potential of revealing more information about the internal operations in the card.
22 It is believed that at least one actual implementation of a smart card suffers from a these problems. The card in question has a special co-processor on chip to allow it to do 2- RSA signatures. It is believed that the terminal can determine when the co-processor is 2s being used by measuring the power supply current as a function of time and the electro-26 magnetic field around the smart card chip. The RSA algorithm involves an exponentiation 27 with a secret exponent. The exponentiation is, in this implementation, done using a square-28 and-multiply algorithm well known in the art. This algorithm involves a large number of 29 squarings interlaced with a smaller number of multiplications. Measuring the activation times of the co-processor allows the terminal to deduce whether the next step is a 31 multiplication or a squaring. With this knowledge the actual secret key used by the card in 32 creating the RSA Cipn~tllre can easily be recovered.
WO 96/25814 PCTrUS95)D~765 It is believed that public-key algorithms are generally more susceptible to this kind of 2 attack then secret key algorithms. but many secret key based systems still suffer from these 3 attacks. If, for example, a PIN verification routine in a smart card co~ al es each digit in 4 sllcc~ssion and aborts the comparison as soon as a micm, tch is found, then the time s between the start of the verification command and the 'PIN incorrect' response reveals which of the digits is wrong. It is believed that this reduces the average number of attempts 7 that have to be made before the right PIN is found in an attack from 5000 to less then 40 8 for a 4-digit decimal PIN. Similar attacks are believed to work against certain secret-key 9 based impleme~t~tions. An obvious solution is to ensure that all processes which might ~o reveal additional information to the terminal are executed in a fixed amount of time. It is ~- believed that this can be achieved by inserting properly timed delay loops at appropriate 12 places.
13 It is believed that many existing smart card implementations will reveal the presence 14 of a file or directory on the card by the timing differences of the responses. Even in cases t6 where the terminal does not have access to said file or directory, the timing of the response ~ will differ depending on whether the file or directory exists or whether it does not exist.
17 Furthermore, several smart card impl~mtont~tions will reveal the presence of files and/or 18 directories to any terminal, even if the terminal has no access to the related smart card 19 application. It is believed that it is standard practice for a smart card to reveal its identity 20 number to any terminal. It is believed that terminals might use this information to invade 21 the privacy of the owner of the smart card.
22 It is believed that for least one specific smart card chip it is possible to determine 23 which instruction is being executed by detailed measurements of the power supply current 24 as a function of time, allowing the terminal to determine which half of an IF st~tPment was 25 executecl, even if the time taken for both branches was the same. As is usual in the art of 26 cryptography, we always assume that the actual code used in the card is known to any 27 ~tt,.cl~er. It is a well established principle of cryptography and security systems that the 28 security should only rely on the secrecy of key material, and not on the secrecy of the 29 processes applied to the keys.
In the preferred implementation the card is careful not to reveal any additional 31 information under these attacks. To ensure security against these attacks the card uses a 32 single execution path. This means that for any process involving information which is not 33 already known to the terminal, and to which the terminal might not have access, the same W O96/25814 PCTrUS9S/0176 sequence of instructions is always used. For example, in the computation of a house such as 2 figure 9, the architecture (number of columns and height of each column) is not secret from 3 the terminal, but the actual values are. For any given ar~hitectllre, the card always uses the 4 same sequence of instructions to compute the house result value 979 from the house origin s value 901, independent of the value of the house origin 901.
6 An example of how this is achieved is given in figure 31. The first process consisting 7 of steps 3100, 3101, 3102 and 3103 show a typical conditional execution sequence.
Starting at 3100 the first step 3101 verifies a certain condition 'cond'. If this condition is 9 false the process continues at step 3103, otherwise it continues at step 3102. In step 3102 a 10 counter 'cnt' is incremented, and two variables 'savel' and 'save'" are assigned with ~1 values 'x' and 'y' respectively. After step 3102, processing continues in step 3103 where 12 the process is terrninated. The second process consisting of steps 3110, 3111, 3112 shows 13 a functionally equivalent process which does not use a conditional execution construction.
1~ After the process start in step 3110, the first action in step 3111 is to convert the condition 15 'cond' to an integer value which is 0 if the condition is false, and 1 if the condition is true.
16 There are standard techniques for converting conditions to such an integer value which are 17 widely used in certain higher-level language implementations. In step 3111 the value 'cond' is used to represent this value. The counter increment is now replaced by an addition: the ,~ value 'cond' is added to the counter. This has the same effect as incrementing the counter 20 only if 'cond' equals 1. If the condition was false, then 'cond' is 0 and the operation has no 21 effect. If the condition was true, 'cond' has a value of I and the addition adds exactly one 22 to the value of 'cnt'. The action 'savel=x' is converted to a more complex action 23 'savel=cond*x+(1-cond)*savel'. If the condition was false, then 'cond' is equal to 0, and 2'~ thus 'cond*x' is also equal to zero. At the same time '(l-cond)' is equal to 1, and thus '(1-25 cond)*savel ' is equal to 'savel '. The sum of both expressions is equal to 'savel ', so that 25 the assignment has no effect. This is of course equivalent to the skipping of this action in 27 the first process. If the condition is true, then 'cond' is equal to 1 and '(l-cond)' is equal 28 to 0, so that the right hand side of the acsignment has a value equal to 'x'. This is of course 29 equivalent to the action 'savel=x' in the first process which is only executed if the 30 condition is true. The third action shows another equivalent formulation, the variable ~1 'save'~' is replaced by an array with indexes '0' and ' I '. The value of 'y' is assigned to 32 'save''[cond]', which implies that if the condition is true then 'y' is assigned to 'save~[l]' 33 and if the condition is false then 'y' is assigned to 'save2[0~'. If the original 'save2' variable _ CA 022l8l78 l997-08-08 W O96/25~14 PCTnUS95101~65 is put in the new 'save'~[l]' and save~[0]' is discarded after the process, then 'save2[1]' 2 will have the same value as the variable 'save~' had after their respective processes, 3 ~ssumin~ an equivalent starting state. These new actions in step 3111 are called 4 functionally equivalent to the actions in step 3102 which are only executed if the condition s 'cond' is true. The process terminates in step 3112.
As a more detailed example we will discuss figure 18 which shows the 'find frame' 7 process rliccussed before. In the preferred implementation, this is one of the processes that 8 uses a fixed execution path. The loop consisting of steps 1802,1803,1804, and 180~is executed a fixed number of times, namely once for each frame slot. The number of frame 10 slots is not a secret, so no special care has to be taken. However, the conditional execution ~1 by steps 1802 and 1803 might reveal if and where in the memory the frame was found, 2 while this data might not always be available to the terminal. Thus, steps 1802 and 1803 are 3 implemented in a single execution path using the techniques shown in figure 31. Steps ~4 1810,1811,1820 and 1830 are also implemented using a single execution path, this involves rewriting the actions of steps 1820 and 1830 into a single sequence of actions .~ which depends on the values of two conditionals. This is a simple generalization of the ~~ techniques shown in figure 31 and as will be obvious to someone ordinarily skilled in the 18 art. The jump to step 1840is not done within the single execution path. This enters ~9 'broken' mode, which basically prevents any further normal proc~ssin~ It is believed that it iS unnecessary to hide this fact from the terminal, as it will be quite obvious to the terminal 21 that the card has entered 'broken' mode.
22 In the preferred embodiment the single execution path is used for all processes for 23 which the execution path taken might reveal any information to the terminal which the 24 terminal would otherwise not learn. It is believed that this provides the best security against 2s any of the attacks mentioned above. Obviously the single execution path does not imply 28 that the same data is always being used in the actions. It is believed that no implementation 27 using secret keys can be protected against an attacker which is able to determine both the 28 execution path, and the data being used in the process.
EMV
The preferred embodiment includes an implementation of the EMV system. It is 30 appreciated that someone of ordinary skill in the art would be familiar with the 31 specifications of the EMV system which were referenced earlier. The preferred W O96125814 PCTrUS9S/0176S
embodiment implements the EMV system and incorporates several improvements, among z others a dynamic off-line authentication of the data sent by the card to the terminal.
3 The preferred embodiment is shown in figure 28. The process starts at the terrninal in 4 step 2800, which is followed by step 2801 in which the terminal asks the card for the s application data. This request is coded into message 2802. When message 2802 is received s by the card, it starts execution of process step 2803. In step 2803 the card sends the 7 application data requested to the terrninal in message 2804. In the EMV system and in the 8 preferred embodiment this sending of application data is actually achieved using several 9 requests in sequence, these are not shown for clarity. Upon reception of message 2804 the 10 terminal starts execution of process step 2805. Execution of steps 2805, 2807, 2808, 2809, 2811, 2812, 2814, 2816, and 2817 occurs only when the transaction is conducted on-line.
12 In the off-line case these steps are omitted (see EMV specifications for more detail). It 13 constructs an authorization request and sends it to the issuer, or a representative of the 1~ issuer in message 2806. When message 2806 is received by the issuer~ it starts execution of 15 step 2807, in which it processes the authorization request. The next step 2808 consists of 1G the creation of a valid script for the terminal, after which both the authorization response 17 and the script are sent in step 2809 to the terminal in message 2810. When message 2810 is 18 received by the terminal it start processing of step 2811. In step 2811 the terrninal 19 processes the script it received from the issuer, this involves sending the commands and 20 data given in the script to the card and awaiting any response. The EMV specifications 21 allows the script to be executed before or after the external authentication in steps 2812, 22 2814 and 2815. Both possibilities are shown in figure 28, and a simple extension would 23 allow two scripts to be used. Our p,efe-,~d embodiment typically executes the script in step 24 2811. ~er step 2811 the terminal in step 2812 sends the authorization code to the card in 25 message 2813. The card verifies the code in step 281'1 and sends the result ofthe 26 verification to the terminal in messa~e 2815. Upon reception of message 2815 the terminal 27 executes process step 2816 in which it verifies the response. The next step 2817 is again 28 the execution of a script with the card (see comments for step 2811). All actions described 29 SO far are an embodiment ofthe EMV specifications. In step 2818 the terminal requests a 30 payment proofofthe card, which it sends in message 2819. Upon reception of message 31 2819 the card executes step 2820 in which it computes the appropriate payment proofand 32 sends the result to the terminal in message 2821. Upon reception of message 2821 the CA 022l8l78 l997-08-08 terminal starts execution of process step 2822 in which it verifies the proof of payment, 2 after which processing terminates at step 2823.
3 Most of the steps described above correspond directly to actions specified in the EMV specs. The ~), ere. ~ed embodiment adds a dynamic authentication to the EMV
s specifications. In the EMV system there is no provision for convincing the terminal of the 6 53llth.onticity of the card and the messages the card sends in the off-line case. The proof of 7 payment of step 2820 (called TC in EMV) is based on a secret key proof, and it is believed 8 that it is not the intention to let the terminal verify the TC. Therefore, in the off-line case in 9 EMV the terminal is susceptible to replay attacks, as are well known in the art. The ~o pl efe., ed embodiment uses the compact endorsement signatures to rectify this. In step ~. 2820 a second element is added to the payment proof. The TC is still sent, but in addition ~2 the card ~llthenticates all the data it sent to the terminal during the transaction using a 3 compact endorsement sign~tllre in the variant that can authenticate an arbitrarily long 1- message, as described earlier. If message 2821 is lost during transmission then the terminal 15 can ask the card to retransmit the daea, in the same manner as the proof(s) of a session can 16 be retransmitted, as shown in figure 32. It is believed that the terminal can verify the ., compact endorsement Cign~ture and thus be assured of the authenticity of the data sent by .~ the card, and therefore also of the correctness of the TC.
~~ The script that the issuer creates can be used to securely perform a variety of func-tions, a typical application would be the increasing of a balance of some form. The scripts 21 are just a set of comm~nrlc which the terminal sends to the card. These are chosen in such a 22 way by the issuer that they constitute a session, as described earlier. A direct session 23 between the card and the issuer to increase a balance would involve more then 2 messages 2~ between the terminal and the issuer: the start session process alone would require 2 2s messages between the card and the issuer (and therefore between the terminal and the 26 issuer). The old limit would have to be read, and then the new limit written requiring more 27 messages. Most existing networks for financial transaction authorization are built upon a 2 2~ message authorization, adding additional messages could lead to complications. The 29 plef~:l I ed embodiment uses the sessions in a different way, allowing the increase to occur using the existing sessions and using only 2 messages between the terminal and the issuer.
3- As mentioned before, the card challenge consists of some counters. These counter values 32 are included in the data sent in messages 2804 and 2806. The issuer now has enough 33 information to simulate the behaviour of the card in the session, specifically it knows the O96/25814 PCTrUS9S/01765 ~ card challen~e that the card will use. This allows the issuer to generate all necessary 2 messages for the succescfill completion of a session. ~nstead of a special 'add amount to 3 balance' function, the pr~fe,led embodiment uses the standard read frame and write frame functions. To this end, the current value of the balance is also included in mess~g~c 2804 s and 2806. The issuer includes a 'read frame' function in the script. The issuer already 6 knows the answer, but the answer is also chained into the session state, as described earlier.
7 If the balance was changed to a different value before the execution of the script, this will result in a different chain state in the card, which results in a failed proof in the 'commit 9 session & end session' process. As an example, but without limitation, a complete script 10 would consist of a ~start session & proof keys' command, a 'read frame' on the balance, a 'write frame' on the balance, and a 'commit session & end session' comm~nd To prevent 12 the terminal from withholding the script, the authorization code sent in message 2813 13 depends on the data of the script, so that the authorization will fail if the terminal does not 14 execute the script. As will be obvious to someone ordinarilly skilled in the art, the ~s authorization code can also be used to notify the card that a script is to be performed in 16 step 2817.
17 The process of performing a script is shown in more detail in figure 33. The process 0 begins at step 3300 at the terminal and continues at step 3301 where the terrninal sets an 19 index variable 'n' to zero. The next step 3302 checks whether the 'n'th command in the C script exists. If the 'n'th command does not exist, processing continues at step 3309. If the 21 'n'th command does exist, processing continues at step 3303. In step 3303 the terrninal 22 sends the command and associated data of the 'n'th command in the script to the terminal 23 in message 3304. Upon reception of message 3304 the card starts processing of step 3305 ~ in which it performs the actions associated with the command and sends the response to the 25 terminal in message 3306. Upon reception of message 3306 the terminal starts processing 25 of step 3307, in which it checks the response message for an error code. If the card 27 reported an error, processing continues at step 3310. ~fthe card did not report an error, the 28 process continues at step 3308, in which the terminal increments the ~n' variable by one.
29 The process then continues at step 3302. In step 3309 the terminal signals a successfill ~ completion ofthe script process. In step 3310 the terminal signals a failure in the script 31 process. In either case the process continues with step 3311 where the process is 32 terrninated.
~ The EMV specifications include some unspecified 'risk management' which the card 2 performs, some specific 'risk management' which the terminal performs, an unspecified 3 authorization process which the issuer performs for on-line transactions. The plef~, I ed embodiment uses a general structure which can be used to implement both credit card s transactions, pre-paid debit card transactions, ATM card transactions etc. The card keeps a 6 balance representin~ the amount that can still be spent using that application. In every 7 succescfill payment, the card decreases this balance by the amount of the payment. The 8 card will refuse an off-line payment for an amount that exceeds the balance in the card, and 9 will request an on-line transaction. To increase the balance of the card, the issuer can send ~o the appropriate comm~nrls in the script which increase the balance. In the preferred embodiment the card increases the ATC (Application Transaction Counter) only for 12 succeccfi-lly completed transactions.
13 In the prefe"ed embodiment, once the the card has issued an ARQC and thus asked for an on-line transaction, the card will not perform any off-line transactions until a 15 successful on-line transaction has been completed.
In the preferred embodiment the issuer keeps a database of all on-line requests, and ~7 of all the payment data it receives from the terminals (possibly through the acquirer) 8 relating to off-line payments. For any off-line or on-line payment, the ATC value of the 19 card is included in the data that reaches the issuer. For on-line transactions, the balance of the card is included in the data that is sent to the issuer. The information related to different 21 transactions might reach the issuer in a non-chronological order. As the card increases the 22 ATC only for successful transactions, the issuer knows exactly how many 'previous' 23 transactions it can still expect. Specifically, in any on-line transaction, the issuer leams the 24 current ATC of the card, and therefore knows how many off-line transactions the card 2s made since the previous on-line transaction. The issuer also learns the current balance of 2~ the card, and can thus determine the total amount of the off-line transactions since the 27 previous on-line transaction. It is beiieved that this provides adequate information to the 28 issuer to make the necessary decisions for the on-line transaction, and any possible script to 29 increase the balance on the card.
The interaction between the card and the issuer are shown in figure 47. This shows 3- the card 4700, the temminal 4704 and the issuer 4706. The card has a balance (CB) 4701, a 32 cryptogram counter (ATC) 4702 and some card counters 4703. In the preferred 33 embodiment there are two counters, one of them is incremented for each 'commit' process, W 096/2581~ PCTrUS95/01765 ~ the other is incremented during each 'commit' or 'cancel' process. These counters are used 2 as the card challenge in the sessions. The card and terminal communicate over 3 communication channel 4720; the terrninal and the issuer communicate over 4 communication channel 4721. During a transaction the terminal typically sends a single s message to the issuer, which replies with a single message. The issuer uses three d~t~bases:
the card base 4708, the event base 4709 and the terminal base 4710, and comrnunicates 7 with those data bases using communication channel 4722. The terminal base contains data associated with each terminal, and is not shown in detail for clarity. Figure 48 shows the 9 data fields of a record in the card base. The first field 4800 contains the primary account .c number (PAN) and the sequence number. This is a unique identification of the card, the primary account number usually corresponds to the credit card number, or bank account 12 number, while the sequence number distinguishes several cards that use the same PAN, for t3 example, but without limitation, two credit cards on the same account. The next field 4801 ~~ contains information about the card status and configuration, which is not shown in detail for clarity. In field 4802 the highest known ATC of the card is stored. Field 4803 stores the 6 ATC value of the last completed on-line transaction, that is, for which the issuer has 7 received the corresponding TC. In field 4804 the issuer stores the ATC value for the last ARQC it received. In field 4805 the issuer m~int~in~ the known card balance KCB, which 1~ is the issuers best approximation of the current balance of the card. The last field 4806 20 contains a settling amount SA, which is the amount the issuer plans to add to the card's 21 balance in the next on-line transaction. Figure 49 shows the fields of a record of the event 22 base, each record representing an event. The first field 4900 contains the PAN and 23 sequence number, which uniquely identifies the card. The field 4901 contains the ATC of 24 the event, field 4902 the status of the event, field 4903 the amount of the event, field 4904 25 the card counter values for the ever,t, field 4905 the card's balance during the event, and 2~S finally field 4906 the settling data for the event.
27 Figure 50 shows a global overview of the issuer processing during an on-line transac-28 tion. In the first step 5000 the issuer receives the authorization request for the transaction, 2i~ inclu~in~ terrninal data and card data. The terminal data typically includes the terminal 30 identity; the card data typically includes the PAN and sequence number, the amount of the 31 transaction, the current value of the card counters, the card balance, the current atc etc. In 32 the next step 5001 the issuer makes some elementary checks on the validity of the data 33 received. In step 5002 the issuer updates the known balance KCB based on the actual carc _ O96125814 PCTrUS9510176S
~ balance CB. In step 5004 the issuer checks for a settling amount for the card, and adds it to 2 the script amount. In step ~005 the issuer decides whether or not to accept the transaction, 3 and finally in step 5006 the issuer sends the authorization for the transaction to the 4 terminal, with an optional script to perform any necessary adjustments of the balance.
s Figure ~ l shows a global overview of the issuer processing when it receives the transaction B data relating to an off-line transaction from a terminal. In the first step 5100 the issuer 7 receives the transaction data, which typically includes a terminal identifier, card data, the 8 amount and a transaction cryptogram. In the next step 5101 the issuer checks the validity 9 of the terminal and card data. In step 5102 the issuer checks the validity of the transaction, ~o among other things it checks that the cryptogram is correct. In the final step 5103 the .. issuer updates the known card balance KCB based on the card balance given with the 2 transaction.
~3 Figure 52 is in two parts, shown as figure 52A and figure 52B. It shows a more ~4 detailed description of the issuer processing during an on-line transaction shown in less ~s detail in figure 50. Some steps of this processing are not shown for clarity. The first step ~ 5200 is the start of the process. At this point the issuer has already received the 17 authorization request, incl~lrling the card identity, the terminal identity, the ATC, the ~ ARQC, the amount, the card counters, the card balance CB etc. In the next step 5201 the 19 issuer sets a variables called 'script amount' to zero, and a variable called 'temp kcb' to the 20 given card balance CB. The 'script amount' variable will contain the amount for which a 21 script will be generated, the 'temp kcb' is used to update the KCB stored by the issuer. The 22 issuer looks up the record for the card in question in the card base, and also the record for 23 the terminal in question in the terminal base. The issuer verifies that the ARQC cryptogram ~ is valid, that the terminal is valid, that the card is valid, that the card has not exceeded its 25 expiration date and that the card has not been blocked. In the next step 5202 the issuer 26 checks whether the HATC (highest known atc) is less then the current ATC. If this is not 27 the case the process continues at step 5213, as indicated by the labels 5250 and 5212. In S this case the ATC of the card is lower then the highest l;nown ATC from that card, so the 29 card's ATC must have decreased. A proper functioning card never decreases the ATC,so 30 this is classified as an 'card fraud detect', an attempted fraud by the card, which is practice 31 means that the tamper-resistance of the card must have been broken, that the card must :!12 have malfunctioned, or that something else in the system is wrong. If the condition in step 3 5202 is true, the process continues at step 5203. In step 5203 the issuer checks whether the W 096/2581~ PCTrUS95/01765 ATC is equal tO the ATC of the last authorization request. ~f this is the case, procPscing 2 continues at step 5204, if this is not the case processing continues at step 5214. If the ATC
is equal to the LAATC, then the last transaction was not completed successfully, as the 4 ATC would have increased had it completed succecsfi~lly. Thus, getting a second s authorization request with the same ATC value implies that the previous transaction was not completed. It is, however, possible that the script was executed but the transaction 7 didn't complete. As all scripts in the preferred embodiment modify the card balance, the 6 issuer can detect whether the script was performed or not. It is anticipated that for scripts 9 that do not modify the b~l~nce, some other value will be used for this function. In the o pler~lled embodiment, the card will not perform an off-line transaction after a failed on-line transaction, so no off-line transactions can occur between a failed on-line transaction and 2 the next on-line transaction. In step 5204 the issuer checks whether a script was issued 13 during the last authorization request, by looking up the recorded events in the event base. If 14 no script was issued, and thus no update of the CB is still outstanding, the process ~s continues at step 5205, otherwise it continues at step 5206. In step 5205 the issuer checks whether the balance recorded in the event base for the last authorization request is the same 17 as the current card balance. If this is not the case, processing continues at step 5213 (via 18 5210 and 5212). Otherwise, processing continues at step 5223 (via 5211 and 5222). In step 19 5206 the issuer checks whether the CB is equal to the balance recorded in the event base 20 during the previous authorization request. If this is the case, processing continues at step 2- 5208, otherwise it continues at step 5207. In step 5207 the issuer checks whether the card 22 balance is the sum of the balance recorded for the previous authorization request and the 23 update amount of the script issued during that authorization process. If this is not the case, 24 the card balance has changed in an inexplicable way, and processing continues at step 5213 2s (via 5210 and 5212), otherwise processing continues at step 5209. In step 5208, the issuer 26 knows that the script of the previous on-line transaction was not completed, and adds the 27 update amount of that script to the 'script amount' variable. In the next step 5209 the 26 issuer marks the record in the event base that contained the information about the script of 29 the previous on-line transaction as either 'completed' or 'incompleted'. That script is then 30 no longer outstanding. After step 5209 processing continues at step 5223 (via 5211 and ,- 5222). In step 5213 the process stops and has detected an error. In step 5214 the issuer 32 checks whether the last authorization request atc LAATC is equal to - 1. If this is the case, ,3 processing continues at step 5219, otherwise it continues at step 5215. The value -1 is used CA 022l8l78 l997-08-08 W O 96/2581~ ~T~US95JD1765 to indicate that the last authorization request was part of a succ~ssfi~l transaction. In step 2 5215 the issuer checks in the event base whether there is still an outstanding script to 3 update the CB. If this is the case, processing continues at step S217, otherwise it continues at step 5216 where the ~temp kcb' variable is set to the value of the balance during the last s authorization request. In step S217 the 'temp kcb' variable is set to the sum of the balance 6 during the last authorization request and the amount of the update of the outs~n~iing 7 script. In the next step 5218 the script in question is marked as 'completed', thus removing it from the 'outct~nf~ing~ state. In steps 5217 and 5218 there was an Oll~ script, and 9 now a new ATC is seen by the issuer, thus the previous authorization transaction was 10 s~lccessfillly completed. At the start of step 5219 the 'temp kcb' variable is an upper bound on the current balance of the card, and in step 5219 the issuer checks whether the card ~2 balance CB is larger then 'temp kcb'. If this is the case, processing continues at step 5213 13 (via 5220 and 5212), otherwise it continues at step 5223 (via 5221 and 5222). In step 5223 4 the issuer checks whether the settling amount is positive. If this is not the case, processing ~s continues at step 5225, otherwise it continues at step 5224 where the settling amount is ~s added to the 'script amount' variable, a~er which processing continues at step 5225. In ~, step 5225 the issuer first verifies that the amount of the transaction is at most the sum of lB the current card balance BC and the 'script amount' variable. If this is not the case, the card 19 balance is insufficient and the issuer does not give an authorization for the transaction. Next 20 the issuer checks whether the script amount is not zero. If this is not the case, processing 21 continues at step 5227, otherwise it continues at step 5226 in which the issuer creates a 22 script for the card using the data available, adds the essPnti~l script inform~tion to the event 23 base, and sets the settling amount in the card base to zero, after which processing continues 2~ at step 5227. In step 5227 the issuer checks whether LAATC is not equal to - 1, and 25 whether ATC is greater then LAATC. If this not the is the case, processing continues at 2~ step 5229, otherwise the process continues at step 5228 where the LOATC value is set to 27 the LAATC a~er which processing continues at step 5229. In step 5229 the issuer adds a 28 record to the event base cont~ining the essenti~i information about this transaction. In the 29 next step 5230 the issuer updates the LAATC value to ATC, the HATC to ATC- 1 and the ~ 30 KCB value to CB, after which the process is terminated in step 5231. A~er the process the 31 issuer sends a reponse to the terminal, cont~ining the authorization cryptogram, the 32 optional script etc.
WO96/25814 PCTrUS95/01765 ~ Figure 53 shows a more detailed description of the issuer processing when it receives 2 the transaction data of an off-line transaction, which was shown in less detail in figure 51.
3 Before the start of the process, the issuer receives the transaction data, typically including the card PAN and sequence number, the amount, the terminal id, the ATC, the card balance s etc The issuer retrieves the record associated with that card from the card base. The issuer verifies the validity of the various identities, and checks that the transaction cryptogram TC
7 iS valid. The issuer looks up the PAN/sequence number/ATC combination in the event base 8 to check that this transaction number has not occurred before. The process starts at step 9 5300. In the next step 5301 the issuer checks whether ATC is greater than HATC the 10 issuer has for that card. If this is not the case, the process continues at step 5303, otherwise it continues at step 5302 in which the HATC value is set to the ATC value, after which the 12 process continues at step 5303. These steps ensure that the HATC value is m~int~ined as 13 the largest ATC value for which a valid TC was received. In step 5303 the issuer checks .~ whether LAATCis equal to - I and ATC is greater or equal to LAATC. If this is not the ~s case, the process continues at step 5309, otherwise it continues at step 530~. In step 5304 the issuer sets the LOATC to LAATC, and sets the LAATC to -1. This serves to m~int~in 17 the LOATC value, which is defined as the last ATC value for which the issuer knows an 18 on-line transaction was successful with that card. In the next step 5305 the issuer checks 10 whether a script was issued during the last on-line transaction by lool;ing in the event base.
20 If this is the case, processing continues at step 5307, otherwise it continues at step 5306. In 21 step 5306 the issuer sets the KCB value to the card balance that the issuer received during 22 the last authorization request, and continues at step 5309. This is an upper limit to the 23 current card balance. In step 5307 the issuer sets the KCB value to the sum of the card 24 balance during the last authorization request and the amount of the update value used in the Z5 script of that request. This again is an upper limit to the current card balance. In the next 2~5 step 5308 the issuer marks the event record associated with that script as 'completed'. In 27 step 5309 the issuer checks whether ATC is greater or equal to LOATC, if this is the case 28 then the amount of the transaction is substracted from the KCB value in step 5310. The 29 process terminates in step 5311.
It is believed that the processes shown in figures 52 and 53 implement a secure 31 method for m~n~ging the card balances, ensuring that the card does not get a higher 32 balance than intended, and that any attempted increases in the balance of the card are 33 completed.
WO 96/2581~ PCTJIJS9SJ1~1765 ~ The processes shown in figures 52 and 53 are fairly specific to the card as imple-2 mented in the preferred embodiment. Depending on various implem~nt~tion details, the 3 exact order and type of actions in the issuer processes might vary, as will be obvious to someone ordinarilly skilled in the art.
s For a credit card application the balance would be the OTB (Open To Buy). This is 6 the amount of money that the user can charge to the credit card before a tr~nc~ctiQn will be 7 refused. It is believed that most current credit cards have such an OTB limit (sometim~s called the credit limit). It is believed that having the card m, int~in the OTB allows off-line 9 tr~n~ctions to occur without the risk of excee~lin~ the OTB. Under some circ~lm~t~ncec .o the OTB should be increased, a typical example of such a circumstance is when the user has .. paced an outstanding credit card bill: the amount paid can be added to the OTB. Typically 12 this will not be communicated to the card directly, as there is no communication link 13 available. The card continues to use its old OTB value, until an on-line transaction occurs.
14 One of the possible reasons for an on-line transaction is that the OTB in the card is 15 e~ch~ ted. During that transaction the issuer can send a script to the card increasing the OTB tc~ the new val~-~ a~ ~ wi~ furth~r ~ tr~r.s2Gti~n to o~CIlF. It is be~e~ed that 17 the p-efe,led embodiment can be used in this way with only a small fraction ofthe 18 transactions being on-line, and without compromising security. The credit card might also 19 be used to perform traditional credit card transactions, not using the EMV system. This 20 might result in the OTB being decreased without the card's knowledge. It is believed that 21 the issuer can use the script to reduce the OTB in the card. As will be obvious to someone 22 ordinarilly skilled in the art the issuer might also split the 'real' OTB of the credit card, and 23 give part of it to the card for use in off-line transactions, while keeping the other part in at 24 the issuer for use in traditional credit card transactions. It is believed that using the script, 25 the issuer can in such a setting increase or decrease the card's OTB depending on the OTB
2G rem~ining at the issuer, thus balancing the two OTBs in case one of them is depleted more 27 then the other.
28 For a pre-paid debit application the balance would, eprese,ll the amount of money 29 stored on the card. During payments this amount typically decreases. Again the card can do 30 an arbitrary number of off-line transactions until the balance has been e~h,.usted. In an on-31 line transaction, the issuer can increase the balance using a script. In pre-paid applications 32 this would require the user to pay the issuer for the additional money that it puts on the 33 card. This might for example, but without limitation, be accomplished by integrating a bank W O96/25814 PCT~US95/0176 account withdrawal (similar to the cash withdrawals at current ATMs). During an on-line 2 transaction, the card has already been authenticated. The EMV specifications already allow 3 a cardholder verification procedure to be included, such as the entry of a PIN code. The 4 card authentication and the PrN code entry provide the same functionality as current cash 5 withdrawals at ATMs, and could possibly be used in a pre-paid withdrawal where the 8 cardholders bank account is debited, and the balance on the card is credited. In the preferred embodiment the card has an option to require a PIN during a transaction, in that D case the card will not complete a transaction without a valid PIN, such a m~ncl~tory PIN
9 enforced by the card is not included in the EMV specifications. As will be obvious to ~o someone ordinarilly skilled in the art, such mandatory verifications enforced by the card can also be applied to any other cardholder verification method.
12 For an on-line debit application the balance itself is not really necessary. The balance 13 can be rendered ineffective by various means, amonn others giving it a very large value.
14 The card authentication and the cardholder verification mentioned above can be used to ~s directly debit the cardholders banliaccount in an on-line transaction, which might also credit .~ the terminal owner's bankaccount at the same time.
17 It will be obvious to a person of ordinary skill in the art that a single card can contain 18 several EMV compatible applications, and can thus be used for several of these ~~ applications.
CARD ~NSTRUCTIONS
In the preferred embodiment the card is a smart card, and communicates with termi-21 nals using the ISO 7816 standard protocol. In this protocol the terminal issuer a sequence 22 of comm~n~ls to the card. Every command consists of a command header sent from the 23 terrninal to the card, some optional data transfer from the terminal to the card and an 2J optional data transfer from the card to the terminal, and finally a result code sent by the 25 card to the terminal. An overview of the sequence in which the commands are meant to be 26 used is shown in figure 29. The card does not allow any other sequence. At any point in 27 time the terrninal can start at step 2900, follow the arrows and issue the comm~nds in the 28 order encountered. After step 2900 the terminal continues either at 2901, 2920, 29tl or 29 2930.
In step 2901 the terminal sends the first of two command that together implement the 31 start session process of figure ''5. Subsequently in step 2902 it sends the second command CA 022l8l78 l997-08-08 WO96/2~814 PCTnUS9~01765 ~ of the start session process. The terminal then sends one or more commands from the set 2 'get frame' 2903, 'put frame' 2904, 'debit frame' 2905, 'redebit frame' 2906, 'kill frame' 3 2907 and 'public debit' 2908. After this sequence of comm~n-ls the terminal sends a 4 'commit' command which termin~t~s the session, and executes the 'commit' process s described earlier. After a session the terminal can start again and issue the 'get proof' COll~"~a~ld 2920 to get the proofs from the previous session, and the 'done' command 2921 7 when the proof has been sl-cceccfully read. The commands mentioned so far implement the 8 basic card functionality.
The EMV implement~tion is largely separate and conforms to the EMV specifications 10 mentioned above. It starts at step 2930 in which the terminal sends a 'select file' comm~ntl which is repeated any number of times. To start a new transaction, the terrninal continues 2 with step 2931, to get the transaction proof of the last transaction again the terminal issues 3 the 'get last AC' command 2940 after step 2930. In step 2931 the terminal issues the 1~ 'manageapplication 1' co,.""~n~ afterwhichitentersaloopinwhichitexecuteseitherof ~s the comm~n-lc ~get file' 2932 and 'get data' 2933 one or more times. Af~Ler this loop, the i~ te~ninal send~ ~he 'veriry' ~ommand 2934 one or more times. ~xecution of the veri~,~
17 command is optional under some circumstances, but this is not shown here for clarity.) The 18 next step is for the terrninal to send the 'generate AC 1' command. For an off-line 19 transaction the terrninal continues at step 2939, for an on-line transaction the terminal 20 continues at step 2936 in which it sends a sequence of commands from a script to the card.
21 The comm~nds that can appear here in 2936 are exactly those that appear in the dotted 22 frame 2910 and are not shown in detail for clarity. Execution of step 2936 is optional. The 23 next command is 'external authenticate' 2937, after which the terminal sends the 'generate 24 AC 2' command in step 2938. Command 2937 and 2938 are optionally. Finally the terminal 25 sends a 'manage application 2' comm~nd.
2~3 For an off-line transaction, the correspondence between figures 28 and 29 are as 27 follows: The steps 2930 and 2931 are administrative and not shown in figure 28. The steps 28 2801 and 2803 are implemented using the commands 2932 and 2933. Command 2934 is 29 not shown in figure ''8 for clarity. For an off-line transaction, steps 2805 till 2817 are not 30 exec~lted. Steps 2818 and 2820 correspond to command 2935, the next col,l"~and the 31 terminal issues is 2939 which is not shown in figure 28 for clarity.
32 For an on-line transaction the correspondence between figures 28 and 29 are as 33 follows: The steps 2930 and 2931 are administrative and not shown in figure 28.
W O96/25814 PCTrUS95/0176'.
~ Com m~n-l~ 2932, 2933 and 2935 together implement steps 2801 and 2803, the command 2 2934 not being shown in figure 28 for clarity. The script of step 2811 corresponds to 3 com m~ntlc 2936 which basically involves an arbitrary session. The external ~-t'rl~nticate 4 command 2937 corresponds to steps 2812, 2814, 2816. Step 2817 is not supported in the s command set shown in figure 29. Steps 2818 and 2820 are implemented by command 6 2938, while command 2939 is not included in figure 28 for clarity.
7 Figures 34, 35, 36, 37 and 38 show the detailed steps of all the comm~n-lc Every 8 command consists of three steps, we will use the 'start session 1 ' command as an example.
The first step 3400 is executed by the terminal. The terminal sends a message 3401 to the lo card which includes a command code to tell the card which command is being executed, ~- and which might include some other data. When the card receives the message 3401 it 12 starts execution of the second step 3402. This involves the card sending a message 3403 13 back to the terminal. This message consists of some optional data, plus a result code. When 14 the message 3403 is received by the terminal, the terminal starts execution of the third step ~s 3404. No action is taken in the third step apart form the analyses of the contents of the last 16 message. Each command corresponds to a single APDU, but might be implemented as two 17 T=0 commands as described in the ISO 7816 standard. This same structure is repeated for 18 each ofthe comrr~ncis. The same structure is repeated for all commands, the items (3400, ~~ 3401, 3402, 3403, 3~S04) corresponding with (3410, 3411, 3412, 3413, 3414), (3420, 20 3421, 3422, 3423, 3~24), (3430, 3431, 3432, 3~33, 3~34), (3500, 3501, 3502, 3503, 21 3504), (3510, 3511, 3512, 3513, 3514), (3520, 3521, 3522, 3523, 352~), (3530, 3531, 22 3532, 3533, 3534), (3600, 3601, 3602, 3603, 3604), (3610, 3611, 3612, 3613, 3614), 23 (3620, 3621, 3622, 3623, 3624), (3630, 3631, 3632, 3633, 3634), (3700, 3701, 3702, 24 3703, 370~), (3710, 3711, 3712, 3713, 3714), (3720, 3721, 3722, 3723, 3724), ~3730, 25 3731, 3732, 3733, 3734), (3800, 3801, 3802, 3803, 3804), (3810, 3811, 3812, 3813, 2t; 3814), (3820, 3821, 3822, 3823, 3824), (3830, 3831, 3832, 3833, 3834), and (3930, 3931, 27 3932, 3933, 3934) respectively. We will refer to any one of these commands by the number 28 of their first step Z9 In the 'start session 1' command 3400 the terminal sends a bitmask which indicates 30 which keys will be used in the session, and the terminal challenge. This corresponds to step 31 2501 in figure ''5. The card sends the card challenge back, corresponding to step 2503. In 32 the 'start session 2' command 3 l lO the terminal sends the card the proof that it knows the 33 keys, corresponding to step 2505. The card responds with onlv a response code. In the 'get W O 96~2581~ PCTnUS9~D~765 ~ 7_ frame' command 3420 the terminal sends the tag field of the frame to be read to the card, 2 and the card replies with the (encrypted) card data, plus an authentication (proof) of this 3 data. In the 'put frame' command 3~30 the terminal sends the tag, the access field value, the data and an al~thentic~tion proof to the card. The card sends a response code. In the s 'kill frame' command 3500 the terminal sends the tag of the frame to be removed, and an 6 ~llthentication proofto the card. The card responds with a response code. In the 'debit 7 frame' command 3510 the terminal sends an identifier of the balance to be debited, and an a amount to be debited. The card subtracts the given amount from the balance indicated and 9 sends a response code. In the 'redebit frame' command 3520 the terminal sends an ~0 identifier of the balance to be redebited, the amount of the redebit, and the redebit key. The .. card replies with a response code. In the 'public debit' command 3530, the terminal sends 12 the balance indicator, the amount of the payment, and the random challenge to the card.
13 The card replies with a response code. In the 'commit' command 3600 the terminal sends 14 the session proof to the card. the card replies with a response code. In the 'done' command ~s 3610 no additional data is exchanged. In the 'get proof command 3620 the terminal sends .~ oniy the command header to the card. The card replies with the session proof, and 17 optionally the public proof. In the 'select file' command 3630 the terminal sends an AID or 18 RID to the card which replies with an FCI. In the 'manage application 1' command 3700, ~~ the terminal sends an 'init' code to the card which replies with a response code. In the 20 'manage application 2' command 3710 the terminal sends an 'exit' code to the card, which 21 replies with a response code. In the 'get data' command 3720 the terminal sends a data 22 object tag to the card, which replies with the data object. In the 'get file' command 3730 a the terrninal sends the file number and the record number to the card, which replies with the 24 requested record. In the 'generate AC 1' command 3800 the terminal sends the requested 25 AC type and the TDOL values to the card, which replies with an AC type, the AC and the 26 ATC. In the 'generate AC 2' command 3810 the terminal sends the requested AC type and 27 the card replies with the AC type, the AC and the ATC. In the 'external authenticate' 28 command 3820 the terminal sends the authentication proof to the card, and the card replies 2~ with a response code. In the 'verify' command 3830 the terminal sends the CVM method 30 and the CVM data to the card which replies with a response code. In the 'get last AC' 31 command 3930 the terminal sends only the command code to the card, which replies with 32 the AC type, the AC and the ATC.
W O96/25814 PCTrUS9S/01765 CLEA~niG l~IETHO DS
Once the transaction between the card and the terminal has been completed, there can 2 be a clearing process in which the information from different transactions are collected and 3 combined. The example of clearing we will use to describe the processes is the clearing of 4 financial payments. The card is used to perform payments to the terminal. One example of a s clearing system is for the terminal to send all the transaction data regarding the payments to 6 the acquirer/issuer which adds the amounts and credits the terminal's account with the total sum. The role ofthe acquirer lW is to collect information from several terminals, and B reimburse the terrninals in 'real' money for the payments they received. As the issuer hands o out the money and the acquirer receives it, there must be some kind of settlement between ~o the issuer and the acquirer. Typically the issuer and acquirer will be parts of the same ~- or~ni7~tion, or organizations that work closely together. We will describe several different 12 clearing methods that can be used under different circumstances.
13 Full data. One of the simplest clearing methods is for the terminal to retain all the 14 relevant data from the payment transaction with the card. During clearing the terminal ~s sends all data to the acquirer which verifies every transaction certificate and then credits the 16 terminal. This gives the acquirer access to all transaction details, at the cost of h~ndlin~
17 every transaction in full.
18 Truncating SAM. The terminal can also be equipped with a secure application 19 module (SAM). This is a tamper-resistant device made by the acquirer. The function of the 20 SAM is to verify the transaction data and add the value of all the received payments. The 21 transaction data is then discarded. This process is usually called truncation. During the 22 clearing process, the SAM informs the acquirer of the total amount received, and 23 cryptographically signs a message to this effect for the acquirer.
24 Truncating SAM with some individual payments. The terminal is again equipped 25 with a SA~I. As in the truncating SAM option, the SAM verifies the transaction data and 25 keeps the totals. However, not all transaction data is discarded, but some or all of the 27 transaction data for some of the transactions is kept. During the clearing process this data 21~ iS also sent to the acquirer. The selection process that chooses for which transactions 29 transaction data is retained can be performed in various ways, by the terminal, by the SAM, 30 or by a combination of the two.
31 Truncating SAM with skeleton transactions. A SAM in the terrninal is used to 32 verify all transactions. For each transaction, only skeleton transaction information is WO96/2581~ PC~rUS95J01765 ~ retained by the terminal. This would typically include the amount, date, time, card identity 2 (if available) etc. The skeleton data is sent to the acquirer during the clearing process. The 3 SA M ensures that the skeleton data sent to the acquirer is correct (by signing it using a 4 digital signature scheme), and mi~,ht optionally keep totals of the transactions and transfer s them separately to the acquirer.
Skeleton transactions with statistic~l checking. In this solution the terminal retains 7 all transaction data for all transactions. During the clearing process the terminal first sends 8 skeleton information for every transaction. This would typically include the amount and D some information which uniquely fixes the rest of the transaction data, such as a .o cryptographic hash on the rest of the transaction data. The acquirer then asks for the full tl transaction data for some of the transactions, which the terrninal sends to the acquirer. The 12 acquirer then verifies these transactions.
13 Binary h~sh tree with St~tiStiC:ll checking. This method is similar to the previous 14 one in that the terminal retains all transaction data Instead of sending skeleton information ~s about all the transactions, the terminal now sends only a fixed amount of data to the 1~ acquirer after which the acquirer can choose a subset of the transactions to inspect for 17 proper h~nclling The terminal builds a binary tree, where each node contains two values:
lB the amount and the hash. There is one leaf for every transaction, which contains the amount 1~ of the transaction, and the hash of the transaction data. The amount at each non-leaf node 20 iS the sum of the amounts in the subnodes. The hash value at each non-leaf node is a 21 cryptographic hash of all the data in the subnodes. The terminal sends the number of 22 transactions (which also determines the structure of the tree), plus the amount and hash 23 value of the root of the tree to the acquirer. The acquirer then selects a subset of the 24 transactions, and sends the selection to the terminal. The terminal responds by slontlin~ the 25 transaction data of the selected transactions, plus the amount and hash values at some of 25 the nodes. The choice of which nodes to send depends on the selection by the acquirer. The 27 nodes selected are those that are the root of a maximal subtree that does not contain a leaf 2~ of a selected transaction. In other words, those nodes whose hash does not depend on any 29 selected transaction, but whose parent node does depend on a selected transaction. Given 3~ these values the acquirer can verify the selected transactions, and verify those parts of the 31 binary tree that are on a path from the root to any one of the selected transactions.
32 In some of the clearing systems the issuer can keep track of all transactions that have 33 occurred. Although cards are tamper-resistant they are not tamper-proof. One attack is to _ W O96/25814 PCTrUS95/01765 'brea'~;' a card, extract all secret information from it and create many duplicate cards, this 2 attack is also called cloning. If each transaction has a unique number which the cards use in 3 sequence, then the issuer can detect the cloning as the cloned cards will either reuse old ~ transaction numbers, or they will use the numbers out of order. As long as the transaction s numbers are all sent to the issuer, this allows detection of this fraud. Once the fraud has been detected, the issuer can blacklist the cloned card.
7 If the card uses a general digital signature scheme, or a secret key based 3 authentication system, it is easy to include a transaction counter in the data being 9 authenticated. Most systems currently built and/or proposed actually have such transaction ~o counters. The compact endorsement signatures disclosed above do not have an inherent numbering, but this can be added. The houses in a town have already a number, and are t2 always used in the same order. The issuer can add a sequence number to each town it gives 13 to the card, and include this sequence number in the town signature. (This way, the town 14 signature is a signature on the sequence number and the town result value.) ~s The full data clearing system does not require a SAM but might lead to a large 15 amount of data being tr~ncmitted from the terminal to the acquirer. This can be costly 17 depending on the communication system used.
18 The SAM-based systems all need a SAM, which by itself can be an expensive piece of 19 equipment. In an environment with multiple issuers, either all issuers have to trust the same 20 SAM or each terminal needs a SAM for every issuer.
21 The last two clearing systems do not require a SAM, but let the terminal do most of 22 the truncation. If a terminal tries to defraud the acquirer/issuer then the terminal will be 23 caught with a certain probability by the statistical checking. Depending on the amount of 24 checking and the selection methods used by the acquirer the expected amount of successful 25 fraud by a terminal before being caught by the acquirer can be fixed. For example, but 2~ without limitation, if the terminal sends skeleton data for each transaction to the acquirer, 27 the acquirer can use the following algorithm to select transactions for fi~ll review. If the 28 amount of the transaction $100 or more then the transaction is selected. If the amount of 29 the transaction x is less then $100, then the transaction is selected with probability x%.
30 Thus, a transaction of $5 would be selected with a ~% probability. It is believed that using 31 this selection method the acquirer is ensured that the expected amount of succ~s.cfill fraud 32 by a terminal before being detected by the acquirer is $100.
WO 96/25814 PCTIUS95~0176 ~ As would be obvious to those of ordinary skill in the art, there are many çssenti~lly z equivalent ways to realize the inventive concepts disclosed. The particular choices that 3 have been made here are merely for clarity in exposition and are sometimes arbitrary. For 4 in~t~nce, without attempting to be exhaustive, there are many one-time signature structures, compression structures, hierarchical structurings, possible parameter values, and a so on.
7 It will also be obvious to those of ordinary skill in the art how parts of the inventive 8 concepts and protocols herein disclosed can be used to advantage without nec~s~ g the 9 complete preferred embodiment. This may be more fully appreciated in light of some ~o examples, where in some uses of the inventive concepts, multiple parties may be combined, ~- simple authorizations instead of actual messages may be used, implementations may involve 12 various hardware forms and memory types, and so forth.
13 Certain variations and substitutions may be apparent to those of ordinary skill in the 14 art. For example: most practical self-authenticating digital signature techniques could be .s applied instead of the RSA systems used as an example; compression functions may take 6 more than two inputs; hierarchies of compression functions may take any other treelike 7 form; and register re-use patterns that more evenly distribute certain types of access may be 1a ~lef~"ed for certain technologies.
19 While these descriptions of the present invention have been given as examples, it will be 20 appreciated by those of ordinary skill in the art that various modifications, alternate 21 configurations and equivalents may be employed without departing from the spirit and 22 scope of the present invention.
,
Claims (72)
1. A method for public-key digital authentication of messages, comprising the steps of:
creating a private key by a signing party;
making a public key, corresponding to said private key of said signing party, verifiable by at least a receiving party;
creating a set of one-time signatures;
forming a compression hierarchy of said one-time signatures;
forming a public key digital signature, verifiable with said public key, on saidcompression hierarchy;
storing edges of said compression hierarchy by an endorser;
endorsing by signing with at least one of said one-time signatures and providingstored edge values;
verification of said one-time signature and said edge values supplied and said digital signature on said compression values; and accomplishing the foregoing by said endorser storing substantially less than all edges and computing before each endorsement substantially less than all edges.
creating a private key by a signing party;
making a public key, corresponding to said private key of said signing party, verifiable by at least a receiving party;
creating a set of one-time signatures;
forming a compression hierarchy of said one-time signatures;
forming a public key digital signature, verifiable with said public key, on saidcompression hierarchy;
storing edges of said compression hierarchy by an endorser;
endorsing by signing with at least one of said one-time signatures and providingstored edge values;
verification of said one-time signature and said edge values supplied and said digital signature on said compression values; and accomplishing the foregoing by said endorser storing substantially less than all edges and computing before each endorsement substantially less than all edges.
2. In the method of claim 1, using a cascade structuring of compression functions.
3. In the method of claim 1, preparing for future endorsements so that they will require substantially less computation.
4. In the method of claim 1, said one-time signature being constructed using different oneway functions in a chain of oneway functions.
5. In the method of claim 3, said preparations being done at least in part by a party different from the endorser.
6. Apparatus for public-key digital authentication of messages, comprising:
means for creating a private key by a signing party;
means for making a public key, corresponding to said private key of said signingparty, verifiable by at least a receiving party;
means for creating a set of one-time signatures;
means for forming a compression hierarchy of said one-time signatures;
means for forming a public key digital signatures, verifiable with said public key, on said compression hierarchy;
means for storing edges of said compression hierarchy by an endorser;
means for endorsing, comprising means for signing with one of said one-time signatures and means for providing stored edge values;
means for verification of a one-time signature and compression hierarchy values supplied and for verification of said digital signature on said compression value;
and means for accomplishing the forgoing by said endorser storing substantially less than all edges and computing before each endorsement substantially less than all edges.
means for creating a private key by a signing party;
means for making a public key, corresponding to said private key of said signingparty, verifiable by at least a receiving party;
means for creating a set of one-time signatures;
means for forming a compression hierarchy of said one-time signatures;
means for forming a public key digital signatures, verifiable with said public key, on said compression hierarchy;
means for storing edges of said compression hierarchy by an endorser;
means for endorsing, comprising means for signing with one of said one-time signatures and means for providing stored edge values;
means for verification of a one-time signature and compression hierarchy values supplied and for verification of said digital signature on said compression value;
and means for accomplishing the forgoing by said endorser storing substantially less than all edges and computing before each endorsement substantially less than all edges.
7. In the apparatus of claim 6, means for forming a cascade structuring of compression functions.
8. In the apparatus of claim 6, means for preparing future endorsements so that they will require substantially less computation.
9. A method for financial transactions, comprising the steps of:
maintaining a challenge seed by a terminal for use with respect to at least one subsequent transaction;
issuing a challenge seed modifier by an on-line server to said terminal;
modifying said challenge seed by said terminal at least responsive to said modifier;
developing a challenge value for use in a subsequent transaction, where said challenge value depends oat least substantially on said challenge seed; and accomplishing the forgoing so as to make said challenge unpredictable even to someone privy to the secrets of said terminal.
maintaining a challenge seed by a terminal for use with respect to at least one subsequent transaction;
issuing a challenge seed modifier by an on-line server to said terminal;
modifying said challenge seed by said terminal at least responsive to said modifier;
developing a challenge value for use in a subsequent transaction, where said challenge value depends oat least substantially on said challenge seed; and accomplishing the forgoing so as to make said challenge unpredictable even to someone privy to the secrets of said terminal.
10. Apparatus for financial transactions, comprising:
means for maintaining a challenge seed by a terminal for use with respect to at least one subsequent transaction;
means for issuing a challenge seed modifier by an on-line server to said terminal;
means for modifying said challenge seed by said terminal at least responsive to said modifier;
means for developing a challenge value for use in a subsequent transaction, where said challenge value depends oat least substantially on said challenge seed; and means for accomplishing the forgoing so as to make said challenge unpredictable even to someone privy to the secrets of said terminal.
means for maintaining a challenge seed by a terminal for use with respect to at least one subsequent transaction;
means for issuing a challenge seed modifier by an on-line server to said terminal;
means for modifying said challenge seed by said terminal at least responsive to said modifier;
means for developing a challenge value for use in a subsequent transaction, where said challenge value depends oat least substantially on said challenge seed; and means for accomplishing the forgoing so as to make said challenge unpredictable even to someone privy to the secrets of said terminal.
11. A method for public key digital authentication of a message, comprising the steps of:
creating a private key for a signing party;
making a public key, corresponding to said private key, verifiable by at least areceiving party;
generating the commit value of a commit-challenge-response protocol by said signing party;
sending said commit value to said receiving party;
forming a mutually random value by said signing party and said receiving party;
choosing the challenge value of said commit-challenge-response protocol as the hash value of the concatenation of the message to be authenticated and said mutually random value;
generating the response value of said commit-challenge-response protocol by saidsigning party;
sending said response value to said receiving party; and verifying said response value by said receiving party.
creating a private key for a signing party;
making a public key, corresponding to said private key, verifiable by at least areceiving party;
generating the commit value of a commit-challenge-response protocol by said signing party;
sending said commit value to said receiving party;
forming a mutually random value by said signing party and said receiving party;
choosing the challenge value of said commit-challenge-response protocol as the hash value of the concatenation of the message to be authenticated and said mutually random value;
generating the response value of said commit-challenge-response protocol by saidsigning party;
sending said response value to said receiving party; and verifying said response value by said receiving party.
12. In the method of claim 11, said commit-challenge-response protocol consisting of a compact endorsement signature protocol.
13. Apparatus for public key digital authentication of a message, comprising:
means for creating a private key for a signing party;
means for making a public key, corresponding to said private key, verifiable by at least a receiving party;
means for generating the commit value of a commit-challenge-response protocol bysaid signing party;
means for sending said commit value to said receiving party;
means for forming a mutually random value by said signing party and said receiving party;
means for choosing the challenge value of said commit-challenge-response protocol as the hash value of the concatenation of the message to be authenticated and said mutually random value;
means for generating the response value of said commit-challenge-response protocol by said signing party;
means for sending said response value to said receiving party; and means for verifying said response value by said receiving party.
means for creating a private key for a signing party;
means for making a public key, corresponding to said private key, verifiable by at least a receiving party;
means for generating the commit value of a commit-challenge-response protocol bysaid signing party;
means for sending said commit value to said receiving party;
means for forming a mutually random value by said signing party and said receiving party;
means for choosing the challenge value of said commit-challenge-response protocol as the hash value of the concatenation of the message to be authenticated and said mutually random value;
means for generating the response value of said commit-challenge-response protocol by said signing party;
means for sending said response value to said receiving party; and means for verifying said response value by said receiving party.
14. A method for storing data in non-volatile memory, comprising the steps of:
initializing a commit value to a logical zero;
storing one or more descriptions of modifications to be made;
setting said commit value to a logical one;
performing the modifications specified by said descriptions setting said commit value to a logical zero; and detecting interruptions in the above mentioned steps, and upon detection performing the steps of:
a) inspecting said commit value;
b) performing said modifications if said commit value is a logical one;
c) setting said commit value to a logical zero
initializing a commit value to a logical zero;
storing one or more descriptions of modifications to be made;
setting said commit value to a logical one;
performing the modifications specified by said descriptions setting said commit value to a logical zero; and detecting interruptions in the above mentioned steps, and upon detection performing the steps of:
a) inspecting said commit value;
b) performing said modifications if said commit value is a logical one;
c) setting said commit value to a logical zero
15. In the method of claim 14, with means for setting said commit value to a logical one value after an interruption and before said modifications are made.
16. In the method of claim 14, with improvements comprising the steps of:
initializing an in-use value to a logical zero;
setting said in-use value to a logical one before said commit value is set to a logical one;
setting said in-use value to a logical zero after said commit value is set to a logical zero; and setting said commit value to a logical zero and then setting said in-use value to a logical zero if the in-use value is found to contain a logical one while the commit value is found to contain a logical zero after an interruption.
initializing an in-use value to a logical zero;
setting said in-use value to a logical one before said commit value is set to a logical one;
setting said in-use value to a logical zero after said commit value is set to a logical zero; and setting said commit value to a logical zero and then setting said in-use value to a logical zero if the in-use value is found to contain a logical one while the commit value is found to contain a logical zero after an interruption.
17. In the method of claim 14 or 16, with different commit values used for different modifications.
18. In the method of claim 14 or 16, each of said modifications consisting of a standard action on one of a given set of memory locations.
19. In the method of claim 18, said standard action consisting of setting the location to fixed value.
20. In the method of claim 18, said retention means for modification descriptions consisting of a single bit for each of the possible locations for the modification.
21. In the method of claim 14 or 16, with improvements comprising the steps of:
storing one or more reversion descriptions to be made; and performing the reversions specified by said reversion descriptions if the commit value is found to contain a logical zero after an interruption.
storing one or more reversion descriptions to be made; and performing the reversions specified by said reversion descriptions if the commit value is found to contain a logical zero after an interruption.
22. In the method of claim 21, each of said reversions consisting of a standard action on one of a given set of memory locations.
23. In the method of claim 22, said standard action consisting of setting the location to fixed value.
24. In the method of claim 22, said retention means for reversion descriptions consisting of a single bit for each of the possible locations for the reversion.
25. Apparatus for storing data in non-volatile memory, comprising:
retention means for a single bit commit value;
retention means for one or more modification descriptions to be made;
initiation means to ensure that said commit value is a logical zero during a prefix of the card life;
means for storing one or more modification descriptions to be made in said second retention means;
means for setting said commit value to a logical one;
means for performing the modifications specified by said descriptions;
means for setting said commit value to a logical zero; and means for detecting an interruption of normal processing and triggering:
a) means for inspecting said commit value;
b) means for performing said modifications if said commit value is a logical one;
and c) means for setting said commit value to a logical zero.
retention means for a single bit commit value;
retention means for one or more modification descriptions to be made;
initiation means to ensure that said commit value is a logical zero during a prefix of the card life;
means for storing one or more modification descriptions to be made in said second retention means;
means for setting said commit value to a logical one;
means for performing the modifications specified by said descriptions;
means for setting said commit value to a logical zero; and means for detecting an interruption of normal processing and triggering:
a) means for inspecting said commit value;
b) means for performing said modifications if said commit value is a logical one;
and c) means for setting said commit value to a logical zero.
26. A method for handling memory errors in a computing device with non-volatile memory, comprising the steps of:
initializing a mode value to indicate a first mode;
detecting the occurrence of an errornous state of said memory;
setting said mode value to indicate a second mode upon detection of said errornous state;
inspecting said mode value in at least one of the processes executed by said computing device; and modifying the behaviour of said process depending on the value of said mode value.
initializing a mode value to indicate a first mode;
detecting the occurrence of an errornous state of said memory;
setting said mode value to indicate a second mode upon detection of said errornous state;
inspecting said mode value in at least one of the processes executed by said computing device; and modifying the behaviour of said process depending on the value of said mode value.
27. In the method of claim 26, said modifying of the behaviour of said process including restriction of normal execution of said process to the first state.
28. In the method of claim 26, said modifying of the behaviour of said process including including enabling a process in the second mode that allows recovery of application data.
29. In the method of claim 28, said process restricting access to data that is non-secret.
30. In the method of claim 29, the secretness of the data being determined by a coding which increases the secretness level if individual bits in said memory are changed from a logical "one" state to a logical "zero" state.
31. In the method of claim 26, said detection of erroneous states using a coding of data to detect memory errors with substantially high probability.
32. Apparaturs for handling memory errors in a computing device with non-volatile memory, comprising of:
means for initializing a mode value to indicate a first mode;
means for detecting the occurrence of an errornous state of said memory;
means for setting said mode value to indicate a second mode upon detection of said errornous state;
means for inspecting said mode value in at least one of the processes executed by said computing device; and means for modifying the behaviour of said process depending on the value of saidmode value.
means for initializing a mode value to indicate a first mode;
means for detecting the occurrence of an errornous state of said memory;
means for setting said mode value to indicate a second mode upon detection of said errornous state;
means for inspecting said mode value in at least one of the processes executed by said computing device; and means for modifying the behaviour of said process depending on the value of saidmode value.
33. A method for communicating and linking a plurality of indepent actions between a terminal and a card, with improvements comprising the steps of:
initializing a first hash state in said card to a known value before the start of the communication;
initializing a second hash state in said terminal to a known value before the start of the communication;
updating said first hash state using a function which takes said first hash state and substantially the data associated with an independent action as input and yieldsthe new value for said first hash state as output;
updating said second hash state using a function which takes said second hash state and substantially the data associated with an independent action as input and yields the new value for said second hash state as output; and making at least some of the data communicated between said terminal and said card dependent on said hash states.
initializing a first hash state in said card to a known value before the start of the communication;
initializing a second hash state in said terminal to a known value before the start of the communication;
updating said first hash state using a function which takes said first hash state and substantially the data associated with an independent action as input and yieldsthe new value for said first hash state as output;
updating said second hash state using a function which takes said second hash state and substantially the data associated with an independent action as input and yields the new value for said second hash state as output; and making at least some of the data communicated between said terminal and said card dependent on said hash states.
34. In the method of claim 33, an initial independent action updating said hash states using at least one secret key.
35. In the method of claim 34, an initial independent action including a proof by said terminal of possesion of said key.
36. In the method of claim 33, 34 or 35, said independent actions including cryptographic confidentiality coding of data communicated between said card and said terminal based on said hash states.
37. In the method of claim 36, said confidentiality coding using the same coding function in said card for both directions of data communication.
38. In the method of claim 36, said confidentiality coding using the same coding function in said terminal for both directions of data communication.
39. In the method of claim 33, 34 or 35, said independent actions only making tentative changes to the state of said card until a final independent action which makes the tentative changes permanent.
40. In the method of claim 39, discarding said tentative changes upon detection of an interruption.
41. In the method of claim 39, said final action including a first cryptographicauthentication by said terminal to said card on said second hash state to start the process of making said tentative changes permanent.
42. In the method of claim 39, said final independent action including a second cryptographic authentication by said card to said terminal on said first hash state to show that said tentative changes have become permanent.
43. In the method of claim 42, a resend process being executed on request of the terminal after said final independent action in which said card resends said second cryptographic authentication to said terminal.
44. In the method of claim 43, with improvements comprising the steps of:
initializing a done value in said card to a logical zero state during said finalindependent action;
inspecting said done value during said resend process;
resending said second cryptographic authentication only if said done value is a logical zero;
sending a request by said terminal to said card to set said done value to a logical one;
and setting said done value to a logical one upon reception of said request.
initializing a done value in said card to a logical zero state during said finalindependent action;
inspecting said done value during said resend process;
resending said second cryptographic authentication only if said done value is a logical zero;
sending a request by said terminal to said card to set said done value to a logical one;
and setting said done value to a logical one upon reception of said request.
45. In the method of claim 41, said last independent action including provisions for said card to wait for a signal of said terminal after having verified said first cryptographic authentication but just before said tentative changes become permanent.
46. In the method of claim 41, the data for said independent actions having been generated by an issuer and sent to said terminal, and where said terminal executes said actions with said card based on the data supplied by said issuer.
47. Apparatus for communicating and linking a plurality of indepent actions between a terminal and a card, with improvements comprising of:
retention means for a first hash state in said card;
retention means for a second hash state in said terminal;
means for initializing said first hash state in said card to a known value before the start of the communication;
means for initializing said second hash state in said terminal to a known value before the start of the communication;
means for updating said first hash state using a function which takes said first hash state and substantially the data associated with an independent action as input and yields the new value for said first hash state as output;
means for updating said second hash state using a function which takes said second hash state and substantially the data associated with an independent action as input and yields the new value for said second hash state as output; and means for making at least some of the data communicated between said terminal and said card dependent on said hash states.
retention means for a first hash state in said card;
retention means for a second hash state in said terminal;
means for initializing said first hash state in said card to a known value before the start of the communication;
means for initializing said second hash state in said terminal to a known value before the start of the communication;
means for updating said first hash state using a function which takes said first hash state and substantially the data associated with an independent action as input and yields the new value for said first hash state as output;
means for updating said second hash state using a function which takes said second hash state and substantially the data associated with an independent action as input and yields the new value for said second hash state as output; and means for making at least some of the data communicated between said terminal and said card dependent on said hash states.
48. A method for performing computations by a card which is communicating with aterminal comprising the steps of:
sending a first message by said terminal;
receiving said first message by said card;
performing computations by said card on the data received in said first message and data stored in the memory of said card;
sending a second message by said card;
receiving said second message by said terminal; and inducing a delay between said first message and said second message, where the duration of said delay is determined solely by public information consisting of the contents of the messages received by said card before said delay, the contents of the messages sent by said card before said delay, and by data that said card would send to said terminal in subsequent communications given appropriate requests by said terminal.
sending a first message by said terminal;
receiving said first message by said card;
performing computations by said card on the data received in said first message and data stored in the memory of said card;
sending a second message by said card;
receiving said second message by said terminal; and inducing a delay between said first message and said second message, where the duration of said delay is determined solely by public information consisting of the contents of the messages received by said card before said delay, the contents of the messages sent by said card before said delay, and by data that said card would send to said terminal in subsequent communications given appropriate requests by said terminal.
49. In the method of claim 48, said delay being made constant by adding sufficient delays in each of the possible execution paths of said computations.
50. In the method of claim 48, said computations being implemented by a sequence of actions each of which induces a known fixed delay where said sequence is solely determined by said public information.
51. In the method of claim 50, said sequence of actions consisting of actions that are functionally equivalent to a set of actions that contains one or more actions that are executed conditionally.
52. In the method of claim 50, said sequence of instructions implementing a conditional storage operation by executing a storage operation using an address whose value is computed as a function of the condition of said conditional storage operation.
53. Apparatus for performing computations by a card which is communicating with a terminal comprising of:
means for sending a first message by said terminal;
means for receiving said first message by said card;
means for performing computations by said card on the data received in said first message and data stored in the memory of said card;
means for sending a second message by said card;
means for receiving said second message by said terminal; and means for inducing a delay between said first message and said second message.
where the duration of said delay is determined solely by public information consisting of the contents of the messages received by said card before said delay, the contents of the messages sent by said card before said delay, and by data that said card would send to said terminal in subsequent communications given appropriate requests by said terminal.
means for sending a first message by said terminal;
means for receiving said first message by said card;
means for performing computations by said card on the data received in said first message and data stored in the memory of said card;
means for sending a second message by said card;
means for receiving said second message by said terminal; and means for inducing a delay between said first message and said second message.
where the duration of said delay is determined solely by public information consisting of the contents of the messages received by said card before said delay, the contents of the messages sent by said card before said delay, and by data that said card would send to said terminal in subsequent communications given appropriate requests by said terminal.
54. A method for converting a set of instructions, comprising the steps of:
inspecting said set of instructions;
determining the conditions used in said set;
adding instructions to said set which convert said conditions to values; and rewriting expressions contained in said set to an equivalent formulation using said values instead of conditional execution of instructions.
inspecting said set of instructions;
determining the conditions used in said set;
adding instructions to said set which convert said conditions to values; and rewriting expressions contained in said set to an equivalent formulation using said values instead of conditional execution of instructions.
52. Apparatus for converting a set of instructions, comprising of:
retention means for storing a set of instructions;
means for inspecting said set of instructions;
means for determining the conditions used in said set; and means for adding instructions to said set which convert said conditions to values;
means for rewriting expressions contained in said set to an equivalent formulation using said values instead of conditional execution of instructions.
retention means for storing a set of instructions;
means for inspecting said set of instructions;
means for determining the conditions used in said set; and means for adding instructions to said set which convert said conditions to values;
means for rewriting expressions contained in said set to an equivalent formulation using said values instead of conditional execution of instructions.
56. A method for collecting transaction information related to one or more transactions from a terminal by an acquirer, comprising the steps of:
computing by said terminal a first value from said transaction information, whose size is substantially smaller than the size of said transaction information;
sending by said terminal to said acquirer a first message including an indication of the number of transactions. the applicable totals of the transactions, and said first value;
receiving said first message by said acquirer;
storing substantially the data from said first message by said acquirer for future computations;
making a random selection from the set of transaction; and sending said random selection in a second message to said terminal;
receiving said second message by said terminal.
sending by said terminal to said acquirer in a third message substantially the transaction information for the transactions in said selection.
computing by said terminal a first value from said transaction information, whose size is substantially smaller than the size of said transaction information;
sending by said terminal to said acquirer a first message including an indication of the number of transactions. the applicable totals of the transactions, and said first value;
receiving said first message by said acquirer;
storing substantially the data from said first message by said acquirer for future computations;
making a random selection from the set of transaction; and sending said random selection in a second message to said terminal;
receiving said second message by said terminal.
sending by said terminal to said acquirer in a third message substantially the transaction information for the transactions in said selection.
57. In the method of claim 56, said first message including skeleton transaction information about all transactions.
58. In the method of claim 56, said first message including a cryptographic hash value on substantially the full the transaction data of all transactions, and said third message including data that allows said hash value to be verified by said acquirer.
59. In the method of claim 58, said cryptographic hash value being computed using a tree structure.
60. Apparatus for collecting transaction information related to one or more transactions from a terminal by an acquirer, comprising:
means for computing by said terminal a first value from said transaction information, whose size is substantially smaller than the size of said transaction information;
means for sending by said terminal to said acquirer a first message including anindication of the number of transactions, the applicable totals of the transactions, and said first value;
means for receiving said first message by said acquirer;
retention means for storing substantially the data from said first message by said acquirer for future computations;
means for making a random selection from the set of transaction;
means for sending said random selection in a second message to said terminal;
means for receiving said second message by said terminal; and means for sending by said terminal to said acquirer in a third message substantially the transaction information for the transactions in said selection.
means for computing by said terminal a first value from said transaction information, whose size is substantially smaller than the size of said transaction information;
means for sending by said terminal to said acquirer a first message including anindication of the number of transactions, the applicable totals of the transactions, and said first value;
means for receiving said first message by said acquirer;
retention means for storing substantially the data from said first message by said acquirer for future computations;
means for making a random selection from the set of transaction;
means for sending said random selection in a second message to said terminal;
means for receiving said second message by said terminal; and means for sending by said terminal to said acquirer in a third message substantially the transaction information for the transactions in said selection.
61. A method for conducting finanancial transactions using a card, a terminal, and an issuer substantially according to the EMV specifications. with improvements comprising the steps of:
generating variable transaction data which is typically different for different transactions;
constructing a message block whose value depends on at least some of said variable transaction data;
generating by said card of an authentication based on public key cryptography on said message block;
sending said authentication in a message to said terminal;
receiving said message by said terminal; and verifying said authentication by said terminal.
generating variable transaction data which is typically different for different transactions;
constructing a message block whose value depends on at least some of said variable transaction data;
generating by said card of an authentication based on public key cryptography on said message block;
sending said authentication in a message to said terminal;
receiving said message by said terminal; and verifying said authentication by said terminal.
62. In the method of claim 61, said message block including the transaction certificate TC.
63. Apparatus for conducting finanancial transactions comprising a card, a terminal, and an issuer substantially according to the EMV specifications, with improvements characterized by:
means for generating variable transactoin data which is typically different for different transactions;
means for constructing a message block whose value depends on at least some of said variable transaction data;
means for generating by said card of an authentication based on public key cryptography on said message block;
means for sending said authentication in a message to said terminal;
means for receiving said message by said terminal; and means for verifying said authentication by said terminal.
means for generating variable transactoin data which is typically different for different transactions;
means for constructing a message block whose value depends on at least some of said variable transaction data;
means for generating by said card of an authentication based on public key cryptography on said message block;
means for sending said authentication in a message to said terminal;
means for receiving said message by said terminal; and means for verifying said authentication by said terminal.
64. A method for conducting finanancial transactions using a card, a terminal, and an issuer substantially according to the EMV specifications, with improvements comprising the steps of:
maintaining a balance value in said card for all financial transaction applications;
decreasing said balance value by the amount of each transaction; and refusing an off-line transaction if the amount of said transaction exceeds said balance value.
maintaining a balance value in said card for all financial transaction applications;
decreasing said balance value by the amount of each transaction; and refusing an off-line transaction if the amount of said transaction exceeds said balance value.
65. In the method of claim 64, said issuer using the script feature of the EMV to modify said balance value stored on said card.
66. In the method of claim 65, with improvements comprising the steps of:
storing information by said issuer related to said card;
storing information by said issuer related to on-line transactions performed by said card;
detecting by said issuer of failures to execute a first script issued by said issuer during an on-line transaction;
creating a second script including substantially the actions of said first script.
sending said second script to said terminal; and executing said script by said terminal with said card
storing information by said issuer related to said card;
storing information by said issuer related to on-line transactions performed by said card;
detecting by said issuer of failures to execute a first script issued by said issuer during an on-line transaction;
creating a second script including substantially the actions of said first script.
sending said second script to said terminal; and executing said script by said terminal with said card
67. In the method of claim 66, with improvements comprising the steps of:
detecting by said issuer after a period of time off-line transactions performed by said card but not presented to said issuer for clearing;
estimating the total amount of said off-line transactions; and adding substantially said total amount to said balance value using a script.
detecting by said issuer after a period of time off-line transactions performed by said card but not presented to said issuer for clearing;
estimating the total amount of said off-line transactions; and adding substantially said total amount to said balance value using a script.
68. Apparatus for conducting finanancial transactions comprising a card, a terminal, and an issuer substantially according to the EMV specifications, with improvements characterized by:
retention means for a balance value in said card;
means for decreasing said balance value by the amount of each transaction; and menas for refusing an off-line transaction if the amount of said transaction exceeds said balance value.
retention means for a balance value in said card;
means for decreasing said balance value by the amount of each transaction; and menas for refusing an off-line transaction if the amount of said transaction exceeds said balance value.
69. A method for conducting finanancial transactions using a card, a terminal, and an issuer substantially according to the EMV specifications, with improvements comprising the step of:
incrementing the transaction counter ATC only for those transactions which are completed successfully.
incrementing the transaction counter ATC only for those transactions which are completed successfully.
70. Apparatus for conducting finanancial transactions comprising a card, a terminal, and an issuer substantially according to the EMV specifications, with improvements characterized by:
means for incrementing the transaction counter ATC only for those transactions which are completed successfully.
means for incrementing the transaction counter ATC only for those transactions which are completed successfully.
71. A method for conducting finanancial transactions using a card, a terminal, and an issuer substantially according to the EMV specifications, with improvements comprising the steps of:
making a decision by said card whether to allow an off-line transaction or require an on-line transaction in a fixed amount of time; and storing said decision in a fixed amount of time.
making a decision by said card whether to allow an off-line transaction or require an on-line transaction in a fixed amount of time; and storing said decision in a fixed amount of time.
72. Apparatus for conducting finanancial transactions comprising a card, a terminal, and an issuer substantially according to the EMV specifications, with improvements characterized by:
means for making a decision by said card whether to allow an off-line transaction or require an on-line transaction in a fixed amount of time; and means for storing said decision in a fixed amount of time.
means for making a decision by said card whether to allow an off-line transaction or require an on-line transaction in a fixed amount of time; and means for storing said decision in a fixed amount of time.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA002218178A CA2218178A1 (en) | 1995-02-13 | 1995-02-13 | Multi-purpose transaction card system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA002218178A CA2218178A1 (en) | 1995-02-13 | 1995-02-13 | Multi-purpose transaction card system |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2218178A1 true CA2218178A1 (en) | 1996-08-22 |
Family
ID=4161622
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002218178A Abandoned CA2218178A1 (en) | 1995-02-13 | 1995-02-13 | Multi-purpose transaction card system |
Country Status (1)
Country | Link |
---|---|
CA (1) | CA2218178A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000057370A1 (en) * | 1999-03-19 | 2000-09-28 | Compaq Computers Inc. | Encrypting secrets in a file for an electronic micro-commerce system |
-
1995
- 1995-02-13 CA CA002218178A patent/CA2218178A1/en not_active Abandoned
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000057370A1 (en) * | 1999-03-19 | 2000-09-28 | Compaq Computers Inc. | Encrypting secrets in a file for an electronic micro-commerce system |
US6424953B1 (en) | 1999-03-19 | 2002-07-23 | Compaq Computer Corp. | Encrypting secrets in a file for an electronic micro-commerce system |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6434238B1 (en) | Multi-purpose transaction card system | |
US6237095B1 (en) | Apparatus for transfer of secure information between a data carrying module and an electronic device | |
US5748740A (en) | Method, apparatus, system and firmware for secure transactions | |
EP2801061B1 (en) | Data protection with translation | |
JP3911683B2 (en) | Consideration transfer system | |
US20100228668A1 (en) | Method and System for Conducting a Transaction Using a Proximity Device and an Identifier | |
KR20090127282A (en) | Authentication device and method | |
JP2005521332A (en) | Method and system for performing transactions using proximity devices | |
WO2002079960A1 (en) | Trusted authorization device | |
US6003764A (en) | Method of securely storing and retrieving monetary data | |
CN1614620A (en) | Portable card readers and method thereof | |
US20230259901A1 (en) | Issuing entity and method for issuing electronic coin data sets, and payment system | |
CA2218178A1 (en) | Multi-purpose transaction card system | |
AU4090800A (en) | Multi-purpose transaction card system | |
JP4334021B2 (en) | Method for proving accumulation in a reader | |
AU722824B2 (en) | Method of securely storing and retrieving monetary data | |
Card | Specifications for Payment Systems | |
EP1020821A2 (en) | Method, apparatus, system and firmware for secure transactions | |
EP1269284A2 (en) | System and method for the protection of electronic communications and data using multiple, single-use key codes | |
Guillou | Some critical remarks on “dynamic data authentication” as specified in EMV'96 | |
Schouwenaar | Dutch EMV-cards and Internet Banking | |
Kuhlmann | Secure, Internet-Based Financial Transactions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Discontinued | ||
FZDE | Discontinued |
Effective date: 20050214 |