Technology for managing personal identification numbers on contactless cards

Abstract

Embodiments disclosed herein provide techniques for secure PIN management of contactless cards using an application on a computing device, such as a mobile computing device. In some embodiments, the computing device can have an application installed such that the computing device acts as a secure endpoint, enabling communication between contactless cards and a backend server to facilitate PIN management. For example, the application can enable a mobile device to view and / or change the PIN associated with a contactless card brought near the mobile device.

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The embodiments disclosed herein relate generally to computing platforms, and more particularly to computing platforms that manage secure personal identification numbers (PINs) for contactless cards. [Background technology]

[0002] A personal identification number (PIN), or sometimes redundantly PIN number or PIN code, is a numeric (or sometimes alphanumeric) passcode used in the process of authenticating a user for system access. PINs have been keys that facilitated private data exchange between different data processing centers in computer networks for financial institutions, governments, and businesses. PINs can be used to authenticate cardholders and banking systems, citizens and governments, employees and businesses, and users and computers, among other things. In common usage, PINs are used for ATM or point-of-sale transactions, secure access control (e.g., computer access, door access, car access, etc.), Internet transactions, or logging into restricted websites. Summary of the Invention

[0003] This summary is not intended to identify only key or essential features of the described subject matter, nor is it intended to be used alone to determine the scope of the described subject matter, which subject matter should be understood by reference to appropriate portions of the entire specification of this patent, any and all drawings, and each claim.

[0004] In one aspect, the present disclosure relates to an apparatus comprising a processor and memory including instructions that, when executed by the processor, cause the processor to perform one or more of: authenticating a user based on credentials received via a user interface; detecting a cryptogram received from a contactless card in proximity to the processor; determining that the contactless card is associated with the user based on authentication of the cryptogram; presenting via the user interface a current personal identification number (PIN) associated with the contactless card based on authentication of the user and authentication of the cryptogram; determining to change the current PIN associated with the contactless card to an updated PIN; identifying the updated PIN based on input received via the user interface; communicating the updated PIN to a server and associating the updated PIN with the contactless card; identifying a PIN script received from the server in response to communication of the updated PIN to the server; and communicating the PIN script to the contactless card and changing the PIN stored on the contactless card from the current PIN to the updated PIN.

[0005] In some embodiments, the mobile device comprises a processor and a memory, and the cryptogram is received from the contactless card via near field communication. In various embodiments, the instructions, when executed by the processor, further cause the processor to communicate the cryptogram to a server and receive verification from the server to authenticate the cryptogram. In many embodiments, the instructions, when executed by the processor, further cause the processor to encrypt an updated PIN for communication to the server. In many such embodiments, the instructions, when executed by the processor, further cause the processor to encrypt the updated PIN based on a unique identifier (UID) received from the contactless card. In many further such embodiments, the instructions, when executed by the processor, further cause the processor to generate a session key using the UID and encrypt the updated PIN based on the UID. In some embodiments, the instructions, when executed by the processor, further cause the processor to authenticate a PIN script based on a message authentication code (MAC) received from the server. In some such embodiments, the instructions, when executed by the processor, further cause the processor to authenticate the PIN script based on the MAC received from the server using an integrated key.

[0006] In another aspect, the present disclosure relates to at least one non-transitory computer-readable medium including a set of instructions that, responsive to being executed by the processor circuit, cause the processor circuit to do one or more of: authenticating a user based on credentials received via a user interface; detecting a cryptogram received from a contactless card proximate to the processor; determining that the contactless card is associated with the user based on authenticating the cryptogram; presenting via the user interface a current personal identification number (PIN) associated with the contactless card based on authenticating the user and authenticating the cryptogram; determining to change the current PIN associated with the contactless card to an updated PIN; identifying the updated PIN based on input received via the user interface; communicating the updated PIN to a server and associating the updated PIN with the contactless card; identifying a PIN script received from the server in response to communicating the updated PIN to the server; and communicating the PIN script to the contactless card and changing the PIN stored on the contactless card from the current PIN to the updated PIN.

[0007] In some embodiments, the set of instructions, in response to execution by the processor circuit, further cause the processor circuit to communicate the ciphertext to a server and receive verification from the server to authenticate the ciphertext. In various embodiments, the set of instructions, in response to execution by the processor circuit, further cause the processor circuit to encrypt an updated PIN for communication to the server. In some embodiments, the set of instructions, in response to execution by the processor circuit, further cause the processor circuit to encrypt the updated PIN based on a unique identifier (UID) received from the contactless card. In some such embodiments, the set of instructions, in response to execution by the processor circuit, further cause the processor circuit to generate a session key using the UID and encrypt the updated PIN based on the UID. In many embodiments, the set of instructions, in response to execution by the processor circuit, further cause the processor circuit to authenticate the PIN script based on a message authentication code (MAC) received from the server. In many such embodiments, the set of instructions, in response to execution by the processor circuit, further cause the processor circuit to authenticate the PIN script based on the MAC received from the server using the integrated key.

[0008] In yet another aspect, the present disclosure relates to a computer-implemented method including one or more of: authenticating a user based on credentials received via a user interface; detecting a cryptogram received from a contactless card; determining that the contactless card is associated with the user based on authenticating the cryptogram; presenting via the user interface a current personal identification number (PIN) associated with the contactless card based on authenticating the user and authenticating the cryptogram; determining to change the current PIN associated with the contactless card to an updated PIN; identifying the updated PIN based on input received via the user interface; communicating the updated PIN to a server and associating the updated PIN with the contactless card; identifying a PIN script received from the server in response to communicating the updated PIN to the server; and communicating the PIN script to the contactless card and changing the PIN stored on the contactless card from the current PIN to the updated PIN.

[0009] Some embodiments include encrypting the updated PIN for communication to the server. Some such embodiments include encrypting the updated PIN based on a unique identifier (UID) received from the contactless card. Some further such embodiments include generating a session key using the UID and encrypting the updated PIN based on the UID. Various embodiments include authenticating the PIN script based on a message authentication code received from the server. [Brief explanation of the drawings]

[0010] [Figure 1] 1 illustrates various aspects of an exemplary system for PIN management according to one or more embodiments described herein. [Figure 2] FIG. 1 illustrates aspects of an exemplary system for PIN management according to one or more embodiments described herein. [Figure 3]FIG. 1 illustrates an exemplary transaction card according to one or more embodiments described herein. [Figure 4] 1 illustrates various aspects of a transaction card according to one or more embodiments described herein. [Figure 5] 5 illustrates a sequence flow 500 according to one or more embodiments described herein. [Figure 6] FIG. 6 illustrates a data structure 600 according to one or more embodiments described herein. [Figure 7] FIG. 1 illustrates a logic flow in accordance with one or more embodiments described herein. [Figure 8] FIG. 8 illustrates a routine 800 according to an embodiment. [Figure 9] FIG. 9 illustrates a computer architecture 900 according to one embodiment. [Figure 10] FIG. 1 illustrates a communication architecture 1000 according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Embodiments disclosed herein provide techniques for secure PIN management of contactless cards using an application on a computing device, such as a mobile computing device. In some embodiments, the computing device can have an application installed, enabling the computing device to function as a secure endpoint that enables communication between contactless cards and a backend server to facilitate PIN management. For example, the application can enable a mobile device to view and / or change the PIN associated with a contactless card brought near the mobile device. These and other embodiments are described and claimed.

