Client Device Authentication Using Contactless Legacy Magnetic Stripe Data

Abstract

To provide client device authentication using contactless legacy magnetic stripe data.SOLUTION: A technique for generating a derived encryption key for a contactless legacy magnetic stripe card is disclosed. A derived key can be generated using a master key, a key derivation value, and an encryption algorithm. In one exemplary embodiment, the key derivation value can be provided by a user as a fingerprint, numeric code, or photo. The user can provide the key derivation value to the card or a mobile phone. The card can generate the derived key using the key derivation value provided by the user. The card or the mobile phone can transmit the derivation value provided by the user to the server and the server can regenerate the derived key using the derivation value provided by the user.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS. This application claims priority to U.S. Patent Application No. 16 / 590,536, filed October 2, 2019.

[0002] Technical field. This application relates to client device authentication using contactless legacy magnetic stripe data. [Background technology]

[0003] Data security and transaction integrity are of great importance to businesses and consumers. This need continues to grow as electronic commerce constitutes an ever-larger share of commercial activity. Contactless cards can be an invaluable resource in providing data security and transaction integrity. While the increasing use of chip-based financial cards (e.g., EMV cards) offers certain secure features over legacy magnetic stripe cards (MSD), the majority of contactless-accepting merchants still utilize MSD cards and MSD technology. Accordingly, many card issuers still choose to support both MSD and EMV cards. Summary of the Invention [Problem to be solved by the invention]

[0004] Because many card issuers in this country still choose to support MSD cards, techniques that facilitate transaction security and user authentication for these cards are desirable. Improving card security for contactless legacy magnetic stripe cards is important, especially when interoperating with mobile phones or similar client devices. Exemplary interactions may include activation, authentication, or step-up authentication with mobile devices, mobile phones, and tablets. [Means for solving the problem]

[0005] In an exemplary embodiment, a secure data transmission system is disclosed that includes an MSD-compliant card ("card"), a mobile phone, and a server. The mobile phone may receive protected data from the card and transmit the protected data to the server for further analysis or action. The card may have a processor and memory, and the card's memory may store a master key (or a derived key), transmission data, and a counter value (and / or a key derivative value). The server may have a processor and memory, and the server's memory may store the master key. The card and the server may be in data communication using a mobile phone. The card may be configured to generate a derivative key using the master key, the counter value (and / or the key derivative value), and one or more cryptographic algorithms and store the derivative key in the card's memory. The card may also generate encrypted transmission data by encrypting the transmission data using one or more cryptographic algorithms and the derivative key, and transmit the encrypted transmission data to the server using the mobile phone. The server is configured to generate a derivative key based on the master key and the counter value (and / or the key derivative value) and store the derivative key in the server's memory. The server may keep the counter value (and / or key derivative value) independently, or may receive it together with (or separately from) the encrypted transmission from the card. The server may use the replicated derived key to decrypt the encrypted transmission and perform further operations, such as authorizing an authentication step.

[0006] In one exemplary embodiment, the key derivation value may be provided by the user as a fingerprint, a numeric code, or a photograph. The user may provide the key derivation value to a card or mobile phone. In this embodiment, the card may use the user-provided key derivation value to generate a derived key. The card or mobile phone may send the user-provided derived value to a server, and the server may regenerate the derived key using the user-provided derived value.

[0007] In an exemplary embodiment, the card may include a derived key and a cryptographic algorithm. The card may use the derived key and a cryptographic algorithm (e.g., Visa® dCVV or MasterCard® CVC3) to generate a cryptogram. The card may send the cryptogram to a mobile phone, which may send the cryptogram to a server. The server may verify the cryptogram and, if the cryptogram is verified, may authorize the transaction. In this exemplary embodiment, the derived key is unique to each card. For example, at the BIN level, there may be a primary key (or master key). The derived key may be generated using an algorithm that operates on the primary key, the PAN, and the PAN sequence number. [Brief explanation of the drawings]

[0008] [Figure 1A] 1 illustrates a contactless card according to an exemplary embodiment. [Figure 1B] 1 shows an exemplary touchpad that includes an NFC tag on the backside of the touchpad. [Figure 2] 1 illustrates a mobile phone according to an exemplary embodiment. [Figure 3] 1 illustrates a data transmission system according to an exemplary embodiment. [Figure 4] 1 shows a flow chart for encrypting and transmitting sensitive data from a card to a server via a mobile phone. [Figure 5] 1 illustrates exemplary hardware components for a server. DETAILED DESCRIPTION OF THE INVENTION

[0009] An objective of some embodiments of the present disclosure is to incorporate one or more keys into contactless legacy magnetic stripe cards. The contactless card can perform authentication and numerous other functions that, without the present disclosure, would require the user to carry a separate physical token in addition to the contactless card. Using a contactless interface, the contactless card can interoperate with a client device (such as a mobile phone). The client device can relay any encrypted data provided by the card to a backend server, which can then authorize various transactions, such as authenticating the user.

