Patent Publication Number: US-8113435-B2

Title: Card reader

Description:
CROSS-REFERENCES TO RELATED APPLICATIONS 
     This application claims the benefit of and is a non-provisional of U.S. Provisional Application 61/147,951 filed on Jan. 28, 2009, which is assigned to the assignee hereof and incorporated herein by reference for all purposes. 
    
    
     BACKGROUND 
     The present application relates generally to communications and, more particularly, to communication with contactless smartcards. 
     Contactless smartcards are widely used to purchase goods and services. For example, it is now possible to pay for gasoline, groceries, and transit fares simply by waving a contactless smartcard in the vicinity of a card reader. Contactless smartcards provide the cardholder with a quick and convenient way to transfer value and often can be recharged or otherwise linked to a line of credit. 
     A contactless smartcard communicates with a card reader using electromagnetic radiation. Card transactions often involve an over-the-air exchange of sensitive information such as account numbers and card identifiers. These exchanges are susceptible to eavesdropping which can lead to hacking the smartcard or the theft of its value. 
     Data encryption can help to reduce the incidence of hacking attacks. However, encryption algorithms can be cracked and are susceptible to unforeseen weaknesses. Moreover, a large body of unencrypted or weakly encrypted cards is currently in circulation. 
     BRIEF SUMMARY 
     A card reader system, method, apparatus, and computer program product are disclosed. The card reader can include a transmitter that modulates a radio frequency carrier with a transmit data signal and a receiver that detects a modulation of the radio frequency carrier by a contactless smartcard. A processor can be coupled to the transmitter and the receiver. The processor can generate the transmit data signal so as to simulate a data exchange according to a protocol of the contactless smartcard. The processor can determine a timing for reading data from or writing data to the contactless smartcard and can discontinue the simulated data exchange based on the timing. 
     In one embodiment, a card reading device is disclosed. The card reading device includes a transmitter configured to modulate a radio frequency carrier of the card reading device with a transmit data signal. The card reading device also includes a receiver configured to detect a modulation of the radio frequency carrier by a contactless smartcard. A processor is coupled to the transmitter and the receiver. The processor is configured to generate the transmit data signal so as to simulate a data exchange according to a protocol of the contactless smartcard. During a period of the simulated exchange, the transmit data signal can include first data representative of outbound communications from the card reading device and second data representative of modulation of the carrier by a contactless smartcard. The processor can be configured to determine a timing for communication with the contactless smartcard and to discontinue the simulated data exchange based on the timing. 
     In another embodiment, a method of operating a card reading device is disclosed. The method includes modulating a radio frequency carrier of the card reading device with first data according to a communication protocol of a contactless smartcard. The method also includes modulating the carrier with second data generated by the card reading device which represents a simulated response to the first data according to the communication protocol. The method further includes initiating a data exchange with the contactless smartcard at a timing determined by the card reading device. Modulating the carrier with the second data can include modulating the carrier at a sub-carrier frequency and adjusting the modulation characteristics to simulate the capabilities of the contactless smartcard. 
     In yet another embodiment, a computer readable medium encoded with data and program instructions for execution by a processor is disclosed. The instructions can cause the processor to control operation of a card reader and to perform steps of modulating a radio frequency carrier of the card reader with a first data sequence representative of outbound communications by the card reader. The steps also include adjusting the modulation characteristics of the radio frequency carrier so as to mimic a modulation of the carrier by a contactless smartcard. The steps can also include modulating the radio frequency carrier with a second data sequence representative of a communication from the contactless smartcard using the adjusted modulation characteristics. 
     In a further embodiment, a method of protecting an exchange between a card reader and a contactless smartcard is disclosed. The method includes modulating a radio frequency carrier of the card reader with a first data sequence and determining the timing of an expected response to the first data sequence based on a protocol of the contactless smartcard. The method includes modulating the radio frequency carrier at a sub-carrier frequency used for communication by the contactless smartcard with a second data sequence prior to the time of the expected response, wherein the second data sequence is unrelated to communication with the contactless smartcard. The method can also include modulating the carrier at the sub-carrier frequency with a third data sequence comprising jamming data generated by the card reader to coincide with the time of the expected response. 
     Additional aspects of the invention will become apparent from the following description and the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows an embodiment of a card reader system. 
         FIG. 2  is a block diagram of an embodiment of a card reading device. 
         FIGS. 3A-3B  show an operation of the card reading device in which simulated inbound data is added to a card transaction. 
         FIG. 4  shows aspects of a simulated exchange performed by the card reading device. 
         FIG. 5  illustrates exemplary card functionality in relation to which the card reading device can perform a simulated data exchange. 
         FIG. 6  shows an interaction between the card reading device and a contactless smartcard. 
         FIG. 7  illustrates aspects of a jamming countermeasure of the card reading device. 
         FIG. 8  shows one embodiment of a process of the card reading device. 
     
    
    
     DETAILED DESCRIPTION 
     The ensuing description provides preferred exemplary embodiment(s) only, and such preferred exemplary embodiments are not intended to limit the scope or applicability of the present invention. Rather, the ensuing description will enable those who are skilled in the art to implement such preferred exemplary embodiment(s). Persons of skill in the art will recognize that various changes may be made in the function and arrangement of elements without departing from the scope of the invention as it is set forth in the appended claims. 
       FIG. 1  shows a card reader system  100  according to one embodiment of the present invention. As illustrated, card reader system  100  includes a card reader  110  and a contactless smartcard  120 . Card reader system  100  can be used for ticketing or similar transactions in which a contactless smartcard is presented to a card reader to gain access to services. For example, card reader system  100  can be located at a transit station gate for admitting passengers to the transit system. Of course, card reader system  100  is not limited to a particular application but can include any exchange of data between a smartcard and a card reader. Other applications of card reader system  100  can include sales transactions with contactless credit cards as well as access control and security systems. 
     Card reader  110  and contactless smartcard  120  (also referred to as “card” or “smartcard”) communicate wirelessly. Communication between the devices can be according to a contactless smartcard (CSC) protocol. The CSC protocol can be standards-based or proprietary. For example, the CSC protocol can be based on the ISO 14443 standards for proximity cards. Within the ISO 14443 standards, a contactless smartcard can be further defined as a Type A or Type B based on the manner in which it communicates. 
     Alternatively, the CSC protocol can be as described in the EMV standard (Europay, MasterCard, and Visa), or some other industry standard for contactless smartcard communications. In some embodiments, the CSC protocol can be proprietary or can include proprietary elements such as commands and data structures. For example, contactless smartcard  120  can be a Mifare® Ultralight or Mifare® Classic card from NXP Semiconductor and card reader  110  can be configured to communicate using commands and data structures which are appropriate for such cards. 
     Contactless smartcard  120  is shown as including an antenna  160  and an integrated circuit  170 . Antenna  160  can be tuned to a carrier frequency of card reader  110 . For example, with ISO 14443 cards, antenna  160  can be a magnetic loop antenna that has been adapted for use with a 13.56 MHz carrier. Integrated circuit  170  is coupled to antenna  160  and can be powered by energy from the radio frequency carrier. In operation, card  120  can communicate with card reader  110  through modulation of the RF carrier. For example, Type A cards can send data to card reader  110  by load-modulating the RF carrier at 847 kHz sub-carrier frequencies (i.e., 12.71 MHz, 14.41 MHz). 
     Integrated circuit  170  can also implement the CSC protocol which governs communication with card reader  110 . Typically, integrated circuit  170  includes a memory or other storage for retaining card data. Data exchanges between devices can be based on precision pulse timing in which contactless smartcard  120  receives a command from card reader  110  and responds to the command at a precisely determined time specified by the CSC protocol. “Exchanges” in card reader system  100  can involve detecting the presence of the smartcard  120  at the card reader  110 , mutual authentication based on a key-exchange, as well as reading data from and writing data to the card&#39;s storage. As used herein, “transaction” can refer to a series of one or more exchanges between smartcard  120  and card reader  110 . Transactions can be described as successful when the exchanges proceed normally, or as failed when the exchanges are halted such as through communication errors, invalid commands, unsuccessful authentication, and the like. 
     Card reader  110  is shown as having an RF interface  130 , a CSC protocol controller  140 , and a countermeasures processor  150 . RF interface  130  can include transmit and receive circuitry for communicating with contactless smartcard  120 . For example, RF interface  130  can include a transmitter that modulates the RF carrier with transmit data and a receiver that detects inbound data from smartcard  120 . In an exemplary embodiment, card reader  110  is a multi-protocol device similar to the Tri-Reader® family of products from Cubic Transportation Systems, Inc. 
     In some embodiments, CSC protocol controller  140  sources the outbound (transmit) data to RF interface  130  and RF interface  130  modulates the RF carrier based on the outbound data it receives. CSC protocol controller  140  can include one or more programmable logic elements such as microprocessors, microcontrollers, field-programmable gate arrays (FPGA), application-specific integrated circuits (ASIC), complex programmable logic devices (CPLD), and the like. CSC Protocol controller  140  can also be configured to determine a precise timing of communications based on the CSC protocol of smartcard  120  and to direct the exchange of commands and data. 
     RF interface  130  can also detect inbound communications from smartcard  120 . For example, Type A cards can load-modulate the RF carrier with Manchester coded data at predetermined sub-carrier frequencies. Type B cards communicate with the card reader  110  by phase-modulating the carrier. CSC protocol controller  140  can be configured to detect the type of card and to demodulate the inbound (receive) data based on the CSC protocol utilized. Depending upon the CSC protocol, CSC protocol controller  140  can also determine an expected timing and content of card responses. 
     Countermeasures processor  150  (“processor”) coordinates the operation of CSC protocol controller  140  and RF interface  130  to counter eavesdropping on exchanges with smartcard  120 . Although shown separately, the functions of processor  150  and CSC protocol  140  may be performed by common hardware. For example, with Mifare® Classic cards, processor  150  may include a proprietary cryptography module used in connection with key exchanges and similar operations. 
     Processor  150  can be configured to counter snooping or hacking attacks on card transactions by generating false triggers and obfuscating the exchange of data. In one embodiment, processor  150  generates data to simulate both sides of a card transaction. For example, processor  150  may cause CSC protocol controller  140  to initiate communication with a non-existent smartcard. Processor  150  can direct CSC protocol controller  140  and RF interface  130  to modulate the RF carrier with outbound data such as a wake-up command or a card selection command for the non-existent card. 
     Processor  150  can also direct CSC protocol controller  140  to simulate a response from the non-existent card. This can involve causing RF interface  130  to amplitude modulate the RF carrier so as to mimic inbound data from the non-existent card. With Type A cards, for example, RF interface  130  can amplitude modulate the 13.56 MHz RF carrier at the 847 kHz sidebands and do so with modulation characteristics which approximate the operation of an actual smartcard. All data in the simulated exchange can conform to requirements of the CSC protocol, but it may be fictitious in nature and therefore worthless to a hacker. After a predetermined time, the simulation can be discontinued and card reader  110  can initiate an actual transaction with smartcard  120 . The duration of the simulated exchange can be varied for each card that is presented at the card reader  110 . 
     Processor  150  can also exploit characteristics of the CSC protocol to frustrate attempts at eavesdropping on communications with smartcard  120 . For example, with MiFare® cards, a timing of the card&#39;s response following a command can be precisely known. After a command is issued, card reader  110  will have the opportunity to simulate inbound data that is irrelevant to the transaction, without disturbing the signal from the card 
     From an eavesdropper&#39;s perspective, card reader  110  greatly increases the difficulty of intercepting and analyzing a card transaction. Beyond creating a large number of false triggers, an eavesdropper cannot assume that data at a given position in a transaction has a particular significance. Such data may be part of a simulated transaction or it may be entirely irrelevant to the transaction. Similarly, data obtained by eavesdropping may be the result of an invalid command or it may be bogus keying material. Processor  150  can be configured to vary the “suite” of countermeasures employed each time a card is presented at card reader  110 . Thus, presenting the same card twice will not reduce the complexity of snooping on a transaction. 
       FIG. 2  is a block diagram of a card reading device (“card reader”)  200  according to one embodiment of the present invention. Card reader  200  can be similar to card reader  110  and can function as part of card reader system  100  in the manner previously described. 
     As shown, card reader  200  communicates using antenna  210 . Antenna  210  can include a tuning circuit and a coil. The tuning circuit can include a variable capacitance or like elements with which to adjust a resonant frequency of antenna  210 . For example, antenna  210  can be tuned to operate at 13.56 MHz for ISO 14443 cards or to some other frequency when implementing different CSC protocols. 
     Antenna  210  is coupled to a transmitter  230 . Transmitter  230  can include an oscillator and can drive antenna  210  to produce the RF carrier. Transmitter  230  can also be coupled to a modulation controller  240  and a scheduler  250 . Modulation controller  240  can output a supply voltage and can determine a level of the RF carrier, a type of modulation, and a modulation level of the transmit signal. For example, when communicating with Type A cards, transmitter  230  can modulate the RF carrier with the transmit data using an on-off keying (100% modulation). With Type B cards, modulation of the RF carrier can be determined by a modulation index and typically ranges from around 8%-15%. 
     IF Filter  220  is disposed between antenna  210  and transmitter  230 . Filter  220  can operate at different frequencies as determined by an input select signal. In the embodiment shown, these operating points include the 13.56 MHz carrier frequency and a 14.41 MHz sideband. Of course, different frequencies can be used with different card types. The intermediate frequency output of filter  220  can be rectified by a diode detector  280  and delivered to a receiver  290 . Receiver  290  can demodulate the rectified IF signal to produce receive data. A select input to receiver  290  can specify the type of demodulation to be performed. For example, amplitude modulation for Type A cards or phase modulation for Type B cards. A level detector  295  coupled to receiver  290  can automatically adjust the receive data signal for use by processor  260 . 
     Processor  260  can control the overall operation of card reader  200  and may include a microprocessor, microcontroller, field-programmable gate array, application-specific integrated circuit, complex programmable logic device, or like hardware elements. Processor  260  can be configured to execute fixed or programmable instructions in connection with implementing the CSC protocols, eavesdropping countermeasures, and other functions of card reader  200 . 
     Processor  260  can be coupled to one or more storage elements  270 . Storage elements  270  can include random access memory (RAM), read-only memory (ROM), flash memory, hard disk drives, optical drives, and other computer-readable storage media encoded with data and program instructions that are accessible to processor  260 . In one specific embodiment, the present invention includes a computer program product comprising a computer-readable storage medium encoded with instructions for carrying various of the operations described herein. 
     Processor  260  can send outbound data to transmitter  230  on a transmit path that includes scheduler  250 . Scheduler  250  can receive the transmit data from processor  260  and schedule it for transmission. Processor  260  can also determine a type of modulation to be applied to the transmit data and a modulation index by signaling to modulation controller  240 . By adjusting the modulation index and the type of modulation, processor  260  can implement different CSC protocols for conducting card transactions as well as a range of eavesdropping countermeasures. 
     In one embodiment, the modulation type output specifies whether transmitter  230  should treat the transmit data as outbound data or as simulated inbound data. Outbound data can be used to amplitude modulate the RF carrier frequency according to the modulation index value. When the modulation type indicates simulated inbound data, transmitter  230  can modulate the transmit data so as to mimic a card response. For example, when it is desired to simulate inbound data from a Type A card, transmitter  230  can modulate the RF carrier at an appropriate sub-carrier frequency. Alternatively, with Type B cards, phase-modulated data can be simulated. When simulating inbound data, the modulation index can be used to reduce the modulation level of the simulated data to approximately 5% of the carrier or some other value that is consistent with the capabilities of an actual smartcard. 
       FIGS. 3A-3B  illustrate an eavesdropping countermeasure such as can be employed by card reader  200 . For purposes of discussion, a Type A card transaction will be illustrated in the following examples. However, similar principles can be used with Type B cards as well as with various proprietary CSC protocols. 
     In  FIG. 3A , item (a) shows the RF carrier which powers the Type A smartcard and serves as the communication medium for the card transaction. Item (b) shows outbound transmit data from processor  260  which can, for example, be a wake-up or other command. Based on the CSC protocol, processor  260  determines that a smartcard will respond after interval Δt. For example, with some Mifare® cards, the response to a wake-up (WUPA) command is expected approximately 80 μs after the command is issued. In that case, a countermeasure lasting up to 80 μs can be inserted before the expected response time. 
     As shown, the RF carrier in item (a) is modulated with transmit data (b) using a modulation index of approximately 100% to create a type of on-off keying. The card responds to the transmit data (b) following interval Δt by load modulating RF carrier (a). This is illustrated by small changes or ripples in the RF carrier. The receive circuitry of card reader  200  filters and demodulates the card-data. Item (c) depicts demodulated and level-adjusted receive data such as can be delivered to processor  260 . 
       FIG. 3B  shows an eavesdropping countermeasure employed during the interval Δt. The eavesdropping countermeasure occurs after outbound transmit data (b) is sent but before the arrival of the expected card response represented by receive data (c). During the interval Δt, processor  260  adjusts the modulation type and modulation index at modulation controller  240  and produces simulated inbound data. Item (d) shows the simulated inbound data with Manchester coding such as might be used with a Type A countermeasure. Item (e) shows modulation of the simulated inbound data at the 847 kHz sub-carrier such as can be produced by transmitter  230 . Lastly, item (f) shows a part of the RF carrier that is modulated with the simulated inbound data. Thus, during the interval Δt, an eavesdropper is presented with a series of false triggers and with simulated card data that originates from card reader  200 . 
       FIG. 4  illustrates an exemplary operation of card reader  200  involving a series of simulated exchanges. In the figure, card reader  200  simulates data exchanges with a non-existent card. Card reader  200  can generate the simulated data exchanges before, during, or after an actual smartcard is presented. For example, simulated exchanges before and after an actual card is presented increase the difficulty of identifying the start of an actual card transaction and of isolating card data. As discussed herein, simulated exchanges can also be initiated during a transaction with an actual card by issuing a HALT command or some other command sequence known to disable smartcard communications. In this way, simulated exchanges can be generated while the actual card is idle or halted. 
     Outbound transmissions (TX-OUT) represent card reader command sequences. The command sequences may or may not correspond to valid commands of the CSC protocol but will typically have the same physical characteristics as actual card reader commands. For example, commands (C 1 , C 2 , C 3 ) for Type A cards will be expressed with on-off keying of the RF carrier whereas commands (C 1 , C 2 , C 3 ) for Type B cards will be expressed by amplitude modulation with the appropriate modulation index. As a result, outbound transmissions (TX-OUT) used in the simulated exchanges are largely indistinguishable at the physical level, and possibly at the logical level, from commands used to communicate with an actual smartcard. 
     Simulated inbound transmissions (TX-IN-SIM) likewise may or may not correspond to valid card responses, but will typically have the same physical characteristics as actual responses. For example, with Type A cards, the simulated inbound transmissions can have a modulation index corresponding to the load modulation level of an actual card and can use a modulation type specifying an appropriate sub-carrier frequency. 
     In the present example, processor  260  orchestrates the simulated exchanges by transmitting command C 1  with a modulation index and modulation type corresponding to signals from the card reader. Processor  260  then changes the modulation type and modulation index to reflect a card response and schedules data for response R 1 . After interval Δt 1 , card reader  200  simulates inbound data by modulating the RF carrier with the data for response R 1 . Response R 1  may or may not be related to command C 1 . For example, command C 1  could be a request command (REQA) to a Mifare® Ultralight card and response R 1  could include a simulated card identifier. Alternatively, C 1  and R 1  could represent portions of a key exchange in which R 1  comprises bogus keying material. In some embodiments, card reader  200  can be configured to detect bogus keying material offered during an actual card exchange and to generate an alarm. 
     Processor  260  changes the modulation type and modulation index back to values corresponding to the card reader and schedules a second command C 2  for transmission. After the interval Δt 2 , card reader  200  transmits command C 2 . This process is then repeated for the second response R 2  and the third command C 3 . Processor  260  can be configured to vary the length and timing of the simulated exchange for each card detected at card reader  200 . In this way, the card transaction is made unpredictable to an eavesdropper. 
     Simulated exchanges can also be initiated after a card is physically presented at card reader  200 . In such cases, it may be desirable to suspend operation of the card while the simulated exchanges are played out and to reactivate the card at a timing that is determined by the card reader. Card reader  200  can suspend and resume card operation based on the CSC protocol and the internal operation of card devices. 
       FIG. 5  is a state diagram  500  of exemplary smartcard functionality which can be manipulated by card reader  200  in conducting a simulated data exchange. State diagram  500  is similar to that of a one type of Mifare® card and will therefore be discussed in terms of the Mifare® command set. However, it will be understood that the present disclosure is not limited to Mifare® cards, but can be implemented at card reader  200  in connection with other standards-based or proprietary CSC protocols and cards. 
     In this exemplary case, when the card is first activated, it transitions from a power-on reset state POR to the IDLE state where it waits for either of two commands. Upon receiving a request REQA or wake up WUPA command, the card transitions to a READY state. In the READY state, the card and reader carry out a mutual authentication procedure. Authentication can involve the exchange of keying material which may be tied to a unique identifier of the card. Upon successful authentication, the card enters the ACTIVE state at which time the card can respond to READ and WRITE commands. In the ACTIVE state, the card can be placed into the HALT state by an explicit HALT command or upon the occurrence of certain error conditions. When halted, the card will respond only to a wake up WUPA command and will interpret other data as an error. 
     Card reader  200  can interrupt a card during a transaction and generate a simulated data exchange while card operation is suspended. For example, after a card has been presented at card reader  200 , processor  260  can add a HALT command to the transmit data. As an alternative to issuing an explicit HALT command, processor  260  can transmit an invalid command or sequence of commands known to give rise to an error condition at the card such that the card returns to the HALT or IDLE operating state. When operation of the card is suspended, processor  260  can orchestrate a simulated exchange as discussed in connection with  FIG. 4 . Following the simulated data exchange, the card can be reactivated with a wake up WUPA, request REQA, or other appropriate command. 
       FIG. 6  illustrates a further eavesdropping countermeasure that can be employed by card reader  200 . In the example, card reader  200  issues a valid command (C 1 ) ostensibly to provoke a response from the card. However, card reader  200  then issues a second identical command before a response is expected from the card. As shown, a second C 1  command is issued. The second identical command disrupts an eavesdropper&#39;s ability to identify a timing of subsequent exchanges in the transaction and may create an error condition at the card. 
     At this point, card reader  200  can proceed to generate simulated exchanges or to transmit random values. For example, card reader  200  can transmit additional valid or invalid commands X 1 , X 2  and can simulate card responses SR 1 , SR 2  to these additional commands. Alternatively, card reader  200  can modulate the RF carrier with random outbound data or it can simulate random inbound data. Thereafter, depending upon the requirements of the CSC protocol, any error conditions that may have been created can be cleared before proceeding. In the present example, a wake up command WUPA is issued to bring the card out of the error state. Following acknowledgement ACK by the card, the transaction proceeds with a READ or other appropriate command. 
     In addition to the preceding countermeasures, card reader  200  can selectively jam card transmissions. In some embodiments, jamming is a process in which the card reader  200  transmits data at a time when the card is also transmitting. The outbound and inbound signals may collide and can interfere either constructively or destructively. When the signals interfere destructively, it can be difficult or impossible to recover the card data from the RF carrier. For an eavesdropper, the collisions create uncertainty and can limit the ability to recover sensitive information from a card transaction. For example, if card reader  200  generates four destructive collisions during a 48-bit key exchange, a hacker has only a 1/16 chance of guessing the correct 48-bit key sequence. 
       FIG. 7  illustrates aspects of a jamming countermeasure such as can be employed by card reader  200 . Items (a)-(b) represent data transmitted by a smartcard during a transaction. As shown, the card transmits Manchester coded binary data (a) by load modulating (b) the RF carrier (c) at a sub-carrier frequency. The effect of the load modulation of RF carrier (c) is recovered in the IF signal (d) output from filter  220  at card reader  200 . Items (a)-(d) show the exchange before application of the jamming countermeasure. 
     With reference to  FIG. 2 , processor  260  can initiate a jamming countermeasure at any point during a transaction by scheduling the transmission of jamming data. Depending upon the requirements of the CSC protocol, for example, processor  260  can selectively jam transmissions during a sensitive part of a card transaction such as when keying material is exchanged during authentication. Processor  260  can determine the timing of a particular card response and can output a jamming data sequence to scheduler  250  for outbound transmission. The modulation type and modulation can be set to match inbound communications from the smartcard. Scheduler  250  can precisely time modulation of the jamming data to coincide with a targeted portion of the exchange. 
     While the jamming countermeasure is active, receiver  290  can detect collisions and infer the data value sent by the card based on knowledge of the jamming data. For example, if a destructive collision is detected when a ‘1’ value of the jamming data was transmitted, receiver  290  can infer that the card sent a ‘0’ during that bit period and can output a ‘0’ to processor  260  in the receive data signal. Alternatively, receiver  290  can be configured simply to discard the collision data without attempting to determine the card&#39;s response. 
     Returning to  FIG. 7 , items (e)-(h) illustrate the effect of the jamming countermeasure. It can be seen that the exemplary card data of item (a) includes the Manchester sequence ‘11011’ distributed over bit periods {circle around ( 1 )}-{circle around ( 5 )}. Item (e) shows the jamming data output by processor  260  (‘01111’) and item (f) shows the corresponding sub-carrier modulation produced by card reader  200 . Item (g) illustrates the combined effect of the jamming data (e) and the card data (a) on the RF carrier (g). Lastly, item (h) represents the IF signal recovered from the RF carrier (g) during the active jamming interval. 
     During bit interval {circle around ( 1 )}, the value of the card data is ‘1’ and the value of the jamming data is ‘0’. The result is a destructive collision represented by a reduced level of the receiver signal (h). When the destructive collision is detected, receiver  290  can either infer that the card sent a ‘1’ based on knowledge of the jamming data, or it can signal an indeterminate value at the bit position. Similarly, during bit interval {circle around ( 3 )}, a destructive collision results when the card transmits a ‘0’ and the jamming data transmitted by card reader  200  is a ‘1’. Note that the receiver signal during bit intervals {circle around ( 2 )}, {circle around ( 4 )}, and {circle around ( 5 )} is not affected by interference between the outbound jamming signal and the inbound card data. 
     As a further disruption to eavesdropping, processor  260  can vary the amplitude of the RF carrier over time. The inventor of the present application has discovered that a typical smartcard will tolerate variation of the RF field on the order of approximately 20% or more. Such variation, for example, can result when the card is introduced to the RF field at different angles and distances from the card reading device. Processor  260  can vary the RF carrier using the carrier level output to modulation controller  240 . In response to changes in the carrier level, modulation controller  240  changes the amplitude of the RF carrier within a predetermined operating range. Varying the level of the RF carrier complicates the process of snooping on card transactions and can be performed each time a card is presented to card reader  200  or even during the course of a card transaction. 
       FIG. 8  is a flowchart  800  showing steps performed by a card reader during a card transaction according to embodiments of the present invention. These steps can be performed by card reader  200  and, in particular, can be implemented by processor  260  through a combination of hardware and software elements. 
     At block  810 , the card reader determines a suite of countermeasures to be employed during a next card transaction. The suite of countermeasures can include one or more of the countermeasures discussed herein and the countermeasures can be implemented before, during, and after the card transaction. A different suite of countermeasures can be selected for each card transaction. Also, in some embodiments, different countermeasures can be selected for use with different types of cards and different CSC protocols. For example, countermeasures for use with Type A cards can differ from those used with Type B cards, Mifare® Ultralight countermeasures may differ from Mifare® Classic measures, and so on. 
     At block  820 , countermeasures can be executed before a card is presented at the card reader. Such countermeasures can include modulating the RF carrier in a random fashion at a frequency used by the card for communicating with the card reader. With Type A cards, for example, a 13.56 MHz carrier could be modulated at its 847 kHz sidebands with random data to create false triggers for a would-be eavesdropper. Alternatively or additionally, the card reader could simulate either or both sides of a fictitious card transaction. 
     At block  830 , a card is detected at the reader when it responds to a wake-up or similar command or following an anti-collision procedure. At block  840 , when the card has been detected, countermeasures can be executed in connection with a card transaction. The card reader can simulate card transmissions at pauses determined according to the CSC protocol. For example, spurious data can be transmitted to simulate inbound data from the card without disrupting the card&#39;s ability to respond to commands. 
     Alternatively, during the card transaction, the card reader can issue a HALT or similar command to suspend the card&#39;s operation, generate a simulated data exchange, and then reactivate the card at a timing determined by the card reader. In like manner, an invalid command or sequence of commands can be used to purposefully suspend card operation so that the card reader can play out a simulated data exchange. During the simulated data exchange, the card reader can also distribute bogus keying material which, in turn, can be registered for tracking purposes. 
     The card reader can also jam communications which occur during the card transaction. For example, per the discussion at  FIG. 7 , the card reader can selectively jam parts of a card&#39;s response to reduce the probability that card data can be completely recovered by an eavesdropper. In some embodiments, the card reader determines the length and timing of the jamming transmission to ensure a minimum number of destructive collisions. 
     At block  850 , the card transaction is complete. For example, data may have been successfully read from or written to the card or the card transaction may have failed. As a further protection, the card reader may continue to execute countermeasures even after the transaction is concluded. Such countermeasures could include random modulation of the RF carrier to simulate inbound card data, valid but useless commands issued to the card, continuing with a simulated data exchange, or any other action for creating false triggers and obfuscating the actual card transaction. 
     As will be understood by those skilled in the art, the present invention may be embodied in other specific forms. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific embodiments of the invention described herein. Such equivalents are intended to be encompassed by the following claims.