[0012] In one embodiment, a user can install an application on a computing device. The user can then provide login credentials to access the application. Upon logging in, the application can prompt the user to bring the contactless card close enough to the computing device to enable near-field wireless communication between the contactless card and the computing device. For example, the application can prompt the user to tap the contactless card against the device. Doing so can cause or instruct the contactless card to generate a cryptogram that can be included as part of a data package, such as an NFC Forum Data Exchange Format (NDEF) file. The data package can further include an unencrypted customer identifier (ID) or any other unique identifier. The application can read the data package via NFC and transmit the data package to a server for PIN management authorization. In the case of PIN management authorization, the server can validate the contactless card and the application is associated with a common authorized user. For example, the server can authenticate the cryptogram, such as using the received data package, and the server can verify the login credentials utilized to access applications corresponding to the same user associated with the contactless card for which PIN management is sought. If the server is capable of authorizing PIN management, the application may be utilized to view and / or edit the PIN associated with the contactless card.

[0013] Advantageously, embodiments disclosed herein provide techniques for securely performing PIN management operations from a computing device on which an application is installed. By leveraging cryptography generated by a user's associated contactless card in combination with accessing the application by providing the user's corresponding login credentials, embodiments of the present disclosure can enable a computing device to serve as a secure endpoint for PIN management operations associated with a contactless card while minimizing the risk of fraud. Additionally, the techniques described herein can enable a user to view a PIN without having to change or reset it, thereby improving the customer experience. Furthermore, by using a computing device on which an application is installed, a user can utilize a contactless card at a merchant's contact terminal to receive a PIN change script, eliminating the need to change the PIN on the contactless card, thereby further improving the customer experience and system efficiency.

[0014]

[0011] Generally referring to the notation and nomenclature used herein, one or more portions of the following detailed descriptions may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A procedure is herein generally conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, but not limited to, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, primarily for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0015] Further, these operations are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary or desirable in most cases for any of the operations described herein that form part of one or more embodiments. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program written in accordance with the teachings herein, and / or specially configured apparatus or digital computers for the required purposes. Various embodiments also relate to apparatus or systems for performing these operations. These apparatus may be specially constructed for the required purposes. The required structure for a variety of these machines will be apparent from the description given.

[0016] Reference will now be made to the drawings, wherein 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, novel embodiments may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form to facilitate description thereof. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter.

[0017] In the figures and accompanying description, the notations "a," "b," and "c" (and similar notations) are intended to be variables representing any positive integer. Thus, for example, if an implementation sets a value of a=5, then the complete set of components 123, denoted as components 123-1 through 123-a (or 123a), can include components 123-1, 123-2, 123-3, 123-4, and 123-5. Embodiments are not so limited.

[0018] 1 illustrates various aspects of a PIN management system 102 according to one or more embodiments described herein. In general, the PIN management system 102 may be utilized to allow a user, via a computing device 104, to view and edit a PIN 144 associated with a contactless card 116. The illustrated embodiment includes a cryptogram 122 generated by the contactless card 116 and provided to the computing device 104. In some embodiments, the computing device 104, such as via an application 114, may transmit the cryptogram 122 to a backend server 124 for authentication. In some such embodiments, PIN management functionality may be provided via the application 114 in response to successful verification of the cryptogram 122, which may be received by the computing device 104 as verification 156.

[0019] The PIN management system 102 includes a computing device 104, a contactless card 116, a backend server 124, account data 128, a key management service 130, and a hardware security module 132. The contactless card 116 includes a communication interface 120 and a memory 118 having an applet 134, a master key 136, an integrated key 138, a unique identifier 140, and a PIN 144.

[0020] The computing device 104 is communicatively coupled to a backend server 124 via a network 142 and includes a memory 106, a user interface 110, and a communication interface 108. The memory 106 includes an operating system 112 having an application 114. The backend server 124 includes a memory 126 having a manager 152, a master key 146, an integration key 148, a unique identifier 150, and login credentials 154. It will be understood that one or more items in the memories 106, 118, 126 may be in encrypted or unencrypted format without departing from the scope of this disclosure. Furthermore, one or more items in the memories 106, 118, 126 may be passed between different ones of the memories 106, 118, 126 in encrypted or unencrypted format.

[0021] 1 has a limited number of elements in a particular topology, it will be understood that PIN management system 102 can include more or fewer elements in alternative topologies as desired for a given implementation without departing from the scope of this disclosure. For example, one or more of account data 128, key management service 130, and hardware security module 132 can be incorporated into backend server 124 without departing from the scope of this disclosure. In another example, one or more operations can be performed by computing device 104 instead of backend server 124 or contactless card 116 without departing from the scope of this disclosure. Embodiments are not so limited.

[0022] In various embodiments, the illustrated embodiments relate to various steps for authenticating a user's contactless card and computing device to function as a secure endpoint providing contactless card PIN management functionality. Contactless card 116 represents any type of payment card, such as a credit card, debit card, ATM card, or gift card. Contactless card 101 may include one or more communication interfaces 120, such as a radio frequency identification (RFID) chip, configured to communicate with a communication interface 108 (also referred to herein as a “card reader,” “wireless card reader,” and / or “wireless communication interface”) of computing device 104 via NFC, EMV standard, or other short-range protocols for wireless communication. While NFC is used herein as an exemplary communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as EMV standard, Bluetooth, and / or Wi-Fi.

[0023] Computing device 104 represents any number and type of computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, a virtual computer system, a desktop computer, etc. Backend server 124 represents any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtual computer system, etc. Although not shown for clarity, computing device 104, contactless card 116, and backend server 124 each include one or more processor circuitry that executes programs, code, and / or instructions.

[0024] As previously described, the memory 118 of the contactless card 116 includes the applet 134, the master key 136, the integrated key 138, the unique identifier 140, and the PIN 144. The applet 134 is executable code configured to perform the operations described herein. The master key 136, the integrated key 138, the unique identifier 140, and the PIN 144 are used to provide security for the system 102, as described in more detail below. As previously described, the memory 106 of the computing device 104 includes an instance of an operating system (OS) 112. Exemplary operating systems 112 include the Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, the OS 112 includes one or more applications, including the application 114. The application 114 is software that enables the computing device 104 to interact and communicate with the contactless card 116 and the backend server 124 to provide PIN management functionality. As previously mentioned, memory 126 of backend server 124 includes manager 152, master key 146, integration key 148, unique identifier 150, and login credentials 154. As described in more detail herein, manager 152 interacts with applications 114 of computing device 104 to facilitate one or more backend PIN management functions described herein. In at least one embodiment, interaction between components may be provided via one or more application programming interfaces (APIs). In some embodiments, integration key 148 is utilized to calculate a message authentication code.

