US20120330843A1 - Transparently securing data for transmission on financial networks - Google Patents

Abstract

Systems and methods for performing financial transactions are provided. In one embodiment, the invention provides a method for processing token data for a bank card transaction, the method includes: receiving a string of first token data from a token at a token reader; modifying the first token data and generating second token data, the second token data including modified token data; performing a modulo arithmetic operation on the second token data and determining a mod10 check digit that will cause a modulo arithmetic check of the second token data to yield the same result as the modulo arithmetic check would yield on the first token data; and inserting the mod10 check digit in the second data string and forwarding the second data string for the transaction.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a divisional of U.S. patent application Ser. No. 12/110,106, which was filed on Apr. 25, 2008 and published as U.S. Publication No. 2008/0243701, which is a continuation of U.S. patent application Ser. No. 11/127,862, filed on May 12, 2005, which issued as U.S. Pat. No. 7,506,812, which is a continuation-in-part of U.S. patent application Ser. No. 10/936,359, filed on Sep. 7, 2004, which issued as U.S. Pat. No. 7,309,012, each of which is herein incorporated by reference in its entirety.
BACKGROUND OF THE INVENTION
• 1. Field of the Invention
• The present invention relates to a method for protecting magnetic stripe data in transit from the magnetic stripe reader to a host computer while maintaining compatibility with the data format contained within the magnetic stripe data. The present invention further relates to a magnetic stripe reader assembly which replaces the magnetic head in conventional point of sale terminals (POS) which encrypts the magnetic stripe information within the magnetic head preventing unauthorized access to said information. More particularly, the present invention relates to a secure magnetic stripe reader attachable to a POS or handheld computing device which enables the secure reading and writing of information on a single or multiple track magnetic stripe by encrypting the card data prior to entering the POS or PDA in a format transparent to the devices normal operation.
• 2. Description of the Related Art
• Cards which have a magnetic stripe attached thereto are ubiquitous in modem society today. That is, nearly everyone carries one of the following cards, each of which typically have a magnetic stripe attached thereto: credit cards, bank cards, automatic teller machines cards (ATM cards), debit cards, identification cards, drivers' licenses, security access cards, check cashing cards, etc.
• The necessity and usefulness of devices which decode the information on such cards are well known. The need to read and decode and save the information on such cards using low cost and portable computing devices including PDA's and cell phones has become increasingly evident in recent months. One such application is in reading the custom formats used in US state driver's licenses. To date, forged drivers licenses used to purchase alcohol and tobacco do not contain correctly encoded data on the attached magnetic stripe. The described invention can be used to read the various formats in use by various US state's department of motor vehicles and display the physical description recorded on the magnetic stripe. Liquor stores, bars, and law enforcement agencies can use this portable system to determine the authenticity of the identification cards being used to purchase controlled substances. One benefit of the current invention over previous art is the increased security of the device and the information transferred. In the age verification application, only the information necessary for the user identification is output from the head in a readable format. Other data such as the driver's license number is output in an encrypted format and stored for later verification of the identifications acceptance if required by law enforcement agencies.
• Another application in using MSR card reader attachments with handheld computing devices such as PDA's and cell phones, is to process credit card and debit card transactions. In these applications, the wireless and movable nature of the POS transaction makes security a requirement. If clear text of the card data is allowed to enter the handheld, a virus or “Trojan horse” program could capture the data to compromise the card holder's monetary accounts. Card skimming, which is the illegal recording and use of credit/debit card information to make fraudulent purchases, currently represents approximately 25% of credit/debit card company losses. This number is expected to increase to over a billion dollars in the future. In spite or long standing regulations that no track data be stored by POS terminals, transaction processing gateways, or merchants in clear text formats it is common knowledge that this data is stored and has been compromised. Millions of credit and debit cards magnetic stripe data has been stolen from these sources and used to transact fraudulent transactions. The major credit and debit card brands have enacted new regulations in an attempt to curb availability of the magnetic stripe data. Unfortunately compliance to these new regulations could require replacing all POS terminals deployed. With millions of POS terminal in use the cost to the merchants for upgrading POS equipment to comply with the new regulations is prohibitive.
• With one implementation of the current invention selected card track data is encrypted during the reading of the magnetic stripe with a format as described in hidden des standard data format drawing. The combination of clear text track data and the encrypted track data which is output from the reader has the same track data format as read from the card which allows legacy POS equipment to function without modification. After the encrypted data is sent to the processing bank via various secure and insecure networks the required keys are used to decrypt and reconstruct the original magnetic stripe data and format of the card data for processing. The output being encrypted as required by the major brands provides for adherence to the new regulations without replacing the POS equipment.
• In another implementation of the current invention selected card track data is encrypted during the manufacturing of the card with a format as described in hidden des standard data format drawing. The data written to the card is used to generate a one way hash code. This hash code and the encryption key used to encode the data are stored in a secure database for future use in decrypting the card data. As with other embodiments of this invention the encrypted card data format is compatible with legacy or the current non encrypted data format currently in use. The clear text information remaining in the stripe data is sufficient for legacy POS equipment to perform is current tasks without changing the current applications or infrastructure. After the encrypted data is sent to the processing bank via various secure and insecure networks the required keys are used to decrypt and reconstruct the original magnetic stripe data and format of the card data for processing. It should be noted that this application and the former where that card data is encrypted in the MSR are cross compatible and there would be benefit in using both techniques together. Encrypting the data in the reader attaches reader and POS information to the card while encrypting during manufacturing prevents standard card readers from reading and storing the data for illicit uses.
• In addition to providing a low power, secure intelligent magnetic stripe reader for handheld computing application this invention can be used in legacy products to provide the additional security required in today's POS markets. The modules intelligent interface can be configured to various digital interfaces such as SPI, I2C, or serial TTL which are supported by the legacy equipment currently in use. In addition, the module can mimic the output of a conventional head providing encrypted data to the legacy equipment. In addition the module can output using new protocols such as Bluetooth.
• Current wired and wireless transaction processing servers rely on whatever the networks “end to end” security is for protecting credit and debit card transactions. In many applications, the network is secure from the transaction terminal to the processing banks server. In some applications, most noticeably the use of cell phone and other handheld computing devices as the POS transaction terminal, the security provided by the network is less than ideal. WAP based transaction processing is subject to the security implementation provided by the wireless carrier. In the case of one such wireless provider. Nextel®, the encryption and hence the security of the data varies from clear text to 56 bit DES to 128 bit IDES. While the IDES meets the card industry standards for security, the others do not, which makes it impossible to guarantee end to end strong encryption of at least the IDES level. The present invention supports strong end to end encryption along with the ability to interface to banks legacy transaction processing systems and to in addition verify the cards authenticity.
SUMMARY OF THE INVENTION
• According to one or more embodiments of the invention, various features and functionality can be provided to enable or otherwise facilitate various forms of token transactions. Particularly, in accordance with one aspect of the invention, data security techniques such as, for example, token encryption is performed in such a way that a modulo arithmetic check will not be able to detect the difference between the encrypted or modified data string and the original data string.
• In one embodiment of the present invention, a method for processing token data for a transaction includes: receiving a string of first token data from a token at a token reader; modifying the first token data and generating second token data, the second token data including modified token data; performing amod10 operation on the second token data and determining amod10 check digit that will cause a modulo arithmetic check of the second token data to yield the same result as the modulo arithmetic check would yield on the first token data; and inserting themod10 check digit in the second data string and forwarding the second data string for the transaction.
• In one embodiment, the second token data may he a string of modified token data and clear text token data assembled in the same format as the first token data. The portion of the token data may be an account number data from first the token data. In the method described above, themod10 check digit may he appended to the second string or replaces a character in the second string. Themod10 check digit can also he added to the first data string at a predetermined location of the first data string. The predetermined location can be one position prior to the last four digits of an account number.
• In yet another embodiment, the method further comprises converting the modified token data to a base10 number prior to generating the second token data. The token can be a bank card and the token data may include card track data. The token can also be a bank card account number PAN (personal account number) and the token data may include modified PAN digits.
• In still yet another embodiment, the modifying procedure comprises converting the first token data to eight bytes, and performing an eight-byte triple DES encryption on the converted token data.
• In still yet another embodiment, the procedures of modifying the first token data and generating second token data include: converting X digits of the first token data to a predetermined number of Y bytes; performing a Y-byte encryption on the converted token data; and converting the encrypted Y bytes of encrypted data to X digits.
• In still yet another embodiment, the procedures of performing themod10 operation and inserting themod10 check digit may comprise performing amod10 calculation on the X digits to determine themod10 check digit and inserting themod10 check digit in the appended predetermined digit location. The token data that is encrypted can be a subset of the original token data string, and the encrypted token data may replace the original token data at the same location or locations in the string.
• In accordance with another embodiment of the present invention, a method for processing bank card data for a purchase transaction includes: receiving a first set of bank card data from a card reader; encrypting selected characters of the card data; replacing the original selected characters of the card data with the encrypted selected characters of the card data creating a second set of card data; performing a modulo arithmetic calculation on the second set of card data and determining amod10 check digit that will cause a modulo arithmetic check of the second set to yield the same result as the modulo arithmetic check would yield on the first set of bank card data; and inserting themod10 check digit in the second data set and forwarding the second data set for the purchase transaction.
• In one embodiment, the second set of card data set may be a string of encrypted card data and original unencrypted card data assembled in the same format as the first set of bank card data. Themod10 check digit may be appended to the second set of card data or may replace a character in the second set of card data. Themod10 check digit can added to the second set of card data at a predetermined location of the second set of card data. In another embodiment, themod10 check digit is added to the second data string at a predetermined location of the second data string and anoriginal mod10 check digit in the first string remains unchanged in the second data string.
• The predetermined location can be one position prior to the last four digits of an account number. The first set of token data can be track data from a track of the bank card. Additionally, the first set of token data can be PAN data from a bank card.
• In another embodiment, the procedure of encrypting selected characters includes converting the selected characters to eight bytes, and performing an triple DES encryption on the selected token data.
• In yet another embodiment, the procedures of the encrypting selected characters comprises and creating a second set of card data include: converting X digits of the first set of bank card to a predetermined number of Y bytes; performing a Y-byte encryption on the converted card data; and converting the encrypted Y bytes of encrypted data to X digits. The procedure of performing themod10 operation and inserting themod10 check digit may comprise performing a modulo calculation on the X digits to determine themod10 check digit and inserting themod10 check digit in the appended predetermined digit. The token data that is encrypted can be a subset of the original token data string, and the encrypted token data may replace the original token data at the same location or locations in the string.
BRIEF DESCRIPTION OF THE DRAWINGS
• The above mentioned and other objects and features of this invention and the manner of attaining them will become apparent, and the invention itself will be best understood by reference to the following description of the embodiment of the invention in conjunction with the accompanying drawings, wherein:
• FIG. 1 is an exploded view of the component parts of a secure magnetic transducer head module, constructed in accordance with the present invention;
• FIG. 2 is a partially exploded view of a secure magnetic transducer head module, constructed in accordance with the present invention;
• FIG. 3 is a perspective view of an assembled secure magnetic transducer head module attached to a card reader slot component, constructed in accordance with the present invention;
• FIG. 4 is a flow diagram illustrating the standard data output format from a standard secure transducer head module, constructed in accordance with the present invention;
• FIG. 5 is a flow diagram illustrating the enhanced data output format from an enhanced secure transducer head module with a card data signature generator, constructed in accordance with the present invention;
• FIG. 6 is a side elevation view of a cell phone including an attached manual magnetic stripe card reader, constructed in accordance with the present invention;
• FIG. 7 is a front view of a cell phone including an attached manual magnetic stripe card reader, constructed in accordance with the present invention;
• FIG. 8 is a bottom side view of a cell phone including an attached manual magnetic stripe card reader, constructed in accordance with the present invention;
• FIG. 9 is a top and side perspective view of a cell phone including an attached manual magnetic stripe card reader, constructed in accordance with the present invention;
• FIG. 10 is a perspective front and side view of a secure transducer head module attached to a reconfigurable processor/memory module debugger, constructed in accordance with the present invention;
• FIG. 11 is a schematic diagram and printed circuit board (PCB) layout diagram of a conventional magnetic stripe card reader, constructed in accordance with the current technology;
• FIG. 12 is a schematic and printed circuit board (PCB) layout of a secure transducer head magnetic stripe card reader, constructed in accordance with the present invention;
• FIG. 13 is a flow chart illustrating the WAP and java application for legacy transaction server support, constructed in accordance with the prior art;
• FIG. 14 is a flow chart illustrating the WAP application for legacy transaction server support (with no authentication), constructed in accordance with the present invention;
• FIG. 15 is a flow chart illustrating the WAP application for a new transaction server support with Secure Stripe® technology employed (authentication), constructed in accordance with the present invention;
• FIG. 16 is a flow chart illustrating the WAP application for a new transaction server (with no authentication), constructed in accordance with the present invention;
• FIG. 17 is a flow chart illustrating the WAP application for a new transaction server (with authentication), constructed in accordance with the present invention;
• FIG. 18 is a flow chart illustrating the Java®/Pocket PC WAP application for legacy transaction server support (with no authentication), constructed in accordance with the present invention;
• FIG. 19 is a flow chart illustrating the Java®/Pocket PC WAP application for legacy transaction server support with Secure Stripe® technology employed (with authentication), constructed in accordance with the present invention;
• FIG. 20 is a flow chart illustrating the Java®Pocket PC application for new transaction server support (with no authentication), constructed in accordance with the present invention;
• FIG. 21 is a flow chart illustrating the Java®Pocket PC application for new transaction server support with Secure Stripe® technology employed (authentication), constructed in accordance with the present invention;
• FIG. 22 is a flow chart illustrating a PDA MSR attachment with wireless link and compatible gateway to cell phone application, to access a wireless gateway, constructed in accordance with the present invention;
• FIG. 23 is a flow diagram illustrating the encrypted and clear text track two credit and debit card data output format from an encrypted secure MSR transducer head compatible with legacy PUS terminals as used in accordance with the present invention;
• FIG. 24 is a flow chart illustrating the enhanced data output format from an encrypted secure MSR transducer head at a point of sale (POS), in communication with a gateway which decrypts the card data and forwards the data to bank using secure data communication networks, constructed in accordance with the present invention;
• FIG. 25 is a flow diagram illustrating the encrypted and clear text track two credit and debit card data output format from encrypted magnetic stripe data encoded at the cards manufacture and compatible with legacy POS terminals as used in accordance with the present invention;
• FIG. 26 is a flow chart illustrating the enhanced data output format from an encrypted magnetic stripe read at the point of sale (POS), in communication with a gateway which forwards the encrypted data to the bank using and the bank uses previously stored keys to decrypt the card data, as constructed in accordance with the present invention;
• FIG. 27 is a flow diagram illustrating the enhanced data output format from an enhanced secure transducer head module with an optional card data signature generator and using the masked data format fortrack1 data, constructed in accordance with the present; and
• FIG. 28 is a flow chart illustrating the enhanced data output format from encrypted magnetic stripe data and an encrypted secure MSR transducer head module with a card data signature generator at a point of sale (POS), in communication with a gateway which decrypts the MSR encryption and to hank which decrypts the encrypted magnetic stripe, constructed in accordance with the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
• Referring now toFIG. 1, there is shown an exploded view of exploded view of asecure head module10 illustrating the component parts thereof. Thesecure head module10 is constructed of a protectivemetal end cap12, asecure module PCB14, amagnetic transducer head16, and aninterconnect flex circuit18. The partially assembledsecure head module22 is attached to theinterconnect flex circuit18 prior to being affixed within thelow jitter spring24.
• Referring now toFIG. 2, there is shown a partially exploded view of an assembledsecure head module26 with an interconnect flex circuit18 (attached), and alow jitter spring24.
• Referring now toFIG. 3, there is shown a perspective view of an assembled secure head magnetic stripe card reader (MSR)20 having asecure head module26, wherein saidsecure head module26 withinterconnect flex circuit18 is mounted within acard reader housing28, and thereby ready to be incorporated into existing card reader units for the purpose of practicing the present invention and allowing for enhanced secure card reading transactions and communications.
• Referring now toFIG. 4, there is shown a flow diagram illustrating the standard data output format from a standard securetransducer head module30. Information stored on the magnetic stripe card is read bycard reader32, encrypted, and sent to ahandheld computing device34, such as a cell phone or a FDA.
• Referring now toFIG. 5, there is shown a flow diagram illustrating the enhanceddata output format40 from an enhanced secure transducer head module with a carddata signature generator42. Information stored on the magnetic stripe card is read by the card reader with asignature generator42, encrypted with a card signature added, here as binary verification data, and sent to ahandheld computing device44, such as a cell phone or a PDA. The generated card signature data enables enhanced security during transaction data flow.
• Referring now toFIGS. 6,7,8 and9 there is shown a several views of a combination cell phone and manual magneticstripe card reader50 comprising a conventional cell phone52 (here representing any handheld computing device) with an attachedmagnetic card reader54. Themagnetic card reader54 is held in place oncell phone52 byattachment arm56. Themagnetic card reader54 includes acard slot58 for swiping the card (not shown) containing data to be read, and anindicator LED66. Themagnetic card reader54 is electronically linked tocell phone52 via anHHCD interface connector62 andcommunication cable64, for the purpose of sending and receiving data and to allow thecell phone52 batteries to power thecard reader54. Thecommunication cable64 leads to the cardreader circuitry housing68 to provide power and send and receive data. This card reader contains the secure head module (seeFIGS. 1 through 3) which is the subject of this patent, and the cardreader circuitry housing68 contains both power management software, and the ability to generate standard and enhanced data formats for secure and enhanced security card transactions.
• Referring now toFIG. 10, there is shown a combination secure transducer head module and a reconfigurable processor/memory module debugger70. The secure transducer headcard reader assembly72 is attached to the reconfigurable processor/memory module debugger74 via a secure head data anddebugger connector cable78. Theconnector cable78 extends from thesecure head76 to a contact point on the printed circuit board (PCB)86 of the reconfigurable processor/memory module debugger74. The reconfigurable processor/memory module debugger74 includes both an externaldebugger interface connector82 and a personal computer PC/terminal interface connector84.
• Referring now toFIG. 11, there is shown a schematic diagram and printed circuit board (PCB) layout diagram90 of a conventional magnetic stripe card reader, constructed in accordance with the current technology.
• Referring now toFIG. 12, there is shown a schematic diagram and printed circuit board (PCB) layout diagram100 of a secure transducer head magnetic stripe card, constructed in accordance with the present invention. Data and electrical current flow from themagnetic head104 to the output/control102.
• Referring now toFIG. 13, there is shown a flow chart illustrating the WAP and java applications for legacy transaction server support, constructed in accordance with the prior art. These WAP and java applications include unsecured connections between card reader's110, wireless PDA's111, smart phones and WAP enabled cell phones and the cell phone gateway over theRF link112. Also, the links between theInternet114 and thecell phone gateway113, and the links between theInternet114 and WAP orJava application servers115 is not a secure connection. Thus, here in this wireless legacy system, the only secure connections exist between the Internet, the legacy transaction servers and the individual bank information systems (as shown in the lower half of this flow chart).
• Referring now toFIG. 14, there is shown a flow chart illustrating the WAP application for legacy transaction server support (with no authentication). The card data is encrypted to CISP compliance at the secure module located inside thecard reader110 using the format indicated inFIG. 4. The encrypted card data is requested by theWAP application server115 through theInternet114. The application server requests the encryption key database server orservice121, through theinternet114, to accept the encrypted data and return decrypted transaction data using a secure internet (SSL) connection. The returned decrypted transaction data is formatted by the WAP application server suitable to the required transaction processor as prior to the addition of the secure module.
• Referring now toFIG. 15, there is shown a flow chart illustrating the WAP application for legacy transaction server support with Secure Stripe® technology employed (authentication). The card data is encrypted to CISP compliance at the secure module located inside thecard reader110, additional second block of encrypted data containing the magnetic stripes security signature and a one-way hash code of the card account number using the format indicated inFIG. 5. The encrypted card data is requested by theWAP application server115. The application server requests the encryption key database server orservice121 to accept the encrypted data and return decrypted transaction data using a secure internet (SSL) connection. The application server requests the Authentication database server orservice130 to verify the magnetic stripe authenticity using the account hash code to index the stored signature value for the magnetic stripe. The results of the signature comparison are used to determine if the card transaction should be terminated or forwarded to the legacy transaction processor based on acceptance rules contained within theencryption database121.
• Referring now toFIG. 16, there is shown a flow chart illustrating the WAP application for a new transaction server (with no authentication). The card data is encrypted to CISP compliance at the secure module located inside thecard reader110 using the format indicated inFIG. 4. The encrypted card data is requested by theWAP application server115 through theInternet114. The application server requests the encryption key database server orservice121, which is located on the same intranet or within the same computer, to accept the encrypted data and return decrypted transaction data. The returned decrypted transaction data is formatted by the WAP application server suitable to the requiredtransaction processor116 and the transaction processed using current bank rules.
• Referring now toFIG. 17, there is shown a flow chart illustrating the WAP application for a new transaction server (with authentication). The card data is encrypted to CISP compliance at the secure module located inside thecard reader110 using the format indicated inFIG. 4. The encrypted card data is requested by theWAP application server115 through theInternet114. The application server requests the Authentication database server orservice130 to verify the magnetic stripe authenticity using the account hash code to index the stored signature value for the magnetic stripe. The results of the signature comparison are used to determine if the card transaction should be terminated based on current bank rules. The application server requests the encryption key database server orservice121, which is located on the same intranet or within the same computer, to accept the encrypted data and return decrypted transaction data. The returned decrypted transaction data is formatted by the WAP application server suitable to thebanks transaction processor116 and the transaction processed using current bank rules
• Referring now toFIG. 18, there is shown a flow chart illustrating the Java®/Pocket PC WAP application for legacy transaction server support). While similar toFIG. 14,FIG. 18 supports greater functionality with the addition of bidirectionalsecure communication140 between thesecure head module110 and thehandheld computing device111. This added communication channel allows for enhancements not possible using the system ofFIG. 14. One primary enhancement is that the secure module can received data from the handheld device to be encrypted along with the card data such as the amount of the transaction. In addition the java or Pocket PC application running in the handheld device can request command and status operations of the secure module without the need for specially encoded cards as required by the WAP systems.
• Referring now toFIG. 19, there is shown a flow chart illustrating the Java®/Pocket PC WAP application for legacy transaction server support with Secure Stripe® technology employed (authentication). While similar toFIG. 15,FIG. 19 supports greater functionality with the addition of bidirectionalsecure communication140 between thesecure head module110 and thehandheld computing device111. This added communication channel allows for enhancements not possible using the system ofFIG. 15. One primary enhancement is that the secure module can received data from the handheld device to be encrypted along with the card data such as the amount of the transaction. In addition the java or Pocket PC application running in the handheld device can request command and status operations of the secure module without the need for specially encoded cards as required by the WAP systems.
• Referring now toFIG. 20, there is shown a flow chart illustrating the Java®Pocket PC application for new transaction server support (with no authentication). While similar toFIG. 16,FIG. 20 supports greater functionality with the addition of bidirectionalsecure communication140 between thesecure head module110 and thehandheld computing device111. This added communication channel allows for enhancements not possible using the system ofFIG. 16. One primary enhancement is that the secure module can received data from the handheld device to be encrypted along with the card data such as the amount of the transaction. In addition the Java or Pocket PC application running in the handheld device can request command and status operations of the secure module without the need for specially encoded cards as required by the WAP systems.
• Referring now toFIG. 21, there is shown a flow chart illustrating the Java®Pocket PC application for new transaction server support with Secure Stripe® technology employed (authentication). This system is similar to that illustrated inFIG. 20 above, however, here the wireless PDAs, the cell phone and the point of sale (POS) computer all are equipped with Java®/Pocket PC (PPC) and Java®/Windows XP applications). While similar toFIG. 17,FIG. 21 supports greater functionality with the addition of bidirectionalsecure communication140 between thesecure head module110 and thehandheld computing device111. This added communication channel allows for enhancements not possible using the system ofFIG. 17. One primary enhancement is that the secure module can received data from the handheld device to be encrypted along with the card data such as the amount of the transaction. In addition the java or Pocket PC application running in the handheld device can request command and status operations of the secure module without the need for specially encoded cards as required by the WAP systems.
• Referring now toFIG. 22, there is shown a flow chart illustrating a PDA MSR attachment with wireless link and compatible gateway to cell phone application, to access a wireless gateway. Heremultiple PDAs111, table mounted POS terminal with secure module for order entry and payment along withinternet access150, and a point of sale register with wireless capabilities are all connected to a wireless local area network (WAN)152. This WAN, and any hard wired PUS registers communicate with a localPUS application server151 which is connected via the Internet and secure connections to a IDES encryption database and transaction processing server. This TDES encryption database and transaction processing server then communicates via the Internet and secure connections to legacy or new transaction processors which in turn communicate via secure connections with bank information systems. Depending on the transaction processor used the local PUS application server either requests the authentication sever to verify the cards authenticity and sends that response along with the encrypted card data to the new transaction server or additionally requests the encryption keys and formats the data for a legacy transaction server. In an alternate method the PUS server forwards the encrypted card and signature to an enabled transaction server to both authenticate and decrypt the card data.
• Referring now toFIG. 23, is a flow diagram illustrating the encrypted and clear text track two credit and debit card data output format from an encrypted secure MSR transducer head compatible with legacy POS terminals as used in accordance with thepresent invention200, constructed in accordance with the present invention. With the current invention activated, selected card data is encrypted within the magnetic head orcard reader204. Various information from the track data is selected based on particular requirements of the PUS system. In general the first for account digits representing the BIN or Bank Identification Number are left as clear text along with the card expiration date and the last four digits of the account number for the PUS to use in card verification and receipt printing. Nineteen digits of the remaining card data are converted to an 8 byte binary value, a time function is added206 and the result TDES encrypted using an electronic code book (ECB)block encryption209. The 8 bytes of encrypted data are converted to a 20digit base 10 number, the least significant 19 digits replace the selected card digits. The last digit is 0 or 1 and is added predefined to a bank field. Anew mod10 character is generated210 and placed into the selected card digit. The combination of encrypted and clear text data output by the secure MSR module and is received by the PUS orPDA device214. The clear text is specific to the application software operating within the PUS orPDA214 allowing normal operation of the device with no or little programming changes. Data sensitive to the application is encrypted while maintaining the format of the original data from the magnetic stripe. After the encrypted data is sent to the processing bank via various secure and insecure networks the required keys are used to decrypt and reconstruct the original magnetic stripe data and format of the card data for processing. In this way, the secure system operates in essentially a transparent fashion, and can be adapted to any existing system already in place or yet to be invented. In an alternative method where the desired number of digits to he encrypted is other than the 19 as described or the encryption block size is larger than the available number of digits to be encoded an output feedback mode (OFB) or the counter mode (CTR) of block encryption may be employed. In these methods fixed data including such variables as the MSR serial number and portions of the clear text card data along with a changing value such as a counter incremented with each block output is encrypted using the desired encryption algorithm. The output bits from the encryption are XORed with the data to be encrypted. In the case that the card digits to be encrypted range for 0 to 9, as commonly found fortrack2 data, 3 bits of the encryption are XORed with each digit from 0 through 7. Thedigits 8 and 9 are left in clear text. Since fewer steps are required for the CTR or OFB method there use may preferred over the ECB method.
• In operation,MSR204 reads the card magnetic stripe data. The data is then “tagged” by taking 19 “d” digits from thetrack2 data and converting it to 8 bytes. Using a time or counter orrandom number generator208, eight byte triple DES (TDES) encryption is coded using the encryption key stored in theMSR204, and used to replace theoriginal card206track2 data. AMod10calculation210 is performed, and themod10 character is inserted into the data before data output to aPOS212. APDA device214 can then send the encrypted data to a server with anencryption key216 before sending the original card data on to the designatedbank218.
• In operation, the hiddenDES system220 illustrated inFIG. 24, allows for the reading of card data through encrypted MSRs at POS registers, for example a POS register at astore front222, a POS register at arestaurant224 and a POS register at an on-line ordering system226. The read data is transmitted to aPOS Gateway1228 for banks A and B, and anotherPOS Gateway2232 for bank C and others. Each of the POS Gateways has an encryption key server,server230 forgateway228, andserver234 forgateway232. The respective POS gateways then employ the bank communication network or networks to send data along a secure connection tolegacy transaction processors238,240 and242, which in turn send financial data to banks A244,13246 andbank C248, via secure connections.
• Referring now toFIGS. 25 and 26, there is shown the present invention in operation using a CPI compliant TDES standard to encode portions of the account data prior to encoding the cards. With the current invention selected card track data is encrypted during the manufacturing of the card. As with other embodiments of this invention the encrypted card data format is compatible with legacy or the current non-encrypted data format currently in use. The clear text information remaining in the stripe data is sufficient for legacy POS equipment to perform is current tasks without changing the current applications or infrastructure. After the encrypted data is sent to the processing hank via various secure and insecure networks the required keys are used to decrypt and reconstruct the original magnetic stripe data and format of the card data for processing. It should be noted that this application and the former where that card data is encrypted in the MSR are cross compatible and there would be significant benefits in using both techniques together. Encrypting the data in the reader attaches reader and POS information to the card while encrypting during manufacturing prevents standard card readers from reading and storing the data for illicit uses.
• In operation, the CPI compliant IDES standarddata format system250, illustrated inFIG. 25 enablescard manufacturing equipment252 to receive anencryption key254 from anencryption key server258 as administrated by each individual bank, herebank260, for example. Again, 19 digits are selected from the card'strack2 data position and converted to 8 bytes. An 8 byte triple DES (TDES)encryption engine262 is used to produce the 8 TDES bytes which are subsequently converted to 19 digits plus 1 bit, and this is used to replace theoriginal card track2 data. AMod10 calculation is performed264, and themod10 character is inserted into the data. At this point the card is custom manufactured for use and is sent to the customer user. When the customer uses the card at aPOS terminal272 the data is readily decrypted and confirmed by the bankskey code server274 and the information sent to associatedbank276.
• FIG. 26 illustrates theCPI DES system280. In operation,encrypted MSRs282,284 and286 representing POS devices located at brick and mortar store fronts, restaurants, on-line ordering systems, etc., send financial data to one ofo POS gateways288 or290, set up for communications to differing bank systems. Using a gateway to bank communication networks, thegateways288 and290 send information via secure connections tolegacy transaction processors294,300 and306. Each of the legacy transaction processors has an associated encryption key database relating to an individual hank. Following encryption by each encryption key database, the financial information can he forwarded to eachbank298,304 and310 via secure connections.
• Referring now toFIG. 27, there is illustrated a flow diagram of the enhanced data output format from an enhanced secure transducer head module with an optional card data signature generator using a hidden DES standard data format ontrack1data system320, constructed in accordance with the present invention. In operation, theMSR322 contains anencryption key324 which is utilized to encrypt selected fields oftrack1 data from thecard326. An optional 8byte authenticity signature328 from theMSR322 sends masked data which is outputted to aPOS330. This data is then sent to aPDA device322 and on to adecryption service module334 linked to an optional cardauthenticity verification engine336, before said data is sent on to the associatedbank338.
• Referring now toFIG. 28, there is illustrated a flow chart of the enhanced data output format from an encrypted secure MSR transducer head module with a card data signature generator using the CPI and hidden DES system, at a point of sale (POS), in communication with a gateway to bank communication networks, constructed in accordance with the present invention. In operation, encrypted MSRs atvarious POS stations342,344 and346 are linked toPUS gateway1348 andgateway2352 which are in continuous electronic communication with encryptionkey databases350 forgateway1348 and encryptionkey database354 forgateway2352. Thegateways348 and352 communicate via a gateway to bank communication network ornetworks356 which direct the information via secure connections tolegacy transaction processors358,368 and374. Each legacy transaction processor is linked to an encryptionkey database360,364 and372, associated with a particular banks IT system. In this way the financial data can be directed to eachbank362,370 and376 in a form which the banking system can read.
• It is a further contemplated object of the present invention to provide a method of sending card authentication signature such as used in Secure Stripe® card authentication system in the otherwise masked data fields oftrack1, using an encrypted method similar to that used in thetrack2 account encryption method shown. It should he noted that the encryption method and the data placement can be varied to suit any particular application, and using the same method as previously shown fortrack2 data is merely a convenience. Data from any information track can he encrypted and utilized for this method and technique.
• The following examples of applications, implementation and operations allowed by the present inventive system are provided to demonstrate the scope and flexibility of the system disclosed herein.
EXAMPLE 1
• In one preferred embodiment of the secure magnetic stripe reader module consisting of a custom ASIC based magnetic head amplifier with integrated precision peak detector attached to a magnetic head and a microcontroller to decode the output of the ASIC and provide TDES encrypted data. The ASIC and a conventional processor, the Silicon Labs C8051F330, are placed on a PCB the size of the back of the magnetic head. The interface cable is attached to the PCB and the assembly mounts in shell of the magnetic head. The head is then potted with epoxy providing a secure barrier to the environment tampering.
• In high security applications a small amount of reactive material such as potassium is placed in the module prior to potting. If the unit is tampered with the reactive material is exposed and causes a reaction destroying the sensitive circuit components. In addition a fuse is placed on the PCB with allows the programming and debug connections to the microcontroller to be broken during final assembly of a product preventing access to the internal operations of the unit. The microcontroller decodes the F2F data encoded on the card and them uses multiple algorithms to decode the F2F data into any of multiple standard formats including ISO 7811, AAMVA, JIS, CDL, raw data, and other custom formats which may be added by the OEM using the module in a custom product. The converted track data is then encrypted to TDES using two 64 bit keys which where previously stored in the flash memory of the controller. The data is then compressed and output in one of multiple formats.
• The data output format is selected using the head interface connector option pins of through sending a command through the Rx data pin. The interface formats which can be selected are I.sup.2C, SPI, NRZ, or USB which all are well known standards. In addition TTL clock and data per track which is well known in the magnetic card reading industry may also be selected. An additional format can be supported which outputs the encrypted data in same F2F format which is encoded on the card at signal levels compatible with magnetic head output. This allows for legacy hardware to use the secure head module without changing the terminal hardware. In addition the secure head module can accept commands via the interface connecter Rx data line or through the use of specially formatted cards which are swiped to execute the commands. An additional format can be supported which supports RE communications such as Bluetooth. The data is converted to a suitable format and sent to either a RF transceiver internal to the head module or connected to the head module though the interface connector cable.
• These techniques allow for command operations in both WAP and Java or Pocket PC thin client applications. In addition to the described card reader functions the unit provides general purpose digital input/output pins at the interface connector. These pins can be controlled by custom applications supplied by the OEM integrating the module in there products. These pins along with the ability to add custom application firmware to the head module allow for added functionality that without these options would require an additional processor and circuitry. One such example is in a serial RS232 stand alone magnetic stripe reader. The added interface pins can be used to control a status indicator and to control the RS232 output driver. In addition custom firmware can be added to output the suppliers banded information and to support custom formats such as those used at conferences to track attendees.
EXAMPLE 1
• An encrypted secure magnetic head module in used to replace the magnetic head in a POS terminal to provide transparent operation for legacy systems.
EXAMPLE 2
• In another preferred embodiment of the secure magnetic stripe reader module is placed in a cell phone or PDA attachment as an enhanced magnetic stripe reader with power management as described in pending patent application Ser. No. 10/074,086 titled Magnetic Stripe Reader for PDA and Method of Making Same. In this embodiment the functionality of the previous work is enhanced with TDES data encryption for security.
EXAMPLE 3
• In another preferred embodiment of the secure magnetic stripe reader attachment for a handheld computing device such as a PDA or cell phone the secure magnetic stripe reader is mounted in conjunction with a secure pin entry keypad in the attachment device allow for secure PIN entry required to accept debit card transactions. Even with access to the internal components and wiring of the attachment the PIN number and card information are held securely inside each secure module with only encrypted data available via the internal wiring. Tampering with the secure reader or secure pin pad module makes the units inoperable.
EXAMPLE 4
• In one preferred embodiment of the secure gateway server receives transaction requests from multiple devices employing the secure MSR module. The transaction data consists of the MSR serial number followed by three blocks of TDES encrypted data containing the swiped card'strack2 data along with a time or transaction number stamp. A second optional TDES data block contains control information to enhance the server's optional application operations such as card authenticity verification, issuing merchant and command requests such as a change key request. Three optional clear text characters are used to signal start of serial number, start of optional encrypted data block, and end of transaction blocks. The various clear text characters also indicate various encryption options such as selection between multiple encryption keys and formats.
• Optionally for WAP based operations where transmission speed is a primary consideration, the transaction data format is adjusted to be a multiple of three characters in length. All transaction data including the serial number, encrypted data blocks, and clear text fields are sent as binary data. In this way a forty digit track two data block can be compressed from 40 to 20 bytes in length. The 8 digit serial number is compressed to 3 bytes in length. This converted binary data is converted to a format compatible with efficient keyboard emulation for the selected WAP device. In the case of Motorola WAP enabled cell phones with external keyboard support the each 3 bytes of binary data is converted to 4 mostly lower case ASCII characters. Using this technique the transaction data is sent in 38 characters rather then the 68 characters required if the data was not compressed.
• This secure gateway has access to a secure database containing keys for all readers allowed access to the gateway. The reader serial number which is sent as part of the transaction in clear text is used to access the key for the readers track data block. The selected key is then used to decrypt the track data which is then packaged and forwarded a conventional wireless gateway for processing. In this way a secure transaction can be maintained over unsecured data paths while maintaining complete compatibility with the current transaction processing services.
EXAMPLE 5
• In another preferred embodiment of the secure gateway server the transaction data consists of the MSR serial number followed by three blocks of TDES encrypted data containing the swiped card'strack2 data along with a time or transaction number stamp. A second TDES data block contains the secure stripe TM signature of the swiped card along with control information to enhance the server's optional application operations such as card authenticity verification, issuing merchant and command requests such as a change key request. Three optional clear text characters are used to signal start of serial number, start of optional encrypted data block, and end of transaction blocks. The various clear text characters also indicate various encryption options such as selection between multiple encryption keys and formats. This secure gateway has access to a secure database containing keys for all readers allowed access to the gateway along with information to complete the transaction such as the internet URL or the phone number of the transaction processing server to be used by this reader.
• In addition the gateway has access to a database containing valid secure stripe TM signatures and authentication decryption keys. The reader serial number which is sent as part of the transaction in clear text is used to access the key for the readers track signature block along with information to complete the transaction such as the internet URL or the phone number of the transaction processing server to be used by this reader. The selected keys are used to decode signature data along with a hash code generated by the secure module from the card data account number. The hash value generated from the card data is used to index the secure stripe database to retrieve the card signature. The database signature is then compared to the decrypted transaction signature and based on the comparison the transaction is sent to the processing bank indicated in the signature database or a message is sent back to the card holder requesting verification of the card's authenticity which may be in the form of a re-swipe of the card or entry of additional information such as billing zip code at which point the transaction is sent to the processing bank using standard formats or declined.
EXAMPLE 6
• In yet another preferred embodiment of the secure gateway server the transaction data consists of the MSR serial number followed by blocks of encrypted data containing the swiped card's track information along with a time or transaction number stamp and GPS location if available. A second TDES data block contains the secure stripe TM signature of the swiped card along with control information to enhance the server's optional application operations such as card authenticity verification, issuing merchant and command requests such as a change key request. Three optional clear text characters are used to signal start of serial number, start of optional encrypted data block, and end of transaction blocks.
• The various clear text characters also indicate various encryption options such as selection between multiple encryption keys and formats. This secure gateway has access to two databases one containing the secure MSR module control block key and a second containing valid secure stripe TM signatures. The reader serial number which is sent as part of the transaction in clear text is used to access the key for the readers track control and signature block. The signature consists of two parts one is the signature value generated during the card swipe and a second is a hash code of that track two card data also generated during the swipe. The hash value is used to index the secure stripe database to retrieve the card signature. In this way, no card data is available on the secure server. The database signature is then compared to the decrypted transaction signature generating a card reliability index which is sent to the processing bank as additional information.
• The bank also receives the encrypted card data may include the time of the transaction, the location of the transaction, and the secure modules unique transaction number. With this additional information the bank can made a more accurate ascertainment of the transactions authenticity prior to acceptance or denial of the requested transaction.
• It should be noted that even though these examples and the supplied figures illustrate the use of the internet as the communication method of choice and communication method such as leased phone lines, POTS, microwave point to point link may be used in place of the internet method. It should be further noted that Legacy systems such as employed by Veri Fone and Hypercom using POTS and leased lines also benefit form the described art for both Legacy and new system implementations.
• It should be understood, however, that even though these numerous characteristics and advantages of the invention have been set forth in the foregoing description, together with details of the structure and function of the invention, the disclosure is illustrative only, and changes may be made in detail, especially in matters of shape, size, construction, materials, chemistry and arrangement of parts within the principal of the invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.

