GB2462648A

GB2462648A - Prevention of Relay Attacks in Electronic Authentication Systems

Info

Publication number: GB2462648A
Application number: GB0814939A
Authority: GB
Inventors: David Main
Original assignee: Visa Europe Ltd
Current assignee: Visa Europe Ltd
Priority date: 2008-08-15
Filing date: 2008-08-15
Publication date: 2010-02-17
Also published as: GB0814939D0

Abstract

A method of preventing relay attacks between a terminal device and a token device (e.g. smartcard) in an electronic authentication system, comprising: sending first dynamic (random) data from said terminal device to said token device and receiving second random data from said token device at said terminal device; monitoring a timing characteristic relating to a time difference between the exchange of the random data; receiving encrypted data generated by the token device after said monitored exchange has taken place, wherein said encrypted data is cryptographically related to both said first and said second random data (e.g. by encrypting the random data) such that a cryptographic validation process may be used to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of random data.

Description

Prevention of Relay Attacks in Electronic Authentication Systems

Field of the Invention

The present invention relates to the field of secure data communication and transmission within electronic authentication systems. The invention relates to methods of preventing relay attacks between a token device and a terminal device in electronic authentication systems, and terminal apparatus, a token device, and a transaction processing system adapted to be used in such methods.

Background of the Invention

With electronic authentication systems there is often a trade off between the complexity of implementation and the amount of fraud that can be prevented. Smartcards, also known as integrated circuit cards (ICCs), are commonly used in electronic authentication systems, and smartcards exist in both contact and contactless forms.

Known electronic authentication systems include electronic payment systems, for which various security mechanisms and protocols are used. Many electronic payment systems use the EMV (Europay�, MasterCard�, Visa�) transaction protocols, as defined for example in the EMV 4.1 and 4.2 Specifications, which are publicly available and published by EMVCo LLC.

These protocols also referred to herein as simply "EMV".

The cryptographic features of smartcard technology add significantly to the effectiveness of electronic authentication systems, but there remain potential fallibilities to fraud in the case of a concerted attack.

Prior art document "Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks" by Drimer and Murdoch, USENIX Security Symposium, September 2007, demonstrates one example of how electronic payment systems using EMV might be susceptible to a type of attack known as a "relay attack".

Figure 1 illustrates apparatus for implementing a relay attack in an electronic authentication system. A genuine ICC 1 is inserted into, communicates with, and may be powered by a fake terminal 2, which in turn is in communication with a surrogate ICC 3 via communication channel 4.

Surrogate ICC 3 is inserted into and communicates with a genuine terminal 5.

The interactions between the genuine terminal 5 and the surrogate ICC 3 are synchronised by the attacker with the interactions between the fake terminal 2 and the genuine ICC 1. Details obtained from the genuine ICC 1 are used to confirm a transaction at genuine terminal 5, unbeknown to the cardholder of genuine ICC 1, who believes that a different transaction at fake terminal 2 is being authorised. A data communications interface 6 allows data to be exchanged between genuine ICC 1 and fake terminal 2. Similarly surrogate ICC 3 and genuine terminal 5 are provided with a data communications interface 7 allowing data to be exchanged between the surrogate ICC 3 and the genuine terminal 5. A data communications channel 4 is present between fake terminal 2 and surrogate ICC 3, allowing data to be exchanged. Data communications channel 4 may include a wireless communications link and/or a fixed line communications link, allowing fake terminal 2 and surrogate ICC 3 to communicate over large distances.

Figure 2 is a sequence diagram illustrating a representative flow of data messages in a relay attack against a contact EMV authentication system, using the apparatus illustrated in Figure 1. A SELECT command 21a is issued from genuine terminal 5 to surrogate ICC 3. Surrogate ICC 3 issues a response message 21b. As previously mentioned the activities of the genuine ICC 1, fake terminal 2, surrogate ICC 3, and genuine terminal 5 are synchronised by the attacker such that at substantially the same time as SELECT command 21 a is issued by genuine terminal 5, fake terminal 2 sends a SELECT command 21c to genuine ICC 1, and genuine ICC 1 issues a response message 21 d.

Note that, for the purpose of illustration, Figure 2 depicts only one SELECT command 21 a, namely the final SELECT command in the selection process described in EMV, which is in general more complex and consists of a number of SELECT commands and responses.

The final SELECT command and/or the whole sequence may be relayed to the genuine ICC 1, but this may not be necessary as the responses could be generated by the surrogate ICC.

With the exception of the VERIFY command 24a, subsequent command requests issued by genuine terminal 5 are relayed to genuine ICC 1 for response.

A genuine terminal GPO command 22a is relayed from surrogate card 3 to fake terminal 2 in step 22b, which in turn is relayed from fake terminal 2 to genuine ICC 1 in message 22c. Genuine ICC 1 increments its Application Transaction Counter (ATC) and responds with a GPO response 22d which is relayed in messages 22e and 22f, from genuine ICC 1 to genuine terminal 5. Similarly, READ_RECORD command 23a is relayed to genuine ICC 1 in data messages 23b and 23c.

Note that, for the purpose of illustration, Figure 2 depicts only one READ RECORD command 23a as having been issued by genuine terminal 5, however more than one READ RECORD command may be issued by the genuine terminal.

Genuine ICC 1 responds in message 23d, the response 23d being relayed to genuine terminal S in messages 23e and 23f. It is to be understood that additional READ RECORD commands, if issued, are relayed in the same manner. Both genuine terminal S and fake terminal 2 request the entry of a personal identification number (PIN), which PiNs are passed to the surrogate ICC 3 and the genuine ICC 1 respectively in a VERIFY command. The VERIFY command requests that an ICC verifies the validity of the entered PIN.

The surrogate cardholder may enter any PIN, as the VERIFY command 24a is ignored by surrogate ICC 3. Entiy of the genuine ICC 1 PIN causes fake terminal 2 to issue a VERIFY command 25a to ICC 1. The genuine ICC 1 verifies the entered PIN, responding with VERIFY command response 25b, which in turn is forwarded to genuine terminal 5 in messages 25c and 25d.

Irrespective of the PIN entered in genuine terminal 5 by the surrogate cardholder, the genuine terminal 5 is always provided with a relayed successftil verification response 25d assuming the genuine cardholder has correctly entered the PIN. As an alternative approach, the surrogate ICC 3 may create and return a successful VERIFY command response, in which case relaying of the response from the genuine card is not necessary.

An INTERNAL AUTHENTICATE command 26a is relayed from genuine terminal 5 to genuine ICC 1 in messages 26b and 26c. The genuine ICC 1 responds with a digital signature, which may be Signed Dynamic Application Data (SDAD) 26d, also commonly referred to as a dynamic signature, which is relayed to genuine terminal 5 in messages 26e and 26f. The genuine terminal 5 verifies the received SDAD.

If online authorisation is required, the genuine terminal 5 generates a 1st GENERATE_AC (Generate Application Cryptogram) command 27a. The message 27a is relayed to genuine ICC 1 in messages 27b and 27c. The genuine ICC 1 responds with an Authorisation Request Cryptogram (ARQC) 27d, which is forwarded to the issuing bank transaction processing system 46 for verification in messages 27e to 27i. The issuing bank transaction processing system response 27j is forwarded to the genuine terminal 5 in messages 27k to 271. Commands 27a through 271 are omitted if authorised offline and genuine terminal 5 sends a GENERATE_AC command 28a which is relayed to genuine ICC 1 in messages 28b to 28c. The genuine ICC 1 generates a Transaction Certificate (TC) 28d, which is returned to the genuine terminal 5 as proof of a successfully authorised transaction in messages 28e and 28f. Alternatively, after online authorisation genuine terminal 5 sends a 2'" GENERATE_AC command 28a which is relayed to genuine ICC 1 in messages 28b to 28c, and genuine ICC 1 generates a Transaction Certificate (TC) 28d, which is returned to the genuine terminal 5 as proof of a successfully authorised transaction in messages 28e and The described contact EMV transaction protocol sequence in Figure 2 uses dynamic data authentication (DDA). Other EMV transaction protocol sequences may be susceptible to the described relay attack, such as EMV transaction protocols utilising either static data authentication (SDA), or combined DDA/application cryptogram generation (CDA).

Figure 3 is a sequence diagram illustrating a representative flow of a relay attack in a contactless electronic authentication system. The apparatus required to implement a relay attack in a contactless electronic authentication system may be substantially identical to the apparatus illustrated in Figure 1, with the exception that the ICC and terminal data communications interfaces 6 and 7 are wireless links, and the ICC 1 and terminal 5 are provided with wireless transceivers. Some known contactless electronic authentication systems operate according to the ISO 14443 standard, in which the ICC is referred to as a Proximity Integrated Circuit Card (P1CC) and the terminal is referred to as a Proximity Coupling Device (PCD). Systems using the ISO 14443 standard operate within the 0-10cm range, and are used in payment applications, the MIFARETM system and other transport applications. Other known contactless electronic authentication systems operate according to the ISO 15693 standard, in which the ICC is referred to as a Vicinity Integrated Circuit Card (VICC) and the terminal is referred to as a Vicinity Coupling Devices (VCD). Systems using the ISO 15693 standard operate within the 0-im range, and are used in RFID applications. Other known contactless authentication systems operate in accordance with the NFC (Near Field Communication) specifications.

Typically mobile phones and personal digital assistants (PDAs) support NFC and are able to communicate with ISO 14443 compliant devices.

Unlike contact transaction schemes, a contactless ICC is typically powered by a terminal's electromagnetic field, which may be operating in the radio frequency spectrum, or other electro-magnetic spectrums. A transaction is initiated when the field strength at an ICC's position is sufficiently strong to power the ICC. The field strength of a genuine terminal is selected such that an ICC is powered only when within acceptably close range of the terminal. In many practical contactless electronic authentication systems this is prescribed to be a small limited distance, to avoid a cardholder unintentionally initiating a transaction merely by being in the vicinity of a terminal. A relay attacker using a fraudulent terminal is however not restricted by such prescriptions, and it is envisaged that a fraudulent terminal capable of initiating transactions with a contactiess ICC from distances significantly greater than the prescribed maximum distance would be used, by selection of a suitably strong field. In such cases a relay attacker could for example initiate a transaction with an ICC in a cardholder's pocket, with the cardholder unknowingly being party to a transaction.

