Technique for utilizing a resource locator with a contactless card to perform a sequence of actions - Patents.com

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 Ser. No. 17 / 235,112, entitled "TECHNIQUES FOR UTILIZING A RESOURCE LOCATOR BY A CONTACTLESS CARD TO PERFORM A COURSE OF ACTIONS," filed April 20, 2021. The contents of the aforementioned application are incorporated herein by reference in their entirety. [Background technology]

[0002] Millions of individuals enjoy the convenience of using credit cards, charge cards, debit cards, or "smart" cards as a convenient method of purchasing goods and / or services. By using these types of cards, individuals can enter into transactions without having cash or currency on hand or otherwise. In the case of credit cards, charge cards, and debit cards, individuals in effect obtain an instant loan of the funds necessary to make a purchase and / or enter into a transaction.

[0003] In order to utilize these cards, customers are typically required to go through an activation process to activate the card. Activating a card typically involves a time-consuming process in which the cardholder calls a phone number or visits a website to enter or otherwise provide card information. However, current solutions are problematic and subject to human error because they require the customer to enter information and are subject to error. Thus, there is an improved method of activating a card. Summary of the Invention

[0004] Embodiments may generally be directed to systems, devices, and techniques, including computer-implemented methods for performing activation of a contactless card via a mobile device. The techniques may include receiving a first uniform resource locator (URL) for an application from a contactless card via a wireless interface, the application configured to perform activation, and launching the application in response to receiving the first URL. The techniques may include writing a second URL for a condition to the contactless card via the wireless interface, receiving the second URL to the condition from the contactless card via the wireless interface, and presenting the condition on a display of the mobile device. The techniques may also include writing a third URL for a first unique identifier for identifying a customer associated with the contactless card, receiving the third URL to verify the condition, and determining that the contactless card is activated at least in part in response to the condition being verified.

[0005] Embodiments may also be generally directed to techniques and systems including an apparatus for exchanging a universal resource locator with a contactless card, the apparatus including a processor and a memory including instructions executable by the processor. The processor, when executing the instructions, may receive a first uniform resource locator (URL) for an application from the contactless card over a wireless interface, the application configured to perform an operation for the contactless card, the processor launching the application in response to receiving the first URL and writing a second URL for the terms to the contactless card over the wireless interface. The processor may also receive the second URL to the terms from the contactless card over the wireless interface, present the terms on a display, write 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 verify the terms.

[0006] Embodiments may also include a non-transitory computer-readable medium including a set of instructions that, when executed by a processor circuit of a contactless card, cause the processor circuit to transmit a first uniform resource locator (URL) for an application to a mobile device over a wireless interface in response to a first wireless read, the first URL being stored in a memory of the contactless card, the instructions causing the processor circuit to store in the memory a second URL for a condition associated with the contactless card, the second URL being received from the mobile device. Embodiments also include a processor circuit configured to transmit the second URL to the condition to the mobile device in response to the second wireless read, store in the memory a third URL for a unique identifier for identifying a customer associated with the contactless card, and transmit the third URL to verify the condition in response to the third wireless read.

[0007] To easily identify the description of any particular element or act, the most significant digit(s) of a reference number refers to the figure number in which that element is first introduced. [Brief description of the drawings]

[0008] [Figure 1] 1 shows a contactless card 100 according to an embodiment. [Diagram 2] 2 illustrates a contactless card component 200 according to an embodiment. [Diagram 3] 1 illustrates aspects of the subject matter according to embodiments. [Figure 4] 4 illustrates a routine 400 according to an embodiment. [Diagram 5] 5 illustrates a routine 500 according to an embodiment. [Figure 6] 6 illustrates a routine 600 according to an embodiment. [Figure 7] 7 shows a sequence flow 700 according to an embodiment. [Figure 8] 8 illustrates a data structure 800 according to an embodiment. [Figure 9]FIG. 1 is a diagram of a key system according to an exemplary embodiment. [Figure 10] 1 is a flowchart of a method for generating a ciphertext according to an embodiment. [Figure 11] 1 illustrates aspects of the subject matter according to embodiments. [Figure 12] 1 illustrates aspects of the subject matter according to embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Embodiments may be generally directed to methods, devices, and systems for performing activation of contactless cards, such as credit cards and debit cards. Generally, a customer may receive a contactless card in the mail or from a bank branch in an inactivated state. To activate the card, the customer must go through a process that typically includes calling a phone number and / or visiting a website. The customer must then enter information, such as an account number on the front of the card, and a back-end activation system operated and / or controlled by the bank performs an activation sequence to activate the card. However, these current solutions are problematic because they require the customer to enter information and are prone to error. For example, a customer may mistype a digit in the account number when entering the account number via a telephone keypad or keyboard. In these situations, the activation system generally does not communicate the error to the customer for security purposes, but simply aborts the activation attempt, e.g., hangs up on the customer or states that activation cannot be completed.

[0010] The embodiments described herein provide an improvement to these problems and one or more technical fields or technical areas, such as electronic activation of contactless cards. The described embodiments include a customer receiving a contactless card from a card issuer with minimal instructions. For example, the instructions may simply tell the customer to turn on a near field communication (NFC) interface on their mobile device. The customer may 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 operating range of the device so that a wireless exchange of information can occur. In one example, the customer may be instructed to tap the contactless card on a surface of the mobile device, such as on 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.

