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/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/0806—Details of the card
  • G07F7/0813—Specific details related to card security
  • G07F7/082—Features insuring the integrity of the data on or in the card

Definitions

• the invention relates to preloaded IC-cards and a system for mutual authentications between preloaded IC-cards and card readers and a method for the mutual authentications according to the generic part of claims 1 , 4 and 10.
• Such preloaded IC-cards and systems for authentication of preloaded IC-cards and of associated card readers are to be used in mobile or public telephones, commodity metering devices, vending machines, point of sales and the like.
• IC-cards are based on the DE-PS 25 60 080 and DE-PS 25 12 935 and are used world wide, today.
• the exchange of information between a card reader and the IC- card may be blocked for writing into sections of a memory already occupied by data.
• the application WO97/21197 describes the payment operation with preloaded IC- cards of prior art identifying the IC-card prior to the payment operation and checking thereafter the correct devaluation of the IC-card content.
• the US-A 4'710'613 teaches to use an identification system to check the validity of the data transfer between a card reader and the IC-card. After inserting the IC-card into the card reader the user inputs a personal identification number to the card reader generating in turn an identification code information using the RSA encryption algorithm and calculates an estimation of the time required for processing the identification code information by a processor of the IC-card. The card reader measures the actual time required for processing the identification code information by the IC-card processor and blocks any further data transfer, if the actual processing time does not meet the estimated time.
• the WO9424673 presents an IC-card containing a microprocessor and non-volatile memory sections divided into pages.
• the microprocessor writes only into one page at a time.
• the memory allocates a first region of a non-volatile memory for data and a second region of non-volatile memory for status information.
• a data write operation is performed by writing data to the first region and writing information to a second region, if the data write operation was performed successfully. This procedure confirms and signifies a fully completed data transfer.
• the US-A 5'572'004 describes a method of payment for services or goods using the preloaded IC-card which communicates with a security module through an electronic terminal located in the card reader. The method ensures the correct devaluation of the IC-card and the correct amount transferred from the IC-card to the security module of the card reader.
• the shield comprises resistive layers over the integrated circuit representing two of the four resistors of the Wheatstone's bridge integrated into the integrated circuit. Any physical damage to the shield will be sensed by the integrated circuit and the integrated circuit will disable any further access.
• IC-cards having cryptographic abilities are used as electronic purses.
• the owner of the purse or smart card Before any transaction takes place, the owner of the purse or smart card has to identify himself to the card reader terminal by a personal identification number.
• the card reader presents a signature based on the personal identification number to the IC- card which in turn is checked by the IC-card, if the personal identification number is valid or not.
• the signature is also called a "Cryptogram".
• the card reader is allowed to proceed with the transaction, e.g. to read the monetary value of the IC-card and to change the monetary value of the IC-card by a certain amount in order to pay for the transaction.
• the preloaded IC-card may be used like money, any bearer of the IC-card is authorised to use it without identification.
• An authentication of the IC-card is made by the card reader terminal in conjunction with a security module.
• a fraudulently altered card reader may deplete the IC-card of its total amount of cash value instead of the exact amount signalled to the owner of the card at the point of sale and illegally transfer the money worth to the security module of the altered card reader. Later the cash value stored in the security module will be unsuspiciously transferred to the bank account of the trickster.
• IC-cards are standardised according to ISO/IEC 7816, parts 1 to 5.
• the primary objects of the present invention are to prevent unauthorised cash value transfer between a IC-card and a not identified card reader and its security module, respectively, and to provide a system comprising the card reader and the preloaded IC-card connected to the card reader, and a method for this system which is secure, and the IC-card.
• Figure 1 is schematic view of a system for mutual authentication of preloaded IC- cards
• Figure 2 is a block diagram of an integrated circuit of the IC-card
• FIG. 3 is a flowchart of a mutual authentication operation
• FIG. 4 is a flowchart of a payment transaction
• Figure 5 shows a random number generator circuit
• Figure 6 shows a counter record
• Figure 7 shows a backup counter area
• FIG. 8 is a flowchart of a key change operation
• Figure 10 shows two memory sections
• Figure 11 visualises an integrity check.
• figure 1 identifies 1 a card reader, 2 an IC-card, 3 an electronic terminal of the card reader 1 , 4 a security module, 5 contact pads, 6 data lines, 7 a socket for the security module 4, 8 an integrated circuit, 9 an electronic lock, 10 a cash value unit counter content, 11 a T-DES unit to produce a security module signature, and 12 a random number generator.
• the electronic circuit 8 is implemented as a tiny module into a flat piece of plastic representing the IC-card 2.
• the contact pads 5 of this module enables the electronic circuit 8 to communicate with the terminal 3.
• the card reader 1 is part of or connected to a stand alone point of sale 52, e.g.
• the card reader 1 provides a bay or a slot to accommodate one IC-card 2, and comprises further the electronic terminal 3 controlling the read-/write operation in conjunction with the security module 4.
• At least one security module 4 used in the card reader 1 has a standardised size looking like a small IC-card 2 (CEN/ENV 1375 - "Additional ICC Formats, - part 1 : ID-000 Card”), and is able to verify the IC-cards 2 of one Issuer and to handle the transactions of the identified IC-cards 2. If the IC-card 2 is inserted into the card reader 1 , the contact pads 5 are brought into contact with contact fingers (not shown here) of the card reader 1 , so that the terminal 3 is able to exchange data with the IC-card 2 by means of the data lines 6.
• Each security module 4 is inserted into the socket 7 to connect it to the terminal 3 for easy exchange or removal, and provides the terminal 3 with specific data of the IC-card 2 for security purposes and memory spaces for the amount of the cash value units collected from the IC-card 2.
• the socket 7 and the data line 6 are indicated in the drawing by double headed arrows indicating the data traffic directions to and from the terminal 3. All data to be exchanged between the IC-card 2 and the security module 4 are handled by the terminal 3.
• the card reader 1 represents the outside world for the IC-card 2.
• the integrated circuit 8 of the preloaded IC-card 2 stores a card identification number and the cash value unit content counter 10 in its memory which is protected by the electronic lock 9.
• the security module 4 identifies the IC-card 2 by its identification number and, if the test is positive, the lock 9 is opened and the cash value units are transferred from the IC-card 2 to the security module 4.
• the drawbacks of this system have been mentioned in the introductory part. Therefore the preloaded IC-card 2 has additional features so that the security module 4 not only identifies the IC-card 2 but also vice versa, i.e. the IC-card 2 is able to check the authenticity of the security module 4 in use.
• FIG. 2 shows the IC-card 2 and in more details the integrated circuit 8 which allows such a mutual authentication between the security module 4 (figure 1) and the IC- card 2.
• the integrated circuit 8 may be a microprocessor based on an 8-bit micro controller 13. Memory sections 14 to 20, and a physical security unit as the lock 9, and a dedicated asynchronous receiver/transmitter unit 21 are connected to this controller 13 by a 12 bit wide address bus 22 and a bi-directional 8 bit wide data bus 23.
• a reset line 24 allows to reset the controller 13 and the lock 9 by the terminal 3 (figure 1). Just for the record, the lock 9 and the receiver/transmitter unit 21 are connected directly to the controller 13 by interrupt and status lines.
• the terminal 3 sends by means of the contact pads 5 synchronised to a clock signal on a clock line 25 the data to be transferred over a bi-directional single wire input/output - line 26 to the integrated circuit 8 or receives the data from the integrated circuit 8.
• the asynchronous receiver/transmitter unit 21 serves as an interface to the data bus 22 controlled by the controller 13.
• the contact pads 5 allow further a connection of the reset line 24, the clock line 25, and the power supply lines (not shown here) to the terminal 3.
• the memory may be divided into seven memory sections 14 to 20 storing data and program information.
• the two ROM sections 14 and 15 may be of a flash memory type or a conventional ROM, having together e.g. 4096 bytes.
• the third section 16 is a random access memory (RAM memory section 16) with a capacity of e.g. 128 bytes which may provide a RAM area 49 for data to be lost due to a reset or a power cut-off.
• the E 2 PROM memory sections 17 to 20 provide the non volatile storage space for sensitive or secret data, e.g. for a secret cryptographic key K in the third memory section 19, for the cash value unit counter content 10 in the forth E 2 PROM memory section 20, for a life cycle status LS in the first E 2 PROM memory section 17, etc. and are protected against analysing, e.g. by use of a scanning electron microscope, by a special shield 27 covering these E 2 PROM memory sections 17 to 20.
• the physical integrity of the shield 27 is at least tested by the controller 13 during each power-up step (figure 3) of the IC-card 2.
• any physical damage to the shield 27 will be sensed and causes the controller 13 to set the life cycle status LS to "Not Valid" and to erase the content of all cells in the E 2 PROM memory sections 17 to 20 where confidential data are stored, e.g. by resetting all these cells of the E 2 PROM memory sections 17 to 20 to zero, and the secret data are lost. At least the cryptographic key K has to be erased to render the IC-card 2 useless.
• the DES transformation and the inverse DES transformation are used for encoding and decoding according to the T- DES transformation and are handled by the same algorithm unit 29 and by the T-DES unit 11 (figure 1), respectively.
• the cryptographic key K is used in the T-DES coding procedure for sensitive data to be exchanged between the IC-card 2 and the security module 4. Therefore the IC-card 2 and the security module 4, both store in their respective memories the identical cryptographic key K and use the identical algorithm in the algorithm unit 29 and in the encoder 11 (figure 1), respectively, to encode and decode the data exchanged.
• Another task of lock 9 is to decode any access request by the terminal 3 to the IC-card 2, to compare the request with the life cycle status LS (e.g. "Test Mode”, "Issuer Mode”, “User Mode”, “Not Valid"), and act accordingly.
• the life cycle test starts each time, the IC-card 2 is connected to the power supply of the card reader 1 (figure 1).
• the lock 9 reads the life cycle status LS.
• the "Test Mode” is only used once for factory quality control using a test program located in the first ROM 14 which disables itself after the "Test Mode” - program has been executed.
• the second ROM 15 stores an operating program.
• the controller 13 runs under the operating program if the life cycle status LS of the IC-card 2 is in "Issuer Mode” or "User Mode” and will be activated by the test program.
• In the "Issuer Mode” also used only once, at least an individual card number, the cash value unit counter contents 10 (figure 1), the date, the keys, other necessary parameters of the IC-card 2, etc. are fed to the E 2 PROM memory sections 17 to 20 under control of the operating program.
• the number of maximum allowed unsuccessful access attempts is stored as the faulty access number 48.
• a life cycle status byte may be used which is stored in the RAM memory section 16. For example seven bits of the life cycle status in the first E 2 PROM memory section 17 are copied into the life cycle status byte.
• the eighth bit represents an authenticate flag indicating the status of the present authentication process. The following procedures are explained on the assumption that in the "Issuer Mode” the faulty access number 48 is set to a number, e.g. to 15 or "F" in hexadecimal notation.
• FIG. 3 shows a schematic flowchart of the mutual authentication process between the IC-card 2 and the card reader 1 (figure 1).
• the flow chart indicates which steps occur in the IC-card 2, the terminal 3, and the security module 4, respectively.
• the mutual authentication process begins at power - up step 31 after the terminal 3 contacts the IC-card 2 and supplies the electrical power.
• a reset signal on the reset line 24 (figure 2) is sent to the IC-card 2 during a reset step 32.
• the controller 13 (figure 2) is set to a start address and overwrites in turn the RAM memory section 16 (figure 2).
• the reset signal initialises the lock 9 (figure 2), too, in order to start a life cycle test on the life cycle status LS during a preparation step 33.
• the controller 13 compares the faulty access number 48 with zero at a card check 331. If the faulty access number 48 equals zero, no more authentications are allowed and the IC-card 2 will be invalidated during an invalidate step 332 by setting the life cycle status LS to "Not Valid" and after erasing the confidential data, and the process is send to an out step 333. Otherwise, the process continues with a random number step 334.
• the life cycle status LS is now in the "User Mode", and the generator circuit 28 (figure 2) prepares a card random number and the controller 13 stores the card random number at the RAM area 49 of the RAM memory section 16 and proceeds to the out step 333, too.
• the life cycle status byte is refreshed and is transferred together with relevant data, if any to the terminal 3.
• the relevant data are e.g. the individual card serial number, an integrated circuit number, the date of issue, the number of cash value units, the card random number, etc.
• the terminal 3 tests the actual life cycle status byte during a terminal check 34 and, if the IC-card 2 is in the "User Mode", the terminal 3 initialises the authentication in a initialisation step 35 by sending the relevant data of the IC-card 2 and a initialisation request to the security module 4; otherwise if the life cycle status byte is set to "Not Valid" the process is terminated by the terminal 3 at stop 36.
• the random number generator 12 (figure 1) generates a security module random number which is stored in the security module 4 together with the relevant data of the IC-card 2, The security module random number is send back to the terminal 3 at a receiving step 38. Then the terminal 3 forwards the security module random number as a encoding request 39 to the lock 9 and initialises a card encoding step 40 starting with a decrement of the faulty access number 48 by one unit. Then the algorithm unit 29 (figure 2) calculates a card signature which is the T-DES - transformation of the security module random number and the relevant data of the IC-card 2 using the cryptographic key K. The card signature and the security module random number are stored at the RAM area 49, too.
• the card signature is sent back to the terminal 3 together with the refreshed life cycle status byte.
• the terminal 3 sends the card signature as an authentication request 41 to the security module 4, where during the authentication test 42 the T-DES unit 11 (figure 1) decodes the transferred card signature with the cryptographic key K, e.g. by comparing the transferred card signature with the card signature recalculated by the T-DES unit 11 using the cryptographic key K and the stored original security module random number and the relevant data of the IC-card 2 stored in the security module 4. According to the result of the comparison a security module status byte is set to "Card Authentic" if the IC- card 2 is acceptable or - if not - to "Card Not Authentic".
• the card signature is stored in the security module 4 and the T-DES unit 11 using the cryptographic key K encodes a security module signature based on the card random number and the previous result of the authentication, i.e. the card signature.
• the security module signature, if any, and the security module status byte are presented to the terminal 3. If a decision 43 establishes the security module status byte to be "Card Not Authentic” the process is aborted at a stop 44. However, if the card signature is correct and the IC-card 2 therefore acceptable to the security module 4, the decision 43 based on the security module status byte branches the process to a verifying request 45. There the terminal 3 presents the security module signature to the lock 9.
• the lock 9 tests the security module signature.
• the algorithm unit 29 (figure 2) recalculates the security module signature with the cryptographic key K and the card signature stored in the RAM memory section 16 and the original card random number, and the controller 13 compares the result with the transmitted security module signature using the comparator 47. If the recalculated and the transmitted security module signatures are equal, the mutual authentication is valid, the faulty access number 48 is incremented by one unit, and the authenticate flag is set to "Access OK". However, if the recalculated and the transmitted security module signatures are different, the authentication failed and the authenticate flag is set to "Access Not OK.
• the IC-card 2 sends the refreshed life cycle status byte to the terminal 3 which tests the life cycle status byte again in a second decision 50. If the life cycle status byte indicates the "User Mode” and the authenticate flag signals that the security module 4 is acceptable for the IC-card 2 ("Access OK"), the lock 9 is unlocked and allows the cash value unit counter content 10 (figure 2) in the fourth memory section 20 to be changed. The mutual authentication is successfully ended at service step 51 and the terminal 3 in connection with the authorised security module 4 is allowed to proceed with a payment transaction. If the second decision 50 senses a faulty authentication, i.e. the authenticate flag is set to "Access Not OK", the process ends at the stop 44. At the end of the successful mutual authentication process both devices, the IC-card 2 and the security module 4, have stored in the respective memories the card signature and the security module signature.
• the figure 4 represents a schematic flowchart of a payment transaction procedure in which authentication is rechecked before the cash value is transferred from the IC- card 2 to the security module 4.
• the terminal 3 accepts from the point of sale 52 a payment request 53 with a transaction value, i.e. the number of the cash value unit to be decreased in the cash value unit counter content 10 (figure 2). Only if the transaction value is less than the cash value unit counter content 10, the terminal 3 proceeds with the procedure and sends a decrease request 54 and the transaction value to the security module 4.
• a new security module signature is established in a signature step 55 and replaces the previous security module signature in the memory.
• the terminal 3 receives the new security module signature and presents it together with the transaction value in a requesting step 57 to the lock 9 (figure 2) of the IC-card 2.
• the controller 13 decrements firstly the faulty access number 48 by one unit and sets the authenticate flag to "Access Not OK". Then the algorithm circuit 29 (figure 2) recalculates the new security module signature in the arithmetic step 58 based on the old security module signature stored at the RAM area 49 in the RAM memory section 16 (figure 2) and the transaction value.
• the old security module signature is replaced by the new security module signature at RAM area 49. If the result of this calculation is the same as the transferred new security module signature, the authentication is verified.
• the actual cash value unit counter content 10 is copied as a previous cash value unit counter content 10' into the fourth E 2 PROM memory section 20 and is thereafter decreased by the transaction value to get a present cash value unit counter content 10, i.e. the present cash value is the difference of the previous cash value minus the transaction value.
• the controller 13 increments the faulty access number 48 (figure 2) by one unit and sets the authenticate flag to "Access OK".
• the refreshed life cycle status byte is sent to the terminal 3 where a third decision 59 on this status byte branches the procedure.
• the terminal 3 If the authenticate flag indicates "Access Not OK", the terminal 3 aborts the procedure at stop 60. If the third decision 59 senses the authenticate flag in the status "Access OK", the terminal 3 sends a signature request 61 to the IC -card 2. In a coding step 62 IC-card 2 generates a new card signature in the algorithm circuit 29 based on the cryptographic key K, the present cash value and the previously used card signature. The new card signature replaces the old card signature in the RAM memory section 16 and is sent to the terminal 3 (terminal step 63). In the meantime, the security module 4 has calculated separately the present cash value from the data stored in the security module 4 in order to enhance security and to save transmission time on the input/output line 26 (figure 2).
• the terminal 3 transfers in a transfer step 64 the new card signature to the security module 4 and initialises an incrementing step 65 wherein the new card signature replaces the stored old one.
• the T-DES unit 11 (figure 1) verifies based on the previously used card signature and the present cash value the authenticity of the new card signature. If the authenticity of the new card signature is true, the status byte is set to "OK" and a transaction counter 66 (figure 1) is incremented by the transaction value, if the authenticity is not verified only the security module status byte is set to "Not OK". The security module status byte is returned to the terminal 3 to be tested in a fourth decision 67. If the security module status byte is "Not OK" then the transaction procedure is terminated at stop 68.
• the terminal 3 has finished the transaction procedure successfully and the payment will be acknowledged to the point of sale 52 in an acknowledge step 69. Then the terminal 3 returns to the service step 51 awaiting a new transaction procedure or the removal of the IC-card 2. From the terminal step 63 onwards the transaction procedure runs independently of any connection to the IC-card 2, up to the acknowledge step 69 and from there to the service step 51 or, if the IC-card 2 is removed, the terminal 3 goes asleep until the next contact with an IC-card 2 will occur.
• the IC-card 2 is locked by the signal on the invalidate line 30 (figure 3) and has to be reset by a signal on the reset line 24 (figure 2) at the reset step 32 (figure 3), in order to restart the authentication process again.
• An other execution of the terminal 3 restarts automatically the authentication process and/or the transaction procedure a limited number of times at the stops 44 and/or 60 by returning to the reset step 32.
• the surveillance of the mutual authentication process covers at least the preparation and exchange periods of the encrypted data, i.e. from the start of the encoding step 40 (figure 3) to the second decision 50 (figure 3) and during the arithmetic step 58, and has the advantage to recognise any access ending irregularly, e.g. due to a non valid IC-card 2, a power failure or a disconnecting of the IC-card 2 from the card reader 1 (figure 1) and to limit the number of these irregular accesses by decrementing the faulty access number 48 stored in the E 2 PROM memory section 20.
• the preparation and exchange periods of the encrypted data involve time consuming calculations and may last up to several seconds and therefore sufficient time is available to end the mutual authentication processes in an irregular way.
• the transaction procedure has the advantage that the data flow on the single wire input/output line 26 is drastically reduced and the calculation time in the respective circuits of the IC-card 2 and of the security module 4 is minimised without sacrificing security.
• the cryptographic processes save advantageously time by calculating only two random numbers at the very beginning of the authentication process and using thereafter the previous respective signatures instead of the time consuming generation and exchange of new random numbers.
• the life cycle status LS may be set by the terminal 3 under certain conditions the terminal 3 contacts the IC-card 2 actively, e.g. at the reset step 32 (figure 3), at the encoding request 39 (figure 3), at the verifying request 45 (figure 3), at the request step 57, at the signature request 61 , etc.
• such a condition may arise in case the security module 4 detected that the transferred card number is listed as stolen or otherwise suspicious.
• life cycle status LS is set to "Not Valid”
• the controller 13 erases at least the confidential cryptographic keys in the third E 2 PROM memory section 19 as described above.
• a generator device 70 which may be used as the random number generator 12 (figure 1) and the generator 28 (figure 2) for generating the security module random number and the card random number, respectively.
• the device 70 comprises a linear shift register 71 , a free-running clock 72, and Boolean units 73.
• the shift register 71 of eight bits is shifting its content from the least significant bit to the most significant bit, e.g. in the drawing of figure 5 the shift register 71 is shifting its content to the right.
• the outputs of actual contents of the most significant or eighth bit and of the sixth bit and of the third bit are mixed together by the Boolean units 73 with a signal of the free-running clock 72 to form a combined signal fed to the input of the least significant bit.
• the signal of the free-running clock 72 is asynchronous to the clock signal of the shift register 71.
• the kind of the Boolean units 73 and the signals of the shift register 71 to be combined by the Boolean units 73, the size of the shift register 71 and the frequency of the free-running clock 72 are determined by the requirements for the generator device 70, e.g. the random numbers produced by the device 70 must be compliant to basic statistical distribution laws and the criteria developed by S. W. Golomb ("Shift Register Sequences" by S. W. Golomb, Holden-Day, San Fancisco 1967 or second edition at Aegean Park Press, 1982).
• the feature of tracking of the number of invalid access attempts and limiting this number to a predetermined number of allowed invalid access attempts has the advantage that the cryptographic key K for the signature generation used by the algorithm circuit 29 cannot be extracted by trial and error attack, hence the cryptographic key K is kept secret.
• the decrease of the faulty access number 48 prior to the authentication process prevents the fooling of the system by tearing the IC-card 2 from the card reader 1 (figure 1) before the faulty access number 48 is incremented again at the end of the successful transaction at the verifying step 46 and the arithmetic step 58 (figure 4).
• the authentication test is started at the beginning of the preparation step 33 instead of the encoding step 40 (figure 3) in order to keep the whole procedure from the preparation step 33 until the end of the verifying step 46 under surveillance.
• the controller 13 is programmed to compare a set of two numbers directly under control of the operating program which eliminates the need of the hardwired comparator 47.
• the cash value unit counter content 10 is stored in the fourth memory section 20 and the cash value units are decremented by the controller 13 as demanded by the terminal 3 until all the cash value units are used up and the cash value is zero. Then the IC-card 2 is used up and discarded.
• An execution of the IC-card 2 is able to be reloaded to a predetermined cash value limit, e.g. the equivalent of CHF 300.00.
• a predetermined cash value limit e.g. the equivalent of CHF 300.00.
• a number of allowed reloads is stored which is set in the "Issuer mode". If the number of allowed reloads is set to zero, the IC-card 2 can be used once, up to the moment the cash value unit counter content 10 reaches zero. As long as the number of allowed reloads is different to zero, the terminal 3 (figure 1) may request the IC- card 2 to get ready to reload the cash value unit counter content 10. This service may be initialised after the mutual authentication has been established at the service step 51 (figure 3).
• the controller 13 tests the number of allowed reloads. If the number of allowed reloads is not zero, then the controller 13 decrements the number of allowed reloads by one unit and the cash value unit counter content 10 can accept new cash value units.
• the reload will take place at a specialised card reader 1 connected to a computer of a bank institute instead to the point of sale 52 (figure 1). Besides the mutual authentication between the IC-card 2 and the card reader 1 , an additional identification of the user by means of the personal identification number is required by the bank institute.
• the number of reloads will be advantageously limited in order to minimise any misuse and to invalidate IC-cards 2 of high age to avoid misfunction due to the limited lifetime of the E 2 PROM memory cells. The limits for e.g.
• the cash value unit counter content 10 the faulty access number 48, the number of reloadings etc., are set in the "Issuer mode" to the maximum allowed numbers which are stored in the memory section 20.
• the appropriate limit will be decreased at least by one unit, if a respective event has occurred.
• This method has the advantage of time saving because the controller 13 compares the respective numbers much faster with zero than it executes a comparison with a number stored in the memory.
• the faulty access number 48 may be incremented by one unit.
• the system of the preloaded IC-card 2 and the card reader 1 has the advantage that the preloaded IC-card 2 and the security module 4 (figure 1) are able to mutually authenticate the partner of the data transfer and provides the system with means to refuse any non - authentic access attempt to the user's payment means. This enhances greatly the level of confidence a customer can put into his IC-card 2 and the Issuer into the whole system.
• the integrated circuit 8 has to prevent effects due to sudden power failures, e.g. in case the IC-card 2 is torn away from the card reader 1 (figure 1) before the transaction has finished or during an updating of one of the counting areas in the E 2 PROM memory sections 17 to 20.
• a hard wired logic prevents the effects of card withdrawal during the updating of the counting area by using a flag or witness bit which is written each time the counter content 10 is changed. Since it is impossible to write the witness bit exactly in parallel with the counter, there is still a possibility that error may occur due to a sudden power failure. This may even result in a state where the counter content 10 can be illegally increased.
• the new IC-card 2 is provided with automatic backup means for each sensitive counter to keep track of the counter content changes by storing at least the previous and the actual content of the respective counters.
• a counter record 74 is shown as an example.
• the counter record 74 comprises three fields, a management field 75 indicating the seniority of the counter record 74, a counter value 76 storing the actual IC-card value 10 (figure 2) at the time the counter record 74 was saved, and a checksum in a checksum field 77, the content of which (the checksum) is based on the counter value 76.
• Each sensitive counter of the IC-card 2 has at least two counter records 74 located in a backup counter area 78 of the memory section 20.
• the integer number of the counter records 74 is greater than 1 , but less than the capacity of the management field 75.
• the most sensitive counter deals with the cash value units. The further description refers to the cash value unit counter.
• the backup counter area 78 has a set of four counter records 74.
• the controller 13 determined during the preparation step 33 (figure 3) a maximal value of the contents in the four management fields 75a to 75d of the backup counter area 78, and stored said maximum value of the four management fields 75a to 75d into an activation field 79 located in the RAM memory section 16.
• the controller 13 will always overwrite the oldest entry in the backup counter area 78.
• the address of the oldest entry is calculated according to the rule: "the content of the activation field 79 increased by one and taken as modulo the number of counter records 74a to 74d in the backup counter area 78". If the counter content, i.e. the.
• the controller 13 gets access over the data bus 23 to the memory section 20 with the backup counter area 78. Then the controller 13 reads out the content of the activation field 79 and determines the address of one of the counter record 74a to 74d by the operation "content of the activation field 79 modulo 4", e.g. counter record 74b, which has been used at the previous change of the counter and recalculates the checksum based on the counter value 76b, e.g. the cash value unit counter content 10. If the recalculated checksum is the same as the checksum stored in field 77b then the previous change of the counter was successfully terminated.
• the controller 13 increments the content of the activation field 79 by one unit, reads out the counter value 76b, and reduces the content of the counter value 76b by a decrement of one or several units as required. Then the new content of the activation field 79 is used by the controller 13 to calculate the new address of the next counter record 74, in this example the counter record 74c. The controller 13 saves the decremented value as the next counter value 76c the incremented content of the activation field 79 in the management field 75c, and calculates the new checksum based on the content of the counter value 76c and saves the new checksum in the field 77c.
• the controller 13 addresses the counter record 74c and recalculates the checksum based on the content of the counter value 76c. Obviously the newly recalculated checksum differs now from the content of the checksum field 77c, because the previous transaction process failed at the arithmetic step 58 (figure 4), i.e. in the previous transaction the incrementing step 65 (figure 4) and the acknowledge step 69 (figure 4) have not been executed and the subtracted transaction amount has not been used for payment.
• the controller 13 decrements therefore the content of the activation field 79 by one unit and reads out the counter value 76b, e.g. the previous cash value unit counter content 10' (figure 2), as the actual cash value unit counter content 10.
• the controller 13 proceeds as above, testing the checksum in the field 77b which is obviously correct, increasing the activation field 79 by one unit, decrementing the cash value unit counter content 10 according to the new transaction, and storing the new actual contents in the fields 75c, 76c, and 77c of the counter record 74c.
• This procedure has the advantage that the owner of the IC-card 2 can not fool the system by manually interrupting the process of transaction nor is it sensitive to accidental wrong handling or to a defective card reader 1 causing power failures in the IC-card 2.
• the controller 13 decides that the respective counter record 74 contains defective memory cells and invalidates the IC -card 2 by setting the life cycle status LS to "Not Valid".
• the third E 2 PROM memory section 19 provides a memory place 80 for an auxiliary key AK.
• the auxiliary key AK is not used for the standard processes. A value is filled in the memory place 80 and is used as the auxiliary key AK during the "Issuer Mode".
• the integrated circuit 8 deciphers a new cryptographic key K with the auxiliary key AK solely in case of a key downloading from the security module 4 (figure 1), e.g. after the cryptographic key K used in the algorithm circuit 29 was discovered.
• the auxiliary key AK is also available in the security module 4.
• FIG 8 shows the relevant part of the authentication process with the additional steps of the key - change process.
• the card signature is transferred to the security module 4 in the authentication request 41. If in the authentication test 42 using the new key K, the security module 4 classifies an IC-card 2 based on the card signature as not authentic, the IC-card 2 may use still the obsolete old key K* or be indeed not authentic.
• a switch 81 activated during the extra maintenance diverts the process to a second authentication test 42' where the card signature is recalculated using the obsolete old key K * and the result is compared with the transferred card signature.
• the IC-card 2 is not authentic and the process is diverted by a second switch 82 back to the terminal 3 with the security module status byte set to "Not Authentic". However, if the recalculated and the transferred card signatures are equal, the security module status byte is set to "Change Key", and the second switch 82 diverts the process to a send key step 83.
• the send key step 83 the new key K is encoded by the T-DES unit 11 (figure 1) using the DES - transformation with auxiliary key AK, the same as is stored at the memory place 80 (figure 2), and the transmitted card signature.
• the T-DES unit 11 prepares a message authentication code using the new key K and the transmitted card signature.
• the security module 4 then transmits the security module status byte, the encrypted new key and the message authentication code to the terminal 3.
• There the first decision 43 detects the security module status byte set to "Change Key”, and the terminal 3 sends the encrypted new key and the message authentication code as a key change request to the IC-card 2.
• the algorithm circuit 29 (figure 2) decodes the encrypted key by the inverse DES - transformation using the auxiliary key AK stored at memory place 80. The result is the new key K which in turn is used to recalculate the message authentication code at a code step 85.
• the comparator 47 (figure 2) compares the recalculated message authentication code and the transmitted message authentication code. If both codes are the identical, i.e. if the comparator 47 senses "True", then the controller 13 (figure 2) considers the transmission of the encrypted key and the message authentication code as correct, replaces the old cryptographic key K by the new key K in the third E 2 PROM memory section 19 (figure 2), sets the authenticate flag to "Access OK", and increments the faulty access number 48 by one unit. The process returns to the terminal 3 at the second decision 50. From then on the IC-card 2 will use the new key K instead of the original, but now obsolete key K*.
• the authenticate flag is set to "Access OK"
• the faulty access number 48 remains reduced by one unit, i.e.. the access is considered by the controller 13 as an invalid access attempt.
• the life cycle status byte is refreshed to "User Mode” and the process returns to the second decision 50 ( figure 3).
• the faulty access number 48 is set to an initial value representing the maximum number of allowed invalid attempts.
• the bits 88 of the ratification area 87 are set to logic one, e.g. if the ratification area 87 is 16 bits wide from the bit 88a to the bit 88q, the hexadecimal representation of the content of the ratification area 87 is "FFFF".
• the logic state of one of the 16 bits 88a to 88q is inverted by the controller 13 (figure 2) so that the number of bits 88 being in the same logic state (either zero or one) is an odd number (marking step).
• the parity of the number of bits 88 being in the same logic state (zero or one) is subsequently referred to as "bit parity".
• the bit parity is used as the content of the authenticate flag, e.g. a logic zero indicates an even parity and a logic one an odd parity.
• the terminal 3 (figure 1) aborts the process at the stops 44 (figure 3) or 60 (figure 4) and the controller 13 sets the invalidate line 30 (figure 2) to active and will not receive any further instruction from the second ROM 15.
• the IC-card 2 has to be reset by a signal on the reset line 24 (figure 2) in order to restart the authentication process again.
• the controller 13 inverts the logic state of a neighbouring bit 88 in order to change the bit parity to even (regularizing step).
• the controller 13 (figure 2) tests in the preparation step 33 the faulty access number 48 (figure 2) at the card check 331.
• the authentication process enters first an additional bit parity check 335 within the random step 334 before the tasks of the random number step 334 are started.
• the bit parity check 335 determines the bit parity of the ratification area 87 (figure 9) and branches the process depending of the bit parity value. An even bit parity assures the controller 13 that any previous authentication was correct.
• the controller 13 changes the bit parity to even by inverting the logic state of one of the 16 bits 88a (figure 9) to 88q (figure 9) in the ratification area 87 and decrements the faulty access number 48 by one unit. Then the authentication process exits the bit parity check 335 and proceeds with the tasks of the random step 334.
• the advantage of the use of the ratification area 87 is that the faulty access number 48 is only decremented and that the change of the E 2 PROM memory cells occurs only after an incorrect event (power failure etc.) which enhances the longevity of the E 2 PROM memory cells involved.
• the controller 13 changes the bit parity to odd by inverting the logic state of one of the 16 bits 88a to 88q in the ratification area 87 before the algorithm unit 29 (figure 2) calculates the card signature.
• the bit parity change may occur between the bit parity check 335 and the random number step 334, instead.
• the controller 13 changes the bit parity in the ratification area 87 to odd if the life cycle status LS is set to "User Mode" and the mutual authentication is assured.
• the controller 13 changes the bit parity in the ratification area 87 again to even, if the controller 13 senses that the mutual authentication was successful and the checksum is placed properly in the checksum field 77 (figure 6), respectively. Otherwise, if the controller 13 senses an unsuccessful authentication, the controller 13 keeps the bit parity in the ratification area 87 in the odd state.
• the authenticate flag carrying the bit parity information is then presented to the terminal 3 which branches the procedure at the second decision 50 to the stop 44 and at the third decision 59 to the stop 60, respectively, if the authenticate flag is set to a logic one. Such a failed access leaves an odd bit parity in the ratification area 87.
• inverting only one bit 88 in the ratification area 87 allows to increase the number of the authentications markedly, e.g. in the example of the 16 bit wide ratification area 87 the increase is 16 - fold to about 800O00 authentications without sacrificing the advantage of the E 2 PROM memory cells, that the configuration of the bits 88 in the ratification area 87 is lost during a powerless period until a next access to a card reader 1 (figure 1). Furthermore, in most access attempts more than one bit of the content of the faulty access number 48 has to be changed, which is a slow and energy consuming process with E 2 PROM memory cells and is unacceptable during a normal authentication and payment transfer.
• the controller 13 reads the ratification area 87 and tests each of the bits 88 starting with the least significant bit 88a and going up to the most significant bit 88q. If the most significant bit 88q is a logic one, the controller 13 determines and marks the first bit starting from the bit 88a which contains a logic one. If the most significant bit 88q is a logic zero, the controller 13 determines and marks the first bit starting from the bit 88a which contains a logic zero. If this marked bit is one of the bits 88a, 88c, 88e, 88g, 88i, 88I, 88n and 88p, the controller 13 considers the bit parity in the ratification area 87 as even.
• bit parity in the ratification area 87 is stored in the authenticate flag. For each change of the bit parity the controller 13 inverts the logic state of the marked bit, only, i.e. the controller 13 converts a logic one into a logic zero or vice versa.
• the advantage for the security of the information transfer is now clear.
• the life cycle status byte comprising the life cycle status LS and the authenticate flag are the only information to be sent in clear, however the information of the life cycle status byte does not allow any conclusions on the information contained in the IC-card 2. All other information exchanged is efficiently and securely scrambled.
• the first E 2 PROM memory section 17 comprises a memory space 89 of which seven bits 88 are used to save the life cycle status LS in the not volatile memory.
• the information at the memory space 89 is only changed to alter the life cycle status.
• a byte area 90 of the RAM memory section 16 is used.
• the controller 13 At the preparation step 33 (figure 3) and at each start of this refreshing process the controller 13 (figure 2) reads out the memory space 89 and copies its content into the byte area 90, e.g. into the seven least significant bits indicated by LS.
• the controller determines the state of the authentication flag and places a single bit flag 91 with the information about the authentication flag at the most significant bit of the byte area 90.
• the life cycle status byte comprises therefore the life cycle status LS and the authenticate flag.
• the controller 13 always reads the life cycle status byte out of the byte area 90 and present it to the terminal 3 (figure 1).
• the preloaded IC-card 2 (figure 2) of prior art have no means to identify themselves prior to customisation at the Issuers' premises.
• the secret cryptographic keys together with the customisation data are copied into the preloaded IC-cards 2.
• FIG 11 shows an integrity check at a terminal 3 dedicated for card customisation used at the Issuer's premises, only.
• the IC-card 2 is connected to the terminal 3 as well as a key bearer 92 on loan from a trusted third party to the Issuer.
• the key bearer 92 has an integrated circuit 92 of the identical design as the integrated circuit
• the key bearer 92 has for example the physical form of a normal IC-card 2 or the one of the security module 4 (figure 1) in order to fit the key bearer 92 into one of the socket 7 (figure 1) of the card reader 1.
• the ROM memory section 15' stores the identical operating program as the ROM memory section 15 and the fourth E 2 PROM memory section 20' which may be empty is a copy of the fourth E 2 PROM memory section 20 of the IC-card 2 to be personalised.
• the IC-card 2 is put into the card reader 1.
• the terminal 3 powers up the IC-card 2 in the reset step 32 (figure 3).
• the IC-card 2 starts to test the life cycle status LS according to the preparation step 33 (figure 3) and presents the refreshed life cycle status byte to the terminal 3.
• the terminal test 34 tests the life cycle status byte. If the life cycle status LS is set to the "Test Mode” the procedure is switched to an identifying step 94, otherwise the procedure is aborted at stop 36.
• the terminal 3 sends an identical challenge 95, e.g. the date and/or the actual time or a random number, to the IC-card 2 and to the key bearer 92.
• the challenge 95 may be send to the IC-card 2 and the key bearer 92 at the same time or at different times.
• the algorithm circuits 29 and 29' independently perform on their own the DES operation based on the challenge 95, and e.g. on the contents of the ROM memory section 15 and 15', and the fourth E 2 PROM memory section 20 and 20', respectively.
• the results of both DES - operations are presented to the terminal 3.
• There the results of both DES - operations are presented to an identification decision 96 to be compared. If the two results are different then the procedure is aborted at the stop 97 because IC-card 2 is considered as defective or as a non-authentic simulator ("Trojan horse").
• the terminal 3 starts the customisation 98 of the IC-card 2 and loads at least the relevant data and the secret key(s) taken from the key bearer 92, e.g. stored in a third E 2 PROM memory section 19', via the terminal 3 into the third and fourth E 2 PROM memory section 19 and 20, respectively.
• the life cycle status LS stored at the memory space 89 (figure 10) is set by the controller 13 (figure 2) to "User Mode".
• the fourth E 2 PROM memory section 20 has now a content different from the fourth E 2 PROM memory section 20' which remains empty.
• a second loading of these sensitive data into the IC-card 2 is impossible even if the IC-card 2 is removed from the card reader 1 before the life cycle status LS is set to "User Mode".
• the response of the IC-card 2 at the identification decision 96 differs from the one of the key bearer 92.
• the life cycle status LS of the personalised IC-cards is not anymore in the "Issuer Mode" the IC-card 2 will be rejected at the terminal check 34 and sent to stop 36.
• the advantage of this authentication prior to the customisation is the enhanced security against the discovery of the secret cryptographic keys and the "illegally refreshing" of used cards at the premises of the Issuer.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Accounting & Taxation (AREA)
• Computer Security & Cryptography (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Finance (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
• Storage Device Security (AREA)

Priority Applications (1)

Applications Claiming Priority (4)

Publications (1)

Family

ID=8232071

Family Applications (1)

Country Status (5)

Families Citing this family (25)

Family Cites Families (16)

• 1999
  • 1999-06-01 EP EP99921050A patent/EP1082710A1/de not_active Withdrawn
  • 1999-06-01 AU AU38419/99A patent/AU3841999A/en not_active Abandoned
  • 1999-06-01 WO PCT/IB1999/000977 patent/WO1999064996A1/en not_active Application Discontinuation
  • 1999-06-03 AR ARP990102624 patent/AR018624A1/es unknown
  • 1999-06-03 TW TW88109224A patent/TW413799B/zh not_active IP Right Cessation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events