[0025] In the embodiment shown in FIG. 1 , a user may log in to application 114 by providing login credentials via user interface 110. The provided login credentials may be compared to login credentials 154 associated with the user to allow the user to access application 114. For example, manager 152 may compare the provided login credentials with login credentials 154. In another example, manager 152 may utilize key management service 130 or hardware security module 132 to compare the provided login credentials with login credentials 154. In some embodiments, login credentials 154, or a portion thereof, may be obtained from account data 128. In one embodiment, login credentials 154 may be stored on computing device 104. In such an embodiment, application 114 may compare the provided login credentials with login credentials 154.

[0026] Once the user logs into the application 114, the user may be instructed to tap the contactless card 116 to the computing device 104 (or otherwise bring the contactless card 101 within communication range of a card reader on the computing device 104). In some embodiments, the user is instructed to tap the contactless card 116 to the computing device 104 in response to selecting a PIN management option in the application 114.

[0027] Generally, when the contactless card 116 is brought within communication range of the communication interface 108 of the computing device 104, the applet 134 of the contactless card 116 can generate the ciphertext 122. The ciphertext 122 can be based on one or more of the master key 136, the integrated key 138, the unique identifier 140, and the PIN 144 of the contactless card 116. For example, the applet 134 can generate the ciphertext 122 based on the master key 136 and the unique identifier 140. The ciphertext may be generated based on any suitable cryptographic technique. In some embodiments, the applet 134 can include the ciphertext 122 and the customer ID (and / or any other unique identifier) ​​in a data package. In at least one embodiment, the data package including the ciphertext 122 and the customer ID is an NDEF file.

[0028] In embodiments, computing device 104 may receive ciphertext 122 from contactless card 116. Computing device 104 may transmit ciphertext 122 to backend server 124, and in some embodiments, backend server 124 may determine that contactless card 116 is associated with a user based on ciphertext 122. For example, backend server 124 may verify information in ciphertext 122 against information stored on backend server 124.

[0029] The PIN management system 102 implements key diversification to protect data, which may be referred to herein as key diversification technology. Generally, the backend server 124 (or another computing device) and the contactless card 116 can be provisioned with the same master keys 136, 146 (also referred to as master symmetric keys). More specifically, each contactless card 116 is programmed with a separate master key that has a corresponding pair in the backend server 124. For example, when the contactless card 116 is manufactured, a unique master key can be programmed into the memory 118 of the contactless card 116. Similarly, the unique master key can be stored in the customer record associated with the contactless card 116 in the account data 128 of the backend server 124 (and / or stored in a different secure location, such as the hardware security module (HSM) 132). The master key may be kept secret from all parties other than the contactless card 116 and the backend server 124, thereby enhancing the security of the system 102.

[0030] In some embodiments, the applet 134 of the contactless card 116 can encrypt and / or decrypt data (e.g., the unique identifier 140) using the master key 136 and the data as inputs to a cryptographic algorithm. For example, encrypting the unique identifier 140 with the master key 136 can result in the ciphertext 122. Similarly, the backend server 124 can encrypt and / or decrypt data associated with the contactless card 116 using the corresponding master key 146.

[0031] In some cases, the contactless card 116 and the backend server 124 can generate session keys using their master keys, as described above. The session keys can be used by the contactless card 116 and the backend server 124 to encrypt and decrypt data. For example, the master keys 136, 146 of the contactless card 116 and the backend server 124 can be used in conjunction with one or more counters to enhance security using key diversification. The counters can include values ​​synchronized between the contactless card 116 and the backend server 124. The counter values ​​can include numbers that change each time data is exchanged between the contactless card 116 and the backend server 124 (and / or between the contactless card 116 and the computing device 104). When preparing to send data (e.g., to the backend server 124 and / or the computing device 104), the applet 134 of the contactless card 116 can increment the counter value. The applet 134 of the contactless card 116 can then provide the master key 136 and the counter value as input to a cryptographic algorithm, which generates a diversified key as output. The cryptographic algorithm can include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, etc. Non-limiting examples of cryptographic algorithms can include symmetric encryption algorithms such as 3DES or AES107, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in more detail in U.S. Patent Application No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0032] Continuing with the key diversification example, contactless card 116 can then encrypt data (e.g., unique identifier 140 and / or any other data) using the diversified key and data as input to a cryptographic algorithm. For example, encrypting unique identifier 140 with the diversified key can result in an encrypted customer ID (e.g., ciphertext) that is included in a data package communicated to computing device 104. Application 114 can then read the data package containing ciphertext 122 and the unencrypted customer ID via communication interface 108.

[0033] Regardless of the encryption technique used, application 114 can transmit the data package including ciphertext 122 and the unencrypted customer ID to backend server 124 over network 142. Application 114 can further indicate to backend server 124 that the data package including ciphertext 122 and the unencrypted customer ID has been read from contactless card 116 via communication interface 108 of computing device 104.

[0034] Upon receipt, manager 152 can attempt to authenticate ciphertext 122. For example, manager 152 can include an authentication application that attempts to decrypt ciphertext 122 using a copy of master key 146 stored by backend server 124. In some embodiments, manager 152 can identify master key 146 and counter value using an unencrypted customer ID included in the data package. In some examples, manager 152 can provide master key 146 and counter value as input to a cryptographic algorithm (e.g., in key management service 130), which generates a diversified key as output. The resulting diversified key may correspond to a diversified key of contactless card 116 that can be used to decrypt ciphertext 122 in the data package.

[0035] The manager 152 can verify or authenticate the ciphertext 122 in the data package by successfully decrypting the ciphertext 122 (e.g., by comparing the unique identifier 140 generated by decrypting the ciphertext 122 with a known unique identifier 150 stored in the account data 128), and / or based on an indication of successful decryption using the master key and / or the shared keys.

[0036] While the one or more keys and / or identifiers are shown as being stored in memory 118, 126, the one or more keys and / or identifiers may be stored elsewhere, such as in a secure element and / or hardware security module 132. In such an embodiment, the secure element and / or hardware security module 132 may use the key and cryptographic function to decrypt the ciphertext. Similarly, the secure element and / or hardware security module 132 may generate a diversified key based on the master key 146 and a counter value, as described above. If the decryption is successful, the manager 152 may enable PIN management functions to be accessed and / or provided via the application 114 of the computing device 104, such as by sending a verification 156. As described in more detail below, such as with respect to FIG. 2, the PIN management functions may include viewing and / or changing the PIN 144 in memory 118 that corresponds to the PIN 146 (deleted) in memory 126.

[0037] However, if manager 152 is unable to decrypt ciphertext 122 and obtain the expected result (e.g., the unique identifier 140 or customer ID for the account associated with contactless card 116), manager 152 does not verify ciphertext 122. In such an example, manager 152 decides to refrain from enabling the PIN management functionality via application 114 of computing device 104. Manager 152 can send an indication of the decryption failure to application 114 of computing device 104. Application 114 can then display an indication of the decryption failure via user interface 110, and thus, a denial of access to the PIN management functionality, to the user via user interface 110.