Take as an example of contactless authentication systems, a system that operates according to the ISO 14443 standard, such as those based on the EMV Contactless Communication Protocol Specification. As with the previously described relay attack illustrated in Figure 2, following device discovery the transaction in a contactless electronic authentication system is initiated by a SELECT command. The commands in the contactiess transaction protocol may be similar to those present in previously described Figure 2, with the exception that PIN entry is not requested, and online verification is not conducted. As with previously described Figure 2, message 30a is the final SELECT command in the selection process, and is issued from genuine terminal 5 to surrogate ICC 3. Furthermore the activities of the genuine ICC 1, fake terminal 2, surrogate ICC 3, and the genuine terminal 5 may be synchronised by the attacker such that at substantially the same time as SELECT command 30a is issued by genuine terminal 5, fake terminal 2 sends SELECT command 30c to genuine ICC 1, and genuine ICC 1 issues a response message 30d. Note, again, that the command-response sequence may involve a number of SELECT commands, which have not been depicted in Figure 3.

Following the SELECT command-response exchange, a GPO command 3 la is relayed from the genuine terminal 5 to the genuine ICC 1 in messages 3 lb and 31 c. The genuine ICC 1 ATC is incremented upon receipt of the message 31c. A response 31d is relayed to the genuine terminal 5 in messages 31e and 31 f. In the illustrated example the INTERNAL_AUTHENTICATE command 32a is issued prior to the READ RECORD command. The command 32a is relayed to genuine ICC 1 in messages 32b and 32c. The genuine ICC 1 replies with its digital signature, which may be a dynamic signature 32d. The signature 32d is relayed to the genuine terminal 5 in messages 32e and 32f. Other sequences may combine the functionalities of the GPO command and the INTERNAL AUTHENTICATE command such that only a single exchange is required with the relayed message 32f being the end response to the command in 31a. In the above-described sequence the genuine terminal 5 awaits the READ_RECORD command response to verify the authenticity of the received dynamic signature (SDAD), as it does not yet possess the required asymmetric cryptographic key to verify the dynamic signature. The READ RECORD command is relayed to genuine ICC 1 in messages 33a, 33b and 33c. Genuine ICC 1 response 33d is relayed to genuine terminal 5 in messages 33e and 33f and is used by genuine terminal 5 to verify the authenticity of the SDAD received in message 32f. Subsequent to processing of the dynamic signature a TC is provided to genuine terminal 5 as confirmation of the transaction. Other sequences may utilise more than one READ RECORD command and the READ_RECORD command or commands may occur before and or after the command that results in the dynamic signature.

The above-mentioned "Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks" by Drimer and Murdoch, and "An RFID Distance Bounding Protocol", by Hancke and Kuhn, IEEE SecureComm 2005, both propose solutions to relay attacks which use a distance bounding mechanism. Such solutions propose introducing a novel cryptographic exchange, to bound the distance the ICC is from the terminal. However, and the addition of a new cryptographic exchange may require a significant amount of redevelopment effort and large scale redeployment of equipment. Moreover, certain types of additional cryptographic process, such as those suggested in the prior art, will tend to significantly increase overall transaction times, which is undesirable given the general desire for faster processing, particularly in contactless electronic authentication systems in which transactions are particularly time-constrained.

It is an objective of the present invention to provide a defence to relay attacks in electronic authentication systems, whilst allowing improved integration with existing electronic authentication systems.

Summary of the Invention

In accordance with an aspect of the invention, there is provided a method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by sending first dynamic data from said terminal device to said token device and receiving second dynamic data from said token device at said terminal device; monitoring a timing characteristic relating to a time difference between said sending and receiving during said exchange; and receiving cryptographically coded data generated by the token device after said monitored exchange has taken place, wherein said cryptographically coded data is cryptographically related to both said first dynamic data and said second dynamic data such that a cryptographic validation process may be used to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.

An advantage of the present invention is that protection against relay attacks may provided without requiring the introduction of complex new cryptographic processes during the monitored exchange. Furthermore, the methods of the present invention may be incorporated into existing authentication processes and existing electronic authentication systems without requiring the introduction of complex new cryptographic processes. The cryptographically coded data may be included as part of cryptographically coded data which is already transmitted in the existing processes and systems.

In preferred embodiments of the invention, the method comprises preventing relay attacks in a transaction authentication system, the method comprising transmitting transaction data from said terminal device, and wherein said cryptographically coded data is cryptographically related to said transaction data in addition to said first dynamic data and said second dynamic.

In preferred embodiments of the invention, the cryptographically coded data is transmitted over a data communications network to a remote authentication processing system capable of performing the cryptographic validation process to confirm that the timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.

In preferred embodiments of the invention, the cryptographic validation process is performed at the terminal device to confirm that the timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.

In preferred embodiments of the invention, the method comprises the terminal device declining to accept the authenticity of the token device if the cryptographic validation process does not confirm the timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.

In preferred embodiments of the invention, the method comprises the terminal device conducting a time-out procedure if the receiving of second dynamic data from the token device at the terminal device exceeds a monitored time period threshold, thereby indicating the likely presence of a relay circuit between the terminal device and the token device.

In accordance with another aspect of the invention there is provided a method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by receiving first dynamic data from said terminal device at said token device and sending second dynamic data from said token device to said terminal device, such that a timing characteristic relating to said exchange may be monitored by said terminal device; storing said first and second dynamic data at said token device when performing the exchange of dynamic data; generating cryptographically coded data by taking said stored first dynamic data and said second dynamic data as inputs to a cryptographic process; and sending the cryptographically coded data from the token device to the terminal device after said monitored exchange has taken place, wherein said cryptographically coded data is cryptographically related to both said first dynamic data and said second dynamic data such that a cryptographic validation process may be used to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.

In accordance with another aspect of the invention there is provided a method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by sending first dynamic data from said terminal device to said token device and receiving second dynamic data from said token device at said terminal device; monitoring a timing characteristic relating to a time difference between said sending and receiving during said exchange; and receiving transaction authentication data from said token device at said terminal device, said transaction authentication data comprising cryptographically coded data generated by the token device to authenticate a transaction, wherein said cryptographically coded data is cryptographically related to at least said first dynamic data such that a cryptographic validation process may be used to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.

In accordance with another aspect of the invention there is provided a method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by receiving first dynamic data from said terminal device at said token device and by sending second dynamic data from said terminal device to said terminal device in response to receiving said first dynamic data; generating transaction authentication data, said transaction authentication data comprising cryptographically coded data generated by the token device to authenticate a transaction; and sending said generated transaction authentication data to said terminal device, wherein said cryptographically coded data is cryptographically related to at least said first dynamic data such that a cryptographic validation process may be used to confirm that a timing characteristic, monitored by said terminal device, is representative of said token device having validly taken part in the exchange of dynamic data.

In accordance with further aspects of the present invention, there is provided terminal apparatus, a token device, and a system comprising terminal apparatus and a token device adapted to conduct the methods described above.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 shows apparatus used in a relay attack.

Figure 2 shows a sequence diagram of a relay attack on an electronic authentication system using a contact EMV transaction protocol sequence, in

accordance with the prior art.

Figure 3 shows a sequence diagram of a relay attack on an electronic authentication system using a contactless transaction protocol.

Figure 4 shows a system diagram of an electronic authentication system in accordance with embodiments of the present invention.

Figure 5 shows a flow chart of a method of preventing relay attacks in electronic authentication systems in accordance with embodiments of the present invention.

Figure 6 shows a sequence diagram of a method of preventing a relay attack in an electronic authentication system in accordance with embodiments of the present invention wherein a cryptographic validation process is performed by a terminal device.

Figure 7 shows a sequence diagram of a method of preventing a relay attack in an electronic authentication system in accordance with embodiments of the present invention wherein a cryptographic validation process is performed by a remote transaction processing system.

Figure 8 shows a sequence diagram of a method of preventing a relay attack in an electronic authentication system using a contact EMV transaction protocol, in accordance with embodiments of the present invention.

Figure 9 shows a sequence diagram of a method of preventing a relay attack in an electronic authentication system using a contactless EMV based transaction protocol, in accordance with embodiments of the present invention.

Detailed Description of the Invention

Figure 4 illustrates apparatus used in a preferred embodiment of the present invention. A token device 41 is powered by a terminal device 42. In embodiments of the present invention the token device 41 is powered by a terminal device token interface means, which in preferred embodiments may involve physical insertion of the token device 41 into the terminal device 42 interface means. In such embodiments it is envisaged that the token device 41 is provided with electrical contacts such that it may be powered by the terminal device 42 physical interface means. In alternative embodiments the terminal device token interface means may comprise a wireless interface means, wherein token device 41 is powered by an electro-magnetic field emitted by terminal device 42, wherein the field may operate in the radio frequency spectrum, the infra-red spectrum, the microwave spectrum, or any other electro-magnetic spectrum.

Token device 41 comprises an integrated circuit (IC), which comprises a data processing unit, and one or more memory units. In preferred embodiments the memory units may comprise volatile memory, non-volatile memory, and any other memory unit types. In certain embodiments the non-volatile memory may include read-only memory (ROM), and/or electrically erasable programmable read-only memory (EEPROM). The volatile memory may comprise random-access memory (RAM). It is envisaged that the token device 41 may comprise other forms of memory means not mentioned herein, and it is to be understood that such alternative memory types fall within the scope of the present invention.

In certain embodiments of the present invention token device 41 integrated circuit (IC) may additionally comprise any of the following: control logic, timer, input/output ports, security circuitry, and a co-processor. In such embodiments the control logic in conjunction with the processing unit provides a means for controlling communication between the input/output ports and any one of the aforementioned memory units.