Claims (18)

1-15. (canceled)

16. A method for processing token data for a purchase transaction, the method comprising:

a terminal receiving a first set of token data from a token;

the terminal encrypting selected characters of the token data;

the terminal replacing the original selected characters of the token data with the encrypted selected characters of the token data creating a second set of token data;

performing a modulo calculation on the second set of token data and determining a check digit that when inserted into the second set of token data will cause a modulo arithmetic check of the second set of token data to yield the same result as the modulo arithmetic check would yield on the first set of token data; and

inserting the check digit in the second data set to create a third data set; and

forwarding the third data set to a transaction processing entity.

17. The method ofclaim 16, wherein the second set of token data comprises a string of encrypted token data and original unencrypted token data assembled in the same format as the first set of token bank data.

18. The method ofclaim 16, wherein the check digit is appended to the second set of token data or replaces a character in the second set of token data.

19. The method ofclaim 16, wherein the check digit is added to the second set of token data at a predetermined location of the second set of token data.

20. The method ofclaim 19, wherein the predetermined location is one position prior to the last four digits of an account number.

21. The method ofclaim 16, wherein the check digit is added to the second data set at a predetermined location of the second data string and an digit in the first data set remains unchanged in the second data set.

22. The method ofclaim 16, wherein the first set of token data is track data from a track of the token.

