HK40096902A - Techniques to utilize resource locators by a contactless card to perform a sequence of operations - Google Patents

Description

Technology that uses contactless cards to perform a series of operations using resource locators

Cross-references to related applications

This application claims priority to U.S. Patent Application Serial No. 17/235,112, filed April 20, 2021, entitled “TECHNIQUES TO UTILIZE RESOURCELOCATORS BY A CONTACTLESS CARD TO PERFORM A SEQUENCE OF OPERATIONS”. The contents of the above application are incorporated herein by reference in their entirety.

Background Technology

Millions of individuals enjoy the convenience of using credit cards, debit cards, debit cards, or "smart" cards as a means of purchasing goods and/or services. By using these types of cards, individuals can conduct transactions without having cash or currency on hand. In the case of credit cards, debit cards, and debit cards, individuals effectively obtain an instant loan of funds needed to purchase and/or conduct transactions.

To use these cards, customers typically have to go through an activation process. Card activation usually involves a time-consuming process where the cardholder makes a phone call or visits a website and enters or otherwise provides card information. However, current solutions are problematic and prone to human error because they require customers to input information, which is error-prone. Therefore, an improved method for card activation exists.

Summary of the Invention

The embodiments can generally relate to systems, devices, and technologies, including a computer-implemented method for activating a contactless card via a mobile device. The technology may include receiving a first Uniform Resource Locator (URL) for an application configured to perform activation from the contactless card via a wireless interface, and launching the application in response to receiving the first URL. The technology may include writing a second URL for conditions to the contactless card via a wireless interface, receiving the second URL for conditions from the contactless card via a wireless interface, and presenting the conditions on a display of the mobile device. The technology may also include writing a third URL for a first unique identifier to identify a customer associated with the contactless card, receiving the third URL to confirm the conditions, and determining that the contactless card is activated at least partially in response to the confirmation of the conditions.

The embodiments may also generally pertain to technologies and systems, including means for exchanging Universal Resource Locators (URLs) with contactless cards, comprising a processor and memory, the memory including instructions executable by the processor. When executing the instructions, the processor may receive, via a wireless interface, a first URL for an application configured to perform operations on the contactless card from the contactless card, launch the application in response to receiving the first URL, and write a second URL for conditions to the contactless card via the wireless interface. The processor may also receive the second URL for conditions from the contactless card via the wireless interface, present the conditions on a display, compose a third URL for a first unique identifier to identify a customer associated with the contactless card, and receive the third URL from the contactless card to confirm the conditions.

The embodiments may also include a non-transitory computer-readable medium comprising a set of instructions responsive to execution by processor circuitry of the contactless card, causing the processor circuitry, in response to a first wireless read, to transmit a first Uniform Resource Locator (URL) for an application to a mobile device via a wireless interface, the first URL being stored in the memory of the contactless card, and a second URL for conditions associated with the contactless card being stored in the memory, the second URL being received from the mobile device. The embodiments also include processor circuitry configured to, in response to a second wireless read, transmit the second URL for conditions to the mobile device, store in memory a third URL for a unique identifier to identify a customer associated with the contactless card, and, in response to a third wireless read, transmit the third URL to confirm the conditions.

Attached Figure Description

To facilitate identification of any discussion of a particular element or action, one or more of the most significant digits in the reference number refer to the figure number in which the element was first introduced.

Figure 1 shows a contactless card 100 according to an embodiment.

Figure 2 shows a contactless card assembly 200 according to an embodiment.

Figure 3 illustrates one aspect of the subject matter according to an embodiment.

Figure 4 illustrates routine 400 according to an embodiment.

Figure 5 illustrates routine 500 according to an embodiment.

Figure 6 illustrates routine 600 according to an embodiment.

Figure 7 illustrates a sequence flow 700 according to an embodiment.

Figure 8 illustrates a data structure 800 according to an embodiment.

Figure 9 is a diagram of a key system according to an example embodiment.

Figure 10 is a flowchart of a method for generating a password according to an example embodiment.

Figure 11 illustrates one aspect of the subject matter according to an embodiment.

Figure 12 illustrates one aspect of the subject matter according to an embodiment.

Detailed Implementation

The embodiments generally pertain to methods, devices, and systems for activating contactless cards (such as credit and debit cards). Typically, a customer may receive a contactless card in the mail or from a bank branch that is inactive. To activate the card, the customer must go through a process, which usually involves making a phone call and/or visiting a website. The customer is then asked to enter information (such as the account number on the card), and an activation sequence is executed by a back-end activation system operated and/or controlled by the bank to activate the card. However, these current solutions are problematic because they require customer input and are prone to error. For example, a customer might incorrectly enter the account number when entering it via a keypad or telephone keypad. In these cases, for security purposes, the activation system typically does not inform the customer of their error but simply stops the activation attempt, for example, by hanging up the customer's call or stating that activation cannot be completed.

The embodiments discussed herein address these problems and provide improvements in one or more technical fields or categories (e.g., electronic activation of contactless cards). The discussed embodiments involve a customer receiving a contactless card from an issuing institution with minimal instructions. For example, the instructions might simply tell the customer to turn on the near-field communication (NFC) interface on their mobile device. The customer can then be instructed to perform a series of taps with the card on and/or near the mobile device to complete the steps required to activate the card. Tapping the card on the mobile device ensures that the customer has brought the contactless card within the device's operating range, and that wireless exchange of information can occur. In one example, the customer might be instructed to tap the contactless card on a surface of the mobile device, such as a display. Bringing the contactless card within range of the mobile device may result in an action or series of actions to perform an operation, such as activating the contactless card.

In a specific example, a contactless card can be sent to a user programmed using resource locators such as a Uniform Resource Locator (URL), Uniform Resource Identifier (URI), Uniform Resource Name (URN), etc. For example, the resource locator can be stored in the contactless card's memory and can be communicated to the mobile device as part of a read operation performed by the mobile device when the contactless card is brought into range. The mobile device can perform actions based on the received resource locator. For example, the resource locator could be a link or instruction to launch an app store or a banking app. After receiving the resource locator, the mobile device can launch the app store to download an app (such as a banking app associated with the contactless card). In some instances, the app may already be installed on the mobile device, and the resource locator may cause the banking app to launch. A mobile device including an app can allow a customer to go through a series of actions, with the next action initiated when the card is brought into the mobile device's wireless communication range. For example, once the app is installed/launched on the mobile device, the customer can be instructed to tap the contactless card again to initiate a set of terms and conditions for reading. Customers can provide an additional tap to accept the contactless card's terms of service and authorize their mobile device to activate the card by communicating with the activation server. Once activated, the card may be in an active state, and then each additional tap may result in the same action, such as the banking app being launched to a login page that displays account details.

The embodiments discussed herein are not limited to performing an activation process. For example, the operations discussed herein can be used to cause any number of operations or a series of actions to be performed, and the contactless card can be used as a state machine to store instructions for the next step in a series of steps for performing an operation. As will become more apparent in the following description, communication exchanges, such as read/write operations, may occur between the device and the card when the contactless card is brought into the wireless operating range of the device. For example, the device can read a resource locator from the card, and the device writes the new instruction or resource locator to the card's memory. The instruction or resource locator can be used by the contactless card to maintain a state or a step in a series of steps to perform an operation. During the next read operation, the contactless card can provide the instruction or resource locator to the reading device to cause the next step. These and other details will become more apparent in the following description.

