A technology for using a resource locator via a contactless card to perform a series of operations.

Abstract

Embodiments may be generally directed to methods, techniques, and devices for utilizing contactless cards to perform a series of operations.

Description

Technical Field

[0001] Related Applications This application claims priority to U.S. Patent Application No. 17 / 235,112, filed Apr. 20, 2021, titled "Techniques for Utilizing a Resource Locator by a Contactless Card to Perform a Series of Operations." The entire content of the foregoing application is incorporated herein by reference in its entirety.

Background Art

[0002] Millions of individuals enjoy the convenience of using credit cards, charge cards, debit cards, or "smart" cards as a convenient way to purchase goods and / or services. By using these types of cards, an individual can conduct transactions without having cash or currency on hand or otherwise. In the case of credit cards, charge cards, and debit cards, an individual effectively obtains immediate financing of the funds necessary to make a purchase and / or conduct a transaction.

[0003] To use these cards, customers generally need to go through an activation process to activate the card. Activating a card generally involves a time-consuming process where the cardholder calls a phone number or visits a website to enter or otherwise provide card information. However, current solutions have problems and are subject to human error. This is because current solutions require customers to enter information and are subject to errors. Therefore, there is a need for an improved method of activating a card.

Summary of the Invention

[0004] Embodiments can generally cover systems, devices, and technologies that include a computer implementation method for performing contactless card activation via a mobile device. The technology may include the steps of: receiving a first uniform resource locator (URL) relating to an application from a contactless card via a wireless interface, wherein the application is configured to perform activation; and launching the application in response to the receipt of the first URL. The technology may also include the steps of: writing a second URL relating to a condition to the contactless card via a wireless interface; receiving the second URL relating to the condition from the contactless card via a wireless interface; and presenting the condition on the display of the mobile device. The technology may also include the steps of: writing a third URL relating to a first unique identifier for identifying a customer associated with the contactless card; receiving the third URL to confirm the condition; and determining that the contactless card is activated, at least in part, in response to the confirmation of the condition.

[0005] The embodiments may also generally cover technologies and systems that include a device for replacing a universal resource locator with a contactless card, the device including a processor and a memory containing instructions that can be executed by the processor. When executing an instruction, the processor may receive a first uniform resource locator (URL) relating to an application from the contactless card via a wireless interface, the application being configured to perform an action for the contactless card, the processor launching the application in response to receiving the first URL, and writing a second URL relating to a condition to the contactless card via the wireless interface. The processor may also receive a second URL relating to a condition from the contactless card via the wireless interface, present the condition on a display, write a third URL relating to a first unique identifier for identifying the customer associated with the contactless card, and receive a third URL from the contactless card to confirm the condition.

[0006] The embodiment may also include a non-temporary computer-readable medium containing a set of instructions, which, depending on being executed by a processor circuit of a contactless card, cause the processor circuit to transmit a first uniform resource locator (URL) relating to an application to a mobile device via a wireless interface in response to a first wireless read, the first URL being stored in the memory of the contactless card; the instructions cause the processor circuit to store in memory a second URL relating to conditions associated with the contactless card, the second URL being received from the mobile device. The embodiment also includes a processor circuit configured to transmit a second URL to conditions to a mobile device in response to a second wireless read, store in memory a third URL relating to a unique identifier for identifying a customer associated with the contactless card, and transmit a third URL to confirm the conditions in response to a third wireless read.

[0007] To facilitate the identification of any particular element or action description, the most significant digit of the reference number refers to the figure number in which that element is first introduced. [Brief explanation of the drawing]

[0008] [Figure 1] A contactless card 100 according to an embodiment is shown. [Figure 2] A contactless card component 200 according to the embodiment is shown. [Figure 3] This shows an embodiment of the subject according to the embodiment. [Figure 4] A routine 400 according to the embodiment is shown. [Figure 5] A routine 500 according to the embodiment is shown. [Figure 6] A routine 600 according to an embodiment is shown. [Figure 7] A sequence flow 700 according to the embodiment is shown. [Figure 8] A data structure 800 according to the embodiment is shown. [Figure 9]This is a diagram of a key system according to an exemplary embodiment. [Figure 10] This is a flowchart of the method for generating ciphertext according to the embodiment. [Figure 11] This shows an embodiment of the subject according to the embodiment. [Figure 12] This shows an embodiment of the subject according to the embodiment. [Modes for carrying out the invention]

[0009] Embodiments can generally relate to methods, devices, and systems for performing the activation of contactless cards, such as credit and debit cards. Generally, a customer can receive a contactless card in an inactive state by mail or from a bank branch. To activate the card, the customer typically needs to go through a process that includes calling a phone number and / or visiting a website. The customer then needs to enter information such as the account number on the front of the card, and a backend activation system operated and / or controlled by the bank performs an activation sequence to activate the card. However, these current solutions have problems because they require the customer to enter information and are prone to errors. For example, when entering the account number via a phone keypad or keyboard, the customer may enter the account number incorrectly. In these situations, the activation system generally does not inform the customer of the error for security reasons, but simply aborts the activation attempt and, for example, hangs up the phone with the customer or states that activation could not be completed.

[0010] The embodiments described herein provide solutions to these problems and improvements in one or more technical fields, for example, the electronic activation of contactless cards. The embodiments described include a customer receiving a contactless card from a card issuer with minimal instructions. For example, the instructions could simply tell the customer to turn on the Near Field Communication (NFC) interface on their mobile device. The customer could then be instructed to perform a series of taps with the card on and / or near the mobile device to go through the steps necessary to activate the card. Tapping the card on the mobile device ensures that the customer brings the contactless card within the operating range of the device and that a wireless exchange of information can take place. In one example, the customer could be instructed to tap the contactless card on a surface of the mobile device, such as on a display. Bringing the contactless card within the range of the mobile device may result in an action or series of actions to perform an action such as activating the contactless card.

[0011] In one specific example, a contactless card may be sent to a programmed user with a resource locator such as a Uniform Resource Locator (URL), Uniform Resource Identifier (URI), or Uniform Resource Name (URN). The resource locator may be stored, for example, in the contactless card's memory, or communicated to a mobile device as part of a read operation performed by the mobile device when the contactless card is within range. The mobile device can take action based on the reception of the resource locator. For example, the resource locator may be a link or instruction to launch an application (app) store or a banking app. Upon receiving the resource locator, the mobile device may launch an app store and download an app, such as a banking app related to the contactless card. In some cases, the app may already be installed on the mobile device, and the resource locator may launch a banking app. The mobile device, including the app, can cause the customer to perform a series of actions, the next of which is initiated when the card is brought within the mobile device's wireless communication range. For example, the customer may be instructed to tap the contactless card again to activate a set of terms and conditions to read once the application is installed / launched on the mobile device. The customer can provide another tap to accept the terms of service for the contactless card and allow the mobile device to activate the card by communicating with an activation server. Once activated, the card can remain activated, and each subsequent tap can trigger the same action; for example, a banking app might launch to a landing page where details about the account can be displayed.