[0011] In one specific example, a contactless card may be sent to a user programmed with a resource locator, such as a Uniform Resource Locator (URL), Uniform Resource Identifier (URI), Uniform Resource Name (URN), etc. The resource locator may be stored, for example, in a memory on the contactless card and communicated to the mobile device as part of a read operation performed by the mobile device when the contactless card is in range. The mobile device may perform an action based on receipt 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 to download an app, such as a banking app, associated with the contactless card. In some cases, the app may already be installed on the mobile device and the resource locator may launch the banking app. The mobile device containing the app may cause the customer to perform a series of actions, the next of which is initiated when the card is brought into wireless communication range of the mobile device. For example, the customer may be instructed to tap the contactless card again to launch 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 contactless card's terms of service and allow the mobile device to activate the card by communicating with an activation server. Once activated, the card can enter an activated state, after which each additional tap can result in the same action, e.g., a banking app being launched to a landing page that can show details about the account.

[0012] The embodiments described herein are not limited to performing an activation process. For example, the operations described herein may be used to cause any number of operations or series of actions to be performed, and the contactless card may be utilized as a state machine that holds instructions for the next step in the series of steps to perform the operation. As will become more apparent in the following description, when the contactless card enters the wireless operating range of the device, a communication exchange, e.g., a read / write operation, 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 step of the series of steps to perform the operation. At the next read operation, the contactless card may provide the instruction or resource locator to the reading device to trigger the next step. These and other details will become more apparent in the following description.

[0013] Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. However, it will be apparent that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate the description. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0014] FIG. 1 illustrates an exemplary configuration of a contactless card 100 that may include a payment card, such as a transaction card, credit card, debit card, or gift card issued by a service provider, as displayed as a service provider indicia 102 on the front or back of the contactless card 100. In some examples, the contactless card 100 is not related to 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, and the like. The contactless card 100 may include a substrate 108 that may include a single layer or one or more laminates of plastic, metal, 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, contactless card 100 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7816 standard, while in other cases the transaction card may conform to the ISO / IEC 14443 standard. However, it is understood that contactless card 100 according to the present disclosure may have different characteristics, and the present 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 a contact pad 104. The contact pad 104 may include one or more pads and may be configured to establish contact with another client device, such as an ATM, a user device, a smartphone, a laptop, a desktop, or a tablet computer, via the transaction card. The contact pad may be designed according to one or more standards, such as the ISO / IEC 7816 standard, and may enable communication according to an EMV protocol. The contactless card 100 may also include processing circuitry, an antenna, and other components, as further described in FIG. 2. These components may be located behind the contact pad 104 or elsewhere on the substrate 108, such as within a different layer 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 strip or tape, which may be located on the back of the card (not shown in FIG. 1). The contactless card 100 may also include an NFC device coupled to an antenna capable of communicating via an NFC protocol. The embodiments are not so limited.

[0016] 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, memory 204, and one or more interfaces 206. It is understood that the processing circuitry 216 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware, as necessary to perform the functions described herein.

[0017] The memory 204 may be a read-only memory, a write-once multiple read memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 100 may include one or more of these memories. The read-only memory may be factory programmable as read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read many times. The write-once / multiple read memory may be programmed at a point in time after the memory chip leaves the factory. Once the memory is programmed, it may not be rewritten, but may be read many times. The read / write memory may be programmed and reprogrammed many times after leaving the factory. The read / write memory may also be read many times after leaving the factory. In some cases, the memory 204 may be an encrypted memory that utilizes an encryption algorithm executed by the processor 202 on the encrypted data.

[0018] The 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 run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 208 is not limited to a Java Card applet, but 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 a numeric counter sufficient to store an integer number. The customer identifier 214 may include a unique alphanumeric identifier assigned to a user of the contactless card 100, which identifier may distinguish a user of the contactless card from other contactless card users. In some examples, the customer identifier 214 may identify both a customer and an account assigned to that customer, and may further identify the contactless card 100 associated with the customer's account. As previously described, the account number 212 may 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 send the account number(s) 212 to a mobile device for auto-filling by an auto-fill service).

[0019] Although the processor 202 and memory elements of the foregoing example embodiments are described with reference to the contact pads 104, the disclosure is not limited thereto. It is understood that these elements may be implemented external to the contact pads 104, or may be completely separate from the contact pads 104, or may be implemented as additional elements in addition to the processor 202 and memory 204 elements disposed within the contact pads.

