HK40120918A - Systems and methods for secure read-only authentication - Google Patents

Description

Systems and methods for secure read-only authentication

This application is a divisional application of application No. 201980041892.0, filed on June 21, 2019, entitled "System and Method for Secure Read-Only Authentication".

Related applications

This application claims priority to U.S. Provisional Patent Application No. 16/014,542, filed June 21, 2018, the entire contents of which are incorporated herein by reference.

manual

Technical Field

The disclosed embodiments generally involve authenticating an account card, and more specifically, authenticating an account card using a synchronized counter.

Background Technology

Many types of interactions on computer systems, such as authenticated logins and other transaction-based processes, are insecure. For example, when attempting to log in to a website on a computer, the website may request a username and password. Anyone with this set of information, whether an authorized user or a malicious user, can use the website for any purpose. To address this insecurity, some transactions require multi-factor authentication, often referred to as "what you know and what you have." For example, when logging into a website, the website may request a username/password combination ("what you know"), as well as a six-digit number displayed on the electronic device ("what you have") or a fingerprint scan ("who you are"). This six-digit number (also known as a time-based one-time password (TOTP)) can be changed every 30 seconds to prevent unauthorized users from reusing it. Another example is that credit cards may contain information stored on them that allows the credit card processor to know whether a user is carrying the card. For example, while the card number may be printed on the front of the card ("what you know"), some information may only be presented as part of the EMV chip ("what you have"). Some devices may read information from the EMV chip for contactless authentication of the user. Some devices allow multi-factor authentication using "what you know" factors and "who you are" factors, such as biometric authentication like facial recognition, fingerprint authentication, and/or iris scanning.

Currently, the EMV protocol relies on two-way communication between the transaction card's EMV chip and the payment terminal (such as a POS machine). To complete a transaction, transaction information is sent from the payment terminal to the transaction card. The EMV chip receives the transaction information, digitally signs it, and sends the signed information back to the payment terminal for authentication. However, many devices and/or operating systems do not support two-way communication, thus preventing transactions from being completed using EMV-enabled transaction cards.

Due to these and other drawbacks associated with authentication using bidirectional communication protocols, there is a need for technically secure, read-only authentication.

Summary of the Invention

Consistent with the disclosed embodiments, a transaction card is provided that is associated with a financial account and used to generate an encrypted value as part of an authentication request. The transaction card includes a radio frequency (RF) transmitter; a clock generator coupled to the RF transmitter, the clock generator being configured to increment a counter value in response to a wireless read signal received from an external RF reader device; and a near-field communication (NFC) tag coupled to the RF transmitter and storing a permanent identifier and the counter value. The NFC tag can be configured to, in response to the received read signal,: generate an encrypted value based on the permanent identifier and the counter value; and provide the encrypted value to the RF transmitter for transmission to the external RF reader device.

Consistent with another disclosed embodiment, a transaction card is provided that is associated with a financial account and generates an encrypted value as part of an authentication request. The transaction card includes an RF transmitter; a near-field communication (NFC) tag coupled to the RF transmitter; and a clock coupled to the NFC tag and powered by a power source. The clock can be configured to send a time value to the NFC tag in response to a wireless read signal received by the NFC tag from an external RF reader device. The NFC tag can be configured to: store a permanent identifier and a time value; and in response to the received read signal, to: generate an encrypted value based on the permanent identifier and the time value; and provide the encrypted value to the RF transmitter for transmission to the external RF reader device.

Consistent with another disclosed embodiment, a transaction card is provided that is associated with a financial account and used to generate an encrypted value as part of an authentication request. The transaction card includes: an RF transmitter; a near-field communication (NFC) tag coupled to the RF transmitter; and a microprocessor coupled to the NFC tag and powered by a power source. The microprocessor can be configured to calculate an updated value in response to a wireless read signal received from an external RF reader device. The NFC tag can be configured to: store a permanent identifier and an updated value, and in response to the received read signal: generate an encrypted value based on the permanent identifier and the updated value, and provide the encrypted value to the RF transmitter for transmission to the external RF reader device.