[0012] The embodiments described herein are not limited to performing an activation process. For example, the operations described herein may be used to perform any number of operations or a series of actions, and the contactless card may be used as a state machine that holds instructions for the next step in a series of steps to perform the operations. As will become clearer in the following description, when the contactless card enters the wireless operating range of the device, communication exchanges, such as read / write operations, may occur between the device and the card. For example, the device may read a resource locator from the card and write a new instruction or resource locator to the card's memory. The instruction or resource locator may be used by the contactless to hold the state or steps in a series of steps to perform the operations. During the next read operation, the contactless card may provide the reading device with the instruction or resource locator to trigger the next step. These and other details will become clearer in the following description.

[0013] Drawings are referenced here, and similar reference numbers are used throughout to indicate similar elements. The following description includes many specific details for explanatory purposes and to provide a complete understanding. However, it will be apparent that novel embodiments can be implemented without these specific details. In other examples, well-known structures and devices are shown in block diagram form for the sake of clarity. The intent is to cover all modifications, equivalents, and substitutions within the claims.

[0014] Figure 1 shows an exemplary configuration of a contactless card 100, which may include a payment card such as a transaction card, credit card, debit card, or gift card issued by a service provider, so as to be displayed on the front or back of the contactless card 100 as a service provider mark 102. In some examples, the contactless card 100 may include an identification card, but is not limited to a payment 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 be a single layer or a laminate of one or more layers made of plastic, metal, and other materials. Typical substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some cases, the contactless card 100 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard, or the transaction card may conform to the ISO / IEC 14443 standard. However, the contactless card 100 relating to this disclosure may have different characteristics, and it should be understood that this disclosure does not require the implementation of a transaction card in a payment card.

[0015] The contactless card 100 may also include identification information 106 displayed on the front and / or back of the card, and contact pads 104. The contact pads 104 may include one or more pads and may be configured to establish contact with another client device such as an ATM, user device, smartphone, laptop, desktop, or tablet computer via the transaction card. The contact pads may be designed in accordance with one or more standards, such as ISO / IEC 7816, and may enable communication in accordance with the EMV protocol. The contactless card 100 may also include processing circuits, antennas, and other components, as further illustrated in Figure 2. These components may be located behind the contact pads 104 or elsewhere on the substrate 108, for example, in different layers of the substrate 108, and may be electrically and physically coupled to the contact pads 104. The contactless card 100 may also include a magnetic strip or tape that 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 that can communicate via the NFC protocol. Embodiments are not limited thereto.

[0016] As shown in Figure 2, the contact pads 104 of the contactless card 100 may include a processing circuit 216 for storing, processing, and communicating information, which includes a processor 202, memory 204, and one or more interfaces 206. It is understood that the processing circuit 216 may include additional components as necessary to perform the functions described herein, including a processor, memory, error and parity / CRC check unit, data encoder, anti-collision algorithm, controller, command decoder, security primitive, and tamper-proof hardware.

[0017] Memory 204 may be read-only memory, write-once multiplex read memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 100 may include one or more of these memories. Read-only memory may be factory programmable as read-only or one-time programmable. One-time programmability provides multiple opportunities to read after being written once. Write-once / multiplex read memory may be programmed after the memory chip leaves the factory. Once programmed, the memory may not be rewritten but may be read multiple times. Read / write memory may be programmed and reprogrammed multiple times after leaving the factory. Read / write memory may also be read multiple times after leaving the factory. In some cases, memory 204 may be encrypted memory that utilizes an encryption algorithm performed by processor 202 on encrypted data.

[0018] Memory 204 may be configured to store one or more applets 208, one or more counters 210, a customer identifier 214, and an account number 212 which may be a virtual account number. The one or more applets 208 may include one or more software applications configured to execute on one or more contactless cards such as Java (registered trademark) card applets. However, it is understood that the applets 208 are not limited to Java card applets and may instead be any software application operable on a contactless card or other device having limited memory. The one or more counters 210 may include numeric counters sufficient to store integers. The customer identifier 214 can include a unique alphanumeric identifier assigned to a user of the contactless card 100, and the identifier can distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 214 can identify both the customer and the account assigned to that customer and can further identify the contactless card 100 associated with the customer's account. As described above, the account number 212 can include thousands of disposable virtual account numbers associated with the contactless card 100. The applet(s) 208 of the contactless card 100 can be configured to manage the account number(s) 212 (e.g., select the account number(s) 212, mark the selected account number(s) 212 as used, and transmit the account number(s) 212 to a mobile device for auto-fill by an auto-fill service).

[0019] Although the processor 202 and memory elements of the foregoing exemplary embodiments have been described with reference to the contact pad 104, the present disclosure is not limited thereto. It is understood that these elements may be implemented outside the contact pad 104, or may be completely separated from the contact pad 104, or may be implemented as additional elements in addition to the processor 202 and memory 204 elements disposed within the contact pad.

[0020] In some examples, the contactless card 100 can include one or more antennas 218. The one or more antennas 218 may be disposed within the contactless card 100 and around the processing circuit 216 of the contact pad 104. For example, the one or more antennas 218 may be integral with the processing circuit 216, and the one or more antennas 218 may be used with an external booster coil. As another example, the one or more antennas 218 may be external to the contact pad 104 and the processing circuit 216.

[0021] In one embodiment, the coil of the contactless card 100 can function as the secondary side of a air-core transformer. The terminal can communicate with the contactless card 100 by means of a switched power or amplitude modulation. The contactless card 101 can infer data transmitted from the terminal using the power connection gap of the contactless card that can be functionally maintained via one or more capacitors. The contactless card 100 can return communication by switching the load or load modulation of the coil of the contactless card. The load modulation can be detected by the coil of the terminal due to interference. More generally, using the antenna 218, the processor 202, and / or the memory 204, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0022] As mentioned above, the contactless card 100 can be built on a software platform that can run on other devices with limited memory, such as a smart card or JavaCard, and can securely run one or more applications or applets. 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 app-based use cases. The applet 208 may be configured to respond to one or more requests, such as a Near Field Wireless Data Exchange request from a reader (e.g., a mobile device or point-of-sale terminal), and generate an NDEF message containing a cryptographically secure OTP encoded as an NDEF text tag.

[0023] An example of an NDEF OTP is the NDEF short record layout (SR=1). In such an example, one or more applets 208 can be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, an NDEF message may contain one or more records. Applet 208 may be configured to add one or more static tag records in addition to the OTP record.

[0024] In some examples, one or more applet 208 may be configured to emulate an RFID tag. The RFID tag can include one or more different forms of tags. In some examples, each time the tag is read, different encrypted data is presented that can indicate the authenticity of the contactless card. Based on one or more applet 208, the NFC reading of the tag can be processed, the data can be sent to a server such as a banking system server, and the data can be verified by the server.

[0025] In some examples, the contactless card 100 and the server may contain specific data so that the card can be properly identified. The contactless card 100 may contain one or more unique identifiers (not shown). Each time a read operation is performed, the counter 210 may be configured to increment. In some examples, each time data is read from the contactless card 100 (for example, by a mobile device), the counter 210 is sent to the server for verification, and (as part of the verification) it is determined whether the counter 210 is equal to a counter on the server.