[0010] In an exemplary embodiment, an MSD card or contactless legacy magnetic stripe card (hereinafter "card") may conform to one or more of the ISO / IEC 7810, ISO / IEC 7811, ISO / IEC 7812, ISO / IEC 7813, ISO 8583, and ISO / IEC 4909 standards. These standards may define the physical properties of the card, including size, flexibility, location of the magnetic stripe, magnetic characteristics, and data format.

[0011] The size of the card may be the same as that of a payment card, credit card, or debit card. According to the ISO / IEC 7810 standard ID-1, the card dimensions are 85.60 x 53.98 mm (3.37 inches x 2.13 inches). However, cards according to these disclosures may have different sizes, and the card need not be implemented as a payment card.

[0012] In an exemplary embodiment, the card may include a magnetic stripe, which may store data by altering the magnetic properties of iron-based magnetic particles in a band of magnetic material on the card. The magnetic stripe may be read by passing it in front of a magnetic reading head. In one exemplary embodiment, there may be up to three tracks on a magnetic card, known as tracks 1, 2, and 3. If one track is unreadable, the card reader of a POS system almost always reads track 1, track 2, and sometimes both. The minimum cardholder account information required to complete a transaction may be present on both tracks.

[0013] In one exemplary embodiment, Track 1 may include information such as a primary account number ("PAN"), name, expiration date, service code, and optional data (e.g., a Pin Verification Key Indicator (PVKI), a Pin Verification Value (PVV), a Card Verification Value (CVV), or a Card Verification Code (CVC)). In one exemplary embodiment, Track 2 may include a PAN, expiration date, service code, and optional data (e.g., the same as Track 1).

[0014] The card may include processing circuitry for storing and processing information, which may include a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper detection hardware.

[0015] Information storage may occur in the processing circuit's memory, which may be read-only memory, write-once-read-many memory, or read / write memory, such as RAM, ROM, and EEPROM. These memories may store information, including information stored in any one of the card's tracks, and the card may include one or more of these memories. Contactless cards may transfer information stored in these memories of the contactless card using NFC technology. Read-only memory can be programmed at the factory to be read-only or programmable only once. One-time programmability provides the opportunity to be written only once and then read multiple times. Write-once / read-many memory can be programmed at a time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can be read any number of times.

[0016] The card's memory may be divided into several zones, each providing a different level of security. The card's processor may keep track of which memory addresses belong to which zone and the circumstances under which each zone is accessible. The card's processor may also process information and store that information in memory. In one exemplary embodiment, the card's memory may be divided into four zones: a secret zone, a confidential zone, a usage zone, and a public zone.

[0017] The private zone may be used to store information that is only usable by the processor itself, e.g., passwords, cryptographic keys. Information stored in this zone is not readable outside the card. In some embodiments, the private zone may be implemented using a separate processor capable of performing cryptographic functions. Cryptographic keys may be sent into or generated in the private zone; in either case, the keys may be stored in the private zone and used to support cryptographic services. If necessary, cryptographic keys may be exported from the private zone.

[0018] In one exemplary embodiment, the card may be a JavaCard that may contain one or more applets. The applets may be protected by a firewall, and data may be assigned to the applets for storage. Data may be stored in EEPROM flash memory by transaction, so that if, for example, power is interrupted and the write is not completed, the content remains the same as before.

[0019] The confidential zone may be used to store a list of all transactions made with the card. The confidential zone may have password protection. In an exemplary embodiment, the password is known only to the card issuer, who may check the card's history as evidence of system abuse. The confidential zone may have read-only access restrictions so that information stored in this zone cannot be changed, e.g., the transaction list cannot be changed. The use zone may be used to store information that may be periodically updated or changed. Depending on the sensitivity of the data, a password may be implemented in this zone. The use zone may have both read and write access protected by a password. The public zone may be used to maintain non-confidential information, such as the card issuer's name and address. The public zone may have read-only access without a password.

[0020] In an exemplary embodiment, the card may store one or more key diversification values. The card may use these key diversification values ​​to generate a diversified key. For example, the card may store a counter value. The counter value may be derived from a counter module that may increment the counter value each time the card interacts with a mobile phone or a server. As another example, the card may store multiple fingerprints and a derived value associated with each fingerprint. The card may include a fingerprint reader, and when a user scans their finger at the fingerprint reader, the card may determine whether any of the stored fingerprints were scanned at the fingerprint reader. The card may select a derived value associated with the scanned fingerprint. The selected derived value may be used to generate a derived key. As yet another example, the card may store a set of multiple random derived values. As yet another example, the card may receive a derived value from an input device attached to the card (e.g., a keypad or fingerprint reader) or from a mobile phone via contactless transmission.