In preferred embodiments the security circuitry, in conjunction with security functionality, provides protection against unauthorised access to internal data. Such circuitry and functions may include, but are not limited to, test function disablement, key usage limits, anti-tearing, clock frequency out of range detection, light detection, temperature detection and anti-glitch measures.

The co-processor provides the IC with a means for performing complex real-time calculations. In preferred embodiments such calculations may include cryptographic calculations. Terminal device 42 comprises at least a processor, volatile memory, non-volatile memory, input/output device, and an interface means for powering token device 41. A data communication means 48 exists between the token device 41 and the terminal device 42 when the token device 41 is being powered by the terminal device 42. In preferred embodiments the terminal device 42 interface means may, in addition to powering the token device 41, also provide for the communication means 48 by which token device 41 and terminal device 42 communicate via the exchange of data. In preferred embodiments communication means 48 may be a half-duplex communications channel, or alternatively a duplex communications channel.

Terminal device 42 may be connected via a communication means, which in preferred embodiments may be an external communication channel 44, to a remote transaction processing system. In preferred embodiments the remote transaction processing system comprises one or more of an acquiring bank transaction processing system 43, network transaction processing system 45, and an issuing bank transaction processing system 46. The skilled reader will appreciate that transaction data may travel across a wide range of interconnected networks operated by a variety of entities, and may include a central authority transaction processing system, and the network transaction processing system 45 is to be understood as encompassing such embodiments. It is envisaged that the one or more individual systems comprising the remote transaction processing system may have communications means 47, 49, 410 allowing any one of the individual systems to transmit data to any other one of the individual systems.

Figure 4 illustrates a preferred embodiment wherein a communication channel 47 is provided for between acquiring bank transaction processing system 43 and issuing bank transaction processing system 46, and/or communication channel 410 is provided between acquiring bank transaction processing system 43 and network transaction processing system 45.

Furthermore, a communication channel 49 may be provided between network transaction processing system 45 and issuing bank transaction processing system 46. The aforementioned communications means 47, 49, 410 may include one or more relaying or proxying data communications nodes routing data between the individual systems.

Figure 5 is a flow chart 500 illustrating a method of preventing relay attacks in accordance with a preferred embodiment of the present invention. In the present description reference is made to the apparatus of Figure 4. Terminal device 42 sends first dynamic data to token device 41, step 502. The dynamic data is unpredictable data, i.e. unpredictable in relation to previously transmitted instances of the same data such that the entropy of any cryptographically coded data using such unpredictable data as input data is sufficiently high such that guessing a result, even with knowledge of all previous outputs, is not feasible within a practical time period. The unpredictable data may be random or quasi-random data in embodiments of the present invention.

In preferred embodiments the terminal device 42 processor generates the first dynamic data, which is forwarded to terminal device 42 input/output port prior to sending to token device 41 via communication channel 48. A copy of the sent first dynamic data is stored, step 504, on terminal device 42 volatile memory, or other temporary storage facility accessible to terminal device 42.

Upon receipt of the first dynamic data, token device 41 stores the received first dynamic data, step 506, in its volatile memory, or other accessible temporary storage facility.

Second dynamic data, from token device 41, is sent to terminal device 42, step 508. In preferred embodiments the second dynamic data is generated by a token device 41 co-processor. The generation may be at any time between power up of token device 41 and the sending of the second dynamic data, or may be generated as a function of the previous transaction and stored in non-volatile memory for use when required. A copy of the sent second dynamic data is stored by token device 41, step 509. In preferred embodiments the second dynamic data is stored in token device 41 volatile memory, which may be in the RAM, or alternatively in other storage facilities readily accessible to the token device 41. A copy of the received second dynamic data is stored by the terminal device 42, step 510, in the terminal device volatile memory or other memory facility local to terminal device 42.

In preferred embodiments a timing characteristic is monitored, wherein the timing characteristic relates to a time difference between the sending of first dynamic data, step 502, and receipt of second dynamic data, step 508 at terminal device 42. In preferred embodiments, the monitoring of the timing characteristic is performed local to the terminal device 42. In preferred embodiments it is envisaged that the monitoring may involve comparison to a clock frequency signal local to terminal device 42. In preferred embodiments the monitored timing characteristic may relate to monitoring a time period threshold, and in particular monitoring whether a time period threshold has been exceeded by the monitored timing characteristic, step 512.

In embodiments where terminal device 42 is monitoring the timing characteristic, verification by the terminal device 42 of an exceeding of a time S period threshold initiates a terminal device 42 time-out procedure, step 514, whereby terminal device 42 conducts a time-out procedure, which may include, but is not limited to, termination of the transaction, step 516.

In alternative embodiments where the terminal device 42 is not monitoring the timing characteristic, it is envisaged that the device monitoring the timing characteristic would be responsible for conducting the time-out procedure, should the monitored time period threshold be exceeded, and either terminating the transaction or instructing terminal device 42 to terminate the transaction. In preferred embodiments of the present invention it is envisaged that the monitoring of the timing characteristic may occur within at least one of the layers of the communication protocol stack used by the terminal device 42.

In certain embodiments the communication protocol may be included in the transaction protocol. The selected communication layer for monitoring of the timing characteristic is at least partly dependent on the configuration of the particular communication protocol stack used by the terminal device 42. In certain embodiments the monitoring of the timing characteristic may be achieved by adjustment of the limits, or the suspension of, existing time-out or time extension features within the protocol stack. The adjustments or suspension may be limited to only during the command processing used to exchange the first dynamic data and the second dynamic data.

Returning to Figure 5, iii the event that the monitored timing characteristic time period threshold has not been exceeded, token device 41 sends transaction authentication data, step 518 to the terminal device 42. In preferred embodiments the transaction authentication data comprises cryptographically coded data, generated by the token device 41, and is used to authenticate a transaction. In preferred embodiments the cryptographically coded data may be generated by the token device 41 integrated circuit co-processor, and is forwarded to token device 41 input/output device prior to being sent to terminal device 42 via the shared communication channel 48. In certain embodiments the transaction may relate to a data transaction, or other transaction requiring authentication data.

In certain embodiments the cryptographically coded data is subjected to a cryptographic validation process, which is executed by the terminal device 42 in step 520. In alternative embodiments a remote transaction processing system, which may include an acquiring bank transaction processing system 43, an issuing bank transaction processing system 46, and a network transaction processing system 45, executes the cryptographic validation process in step 521.

In such embodiments the terminal device 42 sends the transaction authentication data to the remote transaction processing system 519 for execution of the cryptographic validation process.

In a preferred embodiment the cryptographically coded data, generated by token device 41, may relate to token authentication data, wherein the authenticity of the token device 41 is authenticated by the terminal device 42.

A failed cryptographic validation process results in the transaction being terminated. In preferred embodiments the terminal device 42 may terminate the transaction, step 524. In embodiments where the remote transaction processing system is executing the cryptographic validation process, the remote transaction processing system would send a command message to the terminal device 42 in the event of a failed cryptographic validation process, instructing the terminal device 42 to terminate the transaction, step 524.

The token device 41 may generate authentic cryptographically coded data, such coded data being data manipulated according to a cryptographic procedure, and may include a cryptogram, message authentication code or digital signature, or other such cryptographically coded data. A cryptographic procedure may involve at least either a cryptographic procedure comprising the use of asymmetric keys, and/or a cryptographic procedure comprising the use of symmetric keys.

Embodiments using cryptographic procedures comprising asymmetric keys, involve the use of a private-public key pair. In such embodiments it is envisaged that the cryptographically coded data is manipulated using a private key known only to token device 41. At least the private cryptographic key is securely stored in the token device 41 non-volatile memory. Terminal device 42 may validate the received cryptographically coded data utilising the corresponding public key known to the terminal device 42.

In embodiments where symmetric keys are used, it is envisaged that token device 41 and the remote transaction processing system share a symmetric key pair. The cryptographic keys are securely stored in the token device 41 non-volatile memory and in the remote transaction processing system. The terminal device 42 then forwards the cryptographically coded data for verification by the remote transaction processing system.

In alternative embodiments using symmetric keys it is envisaged that token device 41 and terminal device 42 share a symmetric key pair. The cryptographic keys may be securely stored in the token device 41 non-volatile memory and in a secure application module in the terminal device 42. Terminal device 42 may then use the known symmetric key to validate the received cryptographically coded data.

In alternative embodiments of the present invention cryptographic procedures utilising both symmetric and asymmetric keys may be used.

Successfully validated cryptographically coded data may result in the terminal device 42 proceeding with the electronic authentication system's remaining procedural steps, step 526.

In alternative embodiments of the present invention the cryptographically coded data is cryptographically related to at least the first dynamic data. In such embodiments the cryptographic validation process may be used to confirm that the monitored timing characteristic is representative of the token device 41 having validly taken part in the exchange of dynamic data.

The aforementioned cryptographically coded data may be generated by token device 41 applying a cryptographic process requiring either a symmetric or asymmetric cryptographic key, and in preferred embodiments may comprise performing a cryptographic process on selected data, which may at least partly include performing a cryptographic process on the first dynamic data received by token device 41, such that the cryptographically coded data is cryptographically related to at least the first dynamic data. In such embodiments, upon receipt of the transaction authentication data, comprising the cryptographically coded data, the terminal device 42 may decrypt the received cryptographically coded data, and may compare the decrypted first dynamic data at least partly contained in the cryptographically coded data, with a stored copy of the sent first dynamic data, which may be stored in a terminal device 42 volatile memory storage means, to thereby verify the cryptographic relationship, and on the basis of which confirming if the monitored timing characteristic is representative of the token device 41 having validly taken part in the exchange of dynamic data.