[0026] One or more counters 210 may be configured to prevent replay attacks. For example, if a ciphertext is intercepted and replayed, the ciphertext is immediately rejected if counter 210 has been read, used, or otherwise passed. If counter 210 has not been used, it may be replayed. In some examples, a counter incremented on the card is different from a counter incremented for a transaction. The contactless card 101 cannot determine the application transaction counter 210 because there is no communication between the applets 208 on the contactless card 100.

[0027] In some cases, counter 210 may become out of sync. In some cases, counter 210 may be incremented to account for accidental reads that initiate a transaction, such as reads at a certain angle, but the application does not process counter 210. In some cases, when mobile device 10 is woken up, NFC may be enabled and device 110 may be configured to read available tags, but no action is taken in response to the reads.

[0028] To keep counter 210 synchronized, an application such as a background application may be run that can be configured to detect when the mobile device 110 wakes up and then synchronize with a banking system server indicating the reads that occurred as a result of the detection, in order to advance counter 104. In other examples, a hashed one-time password may be used so that a window of missynchronization may be acceptable. For example, if it is within a threshold of 10, counter 210 may be configured to move forward. However, if it is within a different threshold, e.g., 10 or 1000, a request to perform resynchronization may be processed, which may ask the user, through one or more applications, to tap, gesture, or otherwise instruct via the user's device one or more times. The user may be able to know that counter 210 has increased in the appropriate sequence.

[0029] The key diversification techniques described herein with reference to counter 210, the master key, and the diversified key are examples of encryption and / or decryption of key diversification techniques. This exemplary key diversification technique should not be considered limiting to this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0030] During the creation process of the contactless card 100, two encryption keys can be uniquely assigned to each card. The encryption keys may include symmetric keys that can be used for both encrypting and decrypting data. The Triple DES (3DES) algorithm may be used by EMV and implemented by the hardware within the contactless card 100. By using a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information of each entity that requires a key.

[0031] In some cases, to overcome the vulnerabilities of the 3DES algorithm, session keys (such as a unique key for each session) can be derived, but instead of using a master key, unique card derivation keys and counters can be used as diversification data. For example, each time contactless card 101 is used in operation, a different key may be used to generate the message authentication code (MAC) and perform encryption. This provides three layers of cryptography. Session keys can be generated by one or more applets and derived using application transaction counters having one or more algorithms (as defined in EMV4.3 Book 2 A1.3.1 CommonSession Key Derivation).

[0032] Furthermore, the increment for each card may be unique, assigned by personalization, or algorithmically assigned by some identifying information. For example, odd-numbered cards may increment by 2, and even-numbered cards may increment by 5. In some examples, the increment may also vary in a sequence of readings, such that one card may increment in a repeating sequence of 1, 3, 5, 2, 2, ... A specific sequence or algorithmic sequence can be defined during personalization or from one or more processes derived from unique identifiers. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0034] In one embodiment, the contactless card 100 can store a resource locator 220 in memory 204. For example, during the creation process, a resource locator 220 used to initiate the activation process can be written to memory 204. During the activation process, a device such as a mobile device can perform an NDEF read operation to read the resource locator 220. In one example, the contactless card may be started with a resource locator 220 that points to an app store to download an app associated with the contactless card. For example, the resource locator 220 might point to "https: / / play.google.com / store / apps / details?id=<package_name> It could also be "package_name can refer to the application. In another example, resource locator 220 could be "http: / / apps.apple.com / <country> / app / <app-name> / id <store-id>It may also be, where app-name and id are references for downloading the app. In embodiments, memory 204 may include both resource locators so that a customer can activate a contactless card using any device having an Android® operating system or an Apple® operating system. In some cases, the app may already be installed on the mobile device, and resource locator 220 may cause the mobile device's operating system to launch the app. For example, upon receiving resource locator 220, the mobile device can check whether the app is installed, and if it is, the operating system skips the installation process and launches the app.

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

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

[0037] In the embodiment, when the device receives a resource locator from the contactless card 100, the device can write the following actions to the card as resource locators. 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 finished reading and is ready to accept the terms and conditions, the customer can bring the contactless card 100 within the device's range, and the device can perform an NFC read operation to read the resource locator containing the unique identifier. The device can determine that the terms and conditions are accepted and perform activation on the activation server / system.

[0038] The contactless card component 200, including memory 204, may be updated with one or more resource locators 220 during the activation sequence. Each time the contactless card 100 comes within range (NFC range), the resource locator 220 may be updated with a different / new resource locator or instruction to perform the next action for the activation sequence on the mobile device. The mobile device may perform an NDEF write operation to write the new resource locator 220 to memory 204. Each of the different resource locators 220 may cause the mobile device to perform a different action, such as downloading / launching an app, presenting terms and conditions, and accepting terms and conditions, as described above. Once activated, the resource locator 220 may store instructions or resource locators to cause the app on the mobile device to launch a landing page. For example, the resource locator 220 may cause the app to launch a page showing account information associated with the contactless card, such as account balance, payment activity, transactions, benefits / rewards, etc. The contactless card 200 stores the resource locator 220 and can launch the app to a landing page until the resource locator 220 is updated with a new instruction to perform a different action.

[0039] Figure 3 shows an exemplary system 300 that may 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. The components of system 300 may be configured to communicate with each other via one or more wired and / or wireless interconnections. For example, the contactless card 100 may be configured to communicate with the mobile device 302 via a wireless interconnection using a wireless protocol such as NFC®, Bluetooth®, or Wireless Fidelity (WiFi). The mobile device 302 may also be configured to communicate with the activation system 304 according to a wireless and / or wired protocol.

[0040] In one embodiment, the system 300 may be used by a customer to activate the contactless card 100 via a mobile device 302. For example, the contactless card 100 may be configured, during creation, with a resource locator that installs or starts an application associated with the contactless card 100 on the operating system on the mobile device 302. While in operation, the contactless card 100 can turn on a short-range radio on the mobile device 302, such as an NFC interface, and provide a command to the customer to bring the contactless card 100 within range of the mobile device 302. The range may be the operating range of the short-range radio, which is filled by tapping the card on the mobile device 302. In one example, the range may be the operating range according to the NFC standard. The mobile device 302 can detect the contactless card 100 and perform an exchange with the contactless card 100 to establish communication, for example, an NFC exchange.

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

[0042] In some cases, the customer may need to perform several steps to activate the contactless card 100. The mobile device 302 can write a new resource locator to the memory of the contactless card 100 in order to perform each new operation. For example, in response to starting an app on the mobile device 302, the mobile device 302 containing the app can write a new resource locator to the memory of the contactless card 100 (NFC write operation). The new resource locator may be an instruction or link (deep link) pointing to terms and conditions associated with the contactless card 100. Therefore, the next time the contactless card 100 enters the communication range of the mobile device 302, the mobile device 302 can perform another NFC read operation to 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, allowing the app to present the terms and conditions in a graphical user interface (GUI) on the banking app's display or in the mobile device 302's web browser.