Consistent with other disclosed embodiments, a tangible computer-readable storage medium may store program instructions executable by one or more processors for implementing any process disclosed herein.

It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the disclosed embodiments.

Attached Figure Description

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several embodiments and, together with the specification, serve to explain the principles of this disclosure. In the drawings:

Figure 1 is a block diagram of an exemplary system consistent with the disclosed embodiments;

Figures 2A-2C are illustrations of exemplary transaction cards consistent with the disclosed embodiments;

Figures 3A-3C are flowcharts illustrating the incrementing of temporary identifiers consistent with the disclosed embodiments; and

Figure 4 is a flowchart of an exemplary process for authenticating a user of a transaction card with a polymorphic tag, consistent with the disclosed embodiments.

Detailed Implementation

Reference will now be made in detail to exemplary embodiments, examples of which are shown in the accompanying drawings and disclosed herein. Where convenient, the same reference numerals are used throughout the drawings to refer to the same or similar parts.

In the disclosed embodiments, when completing a financial transaction on a mobile device, a user can use a transaction card as a form of authentication. This transaction card may be associated with a financial account held by the user with a financial service provider. Most transaction cards contain a static identifier in one or more RFID tags or other storage components. However, such static identifiers are easily copied by malicious users. The disclosed embodiments implement a transaction card that includes a dynamically polymorphic tag that changes each time the tag is read. This dynamic tag is more secure than traditional static tags and prevents malicious users from easily copying and using the tag.

As used herein, the term "transaction card" refers to any physical card product that, when read by a reader, is configured to provide information such as financial information (e.g., card number, account number, account balance, etc.), quasi-financial information (e.g., points balance, discount information, etc.), and/or personally identifiable information (e.g., name, address, etc.). Examples of transaction cards include, but are not limited to, credit cards, debit cards, gift cards, loyalty cards, frequent flyer cards, merchant cards, discount cards, and so on. The term "transaction card" can also include identification documents such as passport cards, driver's licenses, access cards, or similar identification. The physical characteristics of a transaction card (e.g., size, flexibility, and the location of the various components within the card) may conform to various international standards, including, for example, ISO/IEC 7810, ISO/IEC 7811, ISO/IEC 7812, ISO/IEC 7813, ISO/IEC 7816, ISO 8583, ISO/IEC 4909, and ISO/IEC 14443. For example, according to ISO/IEC 7810, the dimensions of a transaction card can be 85.60mm (width) * 53.98mm (height) * 0.76mm (thickness).

Figure 1 illustrates an exemplary system 100 consistent with the disclosed embodiments. As shown in Figure 1, system 100 may include user equipment 110, transaction card 120, network 130 facilitating communication between components of system 100, and service provider (SP) equipment 140. The components included in system 100 and the arrangement of the components may vary. Therefore, system 100 may further include other components that perform or assist one or more processes consistent with the disclosed embodiments. The components and arrangements shown in Figure 1 are not intended to limit the disclosed embodiments, as the components used to implement the processes and features of this disclosure may vary.

System 100 may include one or more user devices 110. User devices 110 are user-operable and may be desktop computers, laptops, tablets, smartphones, multi-functional watches, multi-functional glasses, tracking devices, or any suitable computing-capable device. User devices 110 may include one or more processors and one or more storage devices known to those skilled in the art. For example, user devices 110 may include one or more memory devices storing data and software instructions that, when executed by one or more processors, perform operations consistent with the disclosed embodiments. On one hand, user devices 110 may have transaction applications installed thereon that enable user devices 110 to communicate with transaction cards 120 or SP devices 140 via network 130 or other means (e.g., near-field communication devices). For example, user devices 110 may be smartphones, tablets, or similar devices that execute stored mobile applications to perform various electronic transactions, such as authentication operations (e.g., logging into a computer system), banking operations (e.g., fund transfers, shopping, or cash withdrawals), or similar operations. In other embodiments, user devices 110 may connect to SP devices 140 using browser software stored and executed on user devices 110. User equipment 110 can be configured to execute software instructions to allow users to access information stored in SP device 140, such as, for example, private keys or other authentication information, financial information related to recent shopping transactions, financial discounts, financial statements, account information, points reward information, etc. Furthermore, user equipment 110 can be configured to execute software instructions to initiate and conduct transactions with SP device 140 and/or transaction card 120, such as logging in or authenticating on a website or computer, cash withdrawal, wire transfer, PIN reset, or call center transactions.