[0038] 2 illustrates various aspects of a PIN management system 202 according to one or more embodiments described herein. In general, the PIN management system 202 may be utilized to allow a user to view and edit a PIN 244 associated with a contactless card 216 via a computing device 204. In some embodiments, the functionality described with respect to FIG. 2 may occur after the cryptogram verification described with respect to FIG. 1. The illustrated embodiment includes a request for an updated PIN 222 that is provided to a backend server 224 based on, for example, input provided to an application 214 via a user interface 210.

[0039] In some embodiments, the backend server 224 can generate a PIN script 258 based on a request for an updated PIN 222. In some such embodiments, the PIN script 258 can be communicated by the computing device 204 to the contactless card 216 and can be used by the applet 234 to install and / or change the current PIN to an updated PIN 244 on the contactless card 216.

[0040] In various embodiments, PIN management system 202 may be the same as PIN management system 102. PIN management system 202 includes a computing device 204, a contactless card 216, a backend server 224, account data 228, a key management service 230, and a hardware security module 232. Contactless card 216 includes a communications interface 220 and a memory 218 having an applet 234, a master key 236, an integrated key 238, a unique identifier 240, and a PIN 244. Computing device 204 is communicatively coupled to backend server 224 via network 242 and includes memory 206, a user interface 210, and a communications interface 208. Memory 206 includes an operating system 212 having applications 214. The backend server 224 includes a memory 226 having a manager 254, a PIN 246, a master key 248, an integrated key 250, a unique identifier 252, a PIN key 256, and a PIN script 258. It will be understood that one or more items in the memories 206, 218, and 226 may be in encrypted or unencrypted format without departing from the scope of this disclosure. Furthermore, one or more items in the memories 206, 218, and 226 may be passed between different ones of the memories 206, 218, and 226 in encrypted or unencrypted format. While the system 200 shown in FIG. 2 has a limited number of elements in a particular topology, it will be understood that the PIN management system 202 can include more or fewer elements in alternative topologies as desired for a given implementation without departing from the scope of this disclosure. For example, one or more of the account data 228, the key management service 230, and the hardware security module 232 can be incorporated into the backend server 224 without departing from the scope of this disclosure. In another example, one or more operations may be performed by computing device 204 instead of backend server 224 or contactless card 216 without departing from the scope of this disclosure. Embodiments are not so limited.

[0041] In various embodiments, the illustrated embodiments relate to various aspects of PIN management functionality provided via computing device 204. In many embodiments, aspects of PIN management described with respect to FIG. 2 may occur after user authentication and cryptogram authentication, such as one or more processes described with respect to FIG. 1. In some embodiments, the PIN management functionality may include submitting a current PIN (e.g., PIN 244) associated with contactless card 216 via user interface 110. A decision to change the current PIN associated with contactless card 216 to an updated PIN may be made based on input provided to application 214 via user interface 210. The updated PIN may be identified based on input received via user interface 210. For example, a user may select an option to change the PIN and may then be prompted to provide an updated PIN. An updated PIN 222, including a request to update the PIN, may be communicated to backend server 224 to associate the updated PIN with contactless card 216. In many embodiments, the request for updated PIN 222 may be encrypted by computing device 204 prior to communication to backend server 224. For example, the unique identifier 240 previously received from the contactless card 216 may be used to encrypt the updated PIN 222 before transmission to the backend server 224. In a further example, the computing device 204 may generate a session key with the unique identifier 240 and encrypt the updated PIN based on the unique identifier 240.

[0042] In some embodiments, the updated PIN 222 may be stored in account data 228 associated with the user. For example, the updated PIN 222 may be stored in account data 228 as an encrypted PIN block. Additionally, manager 254 of backend server 224 may generate or command the generation of a PIN script 258 that changes the PIN on contactless card 216. In various embodiments, manager 254 may utilize one or more of account data 228, key management service 230, and hardware security module 232 to generate the PIN script 258. For example, hardware security module 232 may generate the PIN script 258. The PIN script 258 may include one or more instructions or actions that may be performed by contactless card 204 to store the new PIN 222 in secure memory. In some embodiments, manager 254 may utilize a PIN key 256 to generate the PIN script 258. In one embodiment, the PIN key 256 may include a key common to a range of account numbers. For example, the PIN key 256 may correspond to the first 6 or 8 digits of the account number.

[0043] The PIN script 258 can be communicated to the computing device 204 by the backend server 224 over the network 242. The PIN script 258 can then be communicated by the computing device 204 to the contactless card 216. In many embodiments, the computing device 204 can authenticate the PIN script 258 before communicating the PIN script 258 to the contactless card 216. For example, the computing device 204 can authenticate the PIN script 258 based on a message authentication code received from the backend server 224. In a further example, the computing device 204 can utilize an integrated key to authenticate the PIN script 258 based on a MAC received from the backend server 224.

[0044] In some embodiments, NFC can be used to communicate the PIN script 258 to the contactless card 216. In some embodiments, the application 214 can prompt the user to tap (or bring sufficiently close) the contactless card 216 to the computing device 204 for transmission of the PIN script 258. For example, in response to receiving the PIN script 258 from the backend server 224, the application 214 can utilize the user interface 210 to prompt the user to tap the contactless card 216 to the computing device 204. Once the contactless card 216 receives the PIN script 258, a processing circuit can execute the PIN script 258 to change the PIN 244 from the current PIN to the updated PIN 222. In some embodiments, the applet 234 can utilize the PIN script 258 to update the PIN 244 in the memory of the contactless card 204.

[0045] In embodiments, PIN script 258 may be written in a scripting language such as Python, Ruby, JavaScript, etc., and the instructions may be human readable. In other examples, PIN script 258 may be executable and configured in binary form. Embodiments are not so limited.

[0046] FIG. 3 illustrates an exemplary configuration of a transaction card 300, which may include a payment card, such as a contactless card, credit card, debit card, or gift card, issued by a service provider, as displayed as service provider indicia 302 on the front or back of the transaction card 300. In many embodiments, the transaction card 300 may be the same as or similar to the contactless card 116. In some examples, the transaction card 300 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, or the like. The transaction card 300 may include a substrate 308, which may include a single layer or one or more laminates composed 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, transaction card 300 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7816 standard; otherwise, the transaction card may conform to the ISO / IEC 14443 standard. However, it is understood that transaction card 300 according to the present disclosure may have different characteristics, and the present disclosure does not require the transaction card to be implemented as a payment card. In some embodiments, FIG. 3 may include one or more components that are the same as or similar to one or more other components of the present disclosure. For example, transaction card 300 may be the same as or similar to contactless card 116, 216. Furthermore, one or more components, or aspects thereof, of FIG. 3 may be incorporated into other embodiments of the present disclosure or excluded from the described embodiments without departing from the scope of the present disclosure. Still further, one or more components, or aspects thereof, of other embodiments of the present disclosure may be incorporated into one or more components of FIG. 3 without departing from the scope of the present disclosure. The embodiments are not so limited.