[0043] In embodiments, the contactless card 100 may be used to authenticate a user and accept terms and conditions. For example, a mobile device 302 may obtain a unique identifier associated with a customer. The mobile device 302 may prompt the customer to enter credentials such as a password, unique pattern, biometrics, or passcode, and the mobile device 302 may obtain and / or generate a unique identifier for the customer based on the entered credentials. In some cases, the mobile device 302 may generate a random alphanumeric sequence for the unique identifier. Embodiments are not limited to these.

[0044] The mobile device 302 can perform a write operation to write a new resource locator containing a unique identifier. When the customer is ready to accept the terms and conditions, the mobile device 302 can instruct the customer to place the card within range. The mobile device 302 can read the resource locator containing the unique identifier and perform a read operation to activate the contactless card 100.

[0045] To perform activation, the mobile device 302 can communicate data with the activation system 304. The data may include information to identify the customer, identify the contactless card 100, and confirm that the terms and conditions are accepted. The activation system 304 can process the data and confirm whether the contactless card 100 has been activated or whether the activation to the mobile device 302 has failed. The mobile device 302 can display information on the app GUI indicating whether the contactless card 100 has been activated or not.

[0046] In some cases, the contactless card 100 can generate a unique identifier and communicate with an OTP in order to perform an authentication operation. For example, to accept terms and conditions and / or to launch a banking app and go to a landing page with sensitive information, the mobile device 302 may 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 containing an instruction may be configured to respond to one or more requests, such as a Near Field Radio Data Exchange request from the mobile NFC reader of the mobile device 302, and generate an NDEF message containing a cryptographically secure OTP encoded as an NDEF text tag having a unique identifier. An example of an NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, one or more card instructions may be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, an NDEF message may contain one or more records. The instruction may be configured to add one or more static tag records in addition to the OTP record.

[0047] In this embodiment, the contactless card 100 can be activated, and the resource locator can set a unique identifier for use with an OTP to perform authentication for each read operation. For example, each time the contactless card 100 comes into range of the mobile device 302, the mobile device 302 can receive an OTP with an encrypted unique identifier and perform an authentication operation. If authenticated, the mobile device 302 can take an action, such as launching an app to go to a landing page containing account balance and / or other information about the bank account.

[0048] Figure 4 shows an exemplary routine 400 that may be executed by a mobile device 302 to activate a contactless card 100. In block 402, routine 400 includes receiving a first Uniform Resource Locator (URL) relating to an application from the contactless card via a wireless interface. In embodiments, the application may be a banking app and may be configured to perform the activation. The first URL may be stored in the memory of the contactless card 100 and communicated to the mobile device 302 as part of an NDEF exchange, including an NDEF read. The first URL may be processed by the operating system of the mobile device 302 and may trigger one or more events. Specifically, in block 404, routine 400 includes launching the application in response to the receipt of the first URL. In some cases, the app may be installed on the mobile device 302, and upon receiving the first URL, the operating system may cause the app to run. In other examples, the app may not be installed on the mobile device 302. In these cases, the operating system may launch an app store, and the first URL may include information to direct the app store to the download page for the banking app. The embodiments are not limited to these.

[0049] In block 406, routine 400 includes writing a second URL relating to the conditions to the contactless card. In embodiments, the second URL may include a link, such as a deep link or web link, to a location on the display of the mobile device 302 where the terms and conditions are presented to the user. The mobile device 302 may determine the second URL from the app, which may be a deep link stored locally within the app's files. When the app is launched to perform contactless card activation, it may provide the deep link to the operating system, which may generate a message such as “Write an NDEFMessage” containing the deep link as the second URL to write to the contactless card. In other examples, the app may provide a link to a website or a page of a website that can be accessed via a web browser. The operating system may use an NDEF message to write the website / page link to the contactless card. The contactless card may store a second URL in memory until it is ready to perform the next action for the activation sequence, for example, until the customer is ready to view the terms and conditions by bringing the card back within range of the mobile device.

[0050] In block 408, routine 400 includes receiving a second URL that matches the conditions from the contactless card. In some cases, the app may present a GUI on the display of the mobile device 302 with instructions to bring the contactless card within range of the mobile device 302 to read the terms and conditions, for example, an instruction for the customer to tap the contactless card on the display. The mobile device 302 can perform a read operation. In response to the read operation, the mobile device 302 may receive a second URL from the contactless card in an NDEF message. The operating system of the mobile device 302 may process the second URL, including causing the app or web browser to open and display the terms and conditions. As previously stated, the second URL may be a link to the app itself or a location within a website / page. Furthermore, in block 410, routine 400 includes presenting the conditions on the display of the mobile device. The terms and conditions may be presented in a GUI and are customer-readable. The customer can then read the terms and conditions.

[0051] In block 412, routine 400 includes writing a third URL relating to a unique identifier for identifying a customer associated with a contactless card. The third URL containing the unique identifier may be used by a mobile device 302 to identify the customer and activate the card when the customer accepts the terms and conditions. The unique identifier may be any combination of alphanumeric characters and symbols. In some cases, the unique identifier may be based on information about the contactless card, such as an account number, zip code, address, and / or credentials entered by the customer. However, in other examples, the unique identifier may be completely random and generated by the app and / or operating system.

[0052] In block 414, routine 400 includes receiving a third URL to verify the conditions. In some cases, the app may present the terms and conditions to the customer on the display and include instructions for the customer to bring a contactless card within range of the mobile device 302 to accept the terms and conditions. For example, the instructions may instruct the customer to tap the contactless card on the mobile device 302. The mobile device 302 can perform a read operation when the contactless card is within range. The mobile device 302, including the app, may receive a third URL containing 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 (block 412), the app can determine that the customer has accepted the terms and conditions.

[0053] In some embodiments, the mobile device 302 can activate a contactless card once the customer accepts the terms and conditions. For example, the mobile device 302, including an app, can communicate with an activation system 304 to activate the contactless card. In some examples, the mobile device 302 can communicate with the activation system 304 information indicating that the customer has accepted the terms and conditions, and information identifying the activated contactless card. The information identifying the card may include an identifier associated with the customer (username), the contactless card account number, or other identifying information. The activation system 304 can use the information and activate the contactless card for use in executing a transaction. In block 416, routine 400 includes determining that the contactless card is activated, at least in part, depending on whether the conditions are confirmed. In one example, the mobile device 302 can receive a display from the activation system 304 indicating whether the contactless card has been activated or whether activation failed. The mobile device 302 can notify the customer whether the contactless card is activated, for example, by displaying information on a display. In some cases, if activation fails, the app can provide the customer with instructions on how to correct the failed activation attempt.

[0054] In one embodiment, once the card is activated, the customer can use the contactless card on the mobile device 302 to launch an app and go to a landing page or perform another action. For example, each time the card is brought within range of the mobile device 302, the operating system can perform detection and launch the app. The mobile device 302 can also perform a read operation, and the contactless card can transmit information to the mobile device 302. In one example, the contactless card can generate a ciphertext that includes a unique identifier and an OTP, and communicate with the mobile device 302 using the ciphertext. The mobile device 302 can use the unique identifier and OTP to authenticate the user and present the user with a landing page containing sensitive information.