User equipment 110 can perform one or more operations consistent with the disclosed embodiments. User equipment 110 can be operated by a user. On one hand, the user can be a customer of a financial service provider (e.g., a financial service provider operating SP device 140). For example, the financial service provider can maintain a financial service account (e.g., a checking account, savings account, debit card account, or credit card account) for the user of user equipment 110. User equipment 110 (and/or other items, such as cards, tokens, key cards, or similar items) can access the account to purchase goods, services, or information. Additionally or alternatively, user equipment 110 and financial service accounts (e.g., via a mobile application installed on user equipment 110) can initiate cash withdrawals from ATMs, contact customer call centers, transfers or wire transfers, or reset their debit card PINs.

In some embodiments, user equipment 110 may include an RFID reader that can detect transaction card 120 using one or more wireless protocols (e.g., Near Field Communication (NFC), BLUETOOTH ^™ , BLUETOOTH LE ^™ (BLE), Radio Frequency Identification (RFID)). As described below, transaction card 120 may include a polymorphic tag, enabling the user to use transaction card 120 as a factor in a multi-factor authentication process. User equipment 110 can read the tag and the encrypted value of a "salt" (i.e., a piece of random data) stored on transaction card 120 and compare the encrypted value with a desired value stored on SP device 140.

The transaction card 120 can be configured to transmit data using protocols such as BLUETOOTH ^™ , BLUETOOTH LE ^™ (BLE), Wi-Fi, Near Field Communication (NFC), or similar protocols. In some embodiments, the transaction card 120 may also include a wireless transmitter, such as an RFID transmitter.

In some embodiments, transaction card 120 may include one or more storage devices storing one or more identifiers. For example, transaction card 120 may store a tag or permanent identifier that can uniquely identify transaction card 120, and one or more other temporary/rolling identifiers, such as salted values. For example, transaction card 120 may be configured to store a tag including a private key and a salted value, the salted value being incremented each time user equipment 110 reads transaction card 120. Transaction card 120 may store the salted value in memory (e.g., by overwriting previously recorded salted values). Transaction card 120 may include an encrypted RFID transmitter configured to send permanent and temporary identifiers to user equipment 110. In some embodiments, one or more identifiers may be stored in a database accessible to SP device 120.

Consistent with the disclosed embodiments, SP device 140 can be a system associated with a website, such as a secure data storage website that stores data and provides data to users. SP device 140 can also be a system associated with a financial service provider (not shown), such as a bank, credit card company, lender, brokerage firm, or any other type of financial service entity that generates, provides, manages, and maintains financial service accounts for one or more users.

SP device 140 can be implemented as one or more computing systems configured to execute software instructions stored on one or more storage devices to perform one or more operations consistent with the disclosed embodiments. For example, SP device 140 may include one or more storage devices storing data and software instructions, and one or more processors configured to use the data and execute the software instructions to perform server-based functions and operations known to those skilled in the art. SP device 140 may include one or more general-purpose computers, mainframe computers, or any combination of these types of components.

In some embodiments, SP device 140 may be configured as a specific means, system, etc., based on software instructions that cause a processor to perform one or more operations consistent with the disclosed embodiments. SP device 140 may be standalone or part of a subsystem that is itself part of a larger system. For example, SP device 140 may represent a remotely located distributed server and communicate over a public network (e.g., network 140) or a private network of a financial service provider (such as a LAN).