[0021] Some cards may require physical contact with a client device (or reader / writer, reader, or scanner) to provide information stored on the card to the client device or to write information to the card. Other cards may be contactless, i.e., the card may communicate wirelessly with the client device. A contactless card may be a credit card that includes a magnetic strip or a radio-frequency identification ("RFID") tag. Some contactless cards may include both a magnetic strip and an RFID tag. Some cards may be compatible with wireless communication technologies such as NFC, Bluetooth, Wi-Fi, etc.

[0022] The terminal may communicate with the contact card by establishing electrical contact between the card and the terminal. Thus, the contact card may have a contact area with several contact pads. The area of ​​this area is approximately 1 square centimeter (0.16 square inches). Establishing contact between the pads and the terminal may be achieved by inserting (or temporarily bringing) the contact card into the terminal. Using the electrical connection, the terminal may send signals to the card, and in response, the card may transmit its information to the terminal. Generally, contact cards do not include a battery. However, in some embodiments, the contact card may include a battery.

[0023] When a contactless card is held in proximity to a client device, the client device can communicate with the contactless card. The client device can read the contactless card over short distances using near-field communication ("NFC") technology, which uses radio frequency induction. The contactless card may include an inductor to capture a portion of the incoming radio frequency interrogation signal transmitted by the terminal, rectify it, and use it to power the card's processing circuitry. In this manner, the contactless card may function without an internal power source. However, in some embodiments, the contactless card may include an internal power source.

[0024] FIG. 1A illustrates a contactless card 100 according to an exemplary embodiment. In this embodiment, the card 100 may be a payment card issued by a service provider 101, which may be displayed on the front or back of the card 100. The size of the card 100 may conform to the ID-1 standard of ISO / IEC 7810, i.e., 85.60 x 53.98 millimeters. The card 100 may include a contact pad 102 for establishing contact with a contact terminal. The card 100 may include processing circuitry, an antenna, and other components not shown in FIG. 1A. These components may be located behind the contact pad 102. The card 100 may include various identification information 103 displayed on the front or back of the card. The card 100 may also include a magnetic stripe or tape, which may be located on the back of the card.

[0025] In one exemplary embodiment, the card comprises a Near Field Communication ("NFC") tag. In some embodiments, the NFC tag may include processing circuitry for storing and processing information that modulates and demodulates radio frequency signals (typically signals received from a client device, reader / writer, or scanner). The NFC tag may include anti-collision algorithms, authentication and encryption mechanisms, RF interface circuitry, and an RF antenna operating at 13.56 MHz. The RF antenna may receive and transmit signals. Additionally, the RFID tag may include a power source or means for harvesting DC power from an incident terminal signal. These means may include a modulator, a voltage regulator, a reset, and a connection to the antenna. The antenna may be an electric dipole or coil antenna.

[0026] There may be several types of NFC tags, for example, active tags, battery-backed passive tags, and passive tags. Active tags may be electrically connected to a power source, such as a battery, which may power an integrated circuit. As a result, active tags can periodically transmit information stored on the tag as a signal. Battery-backed passive tags may have an activatable power source electrically connected to them, which may be activated when the tag is exposed to a signal from a terminal. Passive tags are not powered by a power source. Rather, they are energized by wireless energy transmitted to the tag by the terminal.

[0027] In an exemplary embodiment of a passive NFC tag, the tag relies on a signal from a client device to power on. The tag may include a modulator, a voltage regulator, a reset, and a connection to an antenna. The antenna may be an electric dipole antenna or a coil antenna, and the tag's processing circuitry may be connected to the antenna. The type of antenna may be determined based on the frequency band used by the tag. Typically, electric dipole antennas are used in ultra-high frequency tags, while short-wave tags use coil antennas. For example, the antenna for an NFC tag may be a simple dipole if the tag uses a frequency of 915 MHz, but the antenna may have a complex coil shape if the tag uses a frequency of 13.56 MHz. The antenna picks up signals from the terminal and transmits signals to the terminal. The connection from the terminal to the tag provides both the transmitted data and the power to operate the passive NFC tag.

[0028] 1B shows an exemplary contact pad 102 that includes an NFC tag on the back side of the contact pad 102. In this exemplary embodiment, the contact pad 102 may include several gold-plated pads. On the back side of the contact pad 102 may be a processing circuit 104 and an NFC tag. The NFC tag may include an antenna 105. In this exemplary embodiment, the processing circuit 104 is part of the NFC tag.

[0029] In some embodiments, the antenna of the card's NFC tag may be located inside the card, around the contact pad 102. In other embodiments, the card's NFC tag may include several antennas. For example, in addition to antenna 105, the card may include an antenna that extends throughout the card 100, around the contact pad 102. Other combinations are also possible. In some embodiments, the antenna may be external to the contact pad and processing circuitry. In other embodiments, there may be an antenna integrated into the processing circuitry, or the antenna may be used with an external booster coil.