In alternative embodiments of the present invention, cryptographically coded data which is cryptographically related to at least the second dynamic data is received by terminal device 42, wherein the cryptographically coded data is generated by token device 41. In such embodiments the cryptographically coded data related to at least the second dynamic data is generated by a token device 41 integrated circuit in accordance with a cryptographic process. In such embodiments it is envisaged that the employed cryptographic process utilises an asymmetric key, wherein the cryptographically coded data has been signed by a private key known only to token device 41 generating a digital signature, and cannot be anticipated or forged by a relay attacker. Terminal device 42 is able to verify the signature of the received cryptographically coded data, which is a digital signature using a public key. The reader skilled in the art will appreciate that the digital signature serves to confirm the token device 41 as the sender of the cryptographically coded data related to at least the second dynamic data.

A timing characteristic relating to a time difference between the sending of the first dynamic data and receipt of the cryptographically coded data which is cryptographically related to at least the second dynamic data is monitored. If the monitored timing characteristic does not exceed a monitored time period threshold, then the token device 41 sends transaction authentication data to the terminal device for verification as in step 518 of Figure 5, wherein the transaction authentication data comprises cryptographically coded data which is cryptographically related to at least the first dynamic data, thereby confirming to the terminal device 42 that the token device 41 was the recipient of the first dynamic data and when taken together with the terminal device 42 received digital signature, confirming that the monitored timing characteristic is representative of the token device 41 having validly taken part in the exchange of dynamic data. In certain embodiments the digital signature is prepared prior to the token device 41 receiving the first dynamic data from the terminal device 42.

In yet a further embodiment of the present invention the cryptographically coded data cryptographically related to at least the second dynamic data is received as part of the transaction authentication data. In such embodiments the transaction authentication data comprises cryptographically coded data, which is cryptographically related to at least the first and second dynamic data. As with previously described embodiments the cryptographic validation process may be used to confirm that the monitored timing characteristic is representative of token device 41 having validly taken part in the exchange of dynamic data.

In preferred embodiments the monitored timing characteristic relates to a time difference between sending and receiving of dynamic data. In preferred embodiments only if the monitored timing characteristic does not exceed a monitored time period threshold (step 512, Figure 5), is the transaction authentication data sent from the token device 41 to the terminal device 42. The transaction authentication data comprises cryptographically coded data which is subjected to a cryptographic validation process upon receipt thereof by either the terminal device 42, or the remote transaction processing system, which may include comparing the cryptographically coded data cryptographically related to the first dynamic data, and in preferred embodiments is also cryptographically related to the second dynamic data, with the stored and sent dynamic data to verify that the cryptographic relationship is indicative of the faithful transmission, within the monitored timing characteristic, of the sent and received dynamic data between terminal device 42 and token device 41. In the event that a discrepancy is identified in the cryptographic relationship between the stored copy of the first dynamic data and the cryptographically coded data related to the first dynamic data, then terminal device 42 may infer that the terminal device generated first dynamic data was not faithfully transmitted to token device 41 in step 502. In such event the cryptographic validation process fails and terminal 42 terminates the transaction, step 524. Such a failed cryptographic validation process may be indicative of the presence of a relay circuit between the token device 41 and terminal device 42 as illustrated in Figure 1, intercepting and/or manipulating transmitted data.

In embodiments where the cryptographically coded data is cryptographically related to at least the first and second dynamic data, any identified discrepancy in the cryptographic relationship with either the stored first dynamic data or the stored second dynamic data, or both, indicates that the token device 41 may not have validly taken part in the exchange of dynamic data. As with the previously described embodiment any identified discrepancy in the cryptographic relationship may result in the terminal device 42 inferring that either the first dynamic data was not faithfully transmitted in step 502, and/or received in step 506, or second dynamic data was not faithfully transmitted in step 508, and/or received in step 510, or any combination of the described possibilities, and may be indicative of the presence of a relay circuit/attacker. In accordance with previously described embodiments any identified discrepancy in the cryptographic relationship with the stored dynamic data results in terminal device 42 terminating the transaction as illustrated in step 524 of Figure 5. A successful cryptographic validation process confirms that the monitored timing characteristic is indicative of the token device 41 having validly taken part in the exchange of dynamic data.

It is envisaged that the methods of the present invention may be incorporated into an existing electronic authentication system, by requiring the existing transaction authentication data present in such systems to use the exchanged dynamic data values, such that the transaction authentication data serves the dual purpose of authenticating a transaction and confirming the absence of a relay circuit between the terminal device 42 and the token device 41.

Figure 6 is a sequence diagram according to embodiments of the present invention, illustrating how a relay attack may be prevented in an electronic authentication system. After token device 41 has been powered on by the terminal device 42, a token device public key (Ptd) 60a is sent to the terminal device 42. The token device public key Ptd is used by terminal device 42 to verify any cryptographically coded data sent by token device 41 manipulated with token device 41 private key (Std). The token device public key Ptd may be sent to terminal device 42 at any time during the transaction to allow terminal device 42 to verify any cryptographically coded data present in the received transaction authentication data, signed with the token device 41 private key (Std).

In embodiments of the present invention it is envisaged that the token device public key Ptd is cryptographically manipulated prior to being sent, and may be sent as a digital certificate, wherein a cryptographic key different from the token device public key Ptd is required to validate the contents of the digital certificate.

This key may itself be presented as a certificate, as part of a certificate chain that culminates in a trusted root key. A root key, which may be a certificate public key, may be provided to terminal device 42 during manufacture.

First dynamic data 61a is sent from terminal device 42 to token device 41, and a copy of the first dynamic data is stored by terminal device 42. The sending of the first dynamic data 61 a initiates the monitoring of a timing characteristic by the terminal device 42. Upon receipt of first dynamic data 61 a, token device 41 stores a copy, and generates second dynamic data 61b which is sent to terminal device 42. Alternatively the second dynamic data may be generated by token device 41 prior to receiving the first dynamic data, thereby decreasing the token device 41 response time. The dynamic data is designed to be dynamically varied between each transaction so that the same data may not be replayed in different transactions, thus preventing so-called "replay attacks".

In preferred embodiments of the invention, the cryptographically coded data comprised in the transaction authentication data is cryptographically related to both the first dynamic data received by token device 41, and the second dynamic data sent by the token device, thereby validating the receipt of the first dynamic data by the token device 41 and the transmission by the token device of the second dynamic data in response to that receipt. Alternatively, the cryptographically coded data comprised in the transaction authentication data is cryptographically related to the first dynamic data received by token device 41 and not the second dynamic data -in such embodiments, the second dynamic data sent by the token device may be as accompanied by a digital signature, in which case 61b includes a digital signature cryptographically related to second dynamic data.

The received second dynamic data may be stored by terminal device 42.

Receipt by terminal device 42 of the second dynamic data, or alternatively of the digital signature containing the second dynamic data concludes the monitoring of the timing characteristic, which in particular embodiments may be conducted within a selected communication layer within the terminal device 42 adopted transaction protocol, and relates to a time difference between the sending and receiving of the dynamic data.

Embodiments where the second dynamic data is sent with a digital signature, may comprise the added procedure of the terminal device verifying the digital signature in relation to the second dynamic data, and should the verification fail, the transaction may be terminated. As previously stated the passing of a monitored time period threshold results in terminal device 42 conducting a time-out procedure 514 resulting in a transaction being terminated 516.

In preferred embodiments the time period threshold is variably selectable by the manufacturer of terminal device 42 and reflects the performance capabilities of all token devices expected to be presented to the terminal device 42.

In preferred embodiments the time period threshold is selected such that the time latency introduced by a relay circuit present between token device 41 and terminal device 42, causes a time difference between the sending of first dynamic data and the receiving of second dynamic data which is greater than the monitored time period threshold and similarly for embodiments where a digital signature containing the second dynamic data is sent in place of the second dynamic data. The monitored time period threshold is selected such that it is exceeded when a relay circuit is present, provided that the monitored timing characteristic is indicative of a round trip time relating to the sending of first dynamic data from the terminal device 42 to the token device 41, and to the receiving of token device 41 generated second dynamic data, or token device generated digital signature containing the second dynamic data, at terminal device 42.

The presence of a practical relay circuit placed between token device 41 and terminal device 42 would result in a failed monitored time period threshold, provided that the terminal device received second dynamic data is sent by token device 41 in response to receipt of the terminal device 42 issued first dynamic data. A relay attacker may attempt to simulate token device 41 by generating second dynamic data directly in the surrogate ICC, in response to receipt of intercepted terminal device issued first dynamic data, in which case the monitored time period threshold may not be exceeded, despite the presence of a relay circuit as the relay circuit is not introducing any time latency since the first dynamic data is not being relayed across it prior to the sending of the second dynamic data. However, in such a scenario the value of the second dynamic data is unlikely to be the correct value that would be sent by the genuine ICC, and this will become apparent to terminal device 42 during the cryptographic validation process. Similarly in embodiments where a digital signature of the second dynamic data is sent upon receipt of terminal device 42 sent first dynamic data, a relay attacker is highly likely to be unable to generate a valid digital signature, and therefore is unable to anticipate the token device 41 response.

A terminal device 42 generated transaction authentication data request 62a is sent to token device 41, provided the monitored time period threshold is not exceeded. Token device 41 generates transaction authentication data 62b comprising cryptographically coded data relating to at least the token device 41 received first dynamic data. In alternative embodiments the cryptographically coded data may relate to at least the token device 41 received first dynamic data and the token device 41 sent second dynamic data as mentioned previously. In prefelTed embodiments the cryptographically coded data comprised in the transaction authentication data is signed with a private key (Std) known only to token device 41, in which case the cryptographically coded data is a digital signature.

The cryptographically coded data, which may be a digital signature in prefelTed embodiments, is sent to terminal device 42 where it is subjected to a cryptographic validation process. The cryptographic validation process may involve terminal device 42 using Ptd to validate the received cryptographically coded data 62b to verify that the monitored timing characteristic is representative of the token device 41 having validly taken part in the exchange of dynamic data. In preferred embodiments this may verify that the cryptographic relationship is indicative of the faithful transmission, within the monitored timing characteristic, of the sent and received dynamic data. In embodiments where the cryptographically coded data is cryptographically related to at least the first dynamic data, the decrypted data may be compared to the terminal device 42 stored copy of the sent first dynamic data.