Referring now to the accompanying drawings, in which similar reference numerals are consistently used to refer to similar elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding thereof. However, it may be apparent, however, that novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form for the purpose of description. The intention is to cover all modifications, equivalents, and substitutions within the scope of the claims.

Figure 1 illustrates an example configuration of a contactless card 100, which may include a transaction card, payment card, such as a credit card, debit card, or gift card, issued by a service provider (as shown as service provider marking 102 on the front or back of the contactless card 100). In some examples, the contactless card 100 is not a payment card and may include, but is not limited to, an identification card. In some examples, the transaction card may include a dual-interface contactless payment card, a rewards card, etc. The contactless card 100 may include a substrate 108, which may include a single layer or one or more laminates composed of plastics, metals, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 100 may have physical characteristics conforming to the ID-1 format of the ISO/IEC 7816 standard, and the transaction card may additionally conform to the ISO/IEC 14443 standard. However, it should be understood that the contactless card 100 according to this disclosure may have different characteristics, and this disclosure does not require the implementation of a transaction card in a payment card.

The contactless card 100 may also include identification information 106 displayed on the front and/or back of the card, and a contact pad 104. The contact pad 104 may include one or more pads and is configured to establish contact with another client device (such as an ATM, user equipment, smartphone, laptop, desktop, or tablet) via the transaction card. The contact pad may be designed according to one or more standards (such as the ISO/IEC 7816 standard) and enable communication according to the EMV protocol. The contactless card 100 may also include processing circuitry, an antenna, and other components, as will be further discussed in Figure 2. These components may be located behind the contact pad 104 or elsewhere on the substrate 108, for example, within different layers of the substrate 108, and may be electrically and physically coupled to the contact pad 104. The contactless card 100 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card (not shown in Figure 1). The contactless card 100 may also include an NFC device coupled to an antenna capable of communicating via the NFC protocol. Embodiments are not limited in this manner.

As shown in Figure 2, the contact pad 104 of the contactless card 100 may include processing circuitry 216 for storing, processing, and communicating information, including a processor 202, a memory 204, and one or more interfaces 206. It should be understood that the processing circuitry 216 may include additional components required to perform the functions described herein, including a processor, memory, error and parity/CRC checkers, a data encoder, anti-collision algorithms, a controller, a command decoder, security primitives, and tamper-proof hardware.

Memory 204 may be a read-only memory, a write-once-read-many memory, or a read/write memory (e.g., RAM, ROM, and EEPROM), and the contactless card 100 may include one or more of these memories. A read-only memory can be factory-programmable to read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read multiple times. A write-once/read-many memory can be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be overwritten but may be read multiple times. A read/write memory may be programmed and reprogrammed multiple times after leaving the factory. A read/write memory may also be read multiple times after leaving the factory. In some instances, memory 204 may be an encrypted memory that encrypts data using an encryption algorithm executed by processor 202.

Memory 204 may be configured to store one or more applets 208, one or more counters 210, customer identifiers 214, and accounts 212, which may be virtual accounts. One or more applets 208 may include one or more software applications, such as card applets, configured to execute on one or more contactless cards. However, it should be understood that applets 208 are not limited to Java card applets and may instead be any software application operable on a contactless card or other device with limited memory. One or more counters 210 may include numeric counters sufficient to store integers. Customer identifier 214 may include a unique alphanumeric identifier assigned to a user of contactless card 100, and this identifier may distinguish the user of the contactless card from other contactless card users. In some examples, customer identifier 214 may identify a customer and the account assigned to that customer, and may further identify the contactless card 100 associated with that customer's account. As stated, account 212 may include thousands of one-time-use virtual accounts associated with contactless card 100. The applet 208 of the contactless card 100 can be configured to manage account 212 (e.g., select account 212, mark the selected account 212 as used) and transfer account 212 to the mobile device for autofill via an autofill service.

The processor 202 and memory elements of the foregoing exemplary embodiments have been described with reference to the contact pad 104, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of the contact pad 104 or completely separated from the contact pad 104, or as further elements located within the contact pad 104 (in addition to the processor 202 and memory 204 elements).

In some examples, the contactless card 100 may include one or more antennas 218. The one or more antennas 218 may be placed within the contactless card 100 and surrounding the processing circuitry 216 of the contact pad 104. For example, the one or more antennas 218 may be integrated with the processing circuitry 216, and the one or more antennas 218 may be used in conjunction with an external boost coil. As another example, the one or more antennas 218 may be external to the contact pad 104 and the processing circuitry 216.

In an embodiment, the coil of the contactless card 100 can act as the secondary of an air-core transformer. The terminal can communicate with the contactless card 100 by cutting off power or amplitude modulation. The contactless card 101 can infer data transmitted from the terminal using gaps in the power connection of the contactless card, which can be functionally maintained by one or more capacitors. The contactless card 100 can communicate in reverse by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the coil of the terminal through interference. More generally, using antenna 218, processor 202, and/or memory 204, the contactless card 101 provides a communication interface for communication via NFC, Bluetooth, and/or Wi-Fi.

