Patent Application
20130254117
The present invention relates to secure transactions, and more particularly, some embodiments related to a secured transaction system for securing transactions and access authorization over a network.
Token systems have been in use in modern civilization in various implementations to provide and control many forms of access. Access that can be and often times is controlled by tokens can include physical access to rooms, buildings, areas and so on; electronic, access to servers and data files; electronic account access; and so on. Another form of access controlled by tokens is the ability to conduct transactions such as, for example, credit, debit and other financial transactions. Credit cards, charge cards, debit cards, loyalty cards and other purchase-related tokens are used to provide the consumers with ready access to funds. Such transactions can enhance convenience of purchases, extend credit to customers, and so on.
As modern society has evolved, so have our tokens. Early tokens included physical objects such as coins, documents, and other physical objects. One example of a simple physical object token is the subway token made famous by the New York subway system. This simple token resembled a coin, and could be purchased at kiosks and was used to control access to the subway system. Another example of simple physical token for granting access was the early railway token developed, in the 19th century for the British railway system. This token was a physical object, such as a coin, that a locomotive engineer was required to have before entering a particular section of the railway. When the train reached the end of the section, the driver left the token at a drop point so it could be used by the next train going the other way. Because there was only one token for a given section of railway, the token system helped to ensure that only one train would be on that section of the track at a given time.
The railway token system minimized the likelihood of head on collisions, but this simple token also limited the ability for trains to follow one another along a given section. As such, the system evolved into a token and ticket system. In this system, if a train reached a checkpoint and the token was present, the driver was given a ticket to pass, leaving the token in place in case another train approached that section traveling in the same direction. Safeguards were implemented to ensure that tickets were correctly issued. As technology evolved, the physical token and ticket system evolved to include electronic signaling to control access to sections of the railway.
Other examples of tokens to grant access are charge cards, credit cards and debit cards. Some attribute the ‘invention’ of credit cards to Edward Bellamy, who described them in his 19th century novel Looking Backward. Early cards were reportedly used in the early 20th century United States by fuel companies and by Western Union. By mid-century, Diners Club produced a charge card for merchant purchases, which was followed shortly thereafter by American Express. These cards, now ubiquitous in our society, allow customers to make purchases and conduct transactions with relative ease. Early cards were embossed with a customer account number, which was manually transferred to a receipt via a carbon transfer process. Modern cards, or tokens, have evolved to use electronic mechanisms of storing data including, for example, magnetic stripes, REID tags, biometric, based tokens including fingerprints, iris scans, voice recognition and smart card and chip card technologies.
Other examples of tokens include government issued IDs such as driver's licenses and passports. Such tokens can also be used to control access in various forms. For example, a passport can be used to control access to countries and regions. Passports can also be used to access employment and licensing opportunities as a document to prove the holder's citizenship. A driver's license is another form of token, allowing access to driving privileges, and to establishments requiring proof of identity, residency or age. Still other examples of tokens can include bank drafts, stock certificates, currency and other token items relating to finance. Still further token examples can include tokens for physical access and security such as keys, card keys, RF or LC cards, RFID tokens, toll road transponders, and the like.
As these examples illustrate, the use of tokens for various forms of access has gained popularity in various business and industries and has evolved to embrace newly developed technologies. Tokens are not limited to these examples, but can take on various forms and use various instrumentalities and control, govern or arbitrate various forms of access in a variety of different ways. One downside of token access, however, is the opportunity to defraud the system. For example, stolen or counterfeited tokens are often used to gain unauthorized access. In fact, the Federal Trade Commission reports that credit and charge card fraud costs cardholders and issuers hundreds of millions of dollars each year.
Computer programs that are used to secure tokens to prevent fraud are themselves open to attack. To prevent rogue application programs, Trojan horse attacks or viruses from gaining access to the systems using for processing tokens, testing and certification must be completed on the operating system and all applications that can access sensitive information. Even a minor change to an application with no direct access to sensitive data can provide a path for compromising the system. An application that forces a buffer overflow condition has been known to grant complete access to all resources within a computer, including any sensitive data areas. In order to protect against security failure when any part of the security system is changed, all of the application and the operating system must be retested.
Current trends of using mobile platforms including mobile phones, tablets and PDAs and their corresponding operating systems as platforms for processing financial transactions has enabled millions of small merchants to process financial token based transactions. This trend has also supplied a platform for hackers that can be attacked anonymously from private locations rather that at a customer facing POS in a traditional brick and mortar store. Security policies and procedure to adequately handle this new system vulnerability are still lacking.
Due to the large scale loss of sensitive financial data the Payment Card Industry (PCI) was formed as a regulating body to introduce regulations to protect against the loss of sensitive financial data. Included in the new regulations is the use of data encryption and the protection of the associated encryption keys. PCI compliance specifications describe requirements for testing, and auditing financial transaction networks and devices. Among the requirements imposed by these standards is the periodic validation testing of financial processing networks along with conformance testing of hardware devices for token entry. While, these standards have reduced the loss of sensitive financial data, the subsequent manufacture and use of fraudulent financial tokens have limited their effectiveness because the testing is periodic rather than real time. One large financial institution lost sensitive data only one week after passing a data security validation test.
Data encryption has brought a system view to the payment card network. In the past the magstripe reader output clear text to the POS which in turn placed that information in a gateway compatible clear text message which could be reformatted at the gateway or processor to for Visa Net or any other backend system. The terminal manufacturer had little need to understand the payment backend network. Now with the addition of encryption the data keys must be maintained at both ends of each data hop so that the data can be decrypted reformatted and encrypted for the next hop. In addition each server where the data is in the clear must be certified routinely for the new security measures to prevent data and key loss. In some systems the data encrypted in the magstripe reader can be sent to the issuing bank before it is decrypted while in other systems it is decrypted in the POS. To successfully implement a secure data exchange between the cardholders swipe of his credit card at the POS and that data reaching the issuing bank for authorization requires that each POS transaction be understood on a system level.
The security issues brought to light with the addition of encryption to the magstripe reader have been widespread. It has been common for hospitality POS systems including restaurants to enter card data into non-secure PC based POS systems. These systems in turn have been a major focus of attack to attain valid transaction data to use in fraudulent transactions. Valid card data has regularly been found in used PC based POS terminal purchased form eBay by the author. Much of the stolen credit card magstripe data has come from restaurant POS system where malicious software inserted into the POS copies credit card information and delivers it via email or USB drive to the attacker.
In addition to the new requirements for hospitality, call centers routinely take customer data and enter it into call center POS terminals, which are based on non-secure PC platforms. For these systems in addition to the vulnerabilities of malicious software inserted into the POS the manual entry of cardholder data is susceptible to loss from data scanning bugs placed into the device or remote cameras viewing the device display.
Data encryption requires the use of significant computing power to address the needs of the algorithms employed. In a single magstripe read operation of a POS terminal, the effect of an encryption cycle for a single purchase is not significant. Yet for a gateway or processor which may receive thousands of transaction requests from multiple terminals each second the computing resources are formidable. One benchmark requires a decryption appliance to be able to perform one thousand decryptions per second.
Recently updated PCI standards including the use of encryption and the protection of associated encryption keys will help to reduce the loss of sensitive financial data when they become fully implemented. During this transition period multiple years will pass that only a portion of the sensitive financial data is adequately protected from the point of entry throughout the financial transaction networks and devices.
Encryption, key management and control functions required by the PCI 3.0 mandate that the magstripe readers in POS devices, that currently transmit unprotected data, to protect all financial data and the associated encryption keys with a high level of certainty. Currently only Pin Entry Devices are required to meet this level of security. The costs imposed by these new standards related to key management can be staggering.
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 and pin data encryption and authentication can be implemented at the edge of the network.
Token and pin data encryption and authentication may be done by adding an intelligent security module at the edge of the payment network. Preferably, the intelligent security module is located at or near the point of sale and at the point of swipe for transaction card data entry. The security module may include, in one embodiment: a first application microprocessor configured to perform a non-security task on a token information, wherein the non-security task includes one or more tasks from the group including: decoding magstripe data, outputting status information to display devices, processing non-security related applications, processing communication channels such as USB and corn ports, providing keypad scanning functions, providing radio communication support, accepting and processing command requests, encryption determination, encryption-decryption request, key management, token information delivery, or transactional data delivery; and a second security microprocessor configured to perform security-related tasks based on a request from the first microprocessor, wherein the security-related tasks includes one or more tasks from the group of token information authentication, token information decryption, or token information encryption, random number generation, symmetric key encryption including VDES, TDES and AES, public key encryption and authentication, security related command decryption, decoding and application processing. Limiting access of the application processor to the security processor prevents rogue applications running on the application processor from creating adverse affects on the security processor though buffer over-run or other attacks because none of the security processor resources are directly connected to the application processor resources. In one embodiment, a single, well-defined mailbox is the only communication channel between the two processors. Only commands defined for the mailbox interface are executed providing a secure firewall between the two processors.
in one embodiment, the security microprocessor used to protect encryption keys and decrypt, reformat and re-encrypt transaction data is based on smart card technology and provides various attack defeating technologies not provided by the application processor including differential power analysis, chip security grids and automatic key deletion among others.
In one embodiment, the application processor and the security processor are permanently linked at manufacture during the first power-up cycle. Each processor generates random keys and passes them to the other using asymmetric or symmetric key methodologies. Once the new keys are transferred, the power-up keys are deleted and the power-up key process permanently disabled.
Initial secure key loading and reloading represents one of the most difficult aspects of encryption. In one embodiment, using a security processor based on smart card technology, the initial keys and certificates are loaded using the current secure infrastructure during the production of the security processor in the same manner as smart cards are loaded today. These are the same type of smart cards that are used to transfer keys and certificates between hardware security modules used to protect transactional data by financial institutions.
In one embodiment, man in the middle attacks are prevented during manufacture by having the application processor generate a random key and encrypt it with the security processors public key prior to sending it to the security processor. The security processor decrypts the received key uses the key to encrypt a randomly generated local key with the application processors generated and return it to the application processor. A man in the middle can mimic the application processor by encrypting is own key yet it will not be able to decrypt data encrypted by the application processor using, its key. Since the encrypted data from the security processor to be transferred from the application processor over a network to the financial institution is wrapped in the application processors key and must be unwrapped prior to transmission the man in the middle cannot send data through the application processor. Further since the security processor is loaded with keys at manufacture and prior to this wedding process with the application processor the man in the middle cannot impersonate the security processor to the application processor.
in many new transaction processing applications the traditional POS terminal has been replaced with alternative platform devices such as mobile phones and handheld computers. Unlike the traditional POS terminal which have security measures including secure operating systems, only applications that have been pre-tested for security vulnerabilities, anti-tamper devices built into the enclosure along with PCI certification testing, these new platforms are known to have vulnerabilities that may allow for the transaction data to be compromised. In one embodiment, the intelligent security module is located such that the transaction data is collected at the point of entry and secured prior to entering the point of sale device.
In one embodiment, in the case of mobile phones and tablets the data is collected and encrypted prior to being sent as audio input to the phone using the microphone jack, in addition the headphone output is used to supply data and power to the security module via audio tones.
In one embodiment, in the case of mobile phones and tablets the data is collected and encrypted in an accessory to the mobile device prior to being, sent via a platform provided communication connection. In one embodiment, the connection is via a wireless link and in another, the connection is via a hardware connection. In addition, the hardware connection is used to supply data and power to the security module and token reader.
In one embodiment, the financial token reader accessory is used to verify the user of the POS device by reading an identity token of the same physical nature as the financial token. In one case the financial token is a credit card containing the customers financial transaction information and the POS users token is a magstripe card with the same physical nature as the credit card encoded with the POS users identity information. In another embodiment the POS users token is authenticated when swiped using a magstripe authentication system such as Warble® and the results used to allow or deny the POS transactions. In yet another embodiment Warble® is also used to authenticate the credit card token.
In one embodiment, the financial token reader accessory includes a biometric token reader. The biometric token reader is being used to verify the POS operators biometric credentials to allow or deny POS operations. In one embodiment, the biometric token reader consists of a fingerprint reader in addition to a magstripe reader. The POS operator swipes his enrolled finger over the fingerprint reader verifying his identity and then the customer swipes their credit card.
In one embodiment, the financial token reader accessory is used in conjunction with a PC based POS system for the entry of swiped magstripe data and manual entered card data where the keyboard and display is configured to lower the risk of a malicious device from reading non-encrypted data. In one embodiment the tradition LCD display is replaced with LEDs on the keys and to show key entry without showing the digits entered.
In one embodiment, the token to be secured is biometric information captured at the time of the transaction, combined with local and remote device and transactional data and issuer and account identity information. Biometric information can be, by way of example, but is not limited to, a fingerprint, a fingerprint template, an eye scan, or any other biometric information to determine an individual person's identity. Local device information can include, by way of example but not limited to, the serial number of a POS device, geographic location at time of sale, a phone number or MAC address of a mobile device, or a previously exchanged secret or key stored in the POS device or the security processor. Transactional data can include, but is not limited to, any information about the entity providing goods or services, a date, a description and price of the services or goods, geographic data indicating the location of the service or sale of goods. Because this embodiment securely ties together the issuer, the purchaser, and the seller for a given goods or services transaction, it facilitates bypassing the current payment card industry infrastructure, especially when the security module is preloaded with issuer keys or certificates.
In one embodiment, where the platform provides for attachment authentication, such as supported by Apple iAP devices, the authentication chip is used to replace or enhance the token input device security processor.
In the case of mobile phone magnetic stripe reader accessories that receive power form the headphone jack power management is a crucial aspect of the system design. In general, the headphone output from a mobile phone is in the order of ±500 Mv. In one embodiment a unique circuit has been developed that uses the dual stereo channels to double the output voltage. A variety of unique methods to use this technique are presented. In each case the forward diode voltage (Vf) drop of the rectifier diodes must be taken into account. The Vf presents a series voltage drop to the signal to be rectified. The Vf reduces the amount of voltage available to power the circuit. A full wave bridge rectifier lowers the output by two time the Vf. Diodes optimized for low voltage drop 50 mV to 350 mV depending on the current level flowing through them. On method uses a full wave bridge rectifier and id the least efficient. The full wave rectifier takes an AC input signal around and outputs pulsed DC signal referenced to ground. The diodes also prevent current flow back through the diodes when the pulsed voltage is lower that the output voltage across the filter capacitor. Another method uses four FET transistors to steer the input AC voltage so that the voltage is referenced to ground and a diode to prevent the reverse current flow. This lowers the Vf to that of one diode drop. As the current flow through a diode increases so does the voltage drop. In another method multiple diodes are placed in parallel to lower the Vf by spreading the current among multiple diodes. As any individual diode current goes up in relation to the others its VF will increase lowering its current relative to the others. By spreading the current over three diodes of an audio jack transaction card reader the Vf can be reduced significantly. In another method, a transformer can be used with the previous methods to increase the voltage present to power the device and the expense of lowering the current available.
In addition, in the case of mobile phone magnetic stripe readers that receive power by driving the two output channels 180 degrees out of phase the ground reference of the powering device must be taken into consideration. The mobile phone ground reference must be maintained for AC signals. Among the methods presented in the embodiments is isolating the two output channels using a transformer or AC blocking diodes and the powering device ground reference is AC coupled to the magnetic stripe reader power circuit preventing interaction between the two functions.
In other transaction processing applications the traditional POS terminal has been replaced with standard platform devices such as mobile and desktop computers mobile phones and tablets. These computers run operating systems such as Microsoft Windows and Linux which are known to have security vulnerabilities. Unlike the traditional POS terminal which has security measures including secure operating systems, only applications that have been pre-tested for security vulnerabilities, anti-tamper devices built into the enclosure along with PCI certification testing, these new platforms are known to have vulnerabilities that may allow for the transaction data to be compromised. In one embodiment, the intelligent security module is located such that the transaction data is collected and secured prior to entering the computer using a portable token reading, security module. The secured data is then transferred to the computer using any of its communication channels including USB, Bluetooth and serial ports.
In other transaction processing applications, the traditional POS terminal has been replaced with multiple device platforms such as mobile phones and desktop computers. In these application the business owner may be required to purchase and maintain multiple POS transaction processing, devices to support the multiple platforms. Each device can require a separate merchant account to process transactions. According to one embodiment of the invention the portable security module is equipped with multiple interfaces such as USB and audio phone jack. Either interface can be selected depending on the current requirement of the transaction processing platform. The POS application running on either device: formats the previously encrypted token data to be compatible with the processor or gateway being used by the POS application.
Encryption, key management and control functions required by the PCI 3.0 SRED standard incorporates varying levels of protection based on the type of data being protected. For example, private and symmetric keys require a higher level of protection than public keys or encrypted data. The security module may include, in one embodiment, a first application microprocessor configured to perform a low-security task on a token information such as decoding the magstripe data and encrypting the data along with other information such as the magstripe warble signature with the public key of the high-security module, wherein the high security task includes one or more tasks from the group including: receiving the data encrypted by the low-security processor and using the high-security processors private key to decrypt the data and reformat the data into a second encrypted format compatible with the POS or financial transaction network.
PCI 3.0 requires that the physical connection between the magstripe read head, the read head analog electronics and the data encryption module be protected from the attachment of data capture devices designed to collect clear text transaction data. In accordance with one embodiment of this invention the read head analog electronics in integrated into the data encryption low-security processor module, which is secured within the magnetic read head.
In accordance with one embodiment of this invention, the processor module monitors a security grid built into the head module protecting the head to processor connections from tampering.
In accordance with one embodiment of this invention the head analog and digital processor module secures the connection between the head and the processor module by injecting a random signal into the magnetic read head. During a read operation the injected signal is summed with the read signal canceling the injected signal and allowing the data to be read.
In accordance with one embodiment of this invention the head analog and digital processor module consists of a custom ASIC. In another embodiment a COTS (commercial off the shelf) processor is used in conjunction with a novel circuit design to provide the required magnetic peak location accurately at a much lower cost than developing a custom ASIC.
In accordance with FIPS 140-2, the requirements and testing procedures for a hardware security module require the physical boundary to be specified prior to testing. If that boundary is specified as the area encompassing the high-security processor and there is no physical connection to the security processor that can be compromised, then the area within the boundary is the only area required to be tested.
Because only the security processor has access to sensitive information, only the secure processor code and hardware require certification and testing for security flaws with any change to the security system. The application processor can be altered with little or preferably no chance of compromise of the security processor, thus reducing the number of re-certifications required and extent of the recertification testing requirements.
The embodiments described herein are not limited to processing and securing token information, and can also be used for source authentication, random number veneration and other hardware security module functions.
The subject of token information processing will now be described in accordance with various embodiments. The token information can have at least a primary account number of a bank card. The token information can also be encrypted by the first processor with a unique key associated with a second microprocessor. In this case, the second microprocessor can be configured to decrypt the token information, determine a correct encryption key based on a merchant identification and to encrypt the token data using the correct encryption key.
In one embodiment, the first processor is a special purpose device suited to reading and decoding and reformatting the token data and the second processor is a special purpose device suited to high security encryption applications hereafter called a HSM.
The token information can also be encrypted by the first processor using the asymmetric public key of the second microprocessor. This limits the scope of keys in the first processor to that of a public key supporting its lower security level. The HSM protects all other keys.
In one embodiment, the first and second processor are in close proximity to each other such as mounted on the same PCB within the magnetic head structure. On first power up of the assembled unit at manufacture the HSM generates a random public/private key pair. It then sends the public key to the first processor which returns a randomly generated symmetric key encrypted using the HSM public key. The HSM then generates a second key pair, encrypts the new public key with the first processors symmetric key and returns the encrypted public key to the first processor which decrypts the public key. The first processor then encrypts a key generation complete message to the HSM which replies with a second key generation complete message encrypted with the first processors symmetric key.
In one embodiment, the first processor and the HSM permanently disable the ability to generate a first shared symmetric key or asymmetric key pair and are considered wed.
In another embodiment, the I-ISM sends the first processor an encrypted DUKPT root or base derivative key using the first processors symmetric, key. The first processor then initializes its DUKPT key generator and discards the root key.
In one embodiment, the second microprocessor is configured to re-encrypt the decrypted token information with a unique merchant key and to send the re-encrypted token data to the first microprocessor.
In one embodiment, the data encrypted by the security processor and output to the financial network for processing is encrypted using a Format Compatible Encryption. Format Compatible Encryption provides output data that maintains the transport format not the clear data format. The length and character set can be changed to provide for additional data to be transmitted. The additional transport data space can be used to hold transaction encryption data such as the DUKPT KSN.
In another embodiment of the present invention, a method for processing bank card transactions may include: receiving a token information: performing a low-security task on the token information using a first microprocessor, wherein the low-security task includes one or more tasks from the group of encryption determination, encryption-decryption request, key management, token information delivery, or transactional data delivery; and performing a security-related task on the token information using a second microprocessor based on a request from the first microprocessor, wherein the security-related task includes one or more tasks from the group of token information authentication, token information decryption, or token information encryption.
In another embodiment, the decrypting step comprises determining a correct decryption key based on a merchant identification, and/or the token unencrypted data and then decrypting the encrypted token data using the correct decryption key. In yet another embodiment, the method includes a procedure to re-encrypt the decrypted token information with a unique merchant key using the second microprocessor and sending the re-encrypted token data to the first microprocessor.
Encrypting the transaction data using the application processor and security processor with a magnetic stripe reader is not a time intensive operation. Decrypting the data from multiple readers simultaneously at the gateway or processor is time critical. A current benchmark for this decryption appliance is to provide for 1000 decryptions per second. Currently servers and HSMs costing tens of thousands of dollars are used to meet this decryption requirement. In one embodiment, the decryption appliance consists of an array of the security processors similar to that used to encrypt the data and the point of swipe. An array of 1000 security processors each providing one decryption per second provides the same throughput at a fraction of the implementation cost. In addition, since the security perimeter is each processor the decryption appliance construction against tampering is greatly reduced.
In yet another embodiment, the security-related task may include one or more tasks from the group of PIN information authentication, PIN information decryption, or PIN information encryption. The method may also include the procedure of: receiving a PIN information; determining whether the PIN information is encrypted using the first microprocessor; decrypting the PIN information using the HSM; re-encrypting the decrypted token information with the decrypted PIN information using the HSM; and sending the re-encrypted token data to the first microprocessor.
In another embodiment according to the present invention, a method for processing bank card transactions includes; receiving token information from a token card; determining whether the token information is encrypted using a first microprocessor; sending a request from the first microprocessor to a HSM to decrypt an encrypted token information; and decrypting the encrypted token information using the HSM processor. The method may also include the step of receiving a PIN information; decrypting the PIN information if it is encrypted re-encrypting the decrypted token information with the decrypted PIN information; and sending the re-encrypted token data to the first microprocessor.
In another embodiment according to the present invention, a secure transaction apparatus configured to process bank card transactions includes: a first microprocessor configured to receive token information from a token card and to determine whether the token information is encrypted; and a second microprocessor configured to decrypt an encrypted token information based on a request to decrypt from the first microprocessor.
In another embodiment according to the present invention, a secure transaction apparatus configured to process financial card transactions includes: a card reader configured to extract token data from a token card, the card reader having a first security module; a user interface module having a third security module; a communication interface coupled to the card reader, the display module, and the user interface. In this embodiment, each of the security modules comprises: a first microprocessor configured to perform a non-security task on a token information, wherein the non-security task includes one or more tasks from the group of encryption determination, encryption-decryption request, key management, token information delivery, or transactional data delivery; and a second microprocessor configured to perform a security-related task on the token information based on a request from the first microprocessor, wherein the security-related task includes one or more tasks from the group of token information authentication, token information decryption, or token information encryption.
The secure transaction apparatus may also include a biometric module configured to collect biometric data from a user, the biometric module having a third security module, wherein the third security module is similar to the first security module.
In one embodiment, the secure transaction apparatus includes a keypad module configured to collect PIN information from a user, the keypad module having a third security module, wherein the third security module is similar to the first security module.
Other features and aspects of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the features in accordance with embodiments of the invention. The summary is not intended to limit the scope of the invention, which is defined solely by the claims attached hereto.
The present invention, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict typical or example embodiments of the invention. These drawings are provided to facilitate the reader's understanding of the invention and shall not be considered limiting of the breadth, scope, or applicability of the invention. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale.
The figures are not intended to be exhaustive or to limit the invention to the precise form disclosed. It should be understood that the invention can be practiced with modification and alteration, and that the invention be limited only by the claims and the equivalents thereof.
The present invention is directed toward a system and method for providing a system for facilitating token access in various forms. In one embodiment, the system provides systems and methods for secure token access across a communication medium.
Before describing the invention in detail, it is useful to describe an example environment with which the invention can be implemented. One such example is that of a transaction card network that includes a token used to facilitate purchases or other transactions.
The token data in this example is then sent to the appropriate financial institution or institutions, or other entities for processing. Processing can include, in one or more steps, authorization, approval and settlement of the account. As the example in
As only one example of a token 110, a credit card can be used with a conventional magnetic stripe included on one side thereof. Conventional magnetic stripes can include three tracks of data. Further to this example, the ISO/IEC standard 7811, which is used by banks, specifies: that track one is 210 bits per inch (bpi), and holds 79 six-bit plus parity bit read-only characters; track two is 75 bpi, and holds 40 four-bit plus parity bit characters; and track three is 210 bpi, and holds 107 four-bit plus parity bit characters. Most conventional credit cards use tracks one and two for financial transactions. Track three is a read/write track (that includes an encrypted PIN, country code, currency units, amount authorized), but its usage is not standardized among banks.
In a conventional credit card token, the information on track one is contained in two formats, Format B includes the following:
The format for track two can be implemented as follows:
Although a credit card with magnetic stripe data is only one example of a token that can be used in this and other environments, this example environment is often described herein in terms of a credit card implementation for clarity and for ease of discussion.
Upon entering into a transaction, a merchant may ask the customer to present his or her form of payment or credentials, which in this example is the credit card. The customer presents the token 101 (e.g., credit card) to the merchant for use in the transaction POS 104. In one embodiment, the credit card can be swiped at a magnetic stripe reader or otherwise positioned to be read by the data capture device 103. The swipe of the credit card across the magnetic stripe read head inputs a signal into the magstripe reader representative of the magnetic flux transitions pattern encoded onto the magnetic stripe. The read electronics detects the relative locations of the flux transitions and converts the patterns into the corresponding card data values. The data is generally output as ASCII text values of the credit card data. In the current example where a credit card utilizing a magnetic stripe is the token 101, data capture device 103 can include any of a variety of forms of magnetic stripe readers to extract the data from the credit card. In other embodiments or implementations, other forms of data capture devices 103, or readers, can be used to obtain the information from token 101. For example, bar code scanners, smart card readers, RFID readers, near-field devices, and other mechanisms can be used to obtain some or all of the data associated with token 101 and used for the transaction.
The data capture device is in communicative contact with a terminal or point of sale (POS) 104, which can include any of a number of terminals including, for example, point of access terminal, an authorization station, automated teller machine, computer terminal, personal computer, work stations, cell phone, PDA, handheld computing device and other data entry devices. Although in many applications the data capture device 103 is physically separated, but in communicative contact with, the POS 104, in other environments these items can be in the same housing or in integrated housings. For example, terminals such as those available from companies such as Ingenico, Verifone, Apriva, Linkpoint, Hypercom and others can be used.
Continuing, with the credit card example, the customer or cashier can swipe the customer's credit card using the card-swipe device, which reads the card data and forwards it to the cashier's cash register or other POS 104. In one embodiment, the magnetic stripe reader or other data capture device 103 is physically separated, but in communicative contact with, the POS 104. In other environments, these items can be in the same housing or in integrated housings. For example, in current implementations in retail centers, a magnetic stripe reader may be placed on a counter in proximity to a customer, and electronically coupled to the cash register terminal. The cash register terminal may also have a magnetic stripe reader for the sales clerk's use.
The customer may be asked to present a form of ID to verify his or her identity as imprinted on the token 101. For other transactions such as debit card transactions, the user may be required to key in a PIN or other authentication entry.
Continuing with the current credit card example, the POS 104 can be configured to print out a receipt (or may display a signature page on a display screen) and the customer may be required to sign for his or her purchases, thus providing another level of authentication for the purchase. In some environments, POS 104 can be configured to store a record of the transaction for recordkeeping and reporting purposes. Further, in some environments, a record of the transaction may be kept for later account settlement.
Typically, before the transaction is approved, POS 104 seeks authorization from one or more entities in a transaction processing network 123. For example, the merchant may seek approval from the acquiring bank, the issuing bank, a clearing house, or other entity that may be used to approve such transactions. Thus, depending on the token type, institutions involved and other factors, the transaction processing network 123 can be a single entity or institution, or it can be a plurality of entities or institutions. As a further example, in one embodiment, transaction processing, network may include one or more processors or clearing houses to clear transactions on behalf of issuing banks and acquiring banks. The transaction processing, network also include those issuing banks and acquiring banks. For example, one or more entities such as Global Payments, Visa, American Express, and so on, might be a part of transaction processing network. Each of these entities may have one or more processing servers to handle transactions.
In some instances, the approval may also constitute the final settlement of the transaction resulting in the appropriate funds being transferred to consummate the transaction. In other embodiments, however, the authorization may simply be an authorization only and actual account settlement can take place in a subsequent transaction. For example, authorization may verify the validity of certain information such as the account number, expiration date, customer name, and credit limit to determine whether to approve the transaction. Settlement may be accomplished when a series of one or more approved transactions are sent to the appropriate institution(s) for transfer of the funds or other account settlement.
As illustrated in
Although transaction processing network 123 is illustrated using only one block in the example block diagram environment of
Having thus described an example environment, the present invention is from time-to-time described herein in terms of this example environment. Description in terms of this environment is provided to allow the various features and embodiments of the invention to be portrayed in the context of an exemplary application. After reading this description, it will become apparent to one of ordinary skill in the art how the invention can be implemented in different and alternative environments.
As mentioned, before the transaction is approved, POS 104 seeks authorization from one or more financial institutions in network 123. However, based on the architecture of network 100, neither POS 104, gate 120, nor the financial institutions in network 123 can detect in real-time if data capture device 103 has been compromised. For example, device 103 can be compromised in such a way that data from token card 101 can be captured and stored using an unauthorized and altered data capturing device that looks and functions in the same way as an original and authorized data capturing device 103. The unauthorized-altered device can be switched with the original-authorized data capturing device 103 from unsuspecting retailers. This can be done by a misaligned employee of the retailer or by individuals posing, as authorities for one of the network payment providers such as VISA, MasterCard, or American Express. Typically an unauthorized, altered data capturing device 103 is configured to capture token data from token card 101 and the personal pin, if any, for token card 101. The captured data is then stored and transmitted to the fraud perpetrators, and is then used create a clone card or to make illegal online transactions.
Another example of an attack on a network similar to transaction network 100, is a relay attack on a chip-and-pin network. In the relay attack, instead of connecting to the customer's hank via gateway 120 or communication channel 122, the unauthorized, altered data capturing device 103 connects to a computer in the retailer such as a restaurant or to a remote computer and relays the captured token data to the computer. A second remote computer in communicative contact with the first computer in the restaurant can be located at another retailer such as a jewelry store across town. The second computer then receives the captured data from the legitimate card in the restaurant and reprograms a modified bankcard with the captured data. The chip in the modified bankcard is typically removed or altered to be in communicative contact with the second computer. In this way, once the customer in the restaurant has entered their PIN, the fraud perpetrator in the jewelry store puts the knock-off card in the jewelry store's terminal. All transactions from the jewelry store are relayed between the modified bankcard, the two computers, and the unauthorized terminal to the legitimate card. This establishes a link between the jewelry store's terminal to the customer's bank. Thus, instead of paying for example for a $30 meal, the customer is defrauded out of thousands of dollars for jewelry purchases. As can be seen, during this relay attack the perpetrator does not need to hack into an systems or run any decryption, as data is simply being relayed from one terminal to another.
The current architecture of payment networks like, are not configured to detect the above examples of fraud in real-time. Typically, the fraud detection comes after the transaction is made by looking at statistical data or after the customer notified his or her bank that unauthorized transactions have occurred. The intelligence to detect authorized transactions or hacked terminals, if any, of such networks are located at network 123. This, however, is too late to stop illegal transactions as they are occurring.
Traditional financial networks like also cannot perform token and PIN data authentication locally (near the POS), meaning the token and PIN data cannot be authenticated without first transmitting the token and PIN data over the network to the financial institution (e.g., issuing hank) for authentication. For example, in VisaNet, the token and PIN data have to go through one or more gateways and/or data aggregators before arriving at the issuing bank, which then forwards the data to a decryption appliance for verification. Because of the route the token and PIN data have to navigate before arriving at the decryption appliance, there is an inherent delay in the authentication process. Thus, token and PIN data cannot be authenticated locally in real-time. This authorization process is disadvantageous for the retailer because the authentication process is controlled by the payment network instead by the retailer or the cards issuing bank.
Additionally, traditional financial networks maintain control of the authorization process currently used by most retailers by requiring all transaction data to be routed through their networks. This is accomplished by requiring the retailer to use a certified card terminal without the intelligence or the ability to extract necessary information from the token card to enable the card terminal or a POS terminal of the retailer to perform authorization and settlement directly with the issuing bank, A conventional card terminal is configured in such a way such the retailer can only communicate with the traditional payment network or with retailer's bank directly, which in turn sends the authorization and settlement request to the issuing bank. For example, in the Discover Network, to obtain authorization after a card holder presents the card to the retailer, the following steps occur: 1) retailer sends transaction data to an acquiring bank (retailer's bank); 2) the acquiring, bank sends the transaction data to the issuing bank via the Discover Network; 3) the issuing bank then authenticates the card and authorizes the transaction; 4) the issuing bank sends an authorization message to the retailer via the acquiring bank. As described above, the payment networks such as VisaNet and Discover Network maintain control of the authorization and payment process by controlling the way transaction data is routed.
The present invention is directed toward a system and method for securing transaction with security and intelligence at the front end or edge of the network. The front edge of the network can be defined as any point upstream of gateway 120. In one specific embodiment, the front edge of the network is any point upstream of POS 104, but including POS 104.
In one embodiment, encryption information such as a Key Serial Number (KSN) is output in a compatible format to magstripe data with the encrypted card data.
In one embodiment, the data capture device 103 accepts clear text data from the input token and encrypts the data with a DUKPT derived single use key and transmits the encrypted data along with the application specific data format to the security processor 220. The security processor 220 decrypts the data and re-encrypts the data using the POS 104, gateway 120 or transaction processing, network 123 keys and encryption format specified by the application processor 210. The re-formatted data is then returned to the application processor 210 to be included in the data packet to be sent to the POS 104, or gateway 120 or transaction processing network 123 for processing.
In one embodiment, the security processor 220 re-encrypts the data as compressed ISO 7813 financial transaction data using the maximum data count for each track and the data is output as ISO 7813 magnetic stripe data. The data compression along with using the maximum data count allows for additional information to be included with the original transactional data.
In one embodiment, the security processor 220 re-encrypts the data using the largest radix supported by the data transport. In the case of 8 bit binary data the radix of 256 is used, in the case of upper case alphanumeric with punctuation base 42 is sed.
In one embodiment, some of the additional data space created through the compression is used to send the DUKPT KSN with the data.
In one embodiment, some of the additional data space created through the compression is used to send other information used to authenticate the token.
In one embodiment, the PAN which is 14 to 16 digits in length is expanded to the maximum field length of 19 digits. The added digits are placed after the first six digits and prior to the last 4 digits of the PAN to allow for band rounding and receipt printing functions. The digits placed in the expanded data fields are used to convey encryption and status information such as the type of encryption being used and part of the KSN for decryption purposes.
In one embodiment, the application processor send the encrypted transaction data to the POS 104, or gateway 120 or transaction processing network 123 for processing and in addition sends related encryption information such as the DUKPT KSN and other information to authenticate the transition as a separate data packet to the POS 104, or gateway 120 or transaction processing network 123 for processing the encrypted data.
In one embodiment, the application processor 210 can specify that the security processor 220 format the encrypted data in a format preserving or a format compatible structure for a specific target. The target maybe the POS, the gateway, the processor, or any other target for the encrypted data. In which case the application processor 210 encrypts the card data using the security processors 220 shared or public key, then sends the encrypted data to the security processor 220 where the data is decrypted, reformatted into the specified format and re-encrypted using the using the targets shared or public key of the specified target.
In one embodiment the application processor 210 and security processor 220 are located in the same physical processor. In one embodiment, the processor is configured with multiple cores and the application and security functions are separated by processing cores. In another embodiment, the application and security functions are separate tasks within in a single core processor.
In one embodiment the fingerprint token is generated from the operator of the data capture device 103 to verify the operators credentials to process a magstripe transaction. The token is sent to the POS 104 for authentication of the POS user using the store 105. The POS 104 enables or disables the magstripe token reader 103 to process to magstripe transaction. In on embodiment, the customer is given the option to use a magstripe token 101 or a fingerprint token 230 to imitate the transaction.
In one embodiment, the customer supplies a fingerprint token 230 which the POS forwards the token to processing network 123 via the to the gateway 120 or the alternate communication channel 122 which uses the token to lookup the associated transaction token data in store 240. The resulting transaction token data from the store 240 is used to authorize the transaction by the processing institution 123 and the results returned to POS 104 via the gateway 120 or the secondary communication channel 122. In one embodiment the fingerprint token 230 is translated to a valid transaction token via a cloud based store 260.
In one embodiment the fingerprint token 230 is captured at the time of the transaction, and combined with other token data captured 101, along with POS transaction data from the mobile device 260 and the POS application 270, along with data supplied by the transaction-processing network 123. The combined data encrypted within the data capture device 103 and forwarded to the mobile device 260 and gateway 120 to be processed by transaction processing network 123
In one embodiment, security module 310 is configured to perform real time monitoring of transactions as they occur as indicated by block 333. This can be done by having the intelligence built into the security module 310. In conventional networks, real time monitoring and authentication cannot be done because transactional data has to travel through gateway 120 or other data aggregator before reaching network 123 where the intelligence of the network is located. In contrast, the intelligence of network 300 is located at the edge of the network, security module 210., where payment transaction occurs.
As shown in
In one embodiment, pins or other electrical contacts can be provided, at predetermined locations of a secured housing. The epoxy, resin, or other potting material can be a conductive material, thus creating a current path between and among the pins. Control logic can be provided inside of the housing for detecting changes in resistance across various paths between various pairs of pins. Thus, if an attempt is made to open the device or to probe the circuitry to obtain keys, algorithms or other encryption information, the resistance between one or more pairs of contacts will be changed. As a result of the change in resistance, the encryption engine within the secured housing can be configured to be self disabling encrypted data can no longer be generated or is invalid).
Certain types of token card such as an ATM card, debit card or a chip-and-pin card may require a PIN to be entered. The PIN can be encrypted by an encrypting engine in a secure PIN pad (not shown) prior to being transmitted to security module 210 using an encryption key stored in memory or a key generated by an encryption algorithm. In one embodiment, the PIN is encrypted using some or all of the token data extracted from token card 101. Once the PIN is encrypted, the PIN pad transmits the encrypted PIN to security module 310. Token data extracted from token card 101 can be similarly encrypted using a key stored in memory or a key generated with an encryption algorithm.
PIN and token data encryption might be required especially where the data capture device 103 is separate from security module 310. In one embodiment, where data capture device 103 and security module are part of module 315 or a part of the same hardware security module (HSM), PIN and token data transmitted to security module are encrypted even though data capture device 103 and security module 310 are within the same housing. In this way, even if the housing of module 315 is tampered with, clear text data of the PIN and token data cannot be retrieved simply by tapping into the transmission line or other interface between the data capture device 103 and security module 310.
Once security module 310 receives data from data capture device 103, security module 310 may perform PIN authentication or other identity authentication using locally stored authentication data. In one embodiment, the authentication data can be stored in a remote server upstream of gateway 120 or on a network that can be accessed by smart security module 310. Alternatively, the authentication data can be stored within security module 310.
In one embodiment, the security module 210 receives the PIN from the keypad where the PIN is encrypted with a symmetric key algorithm such as, for example, TDES or AES using a shared key. The Security module 310 decrypts the PIN and then re-encrypts it using, for example, one of the DUKPT encryption formats for transmitting the PIN along with the required PAN information retrieved for the token when the token is swiped for authorization using the processor's PIN keys. In one embodiment, the POS 104 receives the encrypted PAN information from the token and the PIN from the keypad and requests the security module 310 to decrypt the portion of the PAN required for the DUKPT PIN encryption. In yet another embodiment the POS 104 encrypts the PIN using the previously encrypted PAN, which is sent to the transaction processing network 123 where the PIN is decrypted using the processor PIN key and then the PAN is decrypted and the PIN verified.
In one embodiment the, security module 310 is configured to accept commands directly from the transaction processing network 123. Once the command has been authenticated, the security module 310 keys and operating parameters can be updated or changed. In addition, the application processor code and security processor code can be updated directly from the transaction processing network 123. In another embodiment the security module 310 is configured to send compliance and status monitoring information to the merchant, the processing institution, the issuing institution, or compliance and status monitoring institution providing real time monitoring fir compliance verification as shown in block 333.
In yet another embodiment, security module 310 is configured to authenticate the token card. For example, this can be accomplished by analyzing physical properties of the token card such as, for example, magnetic signature or noise of the data read from the magnetic stripe of the card. Security module 310 may also use other authentication techniques such as warble, jitter, remnant noise or other authentication techniques. Authentication can be done by comparing the cards detected signature against a previously stored signature for the card. One or more of these authentication techniques are described in detail in U.S. Pat. No. 6,260,146, which is incorporated herein by reference in its entirety. If both of the signatures match within some predetermined level of statistical probability, then the card can be flagged as authentic. Security module 310 may also authenticate the token card by analyzing where the card has been used previously. This may be done locally or remotely. For example, once security module 310 obtains the token card's information (e.g., physical characteristics, account number, etc.) it may query a database for the same card information to see where the card was recently used. The database may be a remote or a local server that can be assessed by security module 310. Alternatively, secure module 310 can send the card information to a remote server where a database is queried for the same card information to see where the card was recently used. In any case, security module 310 may flag the card as stolen or a clone card if it observes abnormal activity such as simultaneous use of the card in two separate locations, recent use in another state or country, etc.
In one embodiment, token card 101 can be a retailer specific issued card such as a payment card, loyalty card or other card. The retailer issued card may be, for example, a smart card with an RFID chip or tag or other processor or processor-like capability. The retailer issued card may have a PIN associated to the account number of the card. In this way, the retailer can perform authentication of the card locally. Local authentication offers several realizable benefits: authentication can be done immediately at the front edge of the network, thus reducing or eliminating the potential for fraud; and the retailer can execute loyalty, customer service, or data aggregation programs locally because the retailer has control of the authentication and identification processes. In a conventional network, a retailer cannot issue its own unique token card (e.g., a customized RFID card to implement a loyalty or other program), without first obtaining adoption from all of the issuing banks.
In one embodiment, token 101 is a smart card with a microprocessor or an RFID card. The smart card can be a store credit card such as, for example, a retailer-branded card or a retailer issued credit card. When a cardholder makes a purchase with the retailer-issued card, local authentication of the card and the PIN can be done by secure module 310. Alternatively, secure module 310 may authenticate the card and the PEN directly with issuing bank via network 200. For example, secure module 310 may authenticate the card by analyzing the card's physical characteristics and then verify the PIN with the issuing bank, if the PIN authenticating data is stored by the issuing bank. In the local authentication example, once the cardholder's account is locally verified, the store may identify the cardholder's identity, analyze the cardholder's shopping history and behavior, etc. using stored information associated to the cardholder's account number. In one embodiment, the cardholder's name can be transmitted and display on POS 104. In this way, the retailer's associate may properly greet the cardholder, for example. In another embodiment, the cardholder's shopping history can be analyzed and a credit or bonus may be offered to the cardholder at POS 104.
In one embodiment, once the sale is finalized and the total amount of money to be charged to the cardholder's account is determined at POS 104, security module 210 may transmit an encrypted transaction data stream that includes data such as the account numbers of the cardholder and the retailer, and the total amount of the transaction to the retailer's financial own network. In this way, the retailer can avoid using traditional financial network such as VisaNet NOVA network, or Discover Network thus avoiding additional transaction fees. Alternatively, security module 310 can be configured to use a traditional network such as VisaNet or other financial networks for settlement, compliance and, marketing and POS status information can be sent directly to the appropriate sources, giving a real time view of the transaction. As can be seen, network 300 allows a retailer to have unprecedented flexibility. With network 300, a retailer may locally authenticate token and PIN data and may execute loyalty or other customer service programs using its own unique credit card without obtaining prior approval from the issuing banks such as VISA or MasterCard.
Security module 310 may also be used to authenticate data capture device 103 to determine whether device 103 is the original certified device or a cloned device configured to steal token and PIN data. This can be done by analyzing the encrypted token or PIN data that has been encrypted with a unique identification number assigned to data capture device 103 or to the retailer that is hosting the data capture device 103. For example, the unique retailer's identification number or serial numbers of data capture devices in the retailer can be programmed into module 310. In this way, if the original data capture device 103 is removed from the retailer and is replaced with a clone, security module 310 would be able to recognize the cloned device by comparing the encrypted identification number with the stored retailer or device identification number. The identification number may be a device serial number or a randomly generated number assigned to the device.
In one embodiment, module 315 can be configured to encrypt transactional data using a unique retailer identifier such that when the settlement occurs at the end at network 123, the credit will always be transferred the retailer that rightfully owns module 315. In this way, when a theft of module 315 occurred and wherever module 315 ultimately resides, the credit during the final settlement will go to the original retailer's bank. For example, if module 215 is wrongfully removed from a grocery store and is relocated to a sporting good store, in an attempt to hack into module 315, any transactions processed by the stolen module (assuming local card and PIN authentication is not at play) at the sporting good store will ultimately credit the grocery store when final the settlement occurs. This is because module 315, in the example above, has been configured to encrypt transactional data with grocery store account number and therefore all settlements will be credited to that account. Additionally, because data capture device 103 and secure module 310 are within the same secured housing, the data capture device cannot be cloned.
In one embodiment. POS 104 and smart module 305 can be implemented as a single module 315. Thus, module 315 may include a token card scanner, a cash register, a display, a graphical user interface, a keypad, a security module 210, and other biometric authentication devices such as, for example, a fingerprint scanner. In one embodiment, each of the individual devices within module 315 includes its own security module 210 even though all of those devices are housed within a single secured housing. In this embodiment, each of the devices within module 315 has its own decryption and encryption engine, thus each device may communicate with each other with encrypted data. In this way, if the secured housing of module 315 is compromised, the hacker will not be able to gain access to any clear text format data. Further, if one of the devices of module 315 (i.e., the user interface) is hacked, the hacker will not be able to gain access to other devices because each of the devices has its own security module 210. The architecture of security module 210 will prevent a hacked device, for example, hacked a keypad, to gain access to the encryption engine of the card scanner. This distributed network security architecture will be further described in detail below.
Security module 210, in this embodiment, has two independent processors. In one embodiment, each processor is assigned with specific duties and cannot perform any functions outside of its original scope. In one embodiment, CPU 410 (the first CPU) main functionalities include non-security tasks such as: perform key management such as communicating with an external decryption appliance to build unique keysets for various to types of token card; perform general data processing such as sending and receiving token, pin, and transactional data; encryption determination such as determining whether a token information is encrypted; encryption-decryption request; and enable and disable overall encryption functionalities of module 210. The main functionalities of CPU 515 may include performing high-level security tasks such as decryption and encryption, keys storing, authenticating token and PIN data, and executing transactional commands. This allows CPU 515 to be independent of CPU 510. Also, since security tasks are performed by CPU 415, CPU 510's firmware and other software functions can be updated routinely without having to re-certify CPU 515 or the entire module 210.
In one embodiment, CPU 510 and CPU 515 communicate via a register 520. Register 520 can be configured to allow only certain requests to CPU 515 from CPU 510. In this way, the number of functions CPU 510 can request CPU 515 can be strictly controlled and limited. This architecture may prevent a hacker from gaining access to the encryption engine within CPU 515 if other component of security module 210, such as CPU 510 or 110 device 505 is compromised. For example, if CPU 510 is compromised, a hacker will not be able to send a command to CPU 515 instructing it to accept new keys or to reset the current keys. In one embodiment, CPUs 510 and 415 are fabricated on a single silicon die (not shown). The dual processor die may have an island of material separating CPU 510 from CPU 515. The dual processor die may also include a register that functions as a single means of communication between CPUs 510 and 515. In this way, the functionalities of each CPU can be separated.
Upon receiving data from I/O device 505. CPU 510 may determine whether the received data is encrypted or not. If the data received is encrypted. CPU 410 may request CPU 415 to decrypt and verify the data. For example, PIN data received from I/O device 505 may be encrypted, thus CPU 510 may request CPU 515 to decrypt the PIN data and to verify its authentication. The PIN data may be verified using data locally stored within module 210 or data stored in a local network that is readily accessible by module 210. In this way, PIN authentication can be performed locally without having to transmit the PIN data through conventional financial networks such as VisaNet in order to have the PIN authenticated. As previously mentioned, this affords retailers with the flexibility of issuing their own card. Since the intelligence required to authenticate a token card and a PIN is built into module 210, retailers may add additional functionalities to their own issued card without the need to obtain approval from issuing banks. For example, a retailer may chose to embed an RFID circuit onto card in order to execute a loyalty program that would award customers based on their shopping history.
In any case, CPU 515 may decrypt and encrypt data using keys stored within the memory cache of CPU 515 or keys stored in an external memory 525 in one embodiment, the keys are stored within the memory cache of CPU 515. In one embodiment, CPU 515 may also use a unique identification number associated with module 210, POS 104, or with the retailer that is hosting module 210 to encrypt the transactional data. In this way, the encrypted transactional data is unique to module 210, POS 104, or to the retailer.
Encrypting the transactional data with a unique POS 104 or retailer identification number offers several benefits. One of the benefits is the ability to uniquely associate security module 210 with a particular POS 104 or a retailer. Since every transactional data can be encrypted with a unique POS or retailer identifier, the paying bank can be instructed to only pay to the retailer that is associated the POS or retailer ID encrypted within the transactional data. Thus, even when module 210 is stolen and used somewhere else, the final payment can still go to the authorized owner of module 210. Another benefit is the real time detection of unauthorized devices such as a I/O device 505 that has been hacked. In module 210, the original authorized I/O device 505 can be configured to encrypt the pin and token data using a unique serial number or retailer ID number that is known to CPU 515. Thus, when CPU 515 decrypts PIN and token data received from I/O device 505, it can verify to see if the serial number or the retailer ID number matches with a stored serial or retail ID number. In the scenario, where there is a mismatch CPU 515 may execute a disable command or cause CPU 510 to perform other preventive security functions such as notifying someone of the fraud.
With a secure communication link between the financial institution to the POS security modules. POS key management and other control functions can be initiated by the financial institution. Either symmetric or public key exchange protocols can be used between the financial institutions and the security modules in the POS terminal to set initial or new keys along with configuring the various terminal options. The secure link between the financial institution 123 and the security/communication module 210 can either be a dedicated channel outside of the normal POS transaction network or can be implemented using the transaction network communication channels. For example, the latter can be accomplished by using data formatted as if it were normal card transaction data expected by the communication network elements.
To increase the security of the POS terminal module 600, the multiple security modules located within the module 210 can share components of the keys and other sensitive information. In this way to extract a key from module 600 requires successfully attacking multiple security modules. Each of the module components 210 can also periodically transmit encrypted status messages to each other and if a module ceases to reply to an interrogation, the other modules respond to an attack by erasing all sensitive information in the POS terminal module 600.
In module 600, biometric module 620 can be a fingerprint scanner or other biometric scanning device. User interface module 625 can be a monitor, a touch screen monitor, or other type of display device. Secure communication module 630 can be a communication interface used to externally transmit and receive data. Key pad module 635 can be a keyboard or a numeric key pad used to enter PIN or other personal identification information, such as a zipcode or a telephone number. Each of security module 210 within each of the modules 615-635 can be configured to encrypt outgoing data (data to be transmitted over communication channel 640) with a unique retailer ID number or a serial number of module 600. Alternatively, the serial number of the module where security module 210 resides can also be used. In this way, when data is received by anyone of the modules 615-635, the module receiving the data can decrypt the encrypted data to verify and determine whether a proper encryption has been performed (encrypted with a proper unique key). If the data is encrypted with the wrong retailer key or identification number, then the module that transmit the incorrect encrypted data may have been tampered with. In this case, module 600 may report the error to the retailer or may disable itself.
Local authentication offers several benefits. For example, authentication can be done immediately at the front edge of the network, thus reducing or eliminating the potential for fraud; and the retailer can execute loyalty, customer service, or data aggregation programs locally because the retailer now has control of the authentication and identification processes. In a conventional network, a retail cannot issue its own unique card, which is needed to execute loyalty or other programs, without first obtaining adoption from all of the issuing, banks. Local authentication allows a retailer to issue its own token card. The retailer issued card can still be a VISA, MasterCard, Discover, American Express or other card but with a PIN associated to the account number of the card. The PIN can be selected by the cardholder but is stored by the card issuing retailer instead of the issuing banks such as VISA or MasterCard. This allows security module 210 to perform local authentication of the token and pin data of the card.
In step 715, once the token and PIN data are authenticated, the transactional data is encrypted. In one embodiment, the transactional data is encrypted using CPU 515 (shown in
In step 915, a unique identification of the POS or the retailer is received. Alternatively, this step is optional because the unique identification of the POS or the retailer can be pre-programmed into security module 210 memory. In one embodiment, a unique identification of the HSM can be used in place of the POS. In step 920, the transactional data is encrypted with a key generated with the unique POS or retailer identification. In this way, the transactional data can have an encrypted code that is specific to a particular POS or retailer. In step 925, the encrypted transactional data is transmitted to bank or other financial institution.
In step 1215, the token and PIN data are authenticated by a security module such as module 210. This authentication process may be done locally and without having to transmit the token and PIN data to an issuing bank or a remote decryption appliance for authentication. This way the retailer that owns the module 210 has control over the authentication process, thus allowing the retailer to execute its own customer service programs. Alternatively, the retailer can configure module 210 to communicate directly with the issuing bank for authentication and authorization. In step 1220, the token and PIN data is encrypted and packaged with other data such as purchase price, date, store H), etc. to create a transactional data. This transactional data is then sent directly to a financial institution for final settlement in step 1230, hi this way, retailers and banks have the option of issuing a card that does not have to use the traditional financial network such as VisaNet or Discover Network for authentication and settlement.
In one embodiment the biometric reader 2010 is used by the customer in place of another token such as a credit card.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as is commonly understood by one of ordinary skill in the art to which this invention belongs. All patents, applications, published applications and other publications referred to herein are incorporated by reference in their entirety, if a definition set forth in this section is contrary to or otherwise inconsistent with a definition set forth in applications, published applications and other publications that are herein incorporated by reference, the definition set forth in this section prevails over the definition that is incorporated herein by reference.
The term tool can be used to refer to any apparatus configured to perform a recited function. For example, tools can include a collection of one or more modules and can also be comprised of hardware, software or a combination thereof. Thus, for example, a tool can be a collection of one or more software modules, hardware modules, software/hardware modules or any combination or permutation thereof. As another example, a tool can be a computing device or other appliance on which software runs or in which hardware is implemented.
As used herein, the term module might describe a given unit of functionality that can be performed in accordance with one or more embodiments of the present invention. As used herein, a module might be implemented utilizing any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, logical components, software routines or other mechanisms might be implemented to make up a module. In implementation the various modules described herein might be implemented as discrete modules or the functions and features described can be shared in part or in total among one or more modules. In other words, as would be apparent to one of ordinary skill in the art after reading this description, the various features and functionality described herein may be implemented in any given application and can be implemented in one or more separate or shared modules in various combinations and permutations. Even though various features or elements of functionality may be individually described or claimed as separate modules, one of ordinary skill in the art will understand that these features and functionality can be shared among one or more common software and hardware elements, and such description shall not require or imply that separate hardware or software components are used to implement such features or functionality.
Where components or modules of the invention are implemented in whole or in part using software, in one embodiment, these software elements can be implemented to operate with a computing or processing, module capable of carrying out the functionality described with respect thereto. One such example computing module is shown in
Referring now to
Computing module 1100 might include, for example, one or more processors or processing devices, such as a processor 1104. Processor 1104 might be implemented using a general-purpose or special-purpose processing engine such as, for example, a microprocessor, controller, or other control logic. In the example illustrated in
Computing module 1100 might also include one or more memory modules, referred to as main memory 1108. For example, preferably random access memory (RAM) or other dynamic memory, might be used for storing information and instructions to be executed by processor 1104. Main memory 1108 might also be used for storing temporary variables or other intermediate information during, execution of instructions to be executed by processor 1104. Computing module 1100 might likewise include a read only memory (“ROM”) or other static storage device coupled to bus 1102 for storing static information and instructions for processor 1104.
The computing module 1100 might also include one or more various forms of information storage mechanism 1110, which might include, for example, a media drive 1112 and a storage unit interface 1120. The media drive 1112 might include a drive or other mechanism to support fixed or removable storage media 1114. For example, a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. Accordingly, storage media 1114, might include, for example, a hard disk, a floppy disk, magnetic tape, cartridge, optical disk, a CD or DVD, or other fixed or removable medium that is read by, written to or accessed by media drive 1112. As these examples illustrate, the storage media 1114 can include a computer usable storage medium having stored therein particular computer software or data.
In alternative embodiments, information storage mechanism 1110 might include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into computing module 1100. Such instrumentalities might include, for example, a fixed or removable storage unit 1122 and an interface 1120. Examples of such storage units 1122 and interfaces 1120 can include a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, a PCMCIA slot and card, and other fixed or removable storage units 1122 and interfaces 1120 that allow software and data to be transferred from the storage unit 1177 to computing module 1100.
Computing module 1100 might also include a communications interface 1124. Communications interface 1124 might be used to allow software and data to be transferred between computing module 1100 and external devices. Examples of communications interface 1124 might include a modem or softmodem, a network interface (such as an Ethernet, network interface card, WiMedia, 802.XX or other interface), a communications port (such as for example, a USB port, IR port, RS232 port Bluetooth interface, or other port), or other communications interface. Software and data transferred via communications interface 1124 might typically be carried on signals, which can be electronic, electromagnetic, optical or other signals capable of being exchanged by a given communications interface 1124. These signals might be provided to communications interface 1124 via a channel 1128. This channel 1128 might carry signals and might be implemented using a wired or wireless medium. Some examples of a channel might include a phone line, a cellular link, an RE link, an optical link, a network interface, a local or wide area network, and other wired or wireless communications channels.
In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as, for example, memory 1108, storage unit 1120, media 1114, and signals on channel 1128. These and other various forms of computer program media or computer usable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, are generally referred to as “computer program code” or a “computer program product” (which may be grouped in the form of computer programs or other groupings). When executed, such instructions might enable the computing module 1100 to perform features or functions of the present invention as discussed herein.
While various embodiments of the present invention have been described above, it should be understood that the have been presented by way of example only, and not of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the invention, which is done to aid in understanding the features and functionality that can be included in the invention. The invention is not restricted to the illustrated example architectures or configurations, but the desired features can be implemented using a variety of alternative architectures and configurations, indeed, it will be apparent to one of skill in the art how alternative functional, logical or physical partitioning and configurations can be implemented to implement the desired features of the present invention. Also, a multitude of different constituent module names other than those depicted herein can be applied to the various partitions. Additionally, with regard to flow diagrams, operational descriptions and method claims, the order in which the steps are presented herein shall not mandate that various embodiments be implemented to perform the recited functionality in the same order unless the context dictates otherwise.
Although the invention is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in various combinations, to one or more of the other embodiments of the invention, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments.
Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof, the terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future.
A group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the invention may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated.
The presence of broadening; words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent. The use of the term “module” does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, can be combined in a single package or separately maintained and can further be distributed in multiple groupings or packages or across multiple locations.
Additionally, the various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts and other illustrations. As will become apparent to one of ordinary skill in the art after reading, this document, the illustrated embodiments and their various alternatives can be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration.
| Number | Date | Country | |
|---|---|---|---|
| 61581733 | Dec 2011 | US |