In embodiments where the cryptographically coded data 62b is related to at least the first and second dynamic data, then the validation process will utilise the terminal device 42 stored copy of the sent first dynamic data and received second dynamic data. Any inconsistency between stored copies of the dynamic data and dynamic data input to the cryptographically coded data will cause the validation process to fail and may indicate that token device 41 has not validly performed its part in the exchange of dynamic data. Such an identified inconsistency may be attributed to a relay circuit, placed between token device 41 and terminal device 42 as illustrated in Figure 1, where the identified inconsistency may be indicative of the presence of an attacker employing a relay strategy.

Figure 7 relates to alternative embodiments of the present invention wherein the transaction authentication data comprising cryptographically coded data is transmitted to a remote transaction processing system, where the cryptographic validation process is performed. In such embodiments the transmitting may comprise transmitting the transaction authentication data over a data communications network. Figure 7 is a sequence diagram illustrating how an alternative embodiment of the present invention may protect against a relay attack such as illustrated in Figure 1.

In these embodiments the cryptographic validation process may be conducted by separate apparatus. The monitoring of a timing characteristic is performed by the terminal device 42, whereas the cryptographic validation process is conducted by a remote transaction processing system, which in some embodiments may comprise one or more of the following: an acquiring bank transaction processing system 43; a network transaction processing system 45, in which the operator may be a central authority (CA); and an issuing bank transaction processing system 46. In embodiments where a remote transaction processing system conducts the cryptographic validation process a symmetric cryptographic key process may be used. In such an embodiment it is envisaged that the remote transaction processing system shares a symmetric cryptographic key pair with the token device 41, which may be provided for during manufacture of token device 41.

As with the embodiments described in relation to Figure 6, terminal device 42 generated first dynamic data is sent 71a to token device 41. A copy of the sent first dynamic data is stored on terminal device 42, and a copy of the received first dynamic data is stored on the token device 41. Token device 41 generated second dynamic data is sent 71b to terminal device 42, and stored by terminal device 42 upon receipt thereof Receipt of the second dynamic data concludes the monitoring of the timing characteristic and if the monitored time period threshold is exceeded, terminal device 42 initiates a time-out procedure, as described in previous embodiments.

Providing that the monitored time period threshold is not exceeded, then terminal device 42 sends a transaction authentication data request 72a to token device 41. As in previously described embodiments, token device 41 generates transaction authentication data comprising cryptographically coded data which is related to the first dynamic data and the second dynamic data, along with the remainder of the trans action details which are normally sent in the transaction authentication data.

The cryptographically coded data generated by the token device 41 is then transmitted to the terminal device 42, which transmits these data on to the remote transaction processing system. The terminal device 42 transmits other transaction data to the remote transaction processing system, in addition to the cryptographically coded data generated by the token device, namely the transaction details and the first and second dynamic data stored by the terminal device 42 during the timed exchange. The remote transaction processing system verifies the transaction authentication data which are cryptographically related to the first and the second dynamic data and the transaction data against the other data sent to it by the terminal device 42.

Alternatively, transaction authentication data comprising the cryptographically coded data may be related to the first dynamic data and not the second dynamic data. In this case the second dynamic data 7 lb may be sent with a cryptogram, encrypted with a symmetric key shared between the token device 41 and the remote transaction processing system. In such an embodiment the terminal device 42 cannot verify that the received cryptogram is cryptographically related to the second dynamic data, only the timing characteristic is monitored by the terminal device 42. The verification of the cryptogram is conducted by the remote transaction processing system.

As with previous embodiments the transaction authentication data is sent 72b to terminal device 42, however in these embodiments the remote transaction processing system performs the cryptographic validation process. The remote transaction processing system requires a means for verifying that the cryptographically coded data is cryptographically related to the dynamic data, and first and second dynamic data are sent along with the received transaction authentication data 72b comprising the cryptographically coded data, to the remote transaction processing system in step 73a.

In some embodiments it is envisaged that the first and second dynamic data are returned by token device 41 concatenated with the cryptographically coded data and taken as a whole for transmission to the remote transaction processing system.

In any case, the terminal device 42 compares the values of the first and second dynamic data received in the cryptographically coded data, with the values stored from the timed exchange. If the values do not match then the terminal device 42 performs exception processing, which may include, but is not limited to, termination of the transaction, plugging of the terminal device 42 stored values into the message 73a and/or flagging of the mismatch in the message 73a.

Receipt of the message 73a triggers the cryptographic validation process by the remote transaction processing system. This may comprise the remote transaction processing system re-computing the cryptographically coded data using the data presented in the message, including the values for the first and second dynamic data. Any inconsistency between the result and the cryptographically coded data from the token device 41 sent in the message 73a may be indicative of the presence of a relay circuit between the token device 41 and terminal device 42 as illustrated in Figure 1, intercepting and/or manipulating transmitted data. Furthermore, a successful cryptographic validation process confirms that the monitored timing characteristic has been respected. Response data 73b confirms success or failure of the cryptographic validation process and on the basis of the remote transaction processing system received response data 73b, the terminal device 42 may either proceed with the transaction or terminate the transaction.

Figure 8 shows embodiments of the present invention incorporated into an electronic authentication system using a representative EMV-based transaction protocol, such as those defined in the EMV 4.1 and 4.2 Specifications, the contents of which are incorporated herein by reference. The EMV 4.1 and 4.2 Specifications are publicly available and published by EMVCo LLC. Figure 4 illustrates the system elements comprised in such an electronic authentication system, with the token device 41 in this embodiment being an EMV-compliant ICC and terminal device 42 being an EMV-compliant point of service (PoS) terminal. In these embodiments the previously described remote transaction processing system may include one or more of an acquiring bank transaction processing system 43, a network transaction processing system 45, which may include a certification authority, and an issuing bank transaction processing system 46, all of which may be provided with communications means as illustrated in Figure 4, wherein it is understood that any one of communication channels 47, 49, and/or 410 may include one or more relaying or proxying data communications nodes as previously described. The present invention may be used in either contact or contactless authentication system embodiments, and such embodiments will be discussed in turn.

In contact authentication system embodiments the ICC 41 is inserted into an ICC reading means which may be physically contained within the PoS terminal 42, and the ICC 41 is provided with electrical contacts such that it may be powered by the PoS terminal 42 as previously described for the token device.

The PoS terminal 42 sends a SELECT command 81a to the ICC 41. ICC 41 responds with a SELECT command response 8 lb confirming support for the selected application. It is to be understood that this is the final SELECT command in the EMV application selection process, which may involve a sequence of SELECT commands using the Payments System Environment (PSE) or direct selection to build a candidate list from which is chosen the Application Identifier (AID) to be used.

In accordance with embodiments of the present invention it is envisaged that the PoS terminal 42 issued SELECT command may be at least partly comprised of first dynamic data. Sending of the SELECT command 81a begins the monitoring of the timing characteristic, and receipt of the SELECT response 8 lb concludes the monitoring of the timing characteristic, as described for previous embodiments. The PoS terminal 42 generated first dynamic data is stored in a writable memory facility accessible to the PoS terminal 42, in accordance with previously described embodiments. In embodiments of the present invention the first dynamic data may be unpredictable data generated by the PoS terminal 42.

Upon receipt of the SELECT command, the ICC 41 stores a copy of the received first dynamic data in a writable memory facility local to the ICC 41.

ICC 41 responds with a SELECT command response 81b, which contains, but is not limited to, an ICC 41 generated second dynamic data. In preferred embodiments the first dynamic data may be the EMV data element referred to as the "Unpredictable Number", and having Tag 9F37', which is generated by the PoS terminal 42 and the second dynamic data may be the EMV data element referred to as the "ICC Dynamic Number", and having Tag 9F4C', which is generated by the ICC 41.

If the exchange exceeds a monitored time period threshold, then the PoS terminal 42 conducts a time-out procedure whereby the transaction is terminated, as described in previous embodiments. In the event that the time period threshold is not exceeded then the procedure is continued, wherein the PoS terminal 42 continues with the next command.

Following receipt of the SELECT command response 8 lb, the PoS terminal 42 sends a GET_PROCESSING_OPTIONS (GPO) command 82a to the ICC 41, the purpose being to receive any particular processing options the ICC 41 may require which are to be used in conjunction with the PoS terminal 42 selected application. Such processing options may include a number of different card authentication methods (CAM) and transaction confirmation methods. Examples of CAM may include Static Data Authentication (SDA), Dynamic Data Authentication (DDA), and/or Combined DDA/Application Cryptogram (CDA). Examples of transaction confirmation methods may involve either offline confirmation or online confirmation. It should be noted that the aforementioned examples do not form an exhaustive list.

The ICC 41 increments its Application Transaction Counter (ATC) upon receipt of GPO command 82a. The ATC is an EMV data element which is used to keep count of the number of transactions conducted with an ICC 41, and is included in the cryptographic processing. The ICC 41 responds with GPO command response 82b, which may indicate processing options supported by the ICC 41, for example this may indicate to the PoS terminal 42 support for SDA, DDA, or CDA authentication methods, and/or whether to seek online or offline transaction confirmation. SDA and DDA are digital signature schemes used to verify the authenticity of an ICC 41 to the PoS terminal 42. SDA uses a static signature which is stored on the ICC 41 during manufacture and is constant for all transactions. DDA uses a dynamic signature which is generated by the ICC 41 for each separate transaction using one or more data generated by the PoS terminal 42, and/or the ICC 41. The digital signature is always different and unpredictable in transactions using DDA. CDA (Combined DDAiApplication Cryptogram Generation) is a method whereby the digital signature is dynamic, as in DDA however, the dynamic signature includes the Application Cryptogram for transmission to a remote transaction processing system for verification. CDA may be thought of as protecting the data to be used for remote verification from attacks such as those from wedge devices. In the current embodiment we will consider the scenario where DDA (Dynamic Data Authentication) is selected.