[0047] Transaction card 300 may also include identification information 306 displayed on the front and / or back of the card and a contact pad 304. Contact pad 304 may include one or more pads and may be configured to establish contact with another customer 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 EMV protocols. Transaction card 300 may also include processing circuitry, an antenna, and other components, as further described in FIG. 4. These components may be located behind contact pad 304 or elsewhere on substrate 308, for example, within a different layer of substrate 308, and may be electrically and physically coupled to contact pad 304. Transaction card 300 may also include a magnetic strip or tape (not shown in FIG. 3) that may be located on the back of the card. Transaction card 300 may also include a near-field communication (NFC) device coupled to an antenna capable of communicating via an NFC protocol. Embodiments are not so limited.

[0048] 4, contact pad 304 of transaction card 300 may include processing circuitry 416 for storing, processing, and communicating information, including a processor 402, memory 404, and one or more interfaces 406. It is understood that processing circuitry 416 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, keys, identifiers, security primitives, and tamper-resistant hardware, as needed to perform the functions described herein.

[0049] The memory 404 may be read-only memory, write-once read-many memory, or read / write memory, such as RAM, ROM, and EEPROM, and the transaction card 300 may include one or more of these memories. Read-only memory may be factory programmable as read-only or one-time programmable. One-time programmable provides the opportunity to write once and read many times. Write-once / read-many memory can be programmed at a time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten but can be read many times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. Read / write memory can also be read many times after leaving the factory. In some cases, the memory 404 may be encrypted memory that utilizes an encryption algorithm executed by the processor 402 on encrypted data.

[0050] The memory 404 can be configured to store one or more applets 408, one or more counters 410, a customer ID 414, and an account number 412, which may be a virtual account number. The one or more applets 408 can 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 408 is not limited to a Java Card applet and can instead be any software application capable of operating on a contactless card or other device with limited memory. The one or more counters 410 can include a numeric counter sufficient to store integers. The customer ID 414 can include a unique alphanumeric identifier assigned to a user of the transaction card 300, which can distinguish a contactless card user from other contactless card users. In some examples, the customer ID 414 can identify both a customer and an account assigned to that customer, and can further identify the transaction card 300 associated with the customer's account. As described above, the account number 412 can include thousands of disposable virtual account numbers associated with the transaction card 300. The applet 408 of the transaction card 300 can be configured to manage account numbers 412 (e.g., select an account number 412, mark the selected account number 412 as used, and send the account number 412 to a mobile device for auto-fill by an auto-fill service).

[0051] Although the processor 402 and memory elements of the foregoing exemplary embodiments are described with reference to contact pads 304, the present disclosure is not limited thereto. It is understood that these elements may be implemented external to contact pads 304, or may be completely separate from contact pads 304, or may be implemented as additional elements in addition to the processor 402 and memory 404 elements disposed within the contact pads.

[0052] In some examples, the transaction card 300 may include one or more antennas 418. The one or more antennas 418 may be mounted within the transaction card 300 around the processing circuit 416 on the contact pad 304. For example, the one or more antennas 418 may be integral with the processing circuit 416, or the one or more antennas 418 may be used in conjunction with an external booster coil. As another example, the one or more antennas 418 may be external to the contact pad 304 and the processing circuit 416.

[0053] In one embodiment, the coil of the transaction card 300 can function as the secondary of an air-core transformer. The terminal can communicate with the transaction card 300 by cutting power or amplitude modulation. The transaction card 300 (e.g., contact card 116) can infer data transmitted from the terminal using a gap in the contactless card's power connection, which can be maintained functionally via one or more capacitors. The transaction card 300 can return communication by switching the load on the contactless card's coil, or by load modulation. Load modulation can be detected by interference with the terminal's coil. More generally, using the antenna 418, processor 402, and / or memory 404, the transaction card 300 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0054] As described above, transaction card 300 can be built on a software platform capable of running on a smart card or other device with limited memory, such as a JavaCard, and can securely execute one or more applications or applets. An applet 408 can be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. Applet 408 can 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 point-of-sale terminal), and generate an NDEF message containing a cryptographically secure OTP encoded as an NDEF text tag.

[0055] An example of an NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, one or more applets 408 can be configured to encode the OTP as a well-known type of text tag in NDEF Type 4. In some examples, an NDEF message may include one or more records. In addition to the OTP record, the applet 408 can be configured to add one or more static tag records.

[0056] In some examples, the one or more applets 408 can be configured to emulate an RFID tag. The RFID tag can include one or more polymorphic 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 the one or more applets 408, an NFC read of the tag can be processed, and the data can be transmitted to a server, such as a server for a banking system, where the data can be verified.

[0057] In some examples, transaction card 300 and the server may contain specific data so that the card can be properly identified. Transaction card 300 may include one or more unique identifiers (not shown). Each time a read operation is performed, counter 410 may be configured to increment. In some examples, each time data from transaction card 300 is read (e.g., by a mobile device), counter 410 is sent to the server for verification, which determines (as part of the verification) whether counter 410 equals the server's counter.

[0058] One or more counters 410 can be configured to prevent replay attacks. For example, if a ciphertext is captured and replayed, it is immediately rejected if the counter 410 is read, used, or otherwise passed on. If the counter 410 is unused, it can be replayed. In some examples, the counter incremented on the card is different from the counter incremented for the transaction. The transaction card 300 cannot determine the application transaction counter 410 because there is no communication between the applets 408 on the transaction card 300. In some examples, the transaction card 300 can include a first applet 440-1, which can be a transaction applet, and a second applet 440-2. Each applet 440-1 and 440-2 can include a respective counter 410.

[0059] In some examples, counter 410 may not be synchronized. In some examples, counter 410 may increment to account for accidental reads that initiate transactions, such as reads at an angle, but the application does not process counter 410. In some examples, NFC may be enabled when mobile device 10 wakes up, and device 110 may be configured to read available tags, but no action is taken in response to the read.

[0060] To keep the counter 410 synchronized, an application, such as a background application, may be run that detects when the device (e.g., computing device 104) wakes up, synchronizes with a banking system server that indicates the readings that occurred due to the detection, and then causes the counter to move forward. 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 410 may be configured to move forward. However, if within a different threshold, e.g., 10 or 1000, a request to perform resynchronization may be processed, which the user requests via one or more applications that the user taps, gestures, or otherwise indicates one or more times via the user's device. If the counter 410 increments in the proper sequence, the user may be notified.

[0061] The key diversification technique described herein with reference to counter 410, 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 limiting of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0062] During the transaction card 300 creation process, two encryption keys may be uniquely assigned per card. The encryption 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 transaction card 300. 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.

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

[0064] 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 over a series of reads, such that a card may be incremented sequentially by repeating 1, 3, 5, 2, 2, ... The specific sequence or algorithmic sequence may be defined during 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.

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

[0066] 5 is a timing diagram illustrating an example sequence for providing authenticated access in accordance with one or more embodiments of the present disclosure. Sequence flow 500 may include transaction card 300 and customer device 502, which may include application 504 and processor 506.