[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 circuitry 216 on the contact pads 104. For example, the one or more antennas 218 may be integral with the processing circuitry 216, or the one or more antennas 218 may be used in conjunction with an external booster coil. As another example, the one or more antennas 218 may be external to the contact pads 104 and the processing circuitry 216.

[0021] In one embodiment, the coil of the contactless card 100 can function as the secondary of an air-core transformer. The terminal can communicate with the contactless card 100 by disconnecting 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 may be functionally maintained via one or more capacitors. The contactless card 100 can communicate back by switching the load or load modulation of the coil of the contactless card. Load modulation may be detected at the coil of the terminal by 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 communication.

[0022] As previously mentioned, the contactless card 100 may be built on a software platform capable of operating on a smart card or other device with limited memory, such as a JavaCard, and may securely execute one or more applications or applets. An applet 208 may 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, such as a mobile NFC reader (e.g., a mobile device or a point-of-sale terminal), and generate an NDEF message that includes the cryptographically secure OTP encoded as an NDEF text tag.

[0023] One 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 text tag of the NDEF Type 4 well-known type. In some examples, an NDEF message can 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.

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

[0025] In some examples, the contactless card 100 and the server may contain specific data so that the card may be properly identified. The contactless card 100 may include 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 from the contactless card 100 is read (e.g., by a mobile device), the counter 210 is sent to the server for validation, which determines (as part of the validation) whether the counter 210 is equal to the server's counter.

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

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

[0028] To keep the counter 210 synchronized, an application may be executed, such as a background application that may be configured to detect when the mobile device 110 wakes up and then synchronize with a server of a banking system indicating the reading that occurred due to the detection in order to advance the counter 104. In another example, a hashed one-time password may be utilized so that a window of mis-synchronization may be accommodated. For example, if within a threshold of 10, the counter 210 may be configured to move forward. However, if within a different threshold, such as 10 or 1000, a request to perform a re-synchronization may be processed, which may require, via one or more applications, that the user tap, gesture, or otherwise indicate one or more times via the user's device. If the counter 210 increments in the proper sequence, the user may know that they have done so.

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

[0030] During the contactless card 100 creation process, two cryptographic keys may be uniquely assigned per card. The cryptographic keys may include symmetric keys that may be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm may be used by EMV and is implemented by hardware within the contactless card 100. A key diversification process may be used to derive one or more keys from a master key based on uniquely identifiable information for each entity that requires a key.

[0031] In some examples, to overcome the shortcomings of the 3DES algorithm, which is susceptible to vulnerabilities, a session key (such as a unique key per session) can be derived, but rather than using a master key, a unique card derivation key and a counter can be used as diversification data. For example, each time the contactless card 101 is used in operation, a different key may be used to create a message authentication code (MAC) and perform encryption. This results in three layers of encryption. The session key may be generated by one or more applets and derived by using an application transaction counter with one or more algorithms (as defined in EMV4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0032] Furthermore, the increments 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 instances, the increments may also vary on successive reads, such that one card may increment in a repeating sequence of 1, 3, 5, 2, 2, ... The specific sequence or algorithmic sequence may be defined at the time of personalization or from one or more processes derived from the unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0034] In an embodiment, the contactless card 100 may store a resource locator 220 in the memory 204. For example, during a creation process, a resource locator 220 that is used to initiate an activation process may be written to the 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 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 may be "https: / / play.google.com / store / apps / details?id=<package_name> " where package_name can refer to an application. In another example, resource locator 220 can be "http: / / apps.apple.com / <country> / app / <app-name> / id <store-id>" where app-name and id are references to download the app. In an embodiment, memory 204 may include both resource locators so that a customer can activate a contactless card using any device with 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 operating system of the mobile device to launch the app. For example, upon receiving resource locator 220, the mobile device may check whether the app is installed and, if so, the operating system skips the installation process and launches the app.

[0035] In an embodiment, the contactless card 100 including the resource locator 220 can be utilized 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 the external device (mobile device). The resource locator 220 in the memory 204 can be updated with new instructions or locators for a series of operations until the series is completed.

[0036] 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 a new resource locator 220 to memory 204 for the next operation to be performed. In some embodiments, the next operation can request that the customer review 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 can be a deep link to a local location within an app on the mobile device. In another example, the link can be an external link (outside of the app) to launch a website in a web browser on the mobile device. The embodiments are not limited to these examples.

[0037] In an embodiment, once the device receives the resource locator from the contactless card 100, the device can write the next action to the card as the resource locator. For example, the device can write a unique identifier that can be utilized 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 within range of the device and the device can perform an NFC read operation to read the resource locator, which includes the unique identifier. The device can determine that the terms and conditions are acceptable and perform the activation with the activation server / system.

[0038] The contactless card component 200, including the memory 204, may be updated with one or more resource locators 220 during an 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 instructions to perform the next operation 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 the memory 204. Each of the different resource locators 220 may cause the mobile device to perform a different operation, such as downloading / launching an app, presenting terms and conditions, and accepting terms and conditions, as previously described. When activated, the resource locator 220 may store instructions or resource locators to cause an 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 information for an account associated with the contactless card, such as account balance, payment activity, transactions, rewards / rewards, etc. The contactless card 200 can store the resource locator 220 and cause the app to launch to a landing page until the resource locator 220 is updated with new instructions to perform another action.

[0039] 3 illustrates an exemplary system 300 that may be utilized to perform contactless card activation. In the illustrated example, the system 300 includes a contactless card 100, a mobile device 302, and an activation system 304. The components of the 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 according to a wireless protocol such as NFC, Bluetooth, Wireless Fidelity (WiFi), etc. 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 an embodiment, the system 300 may be utilized by a customer to activate the contactless card 100 via the mobile device 302. For example, the contactless card 100 may be configured with a resource locator during creation that causes an operating system on the mobile device 302 to install or start an app associated with the contactless card 100. In operation, the contactless card 100 may provide a customer with instructions to turn on a short-range radio on the mobile device 302, such as an NFC interface, and place the contactless card 100 within range of the mobile device 302. The range may be an operating range of the short-range radio that is met by tapping the card on the mobile device 302. In one example, the range may be an operating range according to the NFC standard. The mobile device 302 may detect the contactless card 100 and perform an exchange with the contactless card 100 to establish communication, e.g., an NFC exchange.

[0041] A mobile device 302 in communication with contactless card 100 can perform a read operation (NFC read) to read data from a memory of contactless card 100. In an embodiment, the read operation can reference 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 memory, and provide the resource locator to mobile device 302. Mobile device 302 can process 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 or start a banking app if the app is already installed on mobile device 302.