[0030] In one exemplary embodiment, the card's coil may act as a secondary winding of an air-core transformer. The terminal may communicate with the card by interrupting power or amplitude modulation. The card may use gaps in the card's power connection to infer data transmitted from the terminal. The power connection is kept functional via a capacitor. The card may communicate in the reverse direction by switching a load on the card's coil or by load modulation. Load modulation may be detected at the terminal's coil through interference.

[0031] In an exemplary embodiment, the card may include a keypad and / or fingerprint reader. Using the keypad and / or fingerprint reader, a user may provide input to the card. For example, using the keypad, a user may provide the card with a code that the card can use as a key derivative value. Similarly, a user may scan and store the user's fingerprint on the card. The card may associate each fingerprint scanned and stored on the card with an encryption algorithm (or key derivative value). By scanning the user's fingerprint, the user may specify which encryption code the card can use.

[0032] The client device may be a cellular phone, mobile phone, or tablet. The client device can read information from and write information onto the card. In some embodiments, the client device may send information from the card to a host computer and write information from the host computer to the card. In some embodiments, the host computer may be the client device. The client device may provide power to the card and link the card's hardware interface to the host computer. Because the card's processor can control the actual flow of information to and from the card's memory, the client device may operate with only minimal processing power to send information to the host computer.

[0033] In some embodiments, the client device may include a processor and a transceiver. The transceiver may send and receive data to the card using the NFC protocol. The processor of the client device may decode any data received from the card. The client device may update, delete, or modify information stored on the card.

[0034] The client device may write data to the card by sending the data to the card's processor. The processor may process the data and store it in the card's memory. The client device may have two-way communication with the card as described in ISO 14443. The card may include an NFC tag. The two-way communication may be digitally encoded. There may be several frequency ranges and several proprietary formats for two-way communication. ISO 14443 compliant cards dominate the 13.56 Mhz frequency range (NFC).

[0035] The client device and the card may exchange messages that may include commands or data. For example, the client device may send a command message to the card, the card may process the command message in its processor, and the card may send a response message back to the client device. Each of the command and response messages may include data. The messages may include TLV (Type, Length, and Value) data and commands, such as a STORE_DATA command, that prompts the card to store the data included in the message.

[0036] FIG. 2 illustrates a mobile phone 200 according to an exemplary embodiment. In this exemplary embodiment, the mobile phone 200 may include a display screen 201, a camera 202, and a fingerprint scanner 203. The display screen 201 may be any type of display screen, such as a touchpad LCD display screen. Using the touch screen 201, for example, a customer may input information into the mobile phone 200. As another example, by pressing a button on a graphical user interface, a user may instruct the camera 202 to take a picture of the user. The camera may store the picture and / or transmit the picture to a back-end server. As yet another example, a user may instruct the mobile phone 200 to scan the user's fingerprint using the fingerprint scanner 203. The mobile phone 200 may store the fingerprint and / or transmit the fingerprint to a card or a back-end server.

[0037] In one exemplary embodiment, the mobile phone may be an NFC-compatible mobile phone, which may include an antenna for transmitting and receiving signals, a transceiver, and a processor for decoding data. In the case of a passive NFC tag, the mobile phone may transmit an energy field, which activates the tag (or card) and powers its chip, allowing it to transmit or store data. The tag then converts the radio signal into usable power and responds to the mobile phone in the form of a radio signal. The signal may include the tag's identification information and other information. Once the mobile phone receives the response, it translates the response and extracts all the information contained in the radio signal. The information collected from the tag is then transferred via a communication interface to a back-end server, where the data may be stored in a database or analyzed by the server. The mobile phone may update, delete, or modify the information stored on the card.

[0038] In the exemplary embodiment of FIG. 2, the mobile phone 200 includes one or more antennas (not shown) that enable the device to read information from and write information to a contactless card.

[0039] In this disclosure, the terms client device, mobile phone, reader / writer, scanner, and terminal are used interchangeably and all refer to devices that can scan cards and / or write information to cards. In some embodiments, the mobile phone may be connected to a back-end server. In other embodiments, the mobile phone may be integrated into the back-end server.

[0040] In an exemplary embodiment, the mobile phone may include one or more of a fingerprint reader, a camera, and an application for receiving input from a user (e.g., a PIN code, a key derivation value, or an identification number). The mobile phone may transmit any input provided by the user to a backend server and the card, e.g., for the purpose of key derivation. For example, the backend server may store multiple fingerprints associated with a user, and the server may associate each fingerprint with an encryption algorithm. When scanning a card with the mobile phone, the mobile phone may receive the user's fingerprint (or other information, e.g., a photograph or PIN number) and transmit this information to the backend server. Using this information, the backend server may determine which encryption algorithm was used in the key derivation process.

[0041] When using symmetric cryptographic algorithms, such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cipher-based message authentication code (CMAC) algorithms, it is important that the key remain secret between the party that first processes the data protected with the symmetric algorithm and key, and the party that receives and processes the data using the same cryptographic algorithm and the same key.