Following receipt of GPO response data 82b, the PoS terminal 42 issues a READ RECORD command 83a. It is to be understood that READ RECORD response 83b may contain data such as an issuer public-key certificate (CERTI), ICC public-key certificate (CERT ICC), a certification authority identifier, a private account number (PAN) and other data not mentioned herein, and such embodiments fall within the scope of the present invention. It is also to be understood that data may be variously distributed within ICC 41 and retrieved by the PoS terminal 42 using more than one READ RECORD command, and such embodiments fall within the scope of the present invention.

The one or more public-key certificates may be provided for during manufacture and are stored in the ICC memory (EEPROM). EMV compliant PoS terminals 42 are provided with one or more cryptographic keys specific to each different certification authority. The certification authority identifier identifies the certification authority the ICC 41 is associated with. On the basis of the certification authority identifier the PoS terminal 42 selects a cryptographic key associated with the identified certification authority, such that it may verify CERT I, and in the process recover an issuer public-key Pj. Pj is a public-key provided by the issuer, which may be the issuing bank. In embodiments of the present invention CERTI may be signed with a certification authority private key SCA.

Using the recovered issuer public-key P1 the PoS terminal 42 may verify CERT ICC, which is signed with an issuer private key Sj, thereby recovering an ICC public-key P1cc. The ICC public-key P1cc provides a similar function to the token device public-key Ptd described in previous embodiments. The PoS terminal 42 recovered P1cc is stored in a PoS terminal 42 volatile storage means, which may be for use in verifiying ICC 41 generated cryptographically coded data signed with the ICC 41 private key SICC. The ICC private key SICC provides a similar function as the token device private-key Std described in previous embodiments.

When cardholder verification, by means of PIN is required, the PoS terminal 42 requests entry of a PIN (personal identification number) from the ICC cardholder. The entered PIN is sent for verification to the ICC 41 in a VERIFY command 84a. In certain embodiments the PIN may be encrypted using the recovered ICC public-key P1cc such that only the ICC 41 in possession of SICC may verify the authenticity of the entered PIN. In alternative embodiments the ICC 41 may contain a ftirther digital certificate containing a public-key specifically for encryption of the entered PIN for verification by the ICC 41. The ICC VERIFY command response 84b may contain either a fail or success message in response to the VERIFY command 84a.

An ICC 41 response containing a failure message will result in the PoS terminal 42 requesting cardholder re-entry of the PIN. Additionally, a failed PiN verification will result in the ICC 41 recording a failed PiN verification in a failed PiN verification counter stored in a non-volatile storage means, which the skilled reader will recognise as being a common security feature of electronic authentication systems requiring cardholder PIN entry, thereby preventing brute force, and/or dictionary attacks.

Providing that the VERIFY command response 84b indicates a successfully verified entered PiN, PoS terminal 42 generates and sends an INTERNAL_AUTHENTICATE command 85a to ICC 41. In preferred embodiments 85a may contain authentication related data such as PAN, an ICC 41 identification number, a PoS terminal 42 identification number, and transaction time and date related information, for use by the ICC 41 in generating a digital signature. It is to be understood that the INTERNAL_AUTHENTICATE command 85a may contain other data not mentioned herein, and such embodiments fall within the scope of the present invention.

Upon receipt of the NTERNAL AUTHENTICATE command 85a, the ICC 41 generates transaction authentication data comprising cryptographically coded data. In the present embodiment the cryptographically coded data may be cryptographically related to both the previously received and stored first dynamic data, which may be the Unpredictable Number (Tag 9F37), and the previously generated and storedsecond dynamic data, which may be the ICC Dynamic Number (Tag 9F4C) stored in storage means local to the ICC 41. The cryptographically coded data may also be cryptographically related to the data received in the INTERNAL_AUTHENTICATE command 85a, which may be authentication related data. In a preferred embodiment the cryptographically coded data may be the Signed Dynamic Application Data (SDAD), colloquially referred to as the digital signature.

In preferred embodiments the SDAD may be generated by concatenating data contained in the INTERNAL AUTHENTICATE command 85a with the previously received and stored first dynamic data, namely the Unpredictable Number (Tag 9F37), and the previously generated and stored second dynamic data, namely the ICC Dynamic Number (Tag 9F4C). The concatenated data is hashed and then signed using Sjcc to generate Signed Dynamic Application Data (SDAD) 85b, which is sent to the PoS terminal 42.

Upon receipt of message 85b the PoS terminal 42 performs a cryptographic validation process on the cryptographically coded data, which may be a digital signature, using the ICC public-key Pjcc.

In preferred embodiments the cryptographic validation process may comprise verifying the authenticity of the signature, and confirming that the monitored timing characteristic is representative of the ICC 41 having validly taken part in the exchange of dynamic data. This may comprise verifying that the cryptographically coded data is cryptographically related to the PoS terminal 42 generated first dynamic data, and verifying that the cryptographically coded data is also cryptographically related to the ICC 41 generated second dynamic data.

In embodiments of the present invention the cryptographic validation process may comprise comparing the recovered hash value contained in the digital signature with a hash value re-calculated from the data input to the digital signature, including the copy of the PoS terminal 42 sent first dynamic data stored on the PoS terminal 42, and the PoS terminal 42 stored copy of the received ICC 41 generated second dynamic data. Furthermore a successful cryptographic validation process confirms that the timing characteristic is representative of the token device 41 having validly taken part in the exchange of dynamic data, and may confirm that the monitored timing characteristic is valid. Any identified inconsistency results in a failed SDAD verification and may be indicative of the presence of a relay circuit between the ICC 41 and PoS terminal 42 as illustrated in Figure 1. As with previously described embodiments, a failed cryptographic validation process may result in the PoS terminal 42 initiating a transaction termination procedure.

The PoS terminal 42 then proceeds with the online processing stage of the EMV-based transaction protocol, wherein the PoS terminal 42 generates and sends a 1st GENERATE AC command 86a for an ARQC (Application Request Cryptogram). The 1st GENERATE AC command 86a may include at least the following data: transaction amount, PoS terminal country code, PoS terminal verification results, transaction currency code, transaction date and transaction type. The ICC 41 generates an Authorisation Request Cryptogram (ARQC) 86b in response to the received command 86a.

The cryptogram generated may at least include as input: the ICC Application Interchange Profile; the ICC ATC number; the PoS terminal 42 generated first dynamic data, which may be Unpredictable Number (Tag 9F37), as stored in the ICC 41 memory facility; the ICC 41 generated second dynamic data, which may be ICC Dynamic Number (Tag 9F4C), as stored in the ICC 41 memory; and the data received in 86a.

In alternative embodiments the PoS terminal 42 generated first dynamic data may be included in the 1st GENERATE_AC command 86a, in which case the ICC 41 may compare this value to that stored in the ICC 41 memory and return exception status words if they are different, or may ignore the presence of the first dynamic data in the command data.

It is to be understood that the first and second dynamic data may be the previously generated PoS terminal 42 Unpredictable Number (Tag 9F37) and ICC 411CC Dynamic Number (Tag 9F4C), as previously used for the digital signature, if any, or newly generated first and second dynamic data. In the case of newly generated dynamic data the new dynamic numbers may be obtained using a fresh timed exchange. In preferred embodiments the ARQC message 86b is a message authentication code (MAC), produced with a symmetric key K which may be a session key. In preferred embodiments the symmetric key K is shared only by the ICC 41 and the issuer, which may be the issuing bank. In such embodiments only the issuing bank transaction processing system 46 may verify the ARQC message 86b. The PoS terminal 42 forwards the ARQC message 86b together with additional transaction data, to the issuing bank transaction processing system 46, which may include data messages 86c, 86d, and 86e.

In preferred embodiments the additional transaction data in message 86b includes at least the PoS terminal 42 generated first dynamic data as stored in the PoS 42 memory facility and the ICC 41 generated second dynamic data as stored in the PoS 42 memory. The issuer verifies the received ARQC 86e using its copy of the shared symmetric key K. Any identified inconsistency results in a failed verification and may be indicative of the presence of a relay circuit between the ICC 41 and PoS terminal 42 as illustrated in Figure 1. Furthermore a successful cryptographic validation process confirms that the monitored timing characteristic has been respected. The issuing bank transaction processing system 46 generates issuer authentication data which may either indicate that an ICC 41 requested transaction is being authorised or refused.

In some embodiments the issuer authentication data includes an ARPC (Application Response Cryptogram). The issuer authentication data message 86f is forwarded to the PoS terminal 41 in messages 86g and 86h. Upon receipt of the issuer authentication data message 86h the PoS terminal 41 generates and sends a 2'" GENERATE AC command 87a to the ICC 41.

In some embodiments the ICC 41 uses its shared symmetric key K to verify the received ARPC contained within the 2'" GENERATE AC command 87a. In alternative embodiments, the ARPC may be delivered in a separate EXTERNAL_AUTHENTICATE command preceding the 2'" GENERATE_AC command. If the transaction is being authorised as indicated in the received lAD, then the ICC 41 generates a transaction certificate (TC) response. In the event that the transaction is being refused a transaction refusal response is generated. The ICC 41 response 87b may be a MAC which is at least cryptographically related to the received issuer authentication data. In preferred embodiments an AAC (Application Authentication Cryptogram) is generated in the event that a transaction is being refused by the issuer as identified by ICC 41 from the issuer authentication data.

In accordance with embodiments of the present invention, in addition to minimising the risk of digital signatures being replayed to the PoS terminal 42, and resulting in a false verification of the authenticity of the ICC 41, the SDAD may minimise the risk of relay attacks by confirming that the monitored timing characteristic is representative of the ICC 41 validly playing a part in the dynamic data exchange, and that the ICC 41 is providing a response within the monitored time period threshold. This may be achieved by confirming that the monitored timing characteristic has been respected during the dynamic data exchange, and in particular that the monitored timing characteristic has not exceeded the monitored time period threshold. In the described embodiment the dynamic data exchange was incorporated into the SELECT command-response exchange.