SP device 140 may include or have access to one or more storage devices configured to store data and/or software instructions (used by one or more processors of SP device 140 to perform operations consistent with the disclosed embodiments). For example, SP device 140 may include memory configured to store one or more software programs (which perform multiple functions when executed by a processor). The disclosed embodiments are not limited to a single program or computer configured to perform a specific task. For example, SP device 140 may include memory storing a single program or multiple programs. Furthermore, SP device 140 may execute one or more programs located remotely to SP device 140. For example, SP device 140 may access one or more remote programs stored in memory containing remote components that, when executed, perform operations consistent with the disclosed embodiments. In some aspects, SP device 140 may include server software that generates, maintains, and provides services related to financial account management. In other aspects, SP device 140 may connect to one or more separate servers or similar computing devices that generate, maintain, and provide services associated with financial data for financial service providers associated with SP device 140.

SP device 140 can be configured to generate and send expected values to user device 110. The expected values may correspond to the tags and salt values 120 of transaction cards. SP device 140 can also connect to a database and store the generated tag and salt value pairs associated with one or more transaction cards 120.

Network 130 may include any type of computer networking arrangement for exchanging data. For example, network 130 may be one or more of the Internet, a private data network, a virtual private network over a public network, a Wi-Fi network, a LAN or WAN network, and/or other suitable connections that enable information exchange between the various components of system 100. Network 130 may also include a public switched telephone network ("PSTN") and/or a wireless cellular network. Network 130 may be a secure network or an insecure network. In other embodiments, one or more components of system 100 may communicate directly via one or more dedicated communication links, such as the link between user equipment 110 and service provider equipment 140.

Alternatively or concurrently, network 130 may include a direct communication network. Direct communication may utilize any suitable technology, including, for example, BLUETOOTH ^™ , BLUETOOTH LE ^™ (BLE), Wi-Fi, Near Field Communication (NFC), or other suitable communication methods that provide a medium for transferring data between different devices. In some embodiments, user equipment 110 may connect and communicate via a direct communication network.

Other components known to those skilled in the art may be included in system 100 to process, transmit, provide, and receive information consistent with the disclosed embodiments.

Figure 2A is a diagram of an exemplary transaction card 200A, which may correspond to a transaction card 120 (Figure 1) consistent with the disclosed embodiments. Card 200A may include a clock generator 201, an NFC tag 202, and an RFID transmitter 203.

Clock generator 201 can be configured to initiate a cycle in response to electromagnetic radiation from an RFID reader. For example, transaction card 200A may include a Javacard chip (including NFC tag 202) using ISO 14443, such that clock generator 201 can initiate a cycle upon receiving a signal with a frequency of 13.56 MHz from an RFID reader. Each time clock generator 201 initiates a cycle, a counter can increment by a pre-configured value unique to the transaction card. Therefore, clock generator 201 can be configured to "time" each read of transaction card 120 by the RFID reader. The initial value of the counter can also be a unique, pre-configured, non-zero value. Clock generator 201 can be any clock generator circuit configuration known to those skilled in the art.

NFC tag 202 may be a chip including an antenna and an integrated circuit (IC). In some embodiments, NFC tag 202 may be an RFID tag. In another embodiment, NFC tag 202 may be a component of a microchip or microcontroller operating via an NFC coil. In some embodiments, transaction card 200A may include a microchip (e.g., an EMV chip), a communication device (e.g., a near field communication (NFC) antenna, a device, a WiFi device), a magnetic stripe, a barcode, a quick response (QR) code, and/or other devices besides or alternatives to NFC tag 202. In some embodiments, NFC tag 202 may be a component of a Javacard chip operating according to the ISO 14443 standard.

In some embodiments, the NFC tag 202 may store information including a permanent identifier and a temporary identifier (also referred to as a tag and a salt value, respectively). The permanent identifier may contain a unique identification number for the user. In some embodiments, the permanent identifier may be a unique identifier for a transaction card. In another embodiment, the permanent identifier includes transaction data stored by the NFC tag 202. For example, a merchant ID for one, two, three, etc., past transactions. In other embodiments, the stored transaction data may include transaction type, merchant ID, transaction amount, or any combination thereof. The temporary identifier may be data appended to the permanent identifier, such as a numerical value. Upon detection of an electromagnetic signal emitted by an RFID reader (e.g., an RFID reader placed in a mobile device), a current may be induced in the coil of the NFC tag 202, thereby powering a clock generator 201 to initiate a cycle, causing the temporary identifier to increment by a pre-configured increment. The NFC tag 202 then generates an encrypted value for the permanent identifier and the incrementing temporary identifier. In some embodiments, the encrypted value may include a hash value of the permanent identifier and the incrementing temporary identifier.