[0042] It is also important that the same key is not used too many times. If a key is used or reused too frequently, it can be compromised. Each time a key is used, it provides an attacker with an additional sample of data that has been processed by a cryptographic algorithm with the same key. The more data the attacker has that has been processed with the same key, the more likely the attacker will be able to discover the value of the key. Frequently used keys can be involved in a variety of different attacks.

[0043] Additionally, each execution of a symmetric encryption algorithm can leak information about the key used during the symmetric encryption operation, e.g., side-channel data. Side-channel data may include minute-by-minute power fluctuations that occur as the encryption algorithm executes using the key. Enough measurements of the side-channel data may be made to leak enough information about the key to allow it to be recovered by an attacker. Using the same key to exchange data repeatedly will leak data processed by the same key.

[0044] However, by limiting the number of times a particular key is used, the amount of side-channel data an attacker can gather is limited, thereby reducing exposure to this and other types of attacks. As explained further herein, the parties involved in the exchange of cryptographic information (e.g., sender and receiver) may independently generate keys from a shared initial master symmetric key in combination with a counter value, thereby periodically replacing the shared symmetric key, relying on any form of key exchange to keep the parties synchronized. By periodically changing the secret symmetric key shared by the sender and receiver, the attacks described above are made impossible.

[0045] 3 illustrates a data transmission system according to an exemplary embodiment. The system 300 may include a card 100 and a mobile phone 200 that communicates with one or more servers 500, e.g., via a network. The system 300 may be configured to implement a key derivation algorithm. For example, a sender (e.g., a card) and a receiver (e.g., a back-end server) may wish to exchange data (e.g., sensitive data) via the mobile phone 200.

[0046] In some embodiments, card 100 and server 500 may be provided with the same master symmetric key. The symmetric key may be kept secret from all parties other than card 100 and server 500 involved in the exchange of secure data. It is further understood that some of the data exchanged between card 100 and server 500 includes at least a portion of data that may be referred to as sensitive data, a counter value, or other types of data (e.g., a key derivative value). The counter value may include a number that changes each time data is exchanged between card 100 and server 500. In this disclosure, the counter value and the key derivative value may be used to indicate the same value or different values, both of which are within the scope of this disclosure.

[0047] 4 shows a flowchart for encrypting and transmitting sensitive data from card 100 to server 500 via mobile phone 200. In step 410, when card 100 is preparing to process the sensitive data with a symmetric cryptographic operation, card 100 may update a counter. Both card 100 and server 500 may store a value representing the counter. This value may be updated each time card 100 and server 500 interact.

[0048] In step 420, card 100 may select an appropriate symmetric encryption algorithm. The symmetric encryption algorithm may include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. Card 100's algorithm selection may be based on input, which may be provided by data stored on card 100 (e.g., a counter value), data received from a user (e.g., an input pad on card 100), or data provided by mobile phone 200 or server 500.

[0049] In some embodiments, the symmetric algorithm may include any symmetric encryption algorithm used to generate a derived symmetric key of a desired length. Non-limiting examples of symmetric algorithms may include a symmetric encryption algorithm such as 3DES or AES128, a symmetric HMAC algorithm such as HMAC-SHA-256, and a symmetric CMAC algorithm such as AES-CMAC. It is understood that if the output of the selected symmetric algorithm does not generate a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may generate multiple outputs that can be combined as necessary to generate a key of sufficient length.

[0050] In step 430, card 100 may generate a derived key. For example, the derived key may be generated by encrypting a counter value (i.e., a key derivative value) with a selected symmetric encryption algorithm using the master symmetric key, thereby generating a derived symmetric key. As another example, the master key and the key derivative value may be provided as inputs to an encryption algorithm, the output of which may be a derived (symmetric) key. The derived symmetric key may be used to process the sensitive data before transmitting the results to server 500 via mobile phone 200.

[0051] In step 440, the sensitive data may be protected using one or more cryptographic algorithms and one or more derived keys. The derived keys generated in step 430 may be used with one or more cryptographic algorithms to protect the sensitive data. In some embodiments, multiple cryptographic operations may be performed using the derived symmetric keys before transmission of the protected data. For example, the data may be MACed using a first derived session key, and the resulting output may be encrypted using a second derived session key to generate the protected data. The cryptographic algorithm may be selected using an algorithm selection technique.

[0052] In one exemplary embodiment, the sensitive data may include data similar to the data stored in Track 1 or Track 2 of a magnetic stripe card. In another exemplary embodiment, the sensitive data may include a counter value. In yet another exemplary embodiment, the sensitive data may include other data provided by card 100 or mobile phone 200, such as a number entered via the keypad of card 100 or a photograph captured by mobile phone 200.