[0067] At line 510, the application 504 communicates with the transaction card 300 (e.g., after being brought near the transaction card 300). Communication between the application 504 and the transaction card 300 may include the transaction card 300 being sufficiently close to a card reader (not shown) of the customer device 502 to enable NFC data transfer between the application 504 and the transaction card 300.

[0068] At line 508, after communication is established between the customer device 502 and the transaction card 300, the transaction card 300 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the transaction card 300 is read by the application 504. In particular, this may occur upon a read, such as an NFC read of a Near Field Communication (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader application, such as application 504, may send a message, such as an applet select message, using the applet ID of the NDEF generation applet. Upon confirming the selection, a series of select file messages followed by read file messages may be sent. For example, a sequence may include "select capabilities file," "read capabilities file," and "select NDEF file." At this point, a counter value maintained by the transaction card 300 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 can be created from a message, which may include a header and a shared secret. The MAC ciphertext can then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) can be encrypted with a session key. The ciphertext and header can then be concatenated, encoded as ASCII hex, and returned in the NDEF message format (in response to a "Read NDEF file" message).

[0069] In some examples, the MAC cryptogram may be transmitted as an NDEF tag, and in other examples, the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string). In some examples, the application 504 may be configured to send a request to the transaction card 300, the request including instructions to generate the MAC cryptogram.

[0070] At line 512, transaction card 300 transmits the MAC cryptogram to application 504. In some embodiments, transmission of the MAC cryptogram occurs via NFC, although the disclosure is not limited thereto. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means. At line 514, application 504 communicates the MAC cryptogram to processor 506.

[0071] At line 516, processor 506 verifies the MAC ciphertext according to instructions from application 122. For example, the MAC ciphertext may be verified as described below. In some examples, verification of the MAC ciphertext may be performed by a device other than customer device 502, such as a server of a banking system in data communication with customer device 502. For example, processor 506 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.

[0072] FIG. 6 illustrates an NDEF short record layout (SR=1) data structure 600 according to an example embodiment. One or more applets can be configured to encode the OTP as an NDEF Type 4 well-known type text tag. In some examples, an NDEF message may include one or more records. An applet can be configured to add one or more static tag records in addition to the OTP record. Example tags include, but are not limited to: tag type: well-known type, text, encoding English (en); applet ID: D2760000850101; capability: read-only access; encoding: authentication message, which may be encoded as ASCII hex; and type-length-value (TLV) data, which may be provided as personalization parameters that may be used to generate the NDEF message. In one embodiment, an authentication template may include a first record with a well-known index that provides the actual dynamic authentication data.

[0073] 7 illustrates one embodiment of a logic flow 700 that may represent operations that may be performed in various embodiments in conjunction with the techniques disclosed herein. Logic flow 700 may represent some or all of the operations that may be performed by one or more components / devices / environments described herein, such as one or more of contactless cards 116, 216, computing devices 104, 204, back-end servers 124, 224, key management services 130, 230, and hardware security modules 132, 232.

[0074] In the illustrated embodiment, logic flow 700 may begin at block 702. At block 702, a user may be authenticated based on credentials received via a user interface. For example, the user may be authenticated based on credentials received via a user interface 110 of the computing device 104. Continuing to block 704, logic flow 700 includes receiving a cryptogram from a contactless card in proximity to the computing device. For example, cryptogram 122 received from contactless card 116 may be detected by an application 114 executing on the computing device or mobile device. Continuing to block 706, logic flow 700 includes determining, based on authentication of the cryptogram, that the contactless card is associated with the user. For example, backend server 124 may determine, based on authentication of cryptogram 122, that the contactless card 116 is associated with the user logging into application 114. In some embodiments, the association may be communicated from backend server 124 to computing device 104 at verification 156.

[0075] At block 708, logic flow 700 includes presenting, via a user interface, a current personal identification number (PIN) associated with the contactless card based on user authentication and cryptogram authentication. The current PIN may be associated with the contactless card and presented via a user interface based on user authentication and cryptogram authentication. For example, the current PIN may be presented via user interface 110 of computing device 104 based on user authentication based on login credentials 154 and cryptogram 122.

[0076] At block 710, logic flow 700 includes determining to change a current PIN associated with a contactless card to a new or different PIN from the current PIN associated with the contactless card. For example, application 214 may determine to change PIN 244 associated with contactless card 216 to an updated PIN based on input received via user interface 210. At block 712, logic flow 700 includes identifying an updated PIN based on input received via the user interface, where the updated PIN may be identified based on the input received via the user interface. For example, updated PIN 222 may be determined based on input received via user interface 210.

[0077] At block 714, the logic flow 700 includes communicating the updated PIN to a server to associate the updated PIN with the contactless card, where the updated PIN may be communicated to a server to associate the updated PIN with the contactless card. For example, the computing device 204 may communicate the updated PIN 222 to the backend server 224 over the network 242 to associate the updated PIN 222 with the contactless card 216.

[0078] At block 716, logic flow 700 includes identifying a PIN script received from the server in response to communication of the updated PIN to the server, where the PIN script received from the server can be identified in response to communication of the updated PIN to the server. For example, PIN script 258 can be identified by application 214 in response to communication of updated PIN 222 to backend server 224. As will be appreciated, updated PIN 222 can be received as part of a larger data package sent from computing device 204 to backend server 224. Continuing to block 718, logic flow 700 includes communicating the PIN script to the contactless card to change the PIN stored on the contactless card from the current PIN to the updated PIN. The PIN script can be communicated to the contactless card to change the PIN stored on the contactless card from the current PIN to the updated PIN. For example, the computing device 204 can communicate the PIN script 258 to the contactless card 216 to change the PIN 244 stored in the memory 218 of the contactless card 216 from the current PIN to the updated PIN 222 .

[0079] FIG. 8 illustrates an example routine 800 that may be implemented by a contactless card according to embodiments described herein.

[0080] At block 802, the routine 800 includes receiving, by the contactless card, a request for identifying information from a computing device. For example, the contactless card may receive a request for authentication from a computing device, such as a mobile device, as part of an NFC exchange. The identifying information may include a customer identifier or token, as described herein, that may be configured to uniquely identify the contactless card (and associated user).

[0081] At block 804, the routine 800 includes generating, by the contactless card, a ciphertext that includes the identification information. As described herein, the ciphertext may be generated to include the identification information and encrypted by applying a cryptographic algorithm. In some cases, the cryptographic algorithm may utilize a session key that is generated based on at least the contactless card's master key and a counter value. Further, at block 806, the routine 800 includes communicating, by the contactless card, the ciphertext to a computing device.

[0082] The computing device can receive the cryptogram and transmit the cryptogram to one or more backend servers to authenticate the identity and contactless card. If authenticated and the user successfully logs into an application on the computing device, the user may be permitted to perform one or more operations, including updating the contactless PIN. In response to the user selecting to update the PIN, the computing device can communicate and perform one or more operations to update the current PIN to a new PIN on the backend server, as described herein.