[0042] In some cases, the customer may need to perform several steps to perform activation of the contactless card 100. The mobile device 302 may write a new resource locator to the memory of the contactless card 100 for each new operation. For example, in response to starting an app on the mobile device 302, the mobile device 302 including the app may write a new resource locator to the memory of the contactless card 100 (NFC write operation). The new resource locator may be instructions or a link (deep link) that points to the terms and conditions associated with the contactless card 100. Thus, the next time the contactless card 100 comes within communication range of the mobile device 302, the mobile device 302 may perform another NFC read operation, receive an 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 may process the resource locator, which may enable the app to present the terms and conditions in a graphical user interface (GUI) on the display of the banking app or in a web browser of the mobile device 302.

[0043] In embodiments, the contactless card 100 may be used to authenticate a user and accept terms and conditions. For example, the mobile device 302 may obtain a unique identifier associated with a customer. The mobile device 302 may request the customer to enter credentials, such as a password, a unique pattern, a biometric, a passcode, etc., 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 so limited.

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

[0045] To perform the activation, the mobile device 302 can communicate data with the activation system 304. The data can include information to identify the customer, identify the contactless card 100, verify that the terms and conditions are accepted, etc. The activation system 304 can process the data and verify that the contactless card 100 has been activated or that activation to the mobile device 302 failed. The mobile device 302 can display information in an 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 the OTP to perform an authentication operation. For example, the mobile device 302 can instruct the customer to bring the contactless card 100 within range of the mobile device 302 to accept terms and conditions and / or launch a banking app to a landing page with sensitive information. Once within range, the contactless card 100 and the mobile device 302 can perform an NFC exchange. For example, the contactless card 100 including instructions may be configured to respond to one or more requests, such as a near field wireless data exchange request, from a mobile NFC reader of the mobile device 302 and generate an NDEF message including a cryptographically secure OTP encoded as an NDEF text tag with the unique identifier. One example of an NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, the one or more card instructions may be configured to encode the OTP as a text tag of the well-known type of NDEF Type 4. In some examples, the NDEF message can include one or more records. The instructions may be configured to add one or more static tag records in addition to the OTP record.

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

[0048] FIG. 4 illustrates an example routine 400 that may be executed by the mobile device 302 to activate the contactless card 100. At block 402, the routine 400 includes receiving a first uniform resource locator (URL) for an application from the contactless card over the wireless interface. In an embodiment, the application may be a banking app and may be configured to perform the activation. The first URL may be stored in a 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 an operating system of the mobile device 302 and may trigger one or more events. Specifically, at block 404, the routine 400 includes launching the application in response to receiving the first URL. In some cases, the app may be installed on the mobile device 302 and the operating system may cause the app to run upon receiving the first URL. 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 a download page for the banking app. The embodiments are not so limited.

[0049] At block 406, the routine 400 includes writing a second URL for the terms to the contactless card. In an embodiment, the second URL may include a link, such as a deep link or web link, to a location to cause the user to present the terms and conditions on the display of the mobile device 302. 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 the contactless card activation, it may provide the deep link to the operating system, and the operating system may generate a message, such as "Write an NDEFMessage message," that includes the deep link as the second URL to write to the contactless card. In another example, 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 the NDEF message to write the website / page link to the contactless card. The contactless card can store the second URL in memory until the next action is ready to be performed for the activation sequence, for example until the customer is ready to view the terms and conditions by bringing the card within range of the mobile device again.

[0050] At block 408, the routine 400 includes receiving a second URL from the contactless card that matches the terms. In some cases, the app can present instructions in a GUI on the display of the mobile device 302 for the user to bring the contactless card within range of the mobile device 302 to read the terms and conditions, such as instructions 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 can receive the second URL from the contactless card in an NDEF message. The operating system of the mobile device 302 can process the second URL, including causing the app or a web browser to open and display the terms and conditions. As previously discussed, the second URL may be a link to the app itself or a location within a website / page. Additionally, at block 410, the routine 400 includes presenting the terms on the display of the mobile device. The terms and conditions can be presented in a GUI and are readable to the customer. The customer can then read the terms and conditions.

[0051] At block 412, the routine 400 includes writing a third URL for a unique identifier to identify a customer associated with the contactless card. The third URL containing the unique identifier may be used by the 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 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 the operating system.

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

[0053] In an embodiment, the mobile device 302 can activate the contactless card upon the customer's acceptance of the terms and conditions. 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 has accepted the terms and conditions and information identifying the contactless card being activated. The information identifying the card can include an identifier (username) associated with the customer, an account number for the contactless card, or other identifying information. The activation system 304 can utilize the information and activate the contactless card for use in performing transactions. At block 416, the routine 400 includes determining that the contactless card is activated at least in part in response to the conditions being verified. In one example, the mobile device 302 can receive an indication from the activation system 304 indicating that the contactless card has been activated or whether the activation failed. The mobile device 302 can inform the customer whether the contactless card has been activated, for example, by presenting information on a display. In some cases, if activation fails, the app can present the customer with ways to fix the failed activation attempt.

[0054] In an embodiment, once the card is activated, the customer can utilize the contactless card on the mobile device 302 to launch an app, go to a landing page, or perform another action. For example, the operating system can detect and launch an app each time the card is brought within range of the mobile device 302. 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 cryptogram that can include the unique identifier and the OTP and communicate the cryptogram to the mobile device 302. The mobile device 302 can authenticate the user using the unique identifier and the OTP and have the user presented with a landing page that includes the sensitive information.