RFID transmitter 203 can be configured to transmit encrypted values to a device, such as user equipment 110. RFID transmitter 203 may be part of NFC tag 202 and can be configured to transmit encrypted values to an RFID reader in response to a signal received from a reader. RFID transmitter 203 may be further configured to transmit encrypted transaction card data to user equipment 110.

For example, referring to Figure 3A, in the first cycle, NFC tag 202 can detect a signal from an RFID reader that senses the coil of NFC tag 202. NFC tag 202 can provide power induced by the coil to clock generator 201 (step 301). Each clock cycle begins upon receiving power from NFC tag 202. For example, the power supply received from NFC tag 202 can initiate clock cycle 1, clock cycle 2, ..., clock cycle n. In response, clock generator 201 can return signal 302 to NFC tag 202. In step 303, in response to the reception of signal 302, NFC tag 202 can increment counter 305 by a value N to generate a salted value in the form of a temporary identifier C1. In some embodiments, N can be an integer value. N and/or the initial counter value may be unique to transaction card 200A. In step 304, NFC tag 202 can then append the salted value C1 (e.g., counter + N) to a permanent identifier 306 (e.g., tag) and generate an encryption of (PI + C1). The NFC tag 202 can store C1 as a new counter value.

The above process is repeated each time the NFC tag 202 receives a signal from the RFID reader. Simultaneously, the SP device 140 can receive an indication from the user device 110 that the mobile application has initiated the RFID reader activation. The SP device 140 can store a permanent identifier, an initial counter value, and an incrementing value. The SP device 140 can increment the counter each time it receives information from the user device 110 indicating that the RFID reader has been activated. When a user requests authentication via the user device 110, the device's RFID reader can receive the encrypted value generated by the NFC tag 202 from the RFID transmitter 203 and send the encrypted value to the SP device 140. To authenticate the user, the SP device 140 can verify the encrypted value by comparing the encrypted value from the transaction card 200A with the encrypted value generated by the SP device 140.

In some embodiments, the counter value of the transaction card may be out of sync with the counter value of the SP device. For example, if the transaction card is not successfully read, the user device 110 may not be able to communicate with the SP device 140 to increment the counter. However, even without reading the transaction card, the NFC tag 202 can receive a signal from the RFID reader causing the counter to increment. In some embodiments, if the transaction card 120 is not synchronized with the SP device 140, the SP device 140 may instruct the user to tap the card a certain number of times via the user device 110 to the mobile device 110, thereby generating a certain number of readings for the card that cause the card's counter 305 to increment. The SP device 140 may determine that the sequence of encrypted values generated by performing the certain number of taps matches a desired sequence of encrypted values. If the sequences match, the SP device 140 may cause the user device 110 to send an instruction to the transaction 120 to reset.

The system may include a periodic threshold number at which the NFC tag 202 and the SP device 140 may become out of sync. For example, a harmless action (such as an undesirable card placement or a failed attempt) may cause the transaction card and the SP device to become out of sync. A threshold number can be set so that the user can be authenticated as long as the counter value matches within the periodic threshold number. In this embodiment, if the card's counter value is within the periodic threshold number, the card's counter value is set to the current counter value of the SP device. In another example, the counter may become out of sync due to fraudulent activity. If the counter does not match within the periodic threshold number, the authentication request may be rejected, and a fraud alert may be sent to the user and/or the financial service provider. Furthermore, this authentication method can prevent fraud because even if the encryption of the permanent and temporary identifiers is copied, a malicious user cannot replay the copied encrypted value and will not be able to obtain authentication from the system.