[0083] In embodiments, the backend server can generate a script or set of instructions or actions that can then be communicated to the contactless card. The script can cause the contactless card to update the PIN. For example, the script can include information such as a new PIN and one or more instructions that cause the contactless card to write the new PIN to memory associated with the current PIN. Embodiments are not so limited. For example, the instructions can include authentication instructions that can be utilized by the contactless card to authenticate the script. The backend server can send the script (PIN script) to a computing device for further communication with the contactless card. In some cases, the backend server can encrypt the script using an encryption algorithm. In one example, the backend server can utilize a session key that is used to authenticate the ciphertext.

[0084] At block 808, the routine 800 includes receiving, by the contactless card, a PIN script from the computing device. As described, the PIN script may include one or more instructions configured to cause the contactless card to change the current PIN to a new PIN. In some cases, the contactless card may first decrypt the PIN script by utilizing the session key used to generate the ciphertext.

[0085] At block 810, the routine 800 includes causing the contactless card to change the current PIN to a new PIN based on a PIN script. For example, the PIN script may cause the new PIN to be written to a memory location that stores PINs, such as the memory location associated with the current PIN.

[0086] 9 illustrates an embodiment of an exemplary computer architecture 900 suitable for implementing various embodiments as described above. In one embodiment, computer architecture 900 may include or be implemented as part of one or more systems or devices described herein, such as a computing device or back-end server.

[0087] As used herein, the terms “system” and “component” are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing computer architecture 900. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and components may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to each other by various types of communication media to coordinate operations. Coordination may include unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over the communication media. Information may be implemented as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages can be transmitted over a variety of connections, with exemplary connections including parallel interfaces, serial interfaces, and bus interfaces.

[0088] Computing architecture 100 may include various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation with computing architecture 100.

[0089] 9, computing architecture 100 includes a processor 912, a system memory 904, and a system bus 906. Processor 912 may be any of various commercially available processors.

[0090] The system bus 906 provides an interface to the processor 912 for system components, including, but not limited to, the system memory 904. The system bus 906 can be any of several types of bus structures that can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to the system bus 608 through a slot architecture. Exemplary slot architectures can include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0091] Computing architecture 100 may include or be implemented in a variety of articles of manufacture. An article of manufacture may include a computer-readable storage medium that stores logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. Embodiments may also be implemented at least in part as instructions contained in or on a non-transitory computer-readable medium that may be read and executed by one or more processors to enable performance of the operations described herein.

[0092] The system memory 904 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drives (SSDs), and any other type of storage medium suitable for storing information. In the illustrated embodiment shown in FIG. 9 , the system memory 904 may include non-volatile memory 908 and / or volatile memory 910. A basic input / output system (BIOS) may be stored in the non-volatile memory 908.

[0093] The computer 902 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive 930, a magnetic disk drive 916 that reads from and writes to a removable magnetic disk 920, and an optical disk drive 928 that reads from and writes to a removable optical disk 932 (e.g., a CD-ROM or DVD). The hard disk drive 930, the magnetic disk drive 916, and the optical disk drive 928 may be connected to the system bus 906 by an HDD interface 914, a FDD interface 918, and an optical disk drive interface 934, respectively. The HDD interface 914 of an external drive implementation may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0094] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. A number of program modules can be stored in the drives and nonvolatile memory 908, as well as in volatile memory 910, including, for example, an operating system 922, one or more applications 942, other program modules 924, and program data 926. In one embodiment, the one or more applications 942, other program modules 924, and program data 926 can include, for example, various applications and / or components of the systems described herein.

[0095] A user can enter commands and information into the computer 902 through one or more wired / wireless input devices, such as a keyboard 950 and a pointing device such as a mouse 952. Other input devices can include a microphone, infrared (IR) remote, radio frequency (RF) remote, game pad, stylus pen, card reader, dongle, fingerprint reader, glove, graphics tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), trackball, track pad, sensor, stylus, etc. These and other input devices are often connected to the processor 912 through an input device interface 936 coupled to the system bus 906, but can be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0096] A monitor 944 or other type of display device is also connected to the system bus 906 via an interface, such as a video adapter 946. The monitor 944 may be internal or external to the computer 902. In addition to the monitor 944, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0097] The computer 902 can operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as a remote computer 948. The remote computer 948 can be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment appliance, a peer device, or other common network node, and typically includes many or all of the elements described relative to the computer 902, although for purposes of brevity, only a memory and / or storage device 958 is shown. The logical connections shown include wired / wireless connections to a local area network 956 and / or larger networks, e.g., a wide area network 954. Such LAN and WAN networking environments are commonplace in offices and businesses and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet.

[0098] When used in a local area network 956 networking environment, the computer 902 is connected to the local area network 956 through a wired and / or wireless communication network interface or adapter 938. The network adapter 938 can facilitate wired and / or wireless communication to the local area network 956, and the local area network may also include a wireless access point disposed thereon to communicate with the wireless functionality of the network adapter 938.

[0099] When used in a networked environment of a wide area network 954, the computer 902 may include a modem 940, or be connected to a communication server on the wide area network 954, or have other means of establishing communications over the wide area network 954, such as via the Internet. The modem 940, which may be an internal or external wired and / or wireless device, connects to the system bus 906 via the input device interface 936. In a networked environment, program modules depicted relative to the computer 902, or portions thereof, may be stored in the remote memory and / or storage device 958. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computers may be used.

[0100] The computer 902 is operable to communicate with wired and wireless devices or entities using standards from the IEEE 802 family, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.11 wireless modulation techniques). This includes at least Wi-Fi (i.e., Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, communication can be in a predefined structure, similar to a traditional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, and high-speed wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3-related media and functions).

[0101] The various elements of devices such as those described herein may include various hardware elements, software elements, or a combination of both. Examples of hardware elements include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as the desired computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints desired for a given implementation.

[0102] The components and features of the devices described above may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Furthermore, device features may, where appropriate, be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the foregoing. Note that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuitry."

[0103] 10 is a block diagram illustrating an exemplary communications architecture 1000 suitable for implementing various embodiments as described above. Communications architecture 1000 includes various common communications elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, implementations are not limited to implementations with communications architecture 1000 that may be consistent with the systems and devices described herein.

[0104] 10, communication architecture 1000 includes one or more clients 1002 and servers 1004. The servers 1004 may implement one or more features and embodiments described herein. The clients 1002 and servers 1004 are operatively connected to one or more respective client data store(s) 1006 and server data store(s) 1008 that may be employed to store information local to the respective clients 1002 and servers 1004, such as cookie(s) and / or associated contextual information.

[0105] The clients 1002 and the servers 1004 can communicate information with each other using a communication framework 1010. The communication framework 1010 can implement any well-known communication technology and protocol. The communication framework 1010 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet, etc.), a circuit-switched network (e.g., the public switched telephone network), or a combination of packet-switched and circuit-switched networks (with appropriate gateways and converters).