As explained above, the contactless card 100 can be built on a software platform that operates on smart cards or other devices with limited memory, such as JavaCards, and one or more applications or applets can be securely executed. An applet 208 can be added to the contactless card to provide a one-time password or passcode (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 208 can be configured to respond to one or more requests (such as near-field data exchange requests) from a reader (such as a mobile NFC reader, e.g., a mobile device or point-of-sale terminal) and generate an NDEF message that includes a password-secured OTP encoded as an NDEF text tag.

An example of NDEF OTP is the NDEF Short Record Layout (SR=1). In this example, one or more applets 208 can be configured to encode the OTP into NDEF Type 4 known text tags. In some examples, the NDEF message may include one or more records. The applet 208 can be configured to add one or more static tag records in addition to the OTP record.

In some examples, one or more applets 208 can be configured to simulate RFID tags. RFID tags may include one or more polymorphic tags. In some examples, different cipher data is presented each time the tag is read, which may indicate the authenticity of the contactless card. Based on one or more applets 208, NFC readings of the tags can be processed, data can be transmitted to a server (such as a bank's server), and the data can be verified at the server.

In some examples, the contactless card 100 and the server may include data that allows the card to be correctly identified. The contactless card 100 may include one or more unique identifiers (not shown). A counter 210 may be configured to increment each time a read operation occurs. In some examples, each time data from the contactless card 100 is read (e.g., via a mobile device), the counter 210 is transmitted to the server for verification, and it is determined whether the counter 210 equals (as part of the verification) the server's counter.

One or more counters 210 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if counter 210 has been read, used, or otherwise transmitted. If counter 210 has not yet been used, it can be replayed. In some examples, the counter incremented on the card is different from the counter incremented for each transaction. Because there is no communication between the applets 208 on the contactless card 100, the contactless card 101 cannot determine the application of transaction counter 210.

In some examples, counter 210 may be out of sync. In some examples, counter 210 may be incremented to account for unexpected reads that initiate a transaction (such as reads at an angle), but the application does not process counter 210. In some examples, NFC may be enabled when mobile device 10 is woken up, and device 110 may be configured to read available tags, but without taking any action in response to the read.

To keep counter 210 synchronized, an application (such as a background application) can be executed, configured to detect when mobile device 110 wakes up and synchronizes with the bank's server, indicating a read due to the detection, and then moving counter 104 forward. In other examples, a hashed one-time password can be used to allow for windows that accept erroneous synchronization. For example, if within a threshold of 10, counter 210 can be configured to move forward. However, if within a different threshold number, such as 10 or 1000, a request to perform resynchronization can be processed, requested via one or more applications: by the user tapping, gesturing, or otherwise indicating once or multiple times via the user's device. If counter 210 increments in the appropriate order, it can be known that the user has done so.

The key diversification technique described herein with reference to counter 210, master key, and diversification key is an example of an encryption and/or decryption key diversification technique. This example key diversification technique should not be considered as a limitation of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

During the creation process of the contactless card 100, each card can be uniquely assigned two cryptographic keys. These cryptographic keys may include symmetric keys, which can be used for data encryption and decryption. The Triple DES (3DES) algorithm can be used by EMV, and it is implemented by hardware within the contactless card 100. Through a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information for each entity requiring a key.

In some examples, to overcome the limitations of the 3DES algorithm (which can be vulnerable to vulnerabilities), session keys (such as a unique key for each session) can be derived, but instead of using the master key, the key and counter derived from the unique card can be used as diversification data. For example, each time a contactless card 101 is used in an operation, a different key can be used to create a message authentication code (MAC) and perform encryption. This results in a three-layer cipher. Session keys can be generated by one or more applets and derived by using an application transaction counter with one or more algorithms (as defined in EMV 4.3Book 2A1.3.1 General Session Key Derivation).

Furthermore, the increment for each card can be unique and can be assigned either through personalization or algorithmically through some identifying information. For example, odd-numbered cards can increment by 2, and even-numbered cards can increment by 5. In some examples, the increment can also vary during sequential reading, allowing a card to increment sequentially by 1, 3, 5, 2, 2, ... and repeat. The specific order or algorithmic order can be defined during personalization or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record can be encoded in hexadecimal format.

In an embodiment, the contactless card 100 may store a resource locator 220 in memory 204. For example, during the creation process, the resource locator 220 used to initiate the activation process may be written to memory 204. During the activation process, a device (such as a mobile device) may perform an NDEF read operation to read the resource locator 220. In one example, the contactless card may be initiated with the resource locator 220, which points to an app store to download an app associated with the contactless card. For example, the resource locator 220 may be “https://play.google.com/store/apps/details?id=<package_name>”, where package_name may refer to the app. In another example, the resource locator 220 may be “http://apps.apple.com/<country>/app/<app-name>/id<store-ID>”, where app-name and id are references to the downloaded app. In an embodiment, memory 204 may include two resource locators, allowing a customer to activate the contactless card using any device with an operating system or an operating system. In some instances, the app may already be installed on the mobile device, and resource locator 220 can enable the mobile device's operating system to launch the app. For example, upon receiving resource locator 220, the mobile device can check if the app is installed; if so, the operating system will skip the installation process and launch the app.

In an embodiment, the contactless card 100, including resource locator 220, can be used as a "state machine" in which the next operation in a series of operations can be stored in resource locator 220 until it is ready to be executed/processed by an external device (mobile device). Resource locator 220 in memory 204 can be updated with new instructions or locators for the series of operations until the series is complete.

A device (such as a mobile device) can write to memory 204 using NDEF write or rewrite instructions to update resource locator 220. For example, during an activation process, the mobile device can read resource locator 220 to install and/or launch an app associated with the contactless card. The mobile device can also perform a write operation to write the new resource locator 220 to memory 204 for use in the next operation to be performed. In some embodiments, the next operation may require a customer to review the terms and conditions associated with the contactless card, and the mobile device can write a link to the terms and conditions of resource locator 220 in memory 204. In one example, the link may be a deep link to a local location within the app on the mobile device. In another example, the link may be an external link (outside the app) to launch a website in a web browser on the mobile device. Embodiments are not limited to these examples.

In this embodiment, once the device receives a resource locator from the contactless card 100, the device can write the resource locator to the card as the next step. For example, the device can write a unique identifier that can be used by the customer to accept the terms and conditions. Specifically, when the customer has read and is ready to accept the terms and conditions, the customer can bring the contactless card 100 into the range of the device, and the device can perform an NFC reading operation to read the resource locator including the unique identifier. The device can then determine that the terms and conditions have been accepted and perform activation using an activation server/system.

During the activation sequence, the contactless card component 200 (including memory 204) can be updated with one or more resource locators 220. Each time the contactless card 100 is brought into range (NFC range), the resource locator 220 can be updated with a different/new resource locator or instruction to perform the next operation of the activation sequence on the mobile device. The mobile device can perform an NDEF write operation to write the new resource locator 220 into memory 204. Each of the different resource locators 220 can cause the mobile device to perform different operations, such as downloading/launching an app, presenting terms and conditions, and accepting terms and conditions, as previously discussed. Once activated, the resource locator 220 can store instructions or resource locators to cause the app on the mobile device to initiate a login page. For example, the resource locator 220 can cause the app to initiate a page displaying account information (as associated with the contactless card) (e.g., account balance, payment activity, transactions, bonuses/rewards, etc.). The contactless card 200 can store the resource locator 220 and launch the app to the login page until the resource locator 220 is updated with new instructions to perform another operation.

Figure 3 illustrates an example system 300 that can be used to perform contactless card activation. In the illustrated example, system 300 includes a contactless card 100, a mobile device 302, and an activation system 304. Components of system 300 can be configured to communicate with each other via one or more wired and/or wireless interconnects. For example, contactless card 100 can be configured to communicate with mobile device 302 via a wireless interconnect according to a wireless protocol such as Wi-Fi. Mobile device 302 can also be configured to communicate with activation system 304 according to wireless and/or wired protocols.

In this embodiment, system 300 can be used by a customer to activate contactless card 100 via mobile device 302. For example, contactless card 100 may be configured with a resource locator during creation, which enables the operating system on mobile device 302 to install or launch an app associated with contactless card 100. In operation, contactless card 100 may be provided to the customer with instructions to activate a short-range radio (such as an NFC interface) on mobile device 302 and to bring contactless card 100 within range of mobile device 302. This range may be the operating range of the short-range radio, satisfied by tapping the card onto mobile device 302. In one example, this range may be the operating range according to the NFC standard. Mobile device 302 may detect contactless card 100 and perform an exchange with contactless card 100 to establish communication, such as an NFC exchange.

Mobile device 302, communicating with contactless card 100, can perform a read operation (NFC read) to read data from the memory of contactless card 100. In an embodiment, the read operation may refer to a memory location or another identifier to read a resource locator stored in the memory. Contactless card 100, including circuitry, can process the read operation, retrieve the resource locator from the memory, and provide the resource locator to mobile device 302. Mobile device 302 can process the data including the resource locator received from contactless card 100. In this example, the operating system of mobile device 302 can launch an app store to download a banking app, or initiate the banking app if it is already installed on mobile device 302.

In some instances, a customer may be required to perform multiple steps to activate the contactless card 100. The mobile device 302 can write new resource locators into the memory of the contactless card 100 to perform each new operation. For example, in response to an app initiating the activity, the mobile device 302, including the app, can write (NFC write operation) a new resource locator into the memory of the contactless card 100. The new resource locator can be an instruction or link (deep link) pointing to the terms and conditions associated with the contactless card 100. Therefore, the next time the contactless card 100 is brought within the communication range of the mobile device 302, the mobile device 302 can perform another NFC read operation, receive the updated resource locator from the contactless card 100, and perform one or more operations to process the resource locator. For example, the mobile device 302 can process the resource locator, which could allow the app to present the terms and conditions on the display of a banking app or in a graphical user interface (GUI) on the web browser of the mobile device 302.

In this embodiment, the contactless card 100 can be used to authenticate the user and accept terms and conditions. For example, the mobile device 302 can obtain a unique identifier associated with the customer. The mobile device 302 can request the customer to enter credentials (such as a password, unique pattern, biometrics, passcode, etc.), and the mobile device 302 can obtain and/or generate a unique identifier for the customer based on the entered credentials. In some instances, the mobile device 302 can generate a random alphanumeric sequence for the unique identifier. The embodiments are not limited in this manner.

Mobile device 302 can perform a write operation to write a new resource locator including a unique identifier. Once the customer is ready to accept the terms and conditions, mobile device 302 can instruct the customer to bring the card within range. Mobile device 302 can perform a read operation to read the resource locator including the unique identifier and activate the contactless card 100.

To perform activation, mobile device 302 can communicate data with activation system 304. This data may include information such as identifying the customer, identifying contactless card 100, and confirming that terms and conditions are accepted. Activation system 304 can process the data and confirm with mobile device 302 whether contactless card 100 has been activated or activation failed. Mobile device 302 can display information in its app GUI indicating whether contactless card 100 has been activated.

In some instances, the contactless card 100 can generate a unique identifier and communicate it with an OTP to perform authentication operations. For example, to accept terms and conditions and/or launch a banking app to a login page with sensitive information, the mobile device 302 can instruct the customer to bring the contactless card 100 within range of the mobile device 302. Once within range, the contactless card 100 and the mobile device 302 can perform an NFC exchange. For example, the contactless card 100, including the instruction, can be configured to respond to one or more requests (such as a Near Field Data Exchange request) from a mobile NFC reader of the mobile device 302 and generate an NDEF message that includes a cryptographically secure OTP encoded as an NDEF text tag with a unique identifier. An example of an NDEF OTP is an NDEF short record layout (SR=1). In this example, one or more card instructions can be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. The instructions can be configured to add one or more static tag records in addition to the OTP record.

In this embodiment, the contactless card 100 can be activated, and the resource locator can be set with a unique identifier to be used with the OTP to perform authentication for each read operation. For example, each time the contactless card 100 is brought into range of the mobile device 302, the mobile device 302 can receive the OTP with the encrypted unique identifier and perform the authentication operation. If authenticated, the mobile device 302 can cause actions such as launching an app to a login page (including account balance and/or other information related to a bank account).

Figure 4 illustrates an example routine 400 that can be executed by mobile device 302 to activate contactless card 100. In block 402, routine 400 includes receiving a first Uniform Resource Locator (URL) for an application from the contactless card via a wireless interface. In this embodiment, the application may be a banking app and is configured to perform activation. The first URL may be stored in the memory of contactless card 100 and communicated to mobile device 302 as part of an NDEF exchange including NDEF reading. The first URL may be processed by the operating system of mobile device 302 and trigger one or more events. Specifically, at block 404, routine 400 includes launching the application in response to receiving the first URL. In some instances, the app may be installed on mobile device 302, and the operating system may cause the app to execute upon receiving the first URL. In other instances, the app may not be installed on mobile device 302. In these instances, the operating system may cause an app store to launch, and the first URL may include information directing the app store to a download page for the banking app. The embodiments are not limited in this manner.

In block 406, routine 400 includes writing a second URL for the terms and conditions to the contactless card. In an embodiment, the second URL may include a link to a location (such as a deep link or web link) so that the terms and conditions are presented to the user on the display of mobile device 302. Mobile device 302 can determine the second URL from an app, which may be a deep link stored locally within a file in the app. When the app is launched to perform contactless card activation, it can provide a deep link to the operating system, and the operating system can generate a message, such as a "Write NDEFMessage" message, including the deep link as the second URL written to the contactless card. In other instances, the app may provide a link to a website, or a website page accessible via a web browser. The operating system can use an NDEF message to write the website/page link to the contactless card. The contactless card can store the second URL in memory until it is ready to perform the next action in the activation sequence (e.g., the customer is ready to view the terms and conditions by bringing the card back into the range of the mobile device).

In box 408, routine 400 includes receiving a second URL for the terms and conditions from the contactless card. In some instances, the app may present instructions in a GUI on the display of mobile device 302 for the user to bring the contactless card within range of mobile device 302 to read the terms and conditions, such as instructions for a customer to tap the contactless card on the display. Mobile device 302 may perform the reading operation. In response to the reading operation, mobile device 302 may receive the second URL from the contactless card in an NDEF message. The operating system of mobile device 302 may process the second URL, including causing the app or web browser to open and display the terms and conditions. As mentioned, the second URL may be a location within the app itself or a link to a website/page. Furthermore, and at box 410, routine 400 includes presenting the terms and conditions on the display of the mobile device. The terms and conditions may be presented in a GUI and can be read by the customer. The customer can then read the terms and conditions.

In box 412, routine 400 includes writing a third URL for a unique identifier to identify a customer associated with a contactless card. The third URL, including the unique identifier, can be used by mobile device 302 to identify the customer and activate the card upon acceptance of the terms and conditions. The unique identifier can be any combination of alphanumeric symbols. In some instances, the unique identifier can be based on information associated with the contactless card (e.g., account number, postal code, address, etc.) and/or credentials entered by the customer. However, in other instances, the unique identifier can be completely random and generated by the app and/or operating system.

In box 414, routine 400 includes receiving a third URL to confirm the terms and conditions. In some instances, the app may present the terms and conditions to the customer on a display and include instructions for the customer to bring a contactless card into range of mobile device 302 to accept the terms and conditions. In one example, the instructions may instruct the customer to tap the contactless card against mobile device 302. When the contactless card is in range, mobile device 302 may perform a read operation. Mobile device 302, including the app, may receive a third URL including a unique identifier to ensure that the same customer/card is being used to accept the terms and conditions. If the received unique identifier matches a previously written unique identifier (box 412), the app may determine that the customer has accepted the terms and conditions.

In this embodiment, once the customer accepts the terms and conditions, the mobile device 302 can activate the contactless card. For example, the mobile device 302, including an app, can communicate with the activation system 304 to activate the contactless card. In some examples, the mobile device 302 can communicate to the activation system 304 information indicating that the customer accepts the terms and conditions and information identifying the contactless card being activated. The card identification information may include an identifier (username) associated with the customer, the contactless card's account number, or other identifying information. The activation system 304 can use this information and activate the contactless card for transaction execution. At block 416, routine 400 includes determining that the contactless card is activated at least partially in response to the conditions being acknowledged. In one example, the mobile device 302 may receive an indication from the activation system 304 indicating that the contactless card has been activated or that activation failed. The mobile device 302 can notify the customer, for example, by presenting information on a display (regarding whether the contactless card has been activated). In some instances, when activation fails, the app may present the customer with instructions on how to recover from the failed activation attempt.

In this embodiment, once the card is activated, the customer can use the contactless card and mobile device 302 to launch an app to a login page or perform another action. For example, for each additional instance of the card being brought into the range of mobile device 302, the operating system can detect and launch the app. Mobile device 302 can also perform a read operation, and the contactless card can send information to mobile device 302. In one example, the contactless card can generate a password that may include a unique identifier and an OTP, and communicate this password to mobile device 302. Mobile device 302 can use the unique identifier and OTP to authenticate the user and cause a login page containing sensitive information to be presented to the user.

Figure 5 illustrates an example routine 500 that can be executed by contactless card 100 to activate contactless card 100 via mobile device 302. In block 502, routine 500 includes sending a first Uniform Resource Locator (URL) for an application to the mobile device. In an embodiment, the contactless card may send the first URL to mobile device 302 via a wireless interface (such as an NFC interface) in response to a read operation. The first URL may be stored in the memory of the contactless card. The contactless card, including circuitry, may retrieve the first URL from memory and communicate it to mobile device 302 in an NDEF message. In some instances, the first URL may be a link to launch an app on mobile device 302. In some instances, when an app is not installed on mobile device 302, mobile device 302 may launch an app store in response to receiving the first URL.

In block 504, routine 500 includes receiving a second URL relating to conditions for activating the contactless card. The second URL may be received by the contactless card from mobile device 302. In some instances, mobile device 302 may perform an NFC writing operation to write the second URL into the memory of the contactless card. The second URL may include a link to the terms and conditions associated with the contactless card and may be included in an NDEF message. At block 506, routine 500 includes storing the second URL in memory via the contactless card.

In block 508, routine 500 includes sending a second URL to the mobile device. In an embodiment, the second URL may be communicated by the contactless card in response to another read operation performed by the mobile device 302. The contactless card may send the second URL to the mobile device 302 in an NDEF message. In an embodiment, the read operation may be performed, as previously discussed, when the contactless card is brought into the wireless operating range of the mobile device 302.

In block 510, routine 500 receives a third URL for a unique identifier to identify a customer associated with the contactless card. The third URL can be received by the contactless card in response to a write operation performed by mobile device 302. Similar to a read operation, a write operation can be performed when the contactless card is brought into the wireless range of mobile device 302. In some embodiments, read and write operations can be performed as part of an exchange during the same instance. For example, a customer can bring the contactless card into the range of mobile device 302, and mobile device 302 can perform a read operation, as discussed in block 508, to read the second URL. Mobile device 302 can determine that resource locator 220 needs to be updated and can perform a write operation to write the third URL into the memory of the contactless card. An exchange can occur during a single instance when a customer brings the contactless card into the wireless range. Furthermore, and at block 512, routine 500 includes storing the third URL in the memory of the contactless card.

At block 514, routine 500 includes sending a third URL to the mobile device. In this embodiment, the contactless card may send the third URL in response to the contactless card being brought into the wireless range of the mobile device 302, as previously described. In this instance, a customer may bring the contactless card into the range of the mobile device 302 in response to an instruction presented to the customer on the mobile device 302 and to accept or confirm the terms and conditions. The third URL may include a unique identifier that can be used by the mobile device 302 to confirm that the correct card/customer is confirming the terms and conditions. The third URL may be communicated to the mobile device 302 as part of a read operation and in an NDEF message.

The techniques discussed in this article are not limited to executing activation sequences of contactless cards, but can also be used to perform different operations or series of actions by using the contactless card as a "state machine." For example, a device with NFC read and write capabilities can utilize the memory of the contactless card to store data, such as instructions or instruction blocks, as resource locators. For instance, the device can write data as a resource locator into the memory of the contactless card to store the state of a series of actions or operations to be performed. When the next action is to be performed, the device can read the resource locator and perform the next action based on the contents stored in the memory. The device can write data including the next instruction as a resource locator into the memory of the contactless card. This process can be repeated until the series of actions is completed. In some instances, the contactless card may include an OTP with a resource locator when it is read, allowing the device to verify and/or authenticate the user. Data communicated between the contactless card and the device can be communicated in raw or encrypted format in NDEF messages.

Figure 6 illustrates an example routine 600 that stores data as a resource locator via a contactless card to perform an operation in a series of actions or operations, and the contactless card can be used as a state machine to execute the operations. At block 602, routine 600 includes storing instructions or data in the memory of the contactless card. For example, a device (such as a mobile device or point-of-sale (POS) terminal) can write data including instructions as a resource locator into the memory of the contactless card. The data can be instructions to perform one or more operations to complete a series of operations. The device can perform an NFC write operation to write data to memory using short-range radio (such as NFC and IN and NDEF messages). The contactless card can store data in memory until the next read operation and/or until the data is overwritten. The data or instructions in the resource locator can include any operation that can be performed by a computing device. In the example, the data can be a link to a location, such as a network link or a link/pointer to a memory location. In another example, the data can be computer instructions that can be implemented and/or executed on a device. Instructions can be high-level instructions that can be executed by the device, such as those used in scripting languages, or low-level instructions, such as C code, Java code, assembly code, etc. Implementation examples are not limited in this manner.

At block 604, routine 600 includes providing data to a device. For example, the device may perform an NFC read operation, and a contactless card may generate an NDEF message to communicate data to the device. In some embodiments, the data may be communicated cryptographically, as discussed herein. This data may be used by the device and cause operations to be performed.

At block 606, routine 600 includes determining whether new data containing instructions has been received. For example, a contactless card may detect a write operation initiated by the device to write new data including the next instruction in the series of actions. If new data is detected, the contactless card may store the data in memory, as indicated by routine 600. If no new data is detected, routine 600 may terminate until another write operation is performed.

Routine 600 can be used to perform any type of series of operations by the device, such as completing transactions through a POS terminal and/or on a mobile device, making payments via a bank app, changing settings on a bank app, etc. Implementation examples are not limited to these examples.

Figure 7 is a timing diagram illustrating example sequences for providing authenticated access according to one or more embodiments of the present disclosure. Sequence stream 700 may include a contactless card 100 and a client device 702, which may include an application 704 and a processor 706. In some embodiments, the client device 702 may be a mobile device 302. In some instances, the following sequence may be performed between the mobile device 302 and the contactless card 100 to perform one or more activation steps and/or authenticate the client to launch the app to a login page on the mobile device 302, as previously discussed with respect to Figure 3.

At point 710, application 704 communicates with contactless card 100 (e.g., after being brought near contactless card 100). Communication between application 704 and contactless card 100 may involve contactless card 100 being sufficiently close to a card reader (not shown) of client device 702 to enable NFC data transfer between application 704 and contactless card 100.

At point 708, after communication is established between client device 702 and contactless card 100, contactless card 100 generates a Message Authentication Code (MAC) password. In some examples, this may occur when contactless card 100 is read by application 704. Specifically, this may occur during the reading of a near field data exchange (NDEF) tag (such as NFC reading), which can be created according to the NFC data exchange format. For example, reader applications (such as application 704) may transmit a message (such as an app selection message) with an app ID that generates an NDEF. After confirming the selection, a sequence of selected file messages can be transmitted, followed by read file messages. For example, the sequence may include "Select Capability File", "Read Capability File", and "Select NDEF File". At this point, a counter value maintained by contactless card 100 can be updated or incremented, which may be followed by "Read NDEF File". At this point, a message can be generated, which may include a header and a shared secret. A session key can then be generated. A MAC cipher can be created from a message that may include a header and a shared secret. The MAC cipher can then be concatenated with one or more blocks of random data, and the MAC cipher and the random number (RND) can be encrypted using a session key. Afterward, the cipher and header can be concatenated, encoded into ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF file" message).

In some examples, the MAC cipher may be transmitted as an NDEF tag, and in other examples, the MAC cipher may include a Uniform Resource Identifier (URI) or a locator (e.g., as a formatted string). For example, the MAC cipher may include a resource locator (including a unique identifier). In some examples, application 704 may be configured to transmit a request to contactless card 100 that includes instructions to generate a MAC cipher.

At line 712, the contactless card 100 sends the MAC password to application 704. In some examples, the transmission of the MAC password occurs via NFC; however, this disclosure is not limited thereto. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other means of wireless data communication. At line 714, application 704 communicates the MAC password to processor 706.

At point 716, processor 706 verifies the MAC cipher according to instructions from application 122. For example, the MAC cipher can be verified as explained below. In some examples, MAC cipher verification can be performed by a device other than client device 702, such as a server in a banking system that communicates data with client device 702. For example, processor 706 can output the MAC cipher for transmission to the server in the banking system, which can verify the MAC cipher. In some examples, the MAC cipher can be used as a digital signature for verification purposes. Other digital signature algorithms, such as public-key asymmetric algorithms, like digital signature algorithms and RSA algorithms, or zero-knowledge protocols, can be used to perform this verification.

Figure 8 illustrates an NDEF short record layout (SR=1) data structure 800 according to an example embodiment. One or more applets can be configured to encode OTP as NDEF Type 4 known type text tags. In some examples, the NDEF message may include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: known type, text, encoded English (en); applet ID: D2760000850101; capability: read-only access; encoding: the authentication message may be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as a personalization parameter that can be used to generate the NDEF message. In an embodiment, the authentication template may include a first record with a known index for providing the actual dynamic authentication data.

Figure 9 illustrates a system 900 configured to implement one or more embodiments of the present disclosure. As explained below, during the contactless card creation process, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys may include symmetric keys, which can be used for encryption and decryption of data. The Triple DES (3DES) algorithm can be used by EMV, and it is implemented by hardware in the contactless card. By using a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information for each entity requiring the key.

Regarding master key management, for each part of a portfolio issuing one or more applets, two issuer master keys 902 and 926 may be required. For example, the first master key 902 may include an issuer password generation/authentication key (Iss-Key-Auth), and the second master key 926 may include an issuer data encryption key (Iss-Key-DEK). As further explained herein, the two issuer master keys 902 and 926 are diversified into card master keys 908 and 920, which are unique to each card. In some examples, the Network Profile Record ID (pNPR) 522 and the Derived Key Index (pDKI) 924 (as background data) may be used to identify which issuer master key 902 and 926 is used in the cipher process for authentication. The system performing authentication can be configured to retrieve the values of pNPR 922 and pDKI 924 of the contactless card during authentication.

In some examples, to enhance solution security, session keys can be derived (such as a unique key for each session), but not using the master key. The unique card-derived key and counter can be used as diversification data, as explained above. For example, a different key can be used each time the card is used in an operation to create a Message Authentication Code (MAC) and perform encryption. Regarding session key generation, the key used to generate passwords and cryptographicate data in one or more applets can include session keys (Card-Key-Auth 908 and Card-Key-Dek 920) based on the card's unique key. Session keys (Aut-Session-Key 932 and DEK-Session-Key 910) can be generated by one or more applets and derived using an Application Transaction Counter (pATC) 904 with one or more algorithms. To fit data into one or more algorithms, only the two lower-order bytes of the 4-byte pATC 904 are used. In some examples, the four-byte session key export method may include: F1:=PATC(lower 2 bytes)∥'F0'∥'00'∥PATC(four bytes) F1:=PATC(lower 2 bytes)∥'0F'∥'00'∥PATC(four bytes) SK:={(ALG(MK)[F1])∥ALG(MK)[F2]}; where ALG may include 3DES ECB and MK may include the card-unique exported master key.

As described in this article, one or more MAC session keys can be derived using the lower two bytes of the pATC 904 counter. The pATC 904 is configured to be updated with each tap of the contactless card, and the card master keys Card-Key-AUTH 508 and Card-Key-DEK 920 are further diversified into session keys Aut-Session-Key 932 and DEK-Session-KEY 910. The pATC 904 can be initialized to zero at personalization or applet initialization time. In some examples, the pATC counter 904 can be initialized during or before personalization and can be configured to increment by one with each NDEF read.

Furthermore, updates for each card can be unique and assigned either through personalization or algorithmically through pUID or other identifying information. For example, odd-numbered cards can increment or decrement by 2, and even-numbered cards can increment or decrement by 5. In some examples, updates can also vary during sequential reads, allowing a card to repeat in sequence: 1, 3, 5, 2, 2, ... . The specific order or algorithmic order can be defined during personalization or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

The authentication message can be delivered as the content of a hexadecimal ASCII formatted text NDEF record. In some examples, it may consist only of authentication data and an 8-byte random number (followed by the MAC for the authentication data). In some examples, the random number may precede the password A and can be a block length. In other examples, there may be no limit to the length of the random number. In further examples, the total data (i.e., the random number plus the password) may be a multiple of the block size. In these examples, an additional 8-byte block may be added to match the block generated by the MAC algorithm. As another example, if the algorithm used employs 16-byte blocks, even multiples of the block size may be used, or the output may be automatically or manually padded to multiples of the block size.

MAC can be executed via the function key (AUT-Session-Key) 932. The data specified in the cipher can be processed using the Javacard signature method: ALG_DES_MAC8_IS09797_1_M2_ALG3, associated with the EMV ARQC authentication method. The key used for this calculation can include the session key AUT-Session-Key 932, as explained above. As explained above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As described below, the AUT session key 932 can be used for MAC data 906, and the resulting data or cipher A914 and random number RND can be encrypted using DEK-Session-Key 910 to create the cipher B or output 918 sent in the message.

In some examples, one or more HSM commands can be processed for decryption, such that the final 16 bytes (binary, 32 hexadecimal) can include 3DES symmetric encryption using CBC mode, where a zero IV of a random number is followed by MAC authentication data. The key used for this encryption can include a session key DEK-Session-Key 910 derived from Card-Key-DEK 920. In this case, the ATC value derived from the session key is the least significant byte of the counter pATC 904.

The following format represents an example embodiment of the binary version. Furthermore, in some examples, the first byte may be set to ASCII 'A'.

Another exemplary format is shown below. In this example, the label can be encoded in hexadecimal format.

The UID field of the received message can be extracted to derive the card master key (Card-Key-Auth 908 and Card-Key-DEK 920) for that specific card from the master keys Iss-Key-AUTH 502 and Iss-Key-DEK 926. Using the card master keys (Card-Key-Auth 508 and Card-Key-DEK 920), the counter (pATC) field of the received message can be used to derive the session key (Aut-Session-Key 932 and DEK-Session-Key 910) for that specific card. Password B918 can be decrypted using DEK-Session-Key, which generates password A914 and RND, and RND can be discarded. The UID field can be used to look up the shared secret of the contactless card, which, along with the Ver, UID, and pATC fields of the message, can be processed using the recreated Aut-Session-Key via the password MAC to create a MAC output, such as MAC'. If the MAC' matches the password A914, this indicates that message decryption and MAC checks have both passed. The pATC can then be read to determine its validity.

During the authentication session, one or more passwords can be generated by one or more applications. For example, one or more passwords can be generated as a 3DES MAC using ISO 9797-1 Algorithm 3 with Method 2 padding via one or more session keys (such as Aut-Session-Key 932). Input data 906 can take the form of: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses can include a length in bytes. In some examples, the shared secret can be generated by one or more random number generators that can be configured to ensure that the random numbers are unpredictable through one or more security processes. In some examples, the shared secret can include a random 4-byte binary number from a personalized time-injected card known to the authentication service. During the authentication session, the shared secret may not be provided to the mobile application from one or more applets. Method 2 padding can include forcibly adding a 0x’80’ byte to the end of the input data, and a 0x’00’ byte can be added to the end of the resulting data up to an 8-byte boundary. The resulting password can include a length of 8 bytes.

In some examples, one advantage of encrypting a non-shared random number as the first block using a MAC cipher is that it acts as an initialization vector when using the CBC (Block Chain) mode of a symmetric encryption algorithm. This allows for "scrambling" from block to block without having to pre-establish a fixed or dynamic IV.

By including the Application Transaction Counter (pATC) as part of the data included in the MAC cipher, the authentication service can be configured to determine whether the value conveyed in the clean data has been tampered with. Furthermore, by including the version in one or more ciphers, it becomes much harder for an attacker to intentionally distort the application version and attempt to weaken the strength of the cipher. In some examples, the pATC can start at zero and be updated by 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC equal to or less than a previously received value by the authentication service, this can be interpreted as an attempt to replay an old message, and the authenticated message can be rejected. In some examples, when the pATC is greater than a previously received value, this can be evaluated to determine if it is within an acceptable range or threshold, and if it exceeds or is outside the range or threshold, the verification can be considered a failure or unreliable. In MAC operation 912, data 906 is processed via MAC using Aut-Session-Key 932 to produce MAC output (cipher A) 914, which is encrypted.

To provide additional protection against brute-force attacks that expose the key on the card, it is expected that the MAC cipher 914 will be cryptographic. In some examples, the data or cipher A914 to be included in the ciphertext may include: a random number (8), a cipher (8). In some examples, the number in parentheses may include a length in bytes. In some examples, the random number may be generated by one or more random number generators that can be configured to ensure the random number is unpredictable through one or more secure processes. The key used to cryptographicate the data may include a session key. For example, the session key may include DEK-Session-Key 910. In encryption operation 916, the data or cipher A914 and RND are processed using DEK-Session-Key 910 to produce encrypted data, cipher B 918. The data 914 may be cryptographicated using 3DES in cipher block chaining mode to ensure that an attacker must perform any attack on all ciphertext. As a non-limiting example, other algorithms such as Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' can be used. Any attacker attempting to brute-force the key used to cryptograph this data will be unable to determine when the correct key is used, because correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its randomness.

In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be transmitted in plaintext from one or more applets to the mobile device during the authentication session: version number, to determine the cipher method used and the message format used to verify the password, which allows the method to change in the future; pUID, to retrieve the cipher asset and export the card key; and pATC, to export the session key used for the cipher.

Figure 10 illustrates a method 1000 for generating a password. For example, at box 1002, the Network Profile Record ID (pNPR) and the Derived Key Index (pDKI) can be used to identify which issuer's master key is used in the password process for authentication. In some examples, the method may include performing authentication to retrieve the values of the contactless card's pNPR and pDKI during authentication.

At box 1004, the issuer master keys can be diversified by combining them with the card’s unique ID number (pUID) and the PAN serial number (PSN) of one or more applets (such as payment applets).

At box 1006, Card-Key-Auth and Card-Key-DEK (unique card key) can be created by diversifying the issuer's master key to generate a session key, which can be used to generate a MAC cipher.

At box 1008, the key used to generate the password and cryptographicate data in one or more applets may include the session key from box 1030 based on the card-unique key (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys may be generated by one or more applets and exported using pATC to produce session keys Aut-Session-Key and DEK-Session-Key.

Figure 11 illustrates an exemplary process 1100 of key diversification according to one example. Initially, the sender and receiver may be provided with two different master keys. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value (which may be updated at box 1102) and other data (such as the data to be protected), which can be securely shared with the receiver.

At box 1104, the counter value can be encrypted by the sender using the data encryption master key to generate a data encryption-derived session key, and the counter value can also be encrypted by the sender using the data integrity master key to generate a data integrity-derived session key. In some examples, the entire counter value or a portion of the counter value can be used during both encryption processes.

In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted between the sender and receiver in plaintext, i.e., without encryption.

At box 1106, the data to be protected is processed by the sender using a data integrity session key and a cryptographic MAC algorithm via a cryptographic MAC operation. The protected data (including plaintext and shared secret) can be used to generate a MAC using one of the session keys (AUT-Session-Key).

At box 1108, the data to be protected can be encrypted by the sender using a session key derived from data encryption in conjunction with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data, such as 8 bytes each, and then encrypted using a second session key (DEK-Session-Key).

At box 1110, the encrypted MAC is transmitted from the sender to the receiver with enough information to identify the additional secret information (such as the shared secret, master key, etc.) used to verify the password.

At box 1112, the receiver uses the received counter value to independently derive two derived session keys from the two master keys, as explained above.

At box 1114, the session key derived from data encryption, combined with a symmetric decryption operation, is used to decrypt the protected data. Further processing of the exchanged data then occurs. In some examples, after the MAC is extracted, it is expected that the MAC will be reconstructed and matched. For example, when verifying a password, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. The MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Because the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

At box 1116, the session key derived for data integrity is used in conjunction with the cipher MAC operation to verify that the protected data has not been modified.

Some examples of the methods described herein can advantageously confirm successful authentication when the following conditions are met. First, the ability to verify the MAC indicates that the derived session key is correct. A MAC can only be considered correct if decryption is successful and produces the correct MAC value. Successful decryption indicates that the correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key was created using a master key known only to the sender (e.g., the transmitting device) and the receiver (e.g., the receiving device), it can be believed that the contactless card that initially created and encrypted the MAC is indeed genuine. Furthermore, the counter values used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

After this, the two derived session keys can be discarded, and the next iteration of the data exchange will update the counter value (returning to box 1102), and a new set of session keys can be created (at box 1110). In some examples, the combined random data can be discarded.

Figure 12 illustrates a method 800 for card activation according to an example embodiment. For example, card activation can be performed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers may refer to the same or similar components previously explained, such as contactless card 100, client device 702, and server.

In box 1202, the card can be configured to dynamically generate data. In some examples, this data may include information such as an account number, card identifier, card verification value, or phone number, which can be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted using the systems and methods disclosed herein.

In box 1204, one or more portions of dynamically generated data can be communicated to the device's application via NFC or other wireless communications. For example, tapping the card near the device can allow the device's application to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application to help activate the card, tapping the card can guide the device or prompt the customer to download the associated application from an app store to activate the card. In some examples, the user can be prompted to gesture, place, or orient the card towards the surface of the device, such as placing it at an angle or flat on the surface of the device, nearby, or adjacent to it. In response to the card's gesture, placement, and/or orientation, the device can proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

In box 1206, one or more portions of the data can be communicated to one or more servers, such as an issuer server. For example, one or more encrypted portions of the data can be transmitted from the device to the card issuer server for card activation.

In box 1208, one or more servers may decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and may decrypt it to compare the received data with record data accessible to one or more servers. If a successful match is found by the comparison of one or more decrypted portions of the data by one or more servers, the card may be activated. If an unsuccessful match is found by the comparison of one or more decrypted portions of the data by one or more servers, one or more procedures may occur. For example, in response to the determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be predetermined thresholds, including the number of attempts the user is allowed to activate the card. Alternatively, the user may receive a notification, such as a message on his or her device indicating an unsuccessful attempt at card verification, and call, email, or text message the associated service for assistance in activating the card, or another notification, such as a telephone call on his or her device indicating an unsuccessful attempt at card verification, and call, email, or text message the associated service for assistance in activating the card, or another notification, such as an email indicating an unsuccessful attempt at card verification, and call, email, or text message the associated service for assistance in activating the card.

In box 1210, one or more servers can transmit a return message based on successful card activation. For example, the device can be configured to receive output from one or more servers indicating that the card has been successfully activated by one or more servers. The device can be configured to display a message indicating successful card activation. Once the card has been activated, it can be configured to stop dynamically generating data to prevent fraudulent use. In this way, the card may not be activated thereafter, and one or more servers will be notified that the card has been activated.

Claims (20)

1. A computer-implemented method for activating a contactless card via a mobile device, comprising: The mobile device receives a first Uniform Resource Locator (URL) for an application via a wireless interface from the contactless card, the application being configured to perform the activation; The application is launched by the mobile device in response to receiving the first URL; The mobile device writes a second URL for the conditions to the contactless card via the wireless interface; The mobile device receives the second URL of the conditions from the contactless card via the wireless interface; The conditions are presented by the mobile device on the display of the mobile device; A third URL, written by the mobile device, is used as a first unique identifier to identify a customer associated with the contactless card; The mobile device receives the third URL to confirm the conditions; and The mobile device determines that the contactless card is activated at least in part in response to the confirmation of the condition. 2. The computer-implemented method according to claim 1, comprising: The mobile device sends a command to the contactless card via the wireless interface, the command instructing the contactless card's applet to generate a password; and The password is received by the mobile device based at least in part on the first unique identifier. 3. The calculation method according to claim 2, comprising: The password is sent from the mobile device to the server; and The mobile device receives a response indicating whether the contactless card is activated or not. 4. The computer-implemented method according to claim 1, wherein the wireless interface is one of a near field communication (NFC) interface or a Bluetooth interface. 5. The computer-implemented method according to claim 1, comprising: writing a fourth URL to the contactless card via the wireless interface by the mobile device, the fourth URL including a second unique identifier and a one-time password of the contactless card. 6. The computer-implemented method according to claim 5, comprising: The fourth URL is received by the mobile device from the contactless card via the wireless interface; The mobile device sends at least the one-time password to the server; and The mobile device responds by sending the one-time password reception response, the response including the account balance associated with the contactless card. 7. The computer-implemented method of claim 6, wherein the response is received via a short message service message or an application message in the application. 8. The computer-implemented method of claim 1, wherein the application is launched by the operating system of the mobile device in response to receiving the first URL. 9. The computer-implemented method of claim 1, wherein the second URL of the condition is a deep link pointing to a location within the application. 10. An apparatus for exchanging Universal Resource Locators (URLs) with contactless cards, comprising: processor; and The memory includes instructions that, when executed by the processor, cause the processor to: The application receives a first Uniform Resource Locator (URL) for an application via a wireless interface from the contactless card, the application being configured to perform operations of the contactless card; The application is launched in response to receiving the first URL; The second URL for the conditions is written to the contactless card via the wireless interface; Receive the second URL of the conditions from the contactless card via the wireless interface; The conditions are displayed on the monitor; Compile a third URL for the first unique identifier to identify the customer associated with the contactless card; and The third URL is received from the contactless card to confirm the conditions. 11. The apparatus of claim 10, wherein the processor: Sending app instructions to the contactless card via the wireless interface, the app instructions instructing the contactless card's app to generate a password; and The password is received at least in part based on the first unique identifier. 12. The apparatus of claim 11, wherein the processor: Send the password to the server; and The response indicating whether the contactless card is activated or not is received, at least in part based on the password. 13. The apparatus of claim 10, wherein the wireless interface is one of a near field communication (NFC) interface or a Bluetooth interface. 14. The apparatus of claim 10, wherein the processor writes a fourth URL to the contactless card via the wireless interface, the fourth URL including a second unique identifier of the contactless card and a one-time password. 15. The apparatus of claim 14, wherein the processor: Receive the fourth URL from the contactless card via the wireless interface; Send at least the one-time password to the server; and In response to sending the one-time password reception response, the response includes data associated with the contactless card. 16. The apparatus of claim 15, wherein the response is received via a short message service message or an application message in the application. 17. The apparatus of claim 10, wherein the application is launched by the operating system of the mobile device in response to receiving the first URL. 18. The apparatus of claim 10, wherein the second URL of the condition is a deep link to a location within the application. 19. A non-transitory computer-readable medium comprising a set of instructions, the instructions being responsive to execution by processor circuitry of a contactless card, such that the processor circuitry: In response to the first wireless read, a first Uniform Resource Locator (URL) for the application is sent to the mobile device via a wireless interface, the first URL being stored in the memory of the contactless card; A second URL relating to conditions of the contactless card is stored in the memory, and the second URL is received from the mobile device; In response to the second wireless read, a second URL for the conditions is sent to the mobile device; A third URL for a unique identifier is stored in the memory to identify the customer associated with the contactless card; and In response to a third wireless read, the third URL is sent to confirm the conditions. 20. The non-transitory computer-readable medium of claim 19, wherein the processor: An app is executed based on instructions received from the mobile device, and the app generates a password; and In response to the fourth query, the password is sent to the mobile device, the password including an encrypted unique identifier generated from the unique identifier.