Figure 2B is a diagram of another example card 200B, which may correspond to the transaction card 120 (Figure 1) consistent with the disclosed embodiments. The transaction card 200B may include an NFC tag 202 and an RFID transmitter 203, as well as a real-time clock (RTC) 204 powered by a power supply 205.

RTC 204 can be an integrated circuit configured to maintain precise time. That is, RTC 204 can cycle once per second, thereby incrementing the stored time. When NFC tag 202 receives a signal from an RFID reader, RTC 204 can respond by sending a timestamp to NFC tag 202, thus attaching the timestamp to a permanent identifier. In another embodiment, the timestamp can be attached to a numerical value. To enhance user security, RTC 204 can set a unique start time for each transaction card, making the timestamp at a given moment different for each card.

For example, referring to Figure 3B, when a reading is received from an RFID reader and a current is sensed in the IC of NFC tag 202, NFC tag 202 sends a ping 301 to RTC 204. In response, RTC 204 initiates cycle 1 and sends a signal 302 containing the current timestamp, Time 1, to NFC tag 202. In step 303, NFC tag 202 appends the current timestamp Time 1 to an identifier 307 unique to the transaction card to generate a salted value C1. In step 304, NFC tag 202 appends C1 to a permanent identifier 306 associated with the transaction card and generates an encrypted value of PI+C1. In some embodiments, the encrypted value may be a hash value of PI+C1. In some embodiments, the timestamp itself may be a salted value and may be directly appended to PI 306 without first appending and/or adding to identifier 307. The generated encrypted value may be compared with the encrypted values of the permanent identifier (generated by SP device 140) and the timestamp in the first clock cycle. If the encrypted values match, the user can be authenticated. The RTC 204 of transaction card 200B and the corresponding RTC of SP device 140 can be synchronized by initiating these two RTCs simultaneously. In this embodiment, authentication via transaction card 200B is highly secure because temporary identifiers (e.g., salted values) at any given clock cycle are valid for only a short period of time. For example, encrypted values can be valid within a predetermined time window, such as 30 seconds, 60 seconds, etc. In some embodiments, to account for drift between the server clock and RTC 204, the system can accept a certain number of values before and after the currently accepted value. While using RTC to generate salted values is highly secure, RTC 204 requires power supply 205 (e.g., battery or other power source) to operate accurately.

Figure 2C is a diagram of another example card 200C, which may correspond to the transaction card 120 (Figure 1) consistent with the disclosed embodiments. The transaction card 200C may include an NFC tag 202 and an RFID transmitter 203, as well as a microprocessor 206 powered by a power source 205 (e.g., a battery).

Microprocessor 206 can be any of the following: a Pentium ^™ or Xeon ^™ series microprocessor manufactured by Intel ^™ , a Turion ^™ series microprocessor manufactured by AMD ^™ , or a microprocessor of various types manufactured by Sun Microsystems. In other embodiments, microprocessor 206 can be a programmable logic device. Microprocessor 206 can be configured to implement an algorithm that causes the counter stored in NFC tag 202 to increment by a different value in each clock cycle.

Figure 3C is a simplified example of a series of clock cycles. As described above, NFC tag 202 sends a ping 301 to microprocessor 206 upon receiving a signal from an RFID reader. Microprocessor 206 responds by sending the result of an algorithm applied to X of NFC tag 202. For example, microprocessor 206 can be configured to divide the value X by the number of clock cycles. Thus, in the first clock cycle (cycle 1), counter 305 increments X/1 to generate a temporary identifier, such as a salted value C1 (step 303). In cycle 2, the salted value C1 generated during cycle 1 is incremented X/2 to generate a salted value C2, and so on. More complex algorithms can be implemented in each clock cycle to generate the temporary identifier. In step 304, NFC tag 202 appends the salted value generated in step 303 to a permanent identifier 306 associated with the transaction card and determines the encrypted value of the permanent identifier 306 and the salted value. Depending on the required complexity, the algorithm stored by the processor can be directly applied to counter 305. In other embodiments, the result of this algorithm can be the temporary identifier C1. As described above, the user can be authenticated by verifying the encrypted value generated in step 304 against the expected encrypted value generated by the SP device 140.