In alternative embodiments of the present invention used in conjunction with contact electronic authentication systems using SDA (Static Data Authentication) and CAM (Card Authentication Methods), it is envisaged that the cryptographically coded data may be incorporated into the 1st GENERATE_AC command response -the ARQC 86b. The reader skilled in the art will appreciate that in SDA authentication a digital signature which is a Signed Static Application Data (SSAD) stored on the ICC 41 during manufacture, is used, wherein no provision is made for the inclusion of unpredictable data. Therefore in EMV-based transaction protocol embodiments where SDA authentication is used inclusion of received first dynamic data, and sent second dynamic data is restricted to the online cryptogram.

It should be understood that the described embodiments of the present invention may be used in EMV-based transaction protocols using CDA authentication. In such embodiments it is envisioned that the cryptographically coded data cryptographically related to first and second dynamic data may be included in the online cryptogram, the offline signature, or both. As with previously described embodiments the exchange of first and second dynamic data may occur in any one of the one or more SELECT command exchanges between ICC 41 and PoS terminal 42, and the time characteristic may be monitored as in previous embodiments.

Figure 9 is a sequence diagram illustrating embodiments of the present invention used in conjunction with a representative electronic authentication system utilising a contactless transaction protocol, such as one based on the EMV Contactless Specifications for Payment Systems, the contents of which are incorporated herein by reference. The Contactless Specifications for Payment Systems are publicly available and published by EMVCo LLC.

In embodiments of the present invention used in contactless electronic authentication systems, it is envisaged that the cryptographically coded data may be incorporated into the ICC 41 generated iNTERNAL AUTHENTICATE command response, which is the digital signature. In such embodiments there is no online transaction confirmation stage and there is no cardholder PIN verification procedure.

The labelling of all command-response data pairs appearing in Figure 9, which are shared with Figure 8, have been incremented by 100, and should be interpreted as referring to the same command-response data pairs. As such command-response pairs 181 a and 18 lb in Figure 9 refer to the same SELECT command-response pair 81a and 81b appearing in Figure 8. It is to be understood that the command-response exchanges and their sequences may vary, and any such permutations fall within the scope of the present invention.

Furthermore it is envisaged that the functionalities of the GPO command 1 82a and the INTERNAL AUTHENTICATE command 1 85a may be combined such that only a single exchange is required, and in such embodiments message 1 85b is the end response to 1 82a.

It should be understood that the VERIFY command-response pair are not featured in the contactless embodiments of the present invention, due to the absence of any PiN verification process in such embodiments, as may be seen from Figure 9. Furthermore, it should be observed that GENERATE AC command-response data pairs are not featured, due to the fact that online transaction confirmation and Transaction Certificate generation may be omitted in contactiess embodiments. In such embodiments the only authorisation process present is the CAM, which may be DDA, wherein the meaning is as previously defined. Contactless transaction protocols may also feature online authentication, and it is envisaged that the methods of the present invention may be used in such systems.

In contactless embodiments it is envisaged that the first dynamic data may be the Unpredictable Number generated by the PoS terminal 42 and the second dynamic data may be the ICC Dynamic Number generated by the ICC 41, both of which may be exchanged during the SELECT command-response exchange 181a and 18 lb. As in previously described embodiments, a timing characteristic is monitored relating to the time difference between the sending and receiving of the dynamic data. If a monitored time period threshold is exceeded the PoS terminal 42 initiates a time-out procedure whereby the transaction is terminated.

The transaction is only continued in the event that the monitored time period threshold is not exceeded. As with previously described embodiments, in preferred embodiments of the contactless authentication system the transaction authentication data may be a digital signature 85b comprising cryptographically coded data which may be cryptographically related to the first and second dynamic data, which in preferred embodiments may be the PoS terminal 42 generated Unpredictable Number and the ICC 41 generated ICC Dynamic Number. The cryptographic validation process may comprise digital signature verification, and confirming that the monitored timing characteristic is representative of the ICC having validly taken part in the exchange of dynamic data, by verifying that the cryptographically coded data is cryptographically related to the first dynamic data, and the second dynamic data, as described in previous embodiments.

In alternative embodiments of the present invention used in conjunction with contact or contactless electronic authentication systems, it is envisaged, and falls within the scope of the present invention that the sending and receiving of the first and second dynamic data may be incorporated into any suitable command-response data pair exchanged prior to the sending of the transaction authentication data comprising the cryptographically coded data. In certain embodiments this may require the dynamic data exchange to occur prior to the INTERNAL AUTHENTICATE command 85a. In alternative embodiments this may require that the dynamic data exchange occurs prior to the 1st GENERATE AC command 86a. In further alternative embodiments it is envisaged that an additional SELECT command-response data pair exchange may be incorporated into electronic authentication systems employing EMV-based transaction protocols. The purpose of such an additional SELECT command-response being to exchange the first and second dynamic data required for the monitoring of the timing characteristic, successful verification of which indicating the absence of a relay circuit between the token device and the terminal device. It is to be understood that the current invention can be applied to any command-response that transfers data in both directions (Case 4), including defined commands such as SELECT and any new commands of this nature including any specifically defined for the purpose of dynamic data exchange.

As mentioned in previous embodiments, the monitoring of the timing characteristic may occur within at least one of the layers of the communication protocol stack used by the transaction protocol. It is envisaged that the monitoring of the timing characteristic may occur in any one of the layers of the communication protocol stack present in the authentication systems. Typical authentication systems are comprised of the following communication layers: application layer, transport layer, data link layer, and physical layer. In prefelTed embodiments it is envisaged that the monitoring of the timing characteristic may occur in the application layer. In alternative embodiments it is envisaged that the monitoring of the timing characteristic occurs in the transport layer. In further alternative embodiments it is envisaged that the monitoring of the timing characteristic occurs as an interaction between properties of more than one layer of the communication stack.

In preferred embodiments where the monitoring of the timing characteristic occurs within the application layer, as previously mentioned, it is envisaged that the application layer is provided with a time monitoring means, which may comprise using the internal clock signal of terminal device 42 processor to monitor the time between sending first dynamic data, and receiving second dynamic data, and to initiate a time-out procedure should the monitored timing characteristic exceed a monitored time period threshold, as described in previous embodiments. In preferred embodiments it is envisaged that the application layer may initiate the monitoring as the first dynamic data is submitted to the transport layer, and terminates the monitoring upon receipt of the second dynamic data. In contact EMV authentication systems the minimum time interval between the leading edges of the start bits of the last data character received and the first data characters sent in the opposite direction is 16 ETUs (Elementary Time Units) for the T=0 protocol and 22 ETUs for the T=1 protocol, with the character frame for both protocols having a 10 ETU duration, thus there is a nominal 6 or 12 ETU time delay between the last bit transmitted by the terminal device 42, and the possible appearance of the first bit returned by the token device 41. In practice the time delay may be larger and the token device 41 may issue time-waiting extensions. In preferred embodiments of the present invention it is envisaged that a maximum time latency is prescribed, relating to the maximum time delay between sending of the first dynamic data and receiving of the second dynamic data, as measured from the leading edges of the start bits of the last data character sent in the command, to the leading edge of the start bit of the first character received, in the response data. It is further envisaged that the last data item in the command data is the first dynamic data and the first data item in the response data is the second dynamic data.

Such a maximum prescribed time delay may be the monitored time period threshold. Furthermore it is envisaged that any token device 41 requests for time-waiting extensions for returning the second dynamic data above the monitored time period threshold, will be reflised by the terminal device 42, thereby preventing a relay-attacker from requesting one or more time-waiting extensions to circumvent the monitored time period threshold.

In embodiments where the monitoring of the timing characteristic occurs as an interaction between properties of more than one layer of the communication stack it is envisioned that the application layer may set a code in the command Application Protocol Data Unit (APDU) causing a suspension of the normal long waiting time period and suspension of the automatic granting of wait time extension requests by the transport or data link layers. It is also envisioned that the normal long waiting time period is substituted with a shorter value equivalent to the monitored time period threshold value, for the duration of the dynamic data exchange.

In preferred embodiments the terminal application is not required to measure the lapsed time between sending and receiving of dynamic data, rather only the time period threshold requires monitoring. As such the specific time taken to send and receive dynamic data is not required, only whether the time taken was less than the monitored time period threshold value is known. A transaction may be terminated in the event that the time period threshold value is exceeded.

It is envisaged that the terminal device 42 internal processor clock frequency signal may be used to monitor the time period threshold value. The transaction is continued if the monitored time period threshold value is not exceeded by the sending and receiving of dynamic data. As mentioned in previous embodiments, the monitored time period threshold value is variably selectable. The time period threshold value is selected such that any additional time latency introduced by a relay circuit present between the token device 41 and the terminal device 42 will inevitably result in an exceeding of the monitored time period threshold. In preferred embodiments the monitored time period threshold value is selected to be as close to the minimum necessary time interval, as practically possible for the token device 41, and the terminal device 42 (in the absence of a relay circuit) to exchange data messages. In practice a significant number of the data exchanges between terminal device 42 and token device 41 will exceed the minimum time latency of 6 or 12 ETUs (dependent on whether a TO or T1 protocol is adopted), and insofar some leniency must be introduced into the selection of the monitored time period threshold value. The selection of time period threshold value may be conditioned by technology available to a relay attacker. The speed at which intercepted data may be relayed between terminal device 42 and token device 41 is dependent on the technology available to the relay attacker, and insofar one may select the value of the monitored time period assuming the relay attacker is in possession of the fastest possible communication means. As the speed of communications technology increases, the monitored time period threshold value may be reduced to take such technological advances into account. For example the fastest reported data transfer times for Wi-Fi communication channels is currently approximately 2Oms. Therefore a monitored time period threshold value of less than 2Oms is preferred, since passing of the monitored time period threshold is likely to occur if a relay circuit comprising a Wi-Fi communications channel is present. It is envisaged that the manufacturers of terminal devices, and or the network systems would be responsible for the periodic review of the monitored time period threshold value, thereby ensuring the value is consistent with the current state of communications technology. Such a solution is advantageous in that the longevity and security of current electronic authentication systems may be extended, resulting in a significant increase in the return on investment to the electronic transaction industry. Additionally the solution provided by the present invention is advantageous in that the monitored time period threshold value may be remotely updated using the present data communication infrastructure, by the manufacturer or network authority, at a significant cost savings to the electronic transaction industry.