[0055] Figure 5 shows an exemplary routine 500 that may be performed by the contactless card 100 to activate the contactless card 100 via a mobile device 302. In block 502, routine 500 includes sending a first Uniform Resource Locator (URL) relating to an application to the mobile device. In embodiments, the contactless card may send the first URL to the mobile device 302 in response to a read operation via a wireless interface such as an NFC interface. The first URL may be stored in the contactless card's memory. The contactless card, including the circuitry, may retrieve the first URL from memory and communicate it to the mobile device 302 in an NDEF message. In some cases, the first URL may be a link to launch an application on the mobile device 302. In some cases, if an application is not installed on the mobile device 302, the mobile device 302 may launch an app store in response to receiving the first URL.

[0056] In block 504, routine 500 includes receiving a second URL relating to conditions associated with the activation of a contactless card. The second URL may be received by the contactless card from the mobile device 302. In some cases, the mobile device 302 may perform an NFC write operation to write the second URL to the contactless card's memory. The second URL may include links to clauses and conditions that may be included in an NDEF message associated with the contactless card. In block 506, routine 500 includes the contactless card storing the second URL in memory.

[0057] 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, as described above, the read operation can be performed when the contactless card enters the wireless operating range of the mobile device 302.

[0058] In block 510, routine 500 receives a third URL relating to a unique identifier for identifying a customer associated with a contactless card. The third URL may be received by the contactless card in response to a write operation performed by the mobile device 302. Similar to a read operation, a write operation may be performed when the contactless card is brought into the wireless range of the mobile device 302. In some embodiments, the read and write operations may be performed as part of an exchange between the same instances. For example, a customer may bring the contactless card into the range of the mobile device 302, and the mobile device 302 may perform a read operation to read the second URL, as described in block 508. The mobile device 302 may determine that the resource locator 220 needs to be updated and may perform a write operation to write the third URL to the contactless card's memory. The exchange may take place during a single instance in which the customer brings the contactless card into the wireless range. Furthermore, in block 512, routine 500 includes storing the third URL in the contactless card's memory.

[0059] In block 514, routine 500 includes sending a third URL to the mobile device. In an 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 described above. In this example, the 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 verify that the correct card / customer is confirming the terms and conditions. The third URL may be communicated to the mobile device 302 in an NDEF message as part of the read operation.

[0060] The techniques described herein are not limited to performing activation sequences for contactless cards, but can be used to perform different operations or sets of actions by utilizing the contactless card as a “state machine.” For example, a device having NFC read and write capabilities can utilize the memory of a contactless card to store data such as instructions or instruction blocks as a resource locator. The device can write data to the memory of the contactless card as a resource locator to store, for example, the state of a set of actions or operations to be performed. When the next action should be performed, the device can read the resource locator and perform the next action based on the data stored in memory. The device can write data containing the next instruction to the memory of the contactless card as a resource locator. This process may be repeated until the set of actions is completed. In some cases, the contactless card may include an OTP (One-Time Password) with a resource locator when read, so that the device can verify and / or authenticate the user. The data communicated between the contactless card and the device may be communicated in raw or encrypted format in NDEF messages.

[0061] Figure 6 shows an exemplary routine 600 executed by a contactless card that stores data as a resource locator for performing an action in a series of actions or operations, and the contactless card can be used as a state machine for performing an operation. In 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 a point-of-sale (POS) terminal can write data, including instructions, to the memory of the contactless card as a resource locator. The data may be instructions for performing one or more operations to complete a series of operations. The device may perform an NFC write operation to write data to memory using short-range wireless communication such as NFC and NDEF messages. The contactless card can store the data in memory until the next read operation and / or until the data is overwritten. The data or instructions in the resource locator may include any operations that can be performed by a computing device. In one example, the data may be a link to a location, e.g., a web link or a link / pointer to a memory location. In another example, the data may be a computer instruction that can be executed and / or executed on the device. The instructions may be high-level instructions, such as those used in a scripting language, that can be executed by the device, or low-level instructions, such as C code, Java code, or assembly code. The embodiments are not limited thereto.

[0062] In 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 in ciphertext, as described herein. The data can be used by the device to perform an operation.

[0063] In 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 containing the next instructions for a 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.

[0064] Routine 600 may be used to perform any type of sequence of actions by a device, such as completing a transaction via a POS terminal and / or mobile device, making a payment via a banking app, or changing settings in a banking app. Embodiments are not limited to these examples.

[0065] Figure 7 is a timing diagram showing an exemplary sequence for granting authenticated access according to one or more embodiments of the present disclosure. The sequence flow 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 cases, as described above with respect to Figure 3, the following sequence may be performed between the mobile device 302 and the contactless card 100 to perform one or more of the activation steps and / or authenticate the customer to launch the app on the mobile device 302 and go to a landing page.

[0066] On line 710, application 704 communicates with contactless card 100 (for example, after bringing it close to contactless card 100). Communication between application 704 and contactless card 100 may include the contactless card 100 being close enough to the card reader (not shown) of client device 702 to enable NFC data transfer between application 704 and contactless card 100.

[0067] After communication is established between the client device 702 and the contactless card 100 on line 708, the contactless card 100 generates a Message Authentication Code (MAC) ciphertext. In some examples, this may occur when the contactless card 100 is read by application 704. In particular, this may occur during reading, such as NFC reading of a Near Field Radio Data Exchange (NDEF) tag which may be created according to the NFC Data Exchange format. For example, a reader application such as application 704 may send a message such as an applet selection message having the applet ID of an NDEF generating applet. Upon confirming the selection, a series of selection file messages followed by read file messages may be sent. For example, the sequence may include "Select function file", "Read function file", and "Select NDEF file". At this point, a counter value maintained by the contactless card 100 may be updated or incremented, followed by "Read NDEF file". At this point, a message may be generated which may include a header and a shared secret. Subsequently, a session key may be generated. A MAC ciphertext can be constructed from a message that may include a header and a shared secret. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random numbers (RNDs) may be encrypted with a session key. The ciphertext and header can then be concatenated, encoded as ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF file" message).

[0068] In some examples, the MAC ciphertext may be transmitted as an NDEF tag, and in other examples, the MAC ciphertext may be included with a uniform resource indicator or locator (e.g., as a formatted string). For example, the MAC ciphertext may include a resource locator containing a unique identifier. In some examples, application 704 may be configured to send a request to contactless card 100, the request including an instruction to generate a MAC ciphertext.

[0069] On line 712, the contactless card 100 transmits the MAC ciphertext to application 704. In some embodiments, the transmission of the MAC ciphertext is performed via NFC, but this disclosure is not limited thereto. In other embodiments, this communication may be performed via Bluetooth, Wi-Fi, or other wireless data communication means. On line 714, application 704 transmits the MAC ciphertext to processor 706.

[0070] In line 716, processor 706 verifies the MAC ciphertext according to instructions from application 122. For example, the MAC ciphertext can be verified as described below. In some examples, the verification of the MAC ciphertext may be performed by a device other than client device 702, such as a server in a banking system communicating data with client device 702. For example, processor 706 can output the MAC ciphertext for transmission to a server in a banking system that can verify the MAC ciphertext. In some examples, the MAC ciphertext can function as a digital signature for verification. To perform this verification, other digital signature algorithms such as public-key asymmetric algorithms, e.g., digital signature algorithms and RSA algorithms, or zero-knowledge protocols can be used.