[0106] The communications framework 1010 can implement various network interfaces configured to accept, communicate, and connect to communications networks. A network interface can be considered a specialized form of input / output (I / O) interface. The network interfaces can use connection protocols including, but not limited to, direct connect, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.7a-x network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, etc. Furthermore, multiple network interfaces can be used to participate in various communications network types. For example, multiple network interfaces can be used to enable communications over broadcast, multicast, and unicast networks. When processing requirements demand greater amounts of speed and capacity, a distributed network controller architecture can similarly be used to pool and distribute load and otherwise increase the communications bandwidth needed by the clients 1002 and servers 1004. The communications network may be any one and combination of wired and / or wireless networks, including, but not limited to, direct interconnections, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operating missions as nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communications networks.

[0107] Referring to FIGS. 1A to 8, the various elements of the device as described above can include various hardware elements, software elements, or combinations of both. Examples of hardware elements can include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (such as transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chip sets, etc. Examples of software elements can include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as the desired computational speed, power level, heat tolerance, processing cycle budget, input data speed, output data speed, memory resources, data bus speed, and other design or performance constraints desired for a given implementation.

[0108] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic within a processor, which, when read by a machine, causes the machine to create logic that implements the techniques described herein. Such representations, known as “IP cores,” may be stored on tangible machine-readable media and supplied to various customers or manufacturing facilities for loading into manufacturing machines that implement the logic or processor. Some embodiments may be implemented using, for example, a machine-readable medium or article that may store instructions or sets of instructions that, when executed by the machine, cause the machine to perform methods and / or operations in accordance with embodiments. Such machines may include, for example, any suitable processing platform, computing platform, computer apparatus, processing device, computer system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, e.g., memory, removable or non-removable medium, erasable or non-erasable medium, writable or rewritable medium, digital or analog medium, hard disk, floppy disk, compact disk read-only memory (CD-ROM), recordable compact disk (CD-R), rewritable compact disk (CD-RW), optical disk, magnetic medium, magneto-optical medium, removable memory card or disk, various types of digital versatile disks (DVD), tape, cassette, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0109] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the appended claims. Future applications claiming priority to this application may claim the disclosed subject matter differently and may generally include any set of one or more limitations variously disclosed or otherwise demonstrated herein.

Claims

1. a processor; When executed by the processor, the processor: authenticating a user based on credentials received via a user interface; detecting a cryptogram received from a contactless card in proximity to said processor; determining, based on authentication of the cryptogram, that the contactless card is associated with the user; submitting, via the user interface, a current personal identification number (PIN) associated with the contactless card based on authentication of the user and authentication of the cryptogram; determining to change the current PIN associated with the contactless card to an updated PIN; identifying the updated PIN based on input received via the user interface; communicating the updated PIN to a server to associate the updated PIN with the contactless card; identifying a PIN script received from the server in response to communication of the updated PIN to the server; and communicating the PIN script to the contactless card to change the PIN stored on the contactless card from the current PIN to the updated PIN; a memory containing instructions for causing the An apparatus comprising:

2. The apparatus of claim 1 , wherein a mobile device comprises the processor and the memory, and the cryptogram is received from the contactless card via near field communication.

3. 2. The apparatus of claim 1, wherein the instructions, when executed by the processor, further cause the processor to communicate the ciphertext to the server and receive verification from the server to authenticate the ciphertext.

4. The apparatus of claim 1 , wherein the instructions, when executed by the processor, further cause the processor to encrypt the updated PIN for communication to the server.

5. 5. The apparatus of claim 4, wherein the instructions, when executed by the processor, further cause the processor to encrypt the updated PIN based on a unique identifier (UID) received from the contactless card.

6. 6. The apparatus of claim 5, wherein the instructions, when executed by the processor, further cause the processor to generate a session key using the UID and encrypt the updated PIN based on the UID.

7. The apparatus of claim 1 , wherein the instructions, when executed by the processor, further cause the processor to authenticate the PIN script based on a message authentication code (MAC) received from the server.

8. The apparatus of claim 7 , wherein the instructions, when executed by the processor, further cause the processor to utilize an integrity key to authenticate the PIN script based on the MAC received from the server.

9. In response to being executed by the processor circuit, authenticating a user based on credentials received via a user interface; detecting a cryptogram received from a contactless card in proximity to said processor; determining, based on authentication of the cryptogram, that the contactless card is associated with the user; submitting, via the user interface, a current personal identification number (PIN) associated with the contactless card based on authentication of the user and authentication of the cryptogram; determining to change the current PIN associated with the contactless card to an updated PIN; identifying the updated PIN based on input received via the user interface; communicating the updated PIN to a server to associate the updated PIN with the contactless card; identifying a PIN script received from the server in response to communication of the updated PIN to the server; and communicating the PIN script to the contactless card to change the PIN stored on the contactless card from the current PIN to the updated PIN; At least one non-transitory computer-readable medium comprising a set of instructions for causing the

10. 10. The at least one non-transitory computer-readable medium of claim 9, wherein the set of instructions, in response to execution by the processor circuit, further causes the processor circuit to communicate the ciphertext to the server and receive verification from the server to authenticate the ciphertext.

11. 10. The at least one non-transitory computer-readable medium of claim 9, wherein the set of instructions, in response to execution by the processor circuit, further causes the processor circuit to encrypt the updated PIN for communication to the server.

12. 12. The at least one non-transitory computer-readable medium of claim 11, wherein the set of instructions, in response to execution by the processor circuit, further causes the processor circuit to encrypt the updated PIN based on a unique identifier (UID) received from the contactless card.

13. 13. The at least one non-transitory computer-readable medium of claim 12, wherein the set of instructions, in response to execution by the processor circuit, further causes the processor circuit to generate a session key using the UID and encrypt the updated PIN based on the UID.

14. 10. The at least one non-transitory computer-readable medium of claim 9, wherein the set of instructions, in response to execution by the processor circuit, further causes the processor circuit to authenticate the PIN script based on a message authentication code (MAC) received from the server.

15. 15. The at least one non-transitory computer-readable medium of claim 14, wherein the set of instructions, in response to execution by the processor circuit, further causes the processor circuit to utilize an integrated key to authenticate the PIN script based on the MAC received from the server.

16. authenticating a user based on credentials received via a user interface; detecting the ciphertext received from the contactless card; determining, based on authentication of the cryptogram, that the contactless card is associated with the user; submitting, via the user interface, a current personal identification number (PIN) associated with the contactless card based on authentication of the user and authentication of the cryptogram; determining to change the current PIN associated with the contactless card to an updated PIN; identifying the updated PIN based on input received via the user interface; communicating the updated PIN to a server to associate the updated PIN with the contactless card; identifying a PIN script received from the server in response to communication of the updated PIN to the server; communicating the PIN script to the contactless card to change the PIN stored on the contactless card from the current PIN to the updated PIN; A computer-implemented method comprising:

17. 17. The computer-implemented method of claim 16, comprising encrypting the updated PIN for communication to the server.

18. 20. The computer-implemented method of claim 17, comprising encrypting the updated PIN based on a unique identifier (UID) received from the contactless card.

19. 20. The computer-implemented method of claim 18, comprising generating a session key using the UID to encrypt the updated PIN based on the UID.

20. 17. The computer-implemented method of claim 16, comprising authenticating the PIN script based on a message authentication code received from the server.

Images