Alternative transaction protocol embodiments of the present invention where monitoring of the timing characteristic is performed at the transport layer are advantageous in that the transport layer is already provided with intrinsic time management for the frame waiting time and the waiting time extension process. In accordance with a preferred embodiment of the current invention the intrinsic time management for the frame waiting time and the waiting time extension need to be controlled such that a time-out process is initiated when the monitored time period threshold is exceeded. In such embodiments it is envisaged that the transport layer issues a status message upon exceeding of the monitored time period threshold to the application layer such that the time-out process may be initiated. Furthermore, it is envisaged that the transport layer would reject any waiting time extension requests which would result in the monitored time period threshold being exceeded.

EMV-based transaction protocol systems provide for unpredictable data to be used in the digital signature authentication in DDA embodiments, and in the transaction confirmation phase. The inclusion of such unpredictable data is not originally intended for the purpose of preventing relay attacks, but it is envisaged that such existing unpredictable data may be used in accordance with the method of the present invention as the dynamic data. In such embodiments the first dynamic data may be the Unpredictable Number (Tag 9F37) generated by the PoS terminal 42 as provided for by existing EMV authentication systems.

Similarly the second dynamic data may be the ICC Dynamic Number (Tag 9F4C) generated by the ICC 41 as provided for in existing EMV authentication systems.

In these embodiments of the present invention, the Unpredictable Number (Tag 9F37), and ICC Dynamic Number (Tag 9F4C) may be exchanged prior to the receiving of transaction authentication data by the PoS terminal 42, and used without modification in the transaction authentication data, which may be included in the digital signature, or in the transaction confirmation request, which may be the ARQC, for online verification by the remote transaction processing system. The exchange of the unpredictable data may be included in any suitable command-response data pair as described in previous embodiments of the present invention.

The EMV transaction protocols wherein SDA is used do not provide for an ICC 41 generated dynamic data such as the ICC Dynamic Number (Tag 9F4C). In such embodiments it is envisaged that an ICC Dynamic Number (Tag 9F4C) may be generated for inclusion in the ICC generated cryptographically coded data, which may be the ARQC.

In alternative embodiments it is envisaged that a new data element may be defined to be exchanged and included in the ICC generated cryptographically coded data, which may be the ARQC. In further alternative embodiments it is envisaged that a command with GET_CHALLENGE like functionality can be used to perform the timed exchange and receive the second dynamic number from the ICC 41.

An advantage of the above described methods in accordance with the present invention using transaction authentication data cryptographically related to the first and second dynamic data, in providing protection against relay attacks, over the solutions proposed in the prior art is that the methods of the present invention may be incorporated into the existing authentication processes of existing electronic authentication systems without requiring the introduction of complex new cryptographic processes.

Although the foregoing description describes the cryptographically coded data as using symmetric or asymmetric cryptographic keys, it should be understood that any cryptographic means may be used, providing that the generated cryptographically coded data can be used to authenticate the token device having validly taken part in the exchange of dynamic data.

Furthermore, despite the foregoing description describing the cryptographic validation process being performed by the terminal device or by the remote transaction processing system, it is to be understood that any trusted apparatus and/or validation system may perform the cryptographic validation process, and within the context of the present invention it is not of significant importance whether such cryptographic validation is performed online or offline.

It is envisaged that the choice of apparatus and/or validation system performing the cryptographic validation process will be dependent on the arrangement of the apparatus of the electronic authentication system wherein the methods of the present invention are being applied. It is also envisaged that the methods of the present invention described herein may be incorporated into any electronic authentication system featuring an authentication protocol using data from the terminal device as an input to the cryptographic process conducted at the token device.

It should be understood that the token device may be in the form of a smartcard, a credit card having an integrated circuit thereon, a mobile telephony device, a PDA, and other devices.

The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

Claims 1. A method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by sending first dynamic data from said terminal device to said token device and receiving second dynamic data from said token device at said terminal device; monitoring a timing characteristic relating to a time difference between said sending and receiving during said exchange; and receiving cryptographically coded data generated by the token device after said monitored exchange has taken place, wherein said cryptographically coded data is cryptographically related to both said first dynamic data and said second dynamic data such that a cryptographic validation process may be used to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.
2. A method according to claim 1, wherein the method comprises preventing relay attacks in a transaction authentication system, the method comprising transmitting transaction data from said terminal device, and wherein said cryptographically coded data is cryptographically related to said transaction data in addition to said first dynamic data and said second dynamic data.
3. A method according to claim 1 or 2, comprising transmitting said cryptographically coded data over a data communications network to a remote authentication processing system capable of performing said cryptographic validation process to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.
4. A method according to claim 3, comprising storing said first and second dynamic data at said terminal device when performing the exchange of dynamic data, and transmitting said stored dynamic data to said remote authentication processing system to enable validation of said cryptographically coded data against said stored dynamic data in the remote authentication processing system.
5. A method according to claim 1 or 2, comprising performing said cryptographic validation process at said terminal device to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.
6. A method according to claim 5, comprising performing said cryptographic validation process at said terminal device by storing said first and second dynamic data at said terminal device when performing the exchange of dynamic data, and validating said cryptographically coded data against said stored dynamic data after receipt of said cryptographically coded data.
7. A method according to claim 5 or 6, comprising said terminal device declining to accept the authenticity of the token device if said cryptographic validation process does not confirm said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.
8. A method according to any preceding claim, comprising said terminal device conducting a time-out procedure if the receiving of second dynamic data from said token device at said terminal device exceeds a monitored time period threshold.
9. A method according to any preceding claim, wherein the token device is capable of requesting, and the terminal device is capable of granting, a time extension in relation to a response time period, the method comprising the terminal device processing a time extension request in relation to said monitored timing characteristic differently to another time extension request.
10. A method according to any preceding claim, wherein said cryptographically coded data is in the form of a cryptographic code produced with a symmetric cryptographic key.
11. A method according to any of claims 1 to 9, wherein said cryptographically coded data is in the form of a digital signature produced with an asymmetric cryptographic key.
12. Terminal apparatus adapted to conduct the method of any preceding claim.
13. A method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by receiving first dynamic data from said terminal device at said token device and sending second dynamic data from said token device to said terminal device, such that a timing characteristic relating to said exchange may be monitored by said terminal device; storing said first and second dynamic data at said token device when performing the exchange of dynamic data; generating cryptographically coded data by taking said stored first dynamic data and said second dynamic data as inputs to a cryptographic process; and sending the cryptographically coded data from the token device to the terminal device after said monitored exchange has taken place, wherein said cryptographically coded data is cryptographically related to both said first dynamic data and said second dynamic data such that a cryptographic validation process may be used to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.
14. A method according to claim 13, wherein the method comprises preventing relay attacks in a transaction authentication system, the method comprising receiving transaction data from said terminal device, and generating said cryptographically coded data by taking said transaction data, in addition to said first dynamic data and said second dynamic data, as an input to said cryptographic process.
15. A method according to claim 13 or 14, wherein said cryptographically coded data is in the form of a cryptographic code produced with a symmetric cryptographic key.
16. A method according to claim 13 or 14, wherein said cryptographically coded data is in the form of a digital signature produced with an asymmetric cryptographic key.
17. A token device adapted to conduct the method of any of claims 13 to 16.
18. An authentication processing system comprising terminal apparatus according to claim 12, and a token device according to claim 17.
19. A method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by sending first dynamic data from said terminal device to said token device and receiving second dynamic data from said token device at said terminal device; monitoring a timing characteristic relating to a time difference between said sending and receiving during said exchange; and receiving transaction authentication data from said token device at said terminal device, said transaction authentication data comprising cryptographically coded data generated by the token device to authenticate a transaction, wherein said cryptographically coded data is cryptographically related to at least said first dynamic data such that a cryptographic validation process may be used to confirm that said timing characteristic is representative of said token device having validly taken part in the exchange of dynamic data.
20. A method according to claim 19, wherein said method comprises receiving cryptographically coded data which is cryptographically related to at least said second dynamic data.
21. A method according to claim 20, wherein said cryptographically coded data which is cryptographically related to at least said second dynamic data is received as part of said transaction authentication data.
22. Terminal apparatus adapted to conduct the method of any of claims 19 to 21.
23. A method of preventing relay attacks between a terminal device and a token device in an electronic authentication system, comprising: performing an exchange of dynamic data by receiving first dynamic data from said terminal device at said token device and by sending second dynamic data from said terminal device to said terminal device in response to receiving said first dynamic data; generating transaction authentication data, said transaction authentication data comprising cryptographically coded data generated by the token device to authenticate a transaction; and sending said generated transaction authentication data to said terminal device, wherein said cryptographically coded data is cryptographically related to at least said first dynamic data such that a cryptographic validation process may be used to confirm that a timing characteristic, monitored by said terminal device, is representative of said token device having validly taken part in the exchange of dynamic data.
24. A method according to claim 23, comprising: generating cryptographically coded data which is cryptographically related to at least said second dynamic data; and sending said cryptographically coded data which is cryptographically related to at least said second dynamic data to said terminal device.
25. A method according to claim 24, wherein said cryptographically coded data which is cryptographically related to at least said second dynamic data is sent as part of said transaction authentication data.
26. A method according to any of claims 23 to 25, comprising means for generating said second dynamic data prior to receiving said first dynamic data.
27. A token device adapted to conduct the method of any of claims 23 to 26.
28. A transaction processing system comprising terminal apparatus according to claim 22, and a token device according to claim 27.