[0071] Figure 8 shows an NDEF short record layout (SR=1) data structure 800 according to an exemplary embodiment. One or more applets may be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, an NDEF message may contain one or more records. The applet may 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: well-known type, text, encoded English (en), applet ID: D2760000850101; function: read-only access; encoding: authentication messages may be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as personalization parameters that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record having a well-known index for providing the actual dynamic authentication data.

[0072] Figure 9 shows a diagram of a system 900 configured to carry out one or more embodiments of the present disclosure. As described below, two cryptographic keys can be uniquely assigned to each card during the contactless card creation process. The cryptographic keys may include symmetric keys that can be used for both encrypting and decrypting data. The Triple DES (3DES) algorithm may be used by EMV and implemented by the hardware of the contactless card. By using a key diversification process, one or more keys can be derived from a master key based on uniquely identifiable information of each entity that requires a key.

[0073] With regard to master key management, two issuer master keys 902,926 may be required for each portion of the portfolio in which one or more applets are issued. For example, the first master key 902 may contain the issuer ciphertext generation / authentication key (Iss-Key-Auth), and the second master key 926 may contain the issuer data encryption key (Iss-Key-DEK). As further described herein, the two issuer master keys 902,926 are diversified into card master keys 908,920 unique to each card. In some examples, a network profile record ID (pNPR) 522 and a derived key index (pDKI) 924 can be used as back-office data to identify which issuer master key 902,926 to use in the cryptographic process for authentication. The system performing authentication may be configured to retrieve the pNPR 922 and pDKI 924 values ​​of the contactless card at the time of authentication.

[0074] In some examples, session keys (such as unique keys for each session) can be derived to enhance the security of the solution, but as mentioned earlier, instead of using a master key, unique card-derived keys and counters can be used as diversified data. For example, each time a card is used in operation, a different key may be used to generate a message authentication code (MAC) and perform encryption. Regarding session key generation, the key used to generate ciphertext and encrypt data within one or more applets may include a session key based on card-specific keys (Card-Key-Auth908 and Card-Key-Dek920). Session keys (Automatic session key 932 and DEK session key 910) can be generated by one or more applets and derived by using application transaction counters (pATC)904 in one or more algorithms. Only the two lower bytes of the 4-byte pATC904 are used to fit the data to one or more algorithms. In some examples, a 4-byte session key derivation method can include F1:=PATC(lower 2 bytes)||"F0"||"00"||PATC(4 bytes)F1:=PATC(lower 2 bytes)||"0F"||"00"||PATC(4 bytes)SK:={(ALG(MK)[F1])||ALG(MK)[F2]}, where ALG can contain 3DESECB and MK can contain a card-specific derived master key.

[0075] As described herein, the lower two bytes of the pATC904 counter can be used to derive one or more MAC session keys. Each tap of a contactless card is configured to update pATC904, and the card master keys Card-Key-AUTH508 and Card-Key-DEK920 are further diversified into session keys Auto-Session-Key932 and DEK-Session-KEY910. pATC904 may be initialized to 0 during personalization or applet initialization. In some examples, the pATC counter 904 may be initialized during or before personalization and may be configured to increment by 1 with each NDEF read.

[0076] Furthermore, each card update may be unique, assigned by personalization, or algorithmically assigned by pUID or other identifying information. For example, odd-numbered cards may increase or decrease by 2, and even-numbered cards may increase or decrease by 5. In some examples, updates may also vary in consecutive reads, such that a single card may increase in a repeating sequence of 1, 3, 5, 2, 2, ... A specific sequence or algorithmic sequence can be defined during personalization or from one or more processes derived from unique identifiers. This makes it more difficult for replay attackers to generalize from a small number of card instances.

[0077] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it may contain only the authentication data and an 8-byte random number followed by the MAC of the authentication data. In some examples, the random number may precede ciphertext A and may be one block long. 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 ciphertext) 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 uses 16-byte blocks, it may also be a multiple of that block size, or the output may be automatically or manually padded to a multiple of that block size.

[0078] MAC may be performed using a function key (AUTSession-Key) 932. The data specified in the ciphertext can be processed using the javacard.signature method:ALG_DES_MAC8_ISO9797_1_M2_ALG3 and correlated with the EMVARQC verification method. The key used in this calculation may include the session key AUTSession-Key 932, as described above. As previously mentioned, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As described below, AUTSession-Key 932 can be used in conjunction with MAC data 906, and the resulting data or ciphertext A914 and random number RND can be encrypted using DEK-Session-Key 910 to create ciphertext B or output 918 sent in the message.

[0079] In some cases, one or more HSM commands may be processed for decryption such that the last 16 (binary, 32hex) bytes may contain 3DES symmetric encryption using CBC mode with a zero IV random number followed by MAC authentication data. The key used for this encryption may contain the session key DEK-Session-Key910 derived from Card-Key-DEK920. In this case, the ATC value for session key derivation is the least significant byte of counter pATC904.

[0080] The following format represents an exemplary embodiment of the binary version. Furthermore, in some examples, the first byte may be set to the ASCII character "A". TIFF0007899215000001.tif148170

[0081] Another typical format is shown below. In this example, the tags may be encoded in hexadecimal format. TIFF0007899215000002.tif120169

[0082] The UID field of the received message can be extracted, and the card master keys (Card-Key-Auth908 and Card-Key-DEK920) for that particular card can be derived from the master keys Iss-Key-AUTH502 and Iss-Key-DEK926. Using the card master keys (Card-Key-Auth508 and Card-Key-DEK920), and the counter (pATC) field of the received message, the session keys (Aut-Session-Key932 and DEK-Session-Key910) for that particular card can be derived. Ciphertext B918 may be decrypted using the DEK-Session-KEY to generate ciphertext A914 and RND, and the RND may be discarded. The UID field, along with the Ver, UID, and pATC fields of the message, can be used to retrieve the shared secret of a contactless card that can be processed via an encrypted MAC using an auto-session key recreated to produce MAC output such as MAC'. If the MAC is the same as the ciphertext A914, this indicates that message decryption and MAC check have all passed. Then, the pATC can be read to determine if it is valid.

[0083] During an authentication session, one or more ciphertexts may be generated by one or more applications. For example, one or more ciphertexts may be generated as 3DESMAC using the ISO9797-1 algorithm 3, via one or more session keys such as the automatic session key 932, with padding from Method 2. The input data 906 can take the following form: namely, version(2), pUID(8), pATC(4), shared secret(4). In some examples, the numbers in parentheses may represent the length in bytes. In some examples, the shared secret may be generated by one or more random number generators, which may be configured to ensure that the random numbers are unpredictable via one or more secure processes. In some examples, the shared secret may consist of a random 4-byte binary number that is injected into the card at personalization, known by the authentication service. During an authentication session, the shared secret does not have to be provided to the mobile application from one or more applets. Padding from Method 2 may include adding a mandatory 0x'80' byte to the end of the input data and adding a 0x'00' byte that may be added to the end of the resulting data up to an 8-byte boundary. The resulting ciphertext may be 8 bytes in length.