In some embodiments, if the transaction card 120 is out of sync with the SP device 140, the SP device 140 may send a command to the user equipment 110 to send a signal to the NFC tag 202 to reset the counter. In some embodiments, the user may be required to provide multiple authentication factors before resetting the NFC tag 202. When the NFC tag 202 is reset, the counter or RTC may be set to its initiation starting value. In other embodiments, for increased security, the counter or RTC may be set to a value different from the starting value. In another embodiment, the user equipment 110 may transmit a new algorithm to the microprocessor 206, or may change the increment by which the counter (see FIG. 3A) increases.

Figure 4 is a flowchart illustrating an exemplary process 400 for authenticating a user using a transaction card with a polymorphic tag.

In step 401, system 100 receives an authentication request from user equipment 110 at SP device 140. In some embodiments, the authentication request may be associated with, for example, shopping, transferring funds, or making a payment via a financial service provider's mobile application. The financial service provider may require one or more factors to authenticate the user. The authentication request may include identification information (such as user ID, account number, etc.) to associate the user with a transaction card.

In step 402, the SP device 140 obtains a permanent identifier associated with the transaction card from a memory or database. In some embodiments, the permanent identifier is a private key.

In step 403, SP device 140 generates a temporary identifier. This temporary identifier can be generated using any of the methods described above with reference to FIG3A-3C.

In step 404, SP device 140 generates encryption for permanent identifiers and temporary identifiers.

In step 405, SP device 140 receives an encrypted value from user equipment 110 via network 130. This encrypted value can be obtained from transaction card 120 via RFID reader of user equipment 110.

In step 406, SP device 140 verifies the generated encrypted value based on the received encrypted value. In some embodiments, verification may include a comparison of the encrypted values. If the values are equal, the user can be authenticated. In some embodiments, SP device 140 may store a desired encrypted value associated with one or more clock cycles, up to a threshold number of clock cycles. Therefore, in some embodiments, the user can be authenticated if the received encrypted value matches any of these values.

In step 407, SP device 140 may transmit an authentication command to the mobile device associated with the user. For example, SP device 140 may transmit instructions via network 130 to cause the mobile device to complete a transaction requiring user authentication.

In some embodiments, a transaction card is provided that is associated with a financial account and used to generate an encrypted value as part of an authentication request. The transaction card may include a radio frequency (RF) transmitter; a clock generator coupled to the RF transmitter, the clock generator being configured to increment a counter value in response to a wireless read signal received from an external RF reader device; and a near-field communication (NFC) tag coupled to the RF transmitter and storing a permanent identifier and the counter value. The NFC tag may be configured, in response to the received read signal, to: generate an encrypted value based on the permanent identifier and the counter value; and provide the encrypted value to the RF transmitter for transmission to the external RF reader device.

A permanent identifier can contain a private key.

When the clock generator cycle begins, the RF transmitter can be configured to generate a digital signal.

When the clock generator cycle begins, the clock generator can be configured to increment the counter value by a pre-configured amount. The clock generator can also be configured to update the temporary identifier, the numerical value, and the incremented counter value at the start of the clock generator cycle. The numerical value can be unique to the transaction card. The NFC tag can be configured to generate an encrypted value based on the permanent identifier, the counter value, and the numerical value. The NFC tag can also be configured to store this value after transmission by the RF transmitter.

In some embodiments, the transaction card may include an RF transmitter; a near-field communication (NFC) tag coupled to the RF transmitter; and a clock coupled to the NFC tag and powered by a power source. The clock may be configured to send a time value to the NFC tag in response to a wireless read signal received from an external RF reader device. The NFC tag may be configured to: store a permanent identifier and a time value; and in response to the received read signal, to: generate an encrypted value based on the permanent identifier and the time value; and provide the encrypted value to the RF transmitter for transmission to the external RF reader device.

The power source may include a battery. This power source can provide power to at least one of the radio frequency transmitter or the near-field communication tag.

The time value can include a clock timestamp. The time value can include a timestamp and a value unique to the transaction card. The time value can be valid only for a pre-configured time period.