[0055] FIG. 5 illustrates an example routine 500 that may be executed by the contactless card 100 to activate the contactless card 100 via the mobile device 302. At block 502, the routine 500 includes transmitting a first uniform resource locator (URL) for an application to the mobile device. In an embodiment, the contactless card may transmit the first URL to the mobile device 302 in response to a read operation over a wireless interface, such as an NFC interface. The first URL may be stored in a memory of the contactless card. The contactless card including the circuitry may retrieve the first URL from the 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 app on the mobile device 302. In some cases, when the app 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] At block 504, the routine 500 includes receiving a second URL for terms and conditions associated with activation of the 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 memory of the contactless card. The second URL may include a link to terms and conditions associated with the contactless card and that may be included in an NDEF message. At block 506, the routine 500 includes storing the second URL in memory by the contactless card.

[0057] At block 508, the routine 500 includes sending the 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 when the contactless card comes into wireless operating range of the mobile device 302, as previously described.

[0058] At block 510, the routine 500 receives a third URL for a unique identifier for identifying a customer associated with the 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 the read operation, the write operation may be performed when the contactless card is brought into wireless range of the mobile device 302. In some embodiments, the read and write operations may be performed as part of an exchange during the same instance. For example, a customer may bring a contactless card within range of the mobile device 302, which may perform a read operation to read the second URL, as described at 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 memory of the contactless card. The exchange may occur during a single instance in which the customer brings the contactless card into wireless range. Further, at block 512, the routine 500 includes storing the third URL in the memory of the contactless card.

[0059] At block 514, the routine 500 includes sending the 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 wireless range of the mobile device 302, as described above. In this instance, the customer may bring the contactless card into range of the mobile device 302 in response to instructions 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 may 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 utilized to perform different operations or series of actions by utilizing 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 blocks of instructions, as a resource locator. The device can write data to the memory of the contactless card as a resource locator, for example, 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 data stored in the 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 series of actions is completed. In some cases, the contactless card can include an OTP with the resource locator when it is read so that the device can verify and / or authenticate the user. Data communicated between the contactless card and the device may be communicated in raw or encrypted format in NDEF messages.

[0061] FIG. 6 illustrates an exemplary routine 600 executed by a contactless card that stores data as a resource locator for performing operations in a series of actions or operations, where the contactless card can be utilized as a state machine for performing the operations. In block 602, the routine 600 includes storing instructions or data in a 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 can be instructions for performing one or more operations to complete a series of operations. The device can perform an NFC write operation to write data to the memory utilizing short-range wireless communication such as NFC and NDEF messages. The contactless card can store the data in the 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 one example, the data can be a link to a location, such as a web link or a link / pointer to a memory location. In another example, the data can be computer instructions that can be executed and / or performed on the device. The instructions may be high-level instructions, such as those utilized in a scripting language, or low-level instructions, such as C code, JAVA code, assembly code, etc., that may be executed by the device. Embodiments are not so limited.

[0062] At block 604, the routine 600 includes providing data to the device. For example, the device may perform an NFC read operation, or the contactless card may generate an NDEF message to communicate the data to the device. In some embodiments, the data may be communicated in cryptography, as described herein. The data may be used by the device to perform an operation.

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

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

[0065] 7 is a timing diagram illustrating an example sequence for providing authenticated access in accordance with one or more embodiments of the present disclosure. The sequence flow 700 can include a contactless card 100 and a client device 702, which can include an application 704 and a processor 706. In some embodiments, the client device 702 can be a mobile device 302. In some cases, the following sequence can 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 an app on the mobile device 302 and go to a landing page, as described above with respect to FIG.

[0066] At line 710, the application 704 communicates with the contactless card 100 (e.g., after being brought close to the contactless card 100). The communication between the application 704 and the contactless card 100 may include the contactless card 100 being sufficiently close to a card reader (not shown) of the client device 702 to enable NFC data transfer between the application 704 and the contactless card 100.