[0084] In some examples, one advantage of encrypting unshared random numbers as the first block using MAC ciphertext is that they function as initialization vectors while using the CBC (Block Chaining) mode of the symmetric encryption algorithm. This allows for "scrambling" between blocks without the need to pre-establish either a fixed or dynamic IV.

[0085] By including an Application Transaction Counter (pATC) as part of the data contained in the MAC ciphertext, the authentication service may be configured to determine whether the value carried in clear data has been tampered with. Furthermore, by including a version in one or more ciphertexts, it becomes difficult for an attacker to intentionally falsify the application version in an attempt to weaken the strength of the cryptographic solution. In some examples, the pATC may start at 0 and be updated by 1 each time one or more applications generate authentication data. The authentication service may be configured to track the pATC used during an authentication session. In some examples, if the authentication data uses a pATC less than or equal to a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and the authentication may be rejected. In some examples, if the pATC is greater than a previous value received, this may be evaluated to determine whether it is within an acceptable range or threshold, and if it exceeds or falls outside the range or threshold, the verification may be considered to have failed or to be unreliable. In MAC operation 912, data 906 is processed via MAC using the automatic session key 932 to produce an encrypted MAC output (ciphertext A) 914.

[0086] To provide additional protection against brute-force attacks that would expose the key on the card, the MAC ciphertext 914 is preferably encrypted. In some examples, the data or ciphertext A914 contained in the ciphertext may include random(8), ciphertext(8). In some examples, the numbers in parentheses may include the length in bytes. In some examples, the random numbers may be generated by one or more random number generators that can be configured to make the random numbers unpredictable through one or more secure processes. The key used to encrypt this data may include a session key. For example, the session key may include DEK-Session-Key910. In the cryptographic operation 916, the data or ciphertext A914 and RND are processed using DEK-Session-Key510 to generate the encrypted data, ciphertext B918. The data 914 may be encrypted using 3DES in cipher block chaining mode so that an attacker must perform an arbitrary attack across the entire ciphertext. As a non-restrictive example, other algorithms such as Advanced Encryption Standard (AES) may be used. In some cases, an initialization vector of 0x'0000000000000000' can be used. An attacker attempting to brute-force the key used to encrypt this data would be unable to determine when the correct key was used. This is because correctly decrypted data is indistinguishable from incorrectly decrypted data due to its random appearance.

[0087] For the authentication service to verify one or more ciphertexts provided by one or more applets, during the authentication session, one or more applets must transmit the following data in plain text to the mobile device: a version number to determine the cryptographic method used so that the method may be changed in the future, and a message format for verifying the ciphertext; a pUID for retrieving the crypto asset and deriving the card key; and a pATC for deriving the session key used with respect to the ciphertext.

[0088] Figure 10 shows a method 1000 for generating ciphertext. For example, in block 1002, the network profile record ID (pNPR) and derived key index (pDKI) can be used to identify which issuer master key should be used in the encryption process for authentication. In some examples, the method may include a step of performing authentication to retrieve the pNPR and pDKI values ​​of a contactless card at the time of authentication.

[0089] In block 1004, issuer master keys can be diversified by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of one or more applets, such as a payment applet.

[0090] In block 1006, Card-Key-Auth and Card-Key-DEK (unique card keys) can be created by diversifying the issuer master key to generate a session key that can be used to generate MAC ciphertexts.

[0091] In block 1008, the key used to generate ciphertext and encrypt data within one or more applets may include the session key in block 1030 based on card-specific keys (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys may be generated by one or more applets, derived using pATC, and result in the automatic session key and the DEK session key.

[0092] Figure 11 shows an exemplary process 1100 illustrating key diversification in one example. Initially, the sender and receiver may be provisioned 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 that can be updated in block 1102, and other data to be protected, such as data to be protected, which can protect sharing with the receiver.

[0093] In block 1104, the sender can encrypt the counter value using the data encryption master key to generate a data encryption derivation session key, and the sender can also encrypt the counter value using the data integrity master key to generate a data integrity derivation session key. In some examples, the entire counter value or a portion of the counter value can be used during both encryptions.

[0094] In some examples, the counter value does not need to be encrypted. In these examples, the counter can be sent between the sender and receiver in plain text, i.e., without encryption.

[0095] In block 1106, the data to be protected is processed by the sender in an encrypted MAC operation using a data integrity session key and an encrypted MAC algorithm. The protected data, including plaintext and shared secrets, may be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0096] In block 1108, the data to be protected may be encrypted by the sender using a data encryption derived session key along with a symmetric encryption algorithm. In some examples, the MAC is combined with equal amounts of random data, such as each being 8 bytes long, and then encrypted using a second session key (DEK-Session-Key).

[0097] In block 1110, the encrypted MAC is sent from the sender to the receiver with enough information to identify additional secrets (e.g., shared secret, master key, etc.) in order to verify the ciphertext.

[0098] In block 1112, the receiver uses the received counter value, as described above, to independently derive two derived session keys from the two master keys.

[0099] In block 1114, the data encryption derived session key is used in conjunction with a symmetric decryption operation to decrypt the protected data. Further processing is then performed on the exchanged data. In some examples, it is desirable to reconstruct and verify the MAC after it has been extracted. For example, when verifying ciphertext, decryption may be performed using a appropriately generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using a properly generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

[0100] In block 1116, the data integrity derivation session key is used in conjunction with the cryptographic MAC operation to verify that the protected data has not been altered.

[0101] Some examples of the methods described herein can favorably confirm when authentication success is determined when the following conditions are met: Firstly, the ability to verify the MAC indicates that the derived session key was appropriate. The MAC may only be correct if decryption is successful and an appropriate MAC value is obtained. Successful decryption can indicate that a correctly derived cryptographic key was used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., the sending device) and receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created the MAC and encrypted the MAC is indeed genuine. Furthermore, the counter values ​​used to derive the first and second session keys may be shown to be valid and may be used to perform the authentication operation.

[0102] Subsequently, the two derived session keys may be discarded, the next iteration of data exchange may update the counter value (returning to block 1102), and a new set of session keys may be created (block 1110). In some examples, the combined random data may be discarded.

[0103] Figure 12 shows a method 800 for card activation according to an exemplary embodiment. For example, card activation can be completed 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 described previously, such as the contactless card 100, the client device 702, and the servers.

[0104] In block 1202, the card may 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 telephone number that can be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted via systems and methods disclosed herein.

[0105] In block 1204, one or more portions of dynamically generated data can be communicated to the device's application via NFC or other wireless communication. For example, tapping a card in close proximity to the device can enable the device's application to read one or more portions of data associated with the contactless card. In some examples, if the device does not have an application to assist in activating the card, tapping the card can instruct the device or prompt the customer to a software application store to download the relevant application for activating the card. In some examples, the user may be prompted to gesture, position, or orient the card sufficiently toward the surface of the device, for example, on, near, or diagonally or flatly toward the surface of the device. Depending on the sufficient gesture, position, and / or orientation of the card, the device may proceed to send one or more encrypted portions of the data received from the card to one or more servers.