23. The method ofclaim 16, wherein the first set of token data is PAN data from a token.

24. The method ofclaim 16, wherein the encrypting selected characters comprises converting the selected characters to eight bytes, and performing a triple DES encryption on the selected token data.

25. The method ofclaim 16, wherein the encrypting selected characters comprises and creating a second set of token card data comprises:

converting X digits of the first set of token to a predetermined number of Y bytes; and

performing a Y-byte encryption on the converted token data; and

converting the encrypted Y bytes of encrypted data to X digits.

26. The method ofclaim 16, wherein performing the modulo arithmetic and inserting the check digit comprises performing a modulo calculation on the X digits to determine the check digit and inserting the check digit in the appended predetermined digit.

27. The method ofclaim 16, wherein the token data that is encrypted is a subset of the original token data string, and the encrypted token data replaces the original token data at the same location or locations in the string.

28. A method for securing token data from a token presented for a purchase transaction, the method comprising:

a point of sale token reader receiving the token data from the token for the purchase transaction, wherein the token data comprises clear text token data read from the token at the point of sale, and the clear text token data include a mod10 check digit;

creating secured transaction data by selectively encrypting a first portion of the clear text token data such that a second portion of the clear text token data remains unencrypted in order to traverse the transaction processing network, the second portion including the mod10 check digit;

altering the encrypted first portion such that the mod10 check digit remain valid for the secured transaction data; and

forwarding the secured token transaction data to the transaction processing network for the purchase transaction.

29. The method ofclaim 28, wherein the last four digits of the second portion remain as clear text to maintain compatibility with purchase transaction receipt printing.

30. The method ofclaim 28, wherein an expiry date within the second portion remains as clear text to maintain compatibility with point of sale date checking.

31. The method ofclaim 28, wherein a bank identification number within the second portion remains as clear text to maintain compatibility with a point of sale network requirement.

32. The method ofclaim 28, wherein a portion of a bank identification number within the second portion remains as clear text to maintain compatibility with a point of sale network requirement.

Images