[0053] In step 450, the protected data (i.e., the sensitive data protected in step 430) may be sent to the mobile phone 200, which may send the protected data to the server 500. In step 460, the server 500 may perform the same symmetric encryption using the counter value as input to the encryption and the master symmetric key as the key for the encryption. The output of the encryption may be the same derived symmetric key value generated by the card 100. For example, the server 500 may replicate the derived key generated in the card 100 and use the replicated derived key to decrypt the protected data. As another example, the server 500 may independently generate its own copies of the first and second derived session keys using the counter value. The server 500 may then decrypt the protected data using the second derived session key, which reveals the output of the MAC generated by the card. The server 500 may then process the resulting data by MACing using the first derived session key.

[0054] In one embodiment, server 500 may use the derived key to decrypt the protected sensitive data in step 470. In another embodiment, server 500 may use the derived key in conjunction with one or more cryptographic algorithms to verify the protected data in step 470, and the original data may be verified in step 480. For example, if the output of the MAC operation matches the MAC output revealed by decryption, the data may be considered valid.

[0055] The next time sensitive data needs to be sent from card 100 to server 500 via mobile phone 200, a different counter value may be selected to generate a different derived symmetric key. By processing the counter value with the master symmetric key and the same symmetric encryption algorithm, both card 100 and server 500 may independently generate the same derived symmetric key. This derived symmetric key, but not the master symmetric key, is used to protect the sensitive data.

[0056] Both the card 100 and the server 500 each initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original secret data. Because the derived symmetric key is generated independently by both the card 100 and the server 500, it is never transmitted between the two parties. Therefore, an attacker cannot intercept the derived symmetric key, and the attacker cannot see any data processed with the master symmetric key. As a result, side-channel data leakage related to the master symmetric key is reduced. The operation of the card 100 and the server 500 may also be governed by symmetry requirements regarding how frequently a new derived value, and therefore a new derived symmetric key, is generated. In one embodiment, a new derived value, and therefore a new derived symmetric key, may be generated for every exchange between the card 100 and the server 500.

[0057] In some embodiments, the key derivation value may include a counter value. Other non-limiting examples of key derivation values ​​may include a random nonce generated and transmitted from card 100 to server 500 each time a new derived key is needed, a full counter value transmitted from card 100 to server 500, a portion of the counter value transmitted from card 100 to server 500, a counter maintained independently by card 100 and server 500 but not transmitted between the two devices, a one-time passcode exchanged between card 100 and server 500, and a cryptographic hash of secret data. In some embodiments, one or more portions of the derived value may be used by the parties to generate multiple derived keys. For example, a counter may be used as a key derivation value. Additionally, a combination of one or more of the exemplary key derivation values ​​described above may be used.

[0058] In another embodiment, a portion of the counter may be used as the key derivation value. If multiple master key values ​​are shared between the parties, multiple derived key values ​​may be obtained by the systems and processes described herein. A new derived value, and therefore a new derived symmetric key, may be generated as often as needed. In the most secure case, a new derived value may be generated for each exchange of sensitive data between card 100 and server 500. In practice, this may result in the generation of a one-time-use key, such as a single-use session key.

[0059] In one exemplary embodiment, the key derivation value may be a counter value, however, in other exemplary embodiments, the key derivation value may be determined based on input provided by a user in addition to or instead of a counter value.

[0060] For example, a user may specify a numeric code using a keypad on a mobile phone screen. The mobile phone may transmit this numeric code as a key derivation value to the card and the server. As another example, a user may specify a numeric code using a keypad on a card. The card may use this numeric code as a key derivation value. The card may transmit this derivative value to the mobile phone, which may then transmit this code to the server. The numeric code may be encrypted when transmitted to the mobile phone. As another example, a user may provide a fingerprint on a fingerprint reader on a card or mobile phone. Using the fingerprint, the card or mobile phone may determine a key derivation value. For example, when a user sets up fingerprints on a mobile phone, during setup, the user specifies an alphanumeric value for each finger the user scans. The mobile phone may store each fingerprint and the alphanumeric value in association with each other. Subsequently, when the user wants to authorize a transaction, the user may scan their finger and tap the card on the mobile phone. The mobile phone may transmit the key derivation value associated with the fingerprint to the card and the server. Both the card and the server may use the key derivation value to generate a derived key.

[0061] As another example, a user may scan their finger on the card. In this example, when the user scans their finger, using the card's keypad, the user may specify a key derivative value associated with each fingerprint provided by the user. Subsequently, when the user scans their finger on the card, the card uses the associated key derivative value in an encryption operation. The card may transmit the encrypted data and the key derivative value to the mobile phone, which may then transmit the key derivative value to the server. In one example, during setup, the user may scan their finger on the card (or mobile phone). Once setup is complete, the user may scan the card on the mobile phone. The card (or mobile phone) may transmit the fingerprint and key derivative value association to the mobile phone (or card). In this example, when the user wants to authorize a transaction, the user may scan their fingerprint on the card and mobile phone, and no derivative value needs to be transmitted between the mobile phone and the card.

[0062] In an exemplary embodiment, the card and server may use the fingerprint association for encryption algorithm selection. For example, a user may define an association between each fingerprint and an encryption algorithm. When a user scans their finger on a mobile phone (or card), either the mobile phone or the card may determine the defined encryption algorithm associated with the scanned fingerprint.