[0067] At line 708, after communication is established between the client device 702 and the contactless card 100, the contactless card 100 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 100 is read by the application 704. In particular, this may occur upon a read, such as an NFC read of a Near Field Enabling and Distributed Encryption (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader application, such as the application 704, may send a message, such as an applet selection message, with an applet ID of an NDEF generation applet. Upon confirming the selection, a series of select 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. A session key may then be generated. A MAC ciphertext may be created from the message, which 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 the random number (RND) may be encrypted with a session key. The ciphertext and the header may then be concatenated, encoded as ASCII hexadecimal, and returned in the NDEF message format (in response to a "read NDEF file" message).

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

[0069] At line 712, contactless card 100 transmits the MAC cryptogram to application 704. In some embodiments, the transmission of the MAC cryptogram occurs over NFC, although the disclosure is not limited thereto. In other examples, the communication may occur over Bluetooth, Wi-Fi, or other wireless data communication means. At line 714, application 704 communicates the MAC cryptogram to processor 706.

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

[0071] FIG. 8 illustrates an NDEF Short Record Layout (SR=1) data structure 800 according to an example embodiment. One or more applets may be configured to encode the OTP as a text tag of NDEF Type 4 well-known type. In some examples, the NDEF message may include 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, encoding English (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message may be encoded as ASCII hex; type-length-value (TLV) data may be provided as a personalization parameter that may be used to generate the NDEF message. In one embodiment, the authentication template may include a first record with a well-known index to provide the actual dynamic authentication data.

[0072] FIG. 9 illustrates a diagram of a system 900 configured to implement one or more embodiments of the present disclosure. As described below, during the contactless card creation process, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys can include symmetric keys that can be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm may be used by EMV and is implemented by the contactless card's hardware. A key diversification process can be used to derive one or more keys from a master key based on uniquely identifiable information for 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 a portfolio in which one or more applets are issued. For example, the first master key 902 may include an issuer cryptographic generation / authentication key (Iss-Key-Auth) and the second master key 926 may include an issuer data encryption key (Iss-Key-DEK). As described further herein, the two issuer master keys 902, 926 are diversified into card master keys 908, 920 that are unique for each card. In some examples, the network profile record ID (pNPR) 522 and derived key index (pDKI) 924 as back office data may be used to identify which issuer master key 902, 926 to use in the encryption process for authentication. The system performing the authentication may be configured to retrieve the values ​​of pNPR 922 and pDKI 924 of the contactless card during authentication.

[0074] In some examples, to increase the security of the solution, a session key (such as a unique key per session) can be derived, but as mentioned above, a unique card derived key and counter can be used as diversification data rather than using a master key. For example, a different key can be used to create a message authentication code (MAC) and perform encryption each time the card is used in operation. With regard to session key generation, the key used to generate ciphertext and encrypt data in one or more applets can include a session key based on a card specific key (Card-Key-Auth 908 and Card-Key-Dek 920). The session keys (Automatic Session Key 932 and DEK Session Key 910) can be generated by one or more applets and derived by using an Application Transaction Counter (pATC) 904 in one or more algorithms. Only the two lowest bytes of the four-byte pATC 904 are used to fit the data into one or more algorithms. In some examples, a 4-byte session key derivation method may include F1:=PATC(lowest 2 bytes) || "F0" || "00" || PATC(4 bytes) F1:=PATC(lowest 2 bytes) || "0F" || "00" || PATC(4 bytes) SK:={(ALG(MK)[F1]) || ALG(MK)[F2]}, where ALG may include 3DESECB and MK may include a card-specific derived master key.

[0075] As described herein, the lower two bytes of the pATC 904 counter can be used to derive one or more MAC session keys. At each tap of the contactless card, the pATC 904 is configured to be updated and the card master keys Card-Key-AUTH 508 and Card-Key-DEK 920 are further diversified into session keys Auto-Session-Key 932 and DEK-Session-KEY 910. The pATC 904 can be initialized to 0 at personalization or applet initialization. In some examples, the pATC counter 904 may be initialized at or before personalization and configured to increment by 1 at each NDEF read.

[0076] Additionally, updates for each card may be unique, assigned by personalization, or algorithmically assigned by the pUID or other identifying information. For example, odd numbered cards may be incremented or decremented by 2, and even numbered cards may be incremented or decremented by 5. In some instances, updates may also vary on successive reads, such as one card may increment in a repeating sequence of 1, 3, 5, 2, 2, .... The specific sequence or algorithmic sequence may be defined at the time of personalization or from one or more processes derived from the unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

[0077] The authentication message may be delivered as the contents of a text NDEF record in hexadecimal ASCII format. In some examples, it may include only an 8-byte random number followed by the authentication data and a MAC of the authentication data. In some examples, the random number may precede the ciphertext A and may be one block long. In other examples, there may be no limit on 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, any multiple of that block size may be used, or the output may be padded automatically or manually to a multiple of that block size.

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

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

[0080] The following format represents an example embodiment of the binary version: Additionally, in some examples, the first byte may be set to an ASCII "A." TIFF2024514925000002.tif148170

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

[0082] The UID field of the received message can be extracted to derive the card master keys (Card-Key-Auth 908 and Card-Key-DEK 920) for that particular card from the master keys Iss-Key-AUTH 502 and Iss-Key-DEK 926. The card master keys (Card-Key-Auth 508 and Card-Key-DEK 920) can be used to derive the session keys (Aut-Session-Key 932 and DEK-Session-Key 910) for that particular card using the counter (pATC) field of the received message. Ciphertext B 918 can be decrypted using ciphertext A 914 and the DEK-Session-KEY which produces RND, which may be discarded. The UID field, along with the Ver, UID, and pATC fields of the message, can be used to look up the shared secret of the contactless card which can be processed through an encrypted MAC using the recreated automatic session key to produce a MAC output such as MAC'. If the MAC' is the same as the ciphertext A 914, this indicates that the message decryption and MAC checks all pass. The pATC can then 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, the one or more ciphertexts may be generated using ISO 9797-1 algorithm 3 as 3DESMAC via one or more session keys, such as the automatic session key 932, with method 2 padding. The input data 906 may take the following form: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the number in parentheses may include 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 include a random 4-byte binary number injected into the card at the time of personalization that is known by the authentication service. During an authentication session, the shared secret may not be provided to the mobile application from one or more applets. The method 2 padding 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 result data up to an 8-byte boundary. The resulting ciphertext may be 8 bytes in length.

[0084] In some instances, one advantage of encrypting an unshared random number with a MAC cipher as the first block is that it acts as an initialization vector while using the CBC (Block Chaining) mode of a symmetric encryption algorithm, allowing 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 included in the MAC ciphertext, the authentication service may be configured to determine whether a value carried in the clear data has been tampered with. Additionally, by including the version in one or more ciphertexts, it is 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 that is 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, it may be evaluated to determine if it is within an acceptable range or threshold, and if it is greater or outside the range or threshold, the verification may be considered to have failed or to be unreliable. In a MAC operation 912, the data 906 is processed through a MAC using the automatic session key 932 to produce an encrypted MAC output (ciphertext A) 914.

[0086] The MAC ciphertext 914 is desirably encrypted to provide additional protection against brute force attacks that expose the keys on the card. In some examples, the data or ciphertext A 914 included in the ciphertext may include a random number (8), ciphertext (8). In some examples, the number in parentheses may include the length in bytes. In some examples, the random number may be generated by one or more random number generators, which may be configured to make the random number unpredictable via one or more secure processes. The key used to encrypt this data may include a session key. For example, the session key may include a DEK-Session-Key 910. In an encryption operation 916, the data or ciphertext A 914 and RND are processed using the DEK-Session-Key 510 to generate ciphertext B 918, which is the encrypted data. The data 914 may be encrypted using 3DES in cipher block chaining mode to ensure that an attacker has to perform any attack across all of the ciphertext. Other algorithms may be used, such as the Advanced Encryption Standard (AES), as a non-limiting example. In some instances, an initialization vector of 0x'00000000000000000' can be used. An attacker attempting to brute force the key used to encrypt this data would not be able to determine when the correct key was used, because correctly decrypted data is indistinguishable from incorrectly decrypted data due to its random appearance.

[0087] In order for the authentication service to verify one or more cryptograms provided by one or more applets, it must communicate the following data in plaintext from the one or more applets to the mobile device during an authentication session: a version number to determine the cryptographic method used to allow the method to be changed in the future and a message format to verify the cryptogram; a pUID to extract cryptographic assets and derive a card key; and a pATC to derive a session key to be used in relation to the cryptograms.

[0088] 10 illustrates a method 1000 for generating a ciphertext. For example, in block 1002, a Network Profile Record ID (pNPR) and a Derived Key Index (pDKI) can be used to identify which Issuer Master Key to use in the encryption process for authentication. In some examples, the method can include performing authentication to retrieve values ​​of pNPR and pDKI for the contactless card upon authentication.

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

[0090] In block 1006, the Card-Key-Auth and Card-Key-DEK (Unique Card Key) can be created by diversifying the Issuer Master Key to generate a session key that can be used to generate a MAC ciphertext.

[0091] In block 1008, the keys used to generate ciphertext and encrypt data in one or more applets may include session keys in block 1030 that are 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 and derived using the pATC to result in the session keys Auto Session Key and DEK Session Key.

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

[0093] In block 1104, the counter value may be encrypted by the sender using the data encryption master key to generate a data encryption derived session key, and the counter value may 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 may be used during both encryptions.

[0094] In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted between the sender and receiver in plain text, i.e., without encryption.

[0095] The data to be protected is processed in a cryptographic MAC operation by the sender using a data integrity session key and a cryptographic MAC algorithm, in block 1106. The protected data, including the plaintext and the shared secret, 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 in conjunction with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data, e.g., each 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 using sufficient information to identify additional secret information (eg, a shared secret, a master key, etc.) to verify the ciphertext.

[0098] In block 1112, the recipient independently derives two derived session keys from the two master keys using the received counter values, as described above.

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

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

[0101] Some examples of the methods described herein can advantageously ascertain when successful authentication is determined when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key was proper. The MAC may only be correct if the decryption is successful and results in a proper MAC value. Successful decryption can indicate that a correctly derived encryption key was used to decrypt the encrypted MAC. Because the derived session key is created using a master key known only to the sender (e.g., the sending device) and the recipient (e.g., the receiving device), it can be trusted that the contactless card that originally created the MAC and encrypted it is in fact 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] The two derived session keys may then be discarded, and the next iteration of the data exchange may update the counter value (return 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] 12 illustrates a method 800 for card activation according to an exemplary embodiment. For example, card activation may be completed by a system including a card, a device, and one or more servers. The contactless card, the device, and the one or more servers may refer to the same or similar components as previously described, such as the contactless card 100, the client device 702, and the server.

[0104] At block 1202, the card may be configured to dynamically generate data. In some examples, this data may include information such as an account number, a card identifier, a card verification value, or a phone number that may be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted via the systems and methods disclosed herein.

[0105] At block 1204, one or more portions of the dynamically generated data can be communicated to an application on the device via NFC or other wireless communication. For example, tapping the card in proximity to the device can enable an application on the device to read one or more portions of data associated with the contactless card. In some examples, if the device does not have an application that assists in activating the card, tapping the card can prompt the device or a software application store to prompt the customer to download an associated application to activate the card. In some examples, the user may be prompted to sufficiently gesture, place, or orient the card toward the surface of the device, e.g., placed diagonally or flat on, near, or adjacent to the surface of the device. In response to sufficient gesture, placement, and / or orientation of the card, the device can proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

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

[0107] At block 1208, the one or more servers may decrypt the one or more encrypted portions of the data via the systems and methods disclosed herein. For example, the one or more servers may receive the encrypted data from the device and may decrypt the received data to record the data accessible to the one or more servers. If the resulting comparison of the one or more decrypted portions of the data by the one or more servers results in a successful match, the card may be activated. If the resulting comparison of the one or more decrypted portions of the data by the 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 that includes the number of attempts that the user is allowed to activate the card. Alternatively, the user may receive a notification such as a message on their device indicating the failed attempt to validate the card and a call, email or text to an associated service for assistance in activating the card, or a call on their device indicating the failed attempt to validate the card and another notification such as a call, email or text to an associated service for assistance in activating the card, or an email indicating the failed attempt to validate the card and a call, email or text to an associated service for assistance in activating the card.

[0108] At block 1210, the one or more servers may send a return message based on successful activation of the card. For example, the device may be configured to receive an output from the one or more servers indicating successful activation of the card by the one or more servers. The device may be configured to display a message indicating successful activation of the card. Once the card is activated, the card may be configured to cease dynamic generation of data to avoid fraudulent use. In this manner, the card may not be subsequently activated and the one or more servers are notified that the card has already been activated. < / country>

Claims

1. 1. A computer-implemented method, comprising: providing, by the contactless card, in response to a first wireless reading by the mobile device, first instructions relating to an application, the first instructions being stored in a memory of the contactless card; storing, in the memory, second instructions relating to a condition associated with the contactless card, the second instructions being received from the mobile device; providing, to the mobile device, the second instruction regarding the condition and information associated with the contactless card in response to a second wireless reading by the mobile device; the contactless card storing in the memory third instructions related to a unique identifier received from the mobile device to identify the information associated with the contactless card; providing, by the contactless card, in response to a third wireless reading by the mobile device, third instructions to the mobile device to verify the condition based on the unique identifier of the third instructions; 23. A computer-implemented method comprising:

2. executing an applet based on instructions received from the mobile device, the applet generating a ciphertext; providing the cryptogram to the mobile device in response to a fourth query, the cryptogram including an encrypted unique identifier generated from the unique identifier; The computer-implemented method of claim 1 , comprising:

3. 2. The computer-implemented method of claim 1, wherein providing the first instructions comprises providing the first instructions over a wireless interface configured for near field communication (NFC).

4. The computer-implemented method of claim 1 , further comprising storing fourth instructions from the mobile device, the fourth instructions including a second unique identifier and a one-time passcode for the contactless card.

5. The computer-implemented method of claim 4 , further comprising providing the fourth instructions to the mobile device over a wireless interface, the first, second, third, and fourth instructions comprising a link.

6. The computer-implemented method of claim 1 , wherein the second instruction for the condition is a deep link to a location within the application.

7. An apparatus comprising: A processor; a memory containing instructions; The instructions, when executed by the processor, cause the processor to: causing the contactless card to provide, in response to a first wireless reading by the mobile device, first instructions relating to an application over a wireless interface, the first instructions being stored in a memory of the contactless card; causing the memory to store, by the contactless card, second instructions relating to a condition associated with the contactless card, the second instructions being received from the mobile device; causing the mobile device to provide the second instructions regarding the condition and information associated with the contactless card in response to a second wireless reading by the mobile device of the contactless card; storing, by the contactless card, in the memory, third instructions related to a unique identifier received from the mobile device to identify the information associated with the contactless card; and causing the mobile device to provide, in response to a third wireless read by the contactless card, third instructions to verify the condition based on the unique identifier of the third instructions.

8. The processor, executing an applet based on instructions received from the mobile device, the applet generating a ciphertext; The apparatus of claim 7 , further comprising: in response to a fourth query, causing the mobile device to provide the ciphertext, the ciphertext comprising an encrypted unique identifier generated from the unique identifier.

9. The device of claim 7 , further comprising a wireless interface configured for a Near Field Communication (NFC) protocol.

10. The apparatus of claim 7 , further comprising: fourth instructions stored therein that cause the processor to include a second unique identifier and a one-time passcode for the contactless card.

11. The apparatus of claim 10 , further comprising: causing the processor to provide the fourth instructions over the wireless interface.

12. The apparatus of claim 10 , wherein the second instruction for the condition is a deep link to a location within the application, and the first, second, third, and fourth instructions include links.

13. A non-transitory computer-readable medium comprising a set of instructions, the set of instructions being executed by a processor of a mobile device to cause the processor to: receiving, via the wireless interface, a first instruction relating to an application from the contactless card; writing a second command to the contactless card via the wireless interface; receiving a message from the contactless card via the wireless interface, the message including information related to the contactless card and the second instruction; generating a first unique identifier based on the information of the contactless card; writing third instructions to the contactless card, the third instructions including the first unique identifier; receiving the third command submitted to verify a condition from the contactless card; verifying that the same contactless card is presented based on the first unique identifier and the third command; A non-transitory computer readable medium that determines that the contactless card has been activated in response at least in part to the condition being verified by the same contactless card.

14. The set of instructions, in response to being executed by the processor, causes the processor to: causing the contactless card to transmit applet instructions over the wireless interface, the applet instructions directing an applet on the contactless card to generate a cryptogram; 14. The non-transitory computer-readable medium of claim 13, further comprising: receiving the cryptogram based at least in part on the unique identifier.

15. 14. The non-transitory computer-readable medium of claim 13, wherein the wireless interface issues at least one of a Near Field Communication (NFC) protocol.

16. 14. The non-transitory computer-readable medium of claim 13, further comprising: causing the processor to write fourth instructions to the contactless card via the wireless interface, the fourth instructions including a second unique identifier and a one-time passcode for the contactless card.

17. The processor, receiving the fourth command from the contactless card via the wireless interface; transmitting at least said one-time passcode to a server; 17. The non-transitory computer-readable medium of claim 16, further comprising receiving a response in response to transmitting the one-time passcode, the response including data associated with the contactless card.

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

19. 14. The non-transitory computer-readable medium of claim 13, wherein the application is launched by an operating system in response to receiving the first instruction.

20. 14. The non-transitory computer-readable medium of claim 13, wherein the second instruction for the condition is a deep link to a location within the application, and the first, second, third, and fourth instructions include links.

Images