[0106] In block 1206, one or more portions of the data can be communicated to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data may be sent from the device to the card issuer server for card activation.

[0107] In block 1208, one or more servers can decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers can receive encrypted data from a device and decrypt the received data to record data accessible to one or more servers. If a comparison of one or more decrypted portions of data by one or more servers results in a successful match, the card may be activated. If a comparison of one or more decrypted portions of data by one or more servers results in an unsuccessful match, one or more processes may be performed. For example, in response to a determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold, including the number of attempts the user is allowed to activate the card. Alternatively, the user may receive a message on their device indicating a failed card verification attempt, and a notification such as calling, emailing, or texting the relevant service to assist in activating the card, or another notification such as calling on their device indicating a failed card verification attempt, and a notification such as calling, emailing, or texting the relevant service to assist in activating the card, or another notification such as an email indicating a failed card verification attempt, and a notification such as calling, emailing, or texting the relevant service to assist in activating the card.

[0108] In block 1210, one or more servers may send a return message based on the successful activation of the card. For example, a device may be configured to receive output from one or more servers indicating the successful activation of the card by one or more servers. The device may also be configured to display a message indicating that the card has been successfully activated. Once the card is activated, it may be configured to stop dynamically generating data to prevent fraudulent use. In this way, the card does not need to be activated again, and one or more servers are notified that the card has already been activated. < / country>

Claims

1. A computer implementation method, A contactless card provides a first command to a mobile device to launch an application in response to a first wireless read by the mobile device, wherein the first command is stored in the memory of the contactless card. The contactless card stores in its memory a second instruction that causes the mobile device to display conditions related to the contactless card, the second instruction being received from the mobile device, and the storage step The steps include: the contactless card determining that the second command has been received in response to a second wireless reading by the mobile device, and providing the second command and information associated with the contactless card to the mobile device to display the conditions; The contactless card includes the step of storing in the memory a third instruction that includes a unique identifier received from the mobile device to identify the information associated with the contactless card, The steps include: the contactless card determining that the third command has been received in response to a third wireless read by the mobile device, and providing the mobile device with the third command to confirm the condition based on the unique identifier of the third command; Computer implementation methods including

2. A step of executing an applet based on an instruction received from the mobile device, wherein the applet generates and executes a ciphertext for communicating with the mobile device based on the unique identifier of the received third instruction. A step of providing the ciphertext to the mobile device in response to a fourth query, wherein the ciphertext includes an encrypted unique identifier generated from the unique identifier, The computer implementation method according to claim 1, including the method described in claim 1.

3. The computer implementation method according to claim 1, wherein the step of providing the first instruction includes providing the first instruction via a radio interface configured for near-field communication (NFC).

4. The computer implementation method according to claim 1, comprising the step of storing a fourth instruction from the mobile device, wherein the fourth instruction includes a second unique identifier and a one-time passcode for the contactless card.

5. The computer implementation method according to claim 4, comprising the step of providing the mobile device with the fourth instruction via a wireless interface, wherein the first, second, third, and fourth instructions include links.

6. The computer implementation method according to claim 1, wherein the second instruction relating to the conditions is a deep link to a location within the application.

7. It is a device, Processor and It comprises memory containing instructions, When the aforementioned instruction is executed by the processor, the processor will: In response to a first wireless read by a mobile device, a contactless card provides a first command to the mobile device via a wireless interface to launch an application, and the first command is stored in the memory of the contactless card. The contactless card causes the memory to store a second command that causes the mobile device to display conditions related to the contactless card, and the second command is received from the mobile device. The contactless card determines that the second command has been received in response to the second wireless reading by the mobile device, and provides the mobile device with the second command which displays the conditions, and information associated with the contactless card. The contactless card causes the memory to store a third instruction, which includes a unique identifier received from the mobile device to identify the information associated with the contactless card. A device that determines that a third command has been received by the mobile device in response to a third wireless read by the contactless card, and causes the device to provide the third command to confirm the condition based on the unique identifier of the third command.

8. The aforementioned processor, The applet is executed based on an instruction received from the mobile device, and the applet generates a ciphertext for communicating with the mobile device based on the unique identifier of the received third instruction. The apparatus according to claim 7, wherein, in response to a fourth query, the ciphertext is provided to the mobile device, the ciphertext including an encrypted unique identifier generated from the unique identifier.

9. The apparatus according to claim 7, further comprising a radio interface configured for a Near Field Communication (NFC) protocol.

10. The apparatus according to claim 7, wherein the processor stores a fourth instruction including a second unique identifier and a one-time passcode for the contactless card.

11. The apparatus according to claim 10, wherein the processor is made to provide the fourth instruction via the wireless interface.

12. The apparatus according to claim 10, wherein the second instruction relating to the conditions is a deep link to a location within the application, and the first, second, third, and fourth instructions include a link.

13. A non-temporary computer-readable medium containing a set of instructions, wherein the set of instructions is executed by the processor of a mobile device, and the processor is configured to perform the following actions: A first command to launch an application is received from the contactless card via a wireless interface. A second command is written to the contactless card via the wireless interface, causing the conditions related to the contactless card to be displayed on the mobile device. The wireless interface is used to receive a message from the contactless card, which includes information associated with the contactless card and the second command. Based on the information of the contactless card, a first unique identifier is generated to identify the information. The third instruction, including the first unique identifier, is written to the contactless card. The third command presented to confirm the conditions is received from the contactless card, Based on the first unique identifier and the third instruction, confirm that the same contactless card is being presented. A non-temporary computer-readable medium that, at least in part, confirms the conditions by the same contactless card, receives an indication via the wireless interface that the contactless card has been activated, and determines that the contactless card has been activated.

14. The set of instructions is executed by the processor, and the processor is instructed to: The contactless card is instructed to send an applet command via the wireless interface, and the applet command instructs the applet on the contactless card to generate a ciphertext. The non-temporary computer-readable medium according to claim 13, wherein the ciphertext is received at least partially based on the first unique identifier.

15. The non-temporary computer-readable medium according to claim 13, wherein the wireless interface issues at least one of the Near Field Communication (NFC) protocols.

16. The non-temporary computer-readable medium according to claim 13, wherein the processor causes the contactless card to write a fourth instruction via the wireless interface, the fourth instruction including a second unique identifier and a one-time passcode of the contactless card.

17. The aforementioned processor, The fourth command is received from the contactless card via the wireless interface. At least the one-time passcode is sent to the server, The non-temporary computer-readable medium according to claim 16, which receives a response in response to the transmission of the one-time passcode, and the response includes data associated with the contactless card.

18. The non-temporary computer-readable medium according to claim 17, wherein the response is received via a short message service message or an application message within the application.

19. The non-temporary computer-readable medium according to claim 13, wherein the application is launched by the operating system in response to the receipt of the first instruction.

20. The non-temporary computer-readable medium according to claim 13, wherein the second instruction relating to the conditions is a deep link to a location within the application, and the first, second, third, and fourth instructions include a link.

Images