[0063] In one exemplary embodiment, the mobile phone is configured to take a photo of the user and transmit the user's photo to a server. The server may determine a key derivation value and / or an encryption algorithm based on the photo. In one embodiment, when the server receives the user's photo, the server may first perform a facial recognition function to determine whether the photo belongs to the card's user. If the server determines that the photo belongs to the user, the server may determine the user's facial expression in the photo. For example, if the user is smiling, the server may associate a first derived value and / or a first encryption algorithm with the user's facial expression. However, if the user closes his or her eyes, the server may associate a second derived value and / or a second decryption algorithm with the user's facial expression. The server may then transmit the derived value and / or decryption algorithm associated with the facial expression to the mobile phone, and the mobile phone may transmit the derived value and / or decryption algorithm to the card. The card may generate a derived key using the associated derived value and / or select the associated decryption algorithm for encryption of sensitive data. In another embodiment, the server may determine the color of the user's outfit and determine the derived value and / or encryption algorithm based on the color of the outfit.

[0064] In one exemplary embodiment, the mobile phone may send a photo of the user to a server, and the server may send a hash of the photo to the mobile phone. The mobile phone may send the hash of the photo to the card, and the card may use the hash of the photo as a derived value.

[0065] In one exemplary embodiment, the derived value may be selected based on a fingerprint input provided by the user, and the encryption algorithm may be selected based on a photograph sent by the mobile phone to the server. For example, using the fingerprint, the mobile phone may determine the derived value and send this value to both the card and the server. Further, using the photograph, the server may determine the encryption algorithm. The server may send the selected encryption algorithm to the mobile phone, and the mobile phone may send the selected encryption algorithm to the card.

[0066] In one exemplary embodiment, the derived value may be a combination of multiple derived values, for example, a cryptographic combination of a derived value derived using a fingerprint and a derived value derived using a photograph of the user.

[0067] 5 illustrates exemplary hardware components for a server. Computer system 500, or other similarly configured computer systems, may include and execute one or more subsystem components for performing the functions described herein, including the various flow process steps described above. Similarly, mobile devices, cellular phones, smartphones, laptops, desktops, notebooks, tablets, wearable devices, servers, etc., that include some of the same components of computer system 500 may execute applications (or software) and perform the steps and functions described above. Computer system 500 may also connect to a network 514, such as the Internet or other networks, to receive queries, obtain data, and transmit information and incentives as described above.

[0068] Computer system 500 typically includes memory 502, secondary storage 504, and a processor 506. Computer system 500 may include multiple processors 506 and may be configured as multiple, for example, blade servers or other known server configurations. Computer system 500 may also include network connectivity devices 508, display devices 510, and input devices 512.

[0069] Memory 502 may include RAM or a similar type of memory, which may store one or more applications for execution by processor 506. Secondary storage 504 may include a hard disk drive, floppy disk drive, CD-ROM drive, or other type of non-volatile data storage. Processor 506 executes applications such as those described herein. Applications may be stored in memory 502 or secondary storage 504, or received from the Internet or other network 514. Processing by processor 506 may be implemented as software, such as software modules, for execution by a computer or other machine. These applications preferably include executable instructions to implement the system and subsystem component functions and methods described above and illustrated in the figures herein. The applications preferably provide a graphical user interface (GUI) through which a user can view and interact with the subsystem components.

[0070] Computer system 500 may store one or more database structures in secondary storage 504, for example, to store and maintain information needed to perform the functions described above. Alternatively, such information may reside on a storage device separate from these components.

[0071] It is also noted that the processor 506 may execute one or more software applications to provide the functionality described herein, specifically, one or more software applications to execute and perform the steps and functions in the process flows described above. Such processes may be implemented in software, such as software modules, for execution by a computer or other machine. The GUI may have a format generated as a web page in, for example, HyperText Markup Language (HTML), Extensible Markup Language (XML), or any other format suitable for presentation on a display device, depending on the application used by a user to interact with the computer system 500.

[0072] The input device(s) 512 may include any device for inputting information into the computer system 500, such as a touch screen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. The input and output devices 512 may be used to input information into the GUI during the implementation of the methods described above. The display device 510 may include any type of device for presenting visual information, such as a computer monitor or flat screen display (or mobile device screen). The display device 510 may display the GUI and / or display output from subsystem components (or software).

[0073] Examples of computer system 500 include a dedicated server computer such as a blade server, a personal computer, a laptop computer, a notebook computer, a palmtop computer, a network computer, a mobile device, or any processor-controlled device capable of running a web browser or other type of application to interact with the system.