In another embodiment, the transaction card may include: an RF transmitter; a near-field communication tag coupled to the RF transmitter; and a microprocessor coupled to the near-field communication tag and powered by a power source. The microprocessor may be configured to calculate an updated value in response to a wireless read signal received from an external RF reader device. The near-field communication tag may be configured to: store a permanent identifier and an updated value, and in response to the received read signal: generate an encrypted value based on the permanent identifier and the updated value, and provide the encrypted value to the RF reader for transmission to the external RF transmitter reader device.

Near-field communication tags can be configured to generate temporary identifiers based on updated values during radio frequency transmitter transmission.

The microprocessor can be further configured to change the updated value between subsequent transfers. This updated value can be calculated based on an algorithm. This algorithm can be unique to the transaction card.

The transaction card may further include a memory component coupled to the microprocessor.

Exemplary embodiments of this disclosure describe systems and methods for authenticating users having transaction cards containing polymorphic tags. The above description is provided for illustrative purposes. It is not exhaustive, nor is it limited to the precise form or embodiments of this disclosure. Modifications and adaptations to the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments. For example, the implementations include hardware and software, but systems and methods consistent with this disclosure may be implemented solely as hardware.

Computer programs based on the written descriptions and methods in this specification are within the skill level of software developers. Various programs or program modules can be created using a variety of programming techniques. For example, program parts or modules can be designed or designed using Java, C, C++, assembly language, or any such programming language. One or more such software parts or modules can be integrated into a computer system, a computer-readable medium, or existing communication software.

Furthermore, while illustrative embodiments have been described herein, the scope includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., aspects across different embodiments), adaptations, or variations based on this disclosure. The language used in the claims is interpreted broadly, not limited to the examples described in this specification or in the course of this application, wherein such examples should be interpreted as non-exclusive. Moreover, the steps in the methods of this disclosure can be modified in any way, including by reordering steps or inserting or deleting steps.

Furthermore, although the various aspects of the disclosed embodiments are described as being associated with data stored in memory and other tangible computer-readable storage media, those skilled in the art will understand that these aspects can also be stored on and performed on many types of non-transitory computer-readable media, such as secondary storage devices, like hard disks, floppy disks, CD-ROMs, or other forms of RAM and ROM.

Therefore, this specification and examples are intended to be illustrative only, and their true scope and spirit are indicated by the full scope of the claims and their equivalents.

Claims (10)

1. A transaction card, comprising: Radio frequency transmitter; A clock generator coupled to the radio frequency transmitter and having a dynamic frequency configured to begin a period when the transmitter is transmitting and end a period when the transmitter is not transmitting; and A near-field communication tag, coupled to the clock generator, stores a permanent identifier and a temporary identifier, the temporary identifier including a numerical value and a counter value. 2. The transaction card according to claim 1, wherein the permanent identifier includes a private key. 3. The transaction card according to claim 1, wherein the radio frequency transmitter is configured to generate a digital signal when the clock generator cycle begins. 4. The transaction card according to claim 1, wherein the near-field communication tag is configured to increment the counter by a pre-configured amount when the clock generator cycle begins. 5. The transaction card according to claim 4, wherein the near-field communication tag is configured to update the temporary identifier, the numerical value, and the incrementing counter value when the clock generator cycle begins. 6. The transaction card according to claim 1, wherein the value is unique to the transaction card. 7. The transaction card according to claim 1, wherein the near-field communication tag is configured to generate encryption of the permanent identifier and the temporary identifier. 8. The transaction card according to claim 4, wherein the near-field communication tag is configured to store the temporary identifier after transmission by the radio frequency transmitter. 9. A transaction card, comprising: Radio frequency transmitter; Near-field communication tag, coupled to the radio frequency transmitter; and A real-time clock, coupled to the near-field communication tag and powered by a power source, wherein: The near-field communication tag is configured to store a permanent identifier and a temporary identifier; The near-field communication tag is configured to increment the value of the real-time clock when the radio frequency transmitter transmits data. 10. The transaction card according to claim 9, wherein the power source comprises a battery.