[0074] While only one computer system 500 is shown in detail, system 500 may use multiple computer systems or servers as needed or desired to support users, and may use backup or redundant servers to prevent network downtime in the event of a particular server's failure. Additionally, while computer system 500 is illustrated with various components, those skilled in the art will recognize that the system may include additional or different components. Furthermore, while aspects of the embodiments consistent with the above are described as being stored in memory, those skilled in the art will recognize that these aspects may be stored on or read from other types of computer program products or computer-readable media, such as a hard disk, floppy disk, or CD-ROM, or other forms of secondary storage, including RAM or ROM. The computer-readable media may include instructions for controlling computer system 500 to perform particular methods, such as those described above.

[0075] The present disclosure should not be limited with respect to the specific embodiments described herein, which are intended to be illustrative of various aspects. As will be apparent, numerous modifications and variations can be made without departing from its spirit and scope. In addition to those recited herein, functionally equivalent methods and apparatuses within the scope of the present disclosure may become apparent from the above exemplary descriptions. Such modifications and variations are intended to be included within the scope of the appended claims. The present disclosure should be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to limit the invention.

Claims

1. a magnetic stripe data (MSD) compliant contactless card having a processor and memory, receiving an algorithm selection value; the memory is configured to store a card key, transmission data, and the algorithm selection value; the contactless card selecting a cryptographic algorithm based on the algorithm selection value; the contactless card generating a derived key using the card key and the cryptographic algorithm; the contactless card encrypts the transmission data using the derived key to generate encrypted transmission data; the contactless card transmitting the encrypted transmission data. method.

2. The memory further stores a counter value; The derived key is generated using the card key, the encryption algorithm, and the counter value. The method of claim 1.

3. The method further includes a client application including instructions for execution on a client device, transmitting an algorithm selection value to the contactless card; the client device comprising a client device processor, a client device memory storing a plurality of algorithm selection values, and a client device transmitter; The above method is receiving the encrypted transmission data from the contactless card by the client application; The client application further includes transmitting the encrypted transmission data to a server. The method of claim 1.

4. The memory further stores a key derivative value; the derived key is generated using the card key, the cryptographic algorithm, and the key derivation value; The method of claim 1.

5. The key derivation value includes an alphanumeric code, The method of claim 4.

6. the contactless card further includes an input pad; the algorithm selection value is received via the input pad; The method of claim 1.

7. the algorithm selection value includes biometric data; The method of claim 1.

8. The biometric data includes at least one selected from the group consisting of data associated with a photograph and data associated with a fingerprint. The method of claim 7.

9. The contactless card further includes a fingerprint reader. data associated with the fingerprint is received via the fingerprint reader; 9. The method of claim 8.

10. 1. A system comprising a magnetic stripe data (MSD) compliant contactless card, comprising a processor and memory, the system comprising: The memory stores a card key, transmission data, and an algorithm selection value; The above contactless card is receiving an algorithm selection value; selecting a cryptographic algorithm based on the algorithm selection value; generating a derived key using the card key and the cryptographic algorithm; encrypting the transmission data using the derived key to generate the encrypted transmission data; configured to transmit the encrypted transmission data; system.

11. the algorithm selection value includes biometric data; The system of claim 10.

12. The system further comprises a client application including instructions for execution on the client device; the client device comprising a client device processor, a client device memory storing a plurality of algorithm selection values, and a client device transmitter; The client application is transmitting the algorithm selection value to said contactless card; receiving the encrypted transmission data from the contactless card; Sending the encrypted transmission data to a server; The system of claim 10.

13. the client device further comprises a camera; The client application is Taking a photo of the user using the camera; Sending a photo of the user to the server; The system of claim 12.

14. The system further comprises the server; The above server is receiving the photograph from the client application; performing facial recognition to determine whether the user's photograph belongs to the user associated with the contactless card; The system of claim 13.

15. the facial recognition determines a facial expression of the user; The facial expression is associated with a key diversification value.

15. The system of claim 14.

16. the facial recognition determines a facial expression of the user; The facial expression is associated with a cryptographic algorithm.

15. The system of claim 14.

17. The above server is receiving the photograph from the client application; Generate a hash of the above photo, Sending a hash of the photo as a key diversification value to the client application; 15. The system of claim 14.

18. 1. A computer program comprising a processor and a memory, the computer program comprising instructions for execution by a magnetic stripe data (MSD) compliant contactless card, the computer program comprising: The memory stores a card key, transmission data, and an algorithm selection value; The instructions, when executed, cause the contactless card to perform a procedure including the following actions: The procedure including the above operations is as follows: receiving an algorithm selection value; selecting a cryptographic algorithm based on the algorithm selection value; generating a derived key using the card key and the cryptographic algorithm; encrypting the transmission data using the derived key to generate the encrypted transmission data; transmitting the encrypted transmission data. Computer program.

19. The memory further stores a counter value; The derived key is generated using the card key, the encryption algorithm, and the counter value.

19. A computer program according to claim 18.

20. The memory further stores a key derivative value; the derived key is generated using the card key, the cryptographic algorithm, and the key derivation value; 19. A computer program according to claim 18.

Images