Techniques for securely communicating sensitive data for radically different data messages

Abstract

This disclosure describes techniques for securely communicating sensitive data for radically distinct data messages. Systems and methods for securely communicating sensitive data, such as identifiers, are disclosed. A user device may receive a first message including a terminal type indicator. For certain values of the terminal type indicator, the user device may be configured to transmit a request message including a first identifier and an encrypted identifier. For other values of the terminal type indicator, the user device may be configured to generate a fuzzy identifier based at least in part on a first portion of a second identifier and a second portion of the encrypted identifier. The user device may then transmit a request message including the fuzzy identifier and the encrypted identifier.

Description

[0001] This application is a divisional application of the PCT international application number PCT / US2018 / 055833, the international application date of October 15, 2018, the application number 201880098694.3 entering the Chinese national phase, and the application titled "Technology for securely transmitting sensitive data for fundamentally different data messages". Background Art

[0002] Embodiments of the present disclosure relate to obfuscating sensitive data in messages used in transactions. These techniques can be applied to contact and / or contactless smart card transactions. Generally speaking, contactless smart cards are intended to provide customers with efficient payment methods. Smart cards are able to provide the required information to a point of sale (POS) device in order to complete a transaction by using, for example, radio frequency or infrared signals. The POS device receives the provided information and can process the transaction.

[0003] The information sent by the smart card may include sensitive data, such as a user's account identifier (e.g., a personal account number). Therefore, security measures are needed to protect the user from sophisticated fraudsters who may intercept this information. Current technology may be problematic because the entire account identifier is unencrypted. In other conventional technologies, the account identifier may be encrypted, but still transmitted and / or provided according to a known protocol with a known data field. A smart fraudster can still easily identify the encrypted data field in the message and is therefore more likely to use the information for his or her nefarious behavior. In addition, using conventional technology, the account identifier may remain static, potentially allowing a fraudster to track the user's transactions.

[0004] Furthermore, conventional systems do not restrict the use of sensitive information. For example, once a fraudster has obtained sensitive information, the sensitive information can be exploited in a variety of contexts.

[0005] Embodiments of the present invention address these and other problems individually and collectively. Summary of the invention

[0006] Embodiments of the present invention relate to methods, systems, devices, and computer-readable media that can be used to securely transmit an account identifier (e.g., PAN) associated with a user device such as a contactless smart card. In some embodiments, the user device can store a primary account number (PAN) and a secondary account number (SAN). The account identifier (e.g., PAN) can be transmitted in a manner that does not allow tracking of the account identifier for privacy protection. Advantageously, in embodiments of the present invention, the account information is transmitted in a manner that is secure and does not require updating the existing payment infrastructure in any significant manner.

[0007] In contexts where static identifiers are required, additional account identifiers (e.g., SANs) may be utilized in embodiments discussed herein. As an example, it is contemplated that some types of access devices allow or deny a user access to a resource in near real time. Therefore, such access devices may utilize static identifiers to check against an allow list and / or a block list in order to quickly allow or deny a user access to a smart card. Additional account identifiers (e.g., SANs) may be utilized only in certain circumstances. For example, a system may ensure that a SAN is only usable in transactions involving terminals and / or merchants and / or specific types of transactions. As a non-limiting example, a system may be configured to ensure that a SAN is only utilized in transactions involving transit terminals (e.g., turnstiles at transit agencies).

[0008] One embodiment of the present invention relates to a method comprising receiving, by a user device, a first message including a terminal type indicator from an access device. The method may also include, in response to the terminal type indicator indicating a first terminal type, sending a request message including a first identifier (e.g., a SAN) and an encrypted identifier (e.g., an encrypted identifier generated from a PAN and a transaction counter) from the user device to the access device. The method may also include, in response to the terminal type indicator indicating a second terminal type, generating, by the user device, an obfuscated identifier based at least in part on a first portion of a second identifier (e.g., a primary PAN) and a second portion of the encrypted identifier. The method may also include transmitting from the user device to the access device. In some embodiments, the request message may include the obfuscated identifier and the encrypted identifier.

[0009] Another embodiment of the present invention relates to a user device, the user device comprising: one or more processors; and one or more memories, the one or more memories comprising computer executable instructions, which when executed by the one or more processors cause the user device to perform operations. The operations may include receiving, by the user device, a first message including a terminal type indicator from an access device. The operations may also include, in response to the terminal type indicator indicating a first terminal type, sending a request message including a first identifier (e.g., SAN) and an encrypted identifier (e.g., an encrypted identifier generated from a primary PAN and a transaction counter) from the user device to the access device. The operations may also include, in response to the terminal type indicator indicating a second terminal type, generating, by the user device, an obfuscated identifier based at least in part on a first portion of a second identifier (e.g., primary PAN) and a second portion of the encrypted identifier. The operations may also include transmitting from the user device to the access device. In some embodiments, the request message may include the obfuscated identifier and the encrypted identifier.

[0010] Another embodiment of the present invention relates to a (non-transitory) computer-readable medium. The computer-readable medium includes code for executing the method discussed herein. In some embodiments, a user device such as a smart card may include such a computer-readable medium.

[0011] These and other embodiments of the invention are described in further detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A block diagram of a system for processing transactions is shown according to some embodiments.

[0013] Figure 2 Methods for generating and storing data at a user device according to some embodiments are described.

[0014] Figure 3 Depicted are methods for generating a unique derived key from data residing on a computing device (eg, a smart card) according to some implementations.

[0015] Figure 4 Described are methods for performing offline authentication according to some embodiments.

[0016] Figure 5 A flow chart illustrating a method for securely transmitting sensitive data according to some embodiments.

[0017] Figure 6 An exemplary record format for use in some embodiments is depicted.

[0018] Figure 7 Another exemplary recording format for use in some embodiments is depicted.

[0019] Figure 8 A flowchart of a method for performing data validation according to some embodiments is shown.

[0020] Fig. 9 A flowchart of a method for performing data validation according to some embodiments is shown. DETAILED DESCRIPTION

[0021] As described above, in conventional payment transactions, an account identifier (e.g., a personal account identifier, also referred to as a primary PAN) is not encrypted as it passes from a user device such as a contactless smart card to an access device (e.g., a POS terminal, a turnstile reader, etc.) and ultimately through a conventional payment processing network. In some conventional techniques, the account identifier may be encrypted and / or obfuscated, however, the encrypted / obfuscated data may still be provided in a conventional data field of a transaction message, which can therefore easily identify a potential fraudster.

[0022] Although the entire account identifier can be encrypted, it is not feasible in all cases. If the account identifier is encrypted, the conventional transaction processing system may not be able to successfully process the transaction. For example, a typical account identifier includes a bank identification number (BIN). The BIN is used to route the authorization request message to the appropriate issuer or payment processor. If the account identifier is encrypted, the BIN will change. If the BIN changes, the appropriate authorization request message cannot be routed to the correct issuer.

[0023] Another limitation associated with encrypting the entire account identifier relates to error checking associated with the sequence of digits in the account identifier. Error checking can be implemented using a checksum algorithm that determines whether the digits of the account identifier are in the proper sequence. An example checksum algorithm is the modulo 10 algorithm (also known as the "Luhn check").

[0024] Therefore, encrypting the entire account identifier destroys at least the BIN, the checksum, and the ability to identify the account identifier by the printed digits on the receipt.

[0025] The processing described herein can be used to protect an account identifier at an originating device (e.g., a smart card). As will be described in further detail below, embodiments of the present invention only obfuscate a portion of an account identifier, which allows the BIN of the account to remain unencrypted and continue to use the Luhn check. In addition, embodiments of the present invention can also be used not only to obfuscate an account identifier in a typical authorization request message, but also to ensure that the entire encrypted account identifier is provided elsewhere in the message so that the message is less likely to be identified.

[0026] The techniques discussed herein also enable obfuscated identifiers or SANs to be utilized by a user device depending on the context of the transaction (e.g., what type of terminal is requesting information). Thus, for transactions associated with a first set of transaction types, terminal types, etc., an obfuscated PAN may be utilized in the transaction, whereas for transactions associated with a second set of transaction types, terminal types, etc., a SAN may be utilized. When a SAN is utilized in a permitted context, it may be restricted to processing by authorized entities only. For first set of transactions / terminal type transactions, an obfuscated PAN may be utilized so that the user's activities cannot be tracked. These techniques enable the utilization of static identifiers for offline transactions (e.g., transactions where a terminal authenticates a smart card at the terminal) and subsequent online transactions derived from offline transactions, whereas dynamic identifiers (e.g., dynamic values) may be utilized for online authentication transactions that do not require offline authentication of the other party.

[0027] Before discussing specific embodiments of the invention, some description of certain terminology may be helpful.

[0028] A "computing device" (also referred to as a "user device") may be any suitable device capable of performing computations and capable of communicating with other devices. Portable consumer devices such as smart cards are examples of computing devices. Other types of computing devices may not be portable.

[0029] A "dynamic value" refers to a dynamically changing value. A computing device can maintain various dynamic values. An example of a dynamic value is an application transaction counter (ATC). The ATC can initially be set to a predetermined value by the issuer of the computing device (e.g., an authorized entity). Thereafter, the ATC can be incremented with each transaction. Alternatively, the ATC can be decremented from its initial predetermined value with each transaction. The ATC can be a value of any length. In addition, the issuer can maintain a corresponding ATC for access by the issuer computer. This corresponding ATC can be used to identify payment services that may be repeated for fraudulent purposes. In alternative embodiments, a password, digital signature, or hash value based on transaction data can be used to replace the ATC stored at the computing device, or used together with the ATC stored at the computing device.

[0030] Examples of other dynamic values ​​(e.g., data elements) may include time of day, current transaction amount, and randomly generated numbers from the terminal, etc. Data elements are dynamic, meaning that they may change with each transaction or nearly with each transaction. Dynamic data elements may be associated with a user's computing device and / or may be generally associated with the user.

[0031] An "authorized entity" may be an entity that authorizes a request. Examples of authorized entities may be issuers, government agencies, file repositories, access administrators, etc. An "issuer" may generally refer to a business entity that maintains a user account (e.g., a bank). An issuer may also issue a payment credential to a customer that is stored on a user device such as a cell phone, smart card, tablet computer, or laptop computer. An "authorized entity computer" may be operated by or on behalf of an authorized entity.

[0032] An "acquirer" may generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform both issuer and acquirer functions. Some embodiments may encompass such a single entity, issuer-acquirer. An acquirer may operate an acquirer computer, which may also be generally referred to as a "transmitting computer."

[0033] A "resource provider" may be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, access devices, secure data access points, etc. A "merchant" may generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services. A "resource provider computer" may be any suitable computing device that can be operated by or on behalf of a resource provider.

[0034] A "processing network computer" (also referred to as a central server computer) may include a server computer for processing network data. In some embodiments, the processing network computer may be coupled to a database and may include any hardware, software, other logic, or a combination of the foregoing items for servicing requests from one or more client computers. The processing network computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to serve requests from one or more client computers. In some embodiments, the processing network computer may operate multiple server computers. In such embodiments, each server computer may be configured to process transactions in a given area or to process transactions of a specific type based on transaction data.

[0035] The processing network computer may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception document services, and clearing and settlement services. Exemplary processing network computers may include VisaNet TM . Including VisaNet TM The network includes the ability to process credit card transactions, debit card transactions and other types of commercial transactions. VisaNet TM Specifically include the integrated payment system (integrated payment system) that processes authorization requests and the BaseII system that performs clearing and settlement services. The processing network computer can use any suitable wired or wireless network, including the Internet.

[0036] An "authorization request message" may be an electronic message sent to a transaction processing computer and / or an authorization entity computer (e.g., the issuer of a payment card) to request authorization of a transaction. The authorization request message according to some embodiments may comply with ISO8583, which is a standard for systems for exchanging electronic transaction information associated with payments made by customers using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information", including, by way of example only: service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be used to determine whether to identify and / or authorize the transaction.

[0037] An "authorization response message" may be an electronic message reply to an authorization request message generated by an authorization entity computer or a transaction processing computer. By way of example only, the authorization response message may include one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. The authorization response message may also include an authorization code, which may be a code that the authorization entity (e.g., an issuer bank) transmits back to the resource provider computer in response to the authorization request message in an electronic message (either directly or through a transaction processing computer) indicating that the transaction is approved. The code may serve as proof of authorization. In some embodiments, the transaction processing computer may generate or forward the authorization response message to the resource provider.

[0038] A "primary account number" (PAN) may be an identifier for a payment account. A PAN may include a series of alphanumeric characters (e.g., 16). A PAN (or an obfuscated or encrypted version of a PAN) may be used to initiate, authorize, settle, or resolve a payment transaction. In some embodiments, a PAN may be utilized for any type of transaction.

[0039] A "-account number" (SAN) may be another identifier for a payment account. The SAN may include a series of alphanumeric characters (e.g., 16). The SAN (or an obfuscated or encrypted version of the SAN) may be used to initiate, authorize, settle, or resolve a transaction. In some embodiments, the use of the SAN may be limited to certain types of transactions. For example, the SAN may be utilized when a transaction includes a particular type of merchant (e.g., a transit agency, a transit merchant, a stadium merchant, etc.), when a transaction is initiated by a terminal of a particular terminal type (e.g., a turnstile, etc.), and / or when a transaction is a particular type of transaction (e.g., a transit transaction, a fare check transaction, etc.). In some embodiments, the SAN may be associated with the PAN and both may be associated with a particular user's account (e.g., a financial account maintained by an issuer on behalf of the user). In some embodiments, the PAN and the associated SAN may each include the same 8 leftmost digits (e.g., corresponding to a bank identification number (BIN)).

[0040] An "obfuscated identifier" may include an identifier that is an obfuscated version of an identifier (e.g., a 16-bit PAN). In some embodiments, the obfuscated identifier may be "format-preserving" and may have a numeric format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the obfuscated identifier may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction, or to represent an original document in other systems where an original document would normally be presented.

[0041] An "encrypted identifier" may include any suitable encrypted value. The encrypted value may be generated from an identifier (e.g., a primary PAN) using any suitable encryption technique, such as using symmetric and / or asymmetric encryption techniques. In some embodiments, the encrypted identifier may be generated using a primary PAN and a dynamic value, both stored at a user device.

[0042] For purposes of this application, "payment data" may include: those data elements used by the payment service to perform transactions with respect to financial applications, and any necessary data elements not including the present invention with respect to non-financial transactions. For example, when the payment service is a magnetic stripe credit card transaction, "payment data" will include track 1 and / or track 2 data as understood by a person of ordinary skill in the credit card industry, such as a primary account number, expiration date, service code, and discretionary data. "Payment data" may also include a unique card identification number or a unique identification number of a service provider. Payment data may reside in a memory located on a user device (e.g., a credit and / or debit card, a smart card, etc.).

[0043] A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers acting as a unit. In one example, a server computer may be a database server coupled to a network server.

[0044] "Processor" may refer to any suitable one or more data computing devices. A processor may include one or more microprocessors working together to perform the desired functions. A processor may include a CPU including at least one high-speed data processor sufficient to execute program components for executing user and / or system generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0045] "Memory" may be any suitable device or devices that can store electronic data. Suitable memory may include non-transitory computer-readable media that stores instructions executable by a processor to implement the desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic operating modes.

[0046] Figure 1 A block diagram of a system 100 for processing transactions according to some embodiments is shown. The system 100 may be used to facilitate Figure 1 The system 100 includes a user device 102, a resource provider computer 104, a transmission computer 106, a central server computer 108, and an authorization entity computer 110. Each of these systems and computers can be in operative communication with each other. Figure 1 Specific numbers of components are shown in the drawings. However, it should be understood that embodiments of the present invention may include more than one of each component. In addition, some embodiments of the present invention may include more than one of each component. Figure 1 All components shown in the figure are less or more than the components. In addition, Figure 1 The components in may communicate using any suitable communication protocol over any suitable communication medium, including the Internet.

[0047] The resource provider computer 104 may be operated by or on behalf of a resource provider (e.g., a merchant, a transit system, etc.), and the transmission computer may be associated with the resource provider. For example, the transmission computer may be operated by an acquirer (e.g., a financial institution) responsible for managing an account associated with the resource provider. The authorization entity computer 110 may be operated by an issuer (e.g., another financial institution). In some embodiments, the entity is both an acquirer and an issuer, and embodiments of the present invention include such entities.

[0048] The user device 102 may be in any suitable form. For example, the user device 102 may be handheld and compact, such that it can fit into a wallet and / or pocket. Examples of the user device 102 may include smart cards, credit and / or debit cards, key chain devices, and the like. Other examples of the user device 102 may include a cellular phone, a personal digital assistant (PDA), a pager, a payment card, a security card, an access card, smart media, a transponder, and the like. The user device 102 may also be a stored value card for storing retail store credit, and the like.

[0049] The user device 102 may include a computer readable medium (CRM) 112 and a body 114. The CRM 112 may be located on the body 114, which may be in the form of a plastic substrate, a housing, or other structure. If the user device 102 is in the form of a card, it may have an embossed area 116 with a personal account number (PAN) embossed therein. In some embodiments, the CRM 112 may store the PAN as well as a secondary account number (e.g., SAN) and / or a counter.

[0050] The computer readable medium 112 may be a memory that stores data and may be in any suitable form. An exemplary CRM 112 may be in the form of a magnetic strip, a memory chip, etc. The computer readable medium 112 may electronically store the master and / or encrypted and / or obfuscated PAN in encrypted or unencrypted form.

[0051] The central server computer 108 may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. Exemplary payment processing networks may include VisaNet TM For example, VisaNet TM Payment processing networks such as VisaNet can process credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, it includes the VIP system (Visa Integrated Payment System) that processes authorization requests, and the Base 11 system that performs clearing and settlement services.

[0052] The central server computer 108 may include a server computer. A server computer is typically a powerful computer or computer cluster. For example, a server computer may be a large mainframe, a small computer cluster, or a group of servers acting as a unit. In one example, the server computer may be a database server coupled to a network server. The central server computer 108 may use any suitable wired or wireless network, including the Internet.

[0053] The resource provider computer 104 may also have an access device 118 (e.g., a turnstile, door, point-of-sale terminal, etc.) that is capable of interacting with the user device 102, or receiving communications therefrom. Figure 1 In some embodiments, the access device 118 may be a component of the resource provider computer 104 and / or the access device 118 may be accessed by the resource provider computer and / or communicate with the resource provider computer 104. In some embodiments, the access device 118 may be located at any other suitable location in other embodiments of the present invention. The resource provider computer 104 may include any suitable computing device operated by a resource provider (e.g., a merchant). In some embodiments, the resource provider computer 104 may include one or more server computers, which may host one or more websites associated with the resource provider (e.g., a merchant). In some embodiments, the resource provider computer 104 may be configured to send data to the central server computer 108 via the transmission computer 106 as part of the payment verification and / or authentication process for the transaction between the user (e.g., a customer) and the resource provider. The resource provider computer 104 may also be configured to generate authorization request messages for transactions between the resource provider and the user 103, and route these authorization request messages to the authorization entity computer 110 (e.g., via the transmission computer 106 and / or the central server computer 108) for additional transaction processing.

[0054] Access devices according to embodiments of the present invention may be in any suitable form. Examples of access devices include point of sale (POS) devices, turnstiles, doors, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc.

[0055] The access device 118 may include a reader 120, a processor 122, and a computer readable medium 124. The reader 120 may use any suitable contact or contactless operation mode. For example, an exemplary card reader may include an RF (radio frequency) antenna, a magnetic stripe reader, etc. to interact with the user device 102.

[0056] In at least one embodiment, user 103 may use user device 102 (e.g., a credit card) to initiate a purchase of goods or services at resource provider computer 104. User device 102 may interact with access device 118, such as a POS (point of sale) terminal. For example, user 103 may have a credit card and may swipe the card through an appropriate slot in the POS terminal. Alternatively, the POS terminal may be a contactless reader and user device 102 may be a contactless device, such as a contactless card. During this interaction, user device 102 may be configured to determine that access device 118 is a particular type of terminal (e.g., a POS device). If access device 118 is this particular type of terminal, user device 102 may provide an obfuscated version of the primary PAN stored at user device 102 and an encrypted version of the primary PAN to access device 118.

[0057] The authorization request message can then be forwarded to a transmission computer 106. The transmission computer 106 is typically associated with a business entity (e.g., a commercial bank) that has a business relationship with a specific resource provider (e.g., a merchant) or other entity and may be involved in the transaction process. The transmission computer 106 may issue and manage accounts for resource providers and exchange funds with the authorization entity computer 110 on behalf of the resource provider. Some entities may perform the functions of both the authorization entity computer 110 and the transmission computer 106. Embodiments of the present invention encompass such single-entity issuer-acquirer computers. After receiving the authorization request message, the transmission computer 106 may send the authorization request message to a central server computer 108. The central server computer 108 may then forward the authorization request message to the authorization entity computer 110 of the user device 102 or a third-party entity acting on behalf of the authorization entity.

[0058] The central server computer 108 can be a network including or operating at least one server computer for processing (e.g., payment processing). The server computer in the central server computer 108 can include a processor and a computer-readable medium coupled to the processor, and the computer-readable medium includes a code executable by the processor for performing the functions described herein. In some embodiments, the server computer can be coupled to a database and can include any hardware, software, other logic or a combination of the foregoing items for serving requests from one or more client computers. The server computer can include one or more computing devices and can use any of various computing structures, arrangements and compilations to serve requests from one or more client computers. In some embodiments, the central server computer 108 can operate multiple server computers. In such embodiments, each server computer can be configured to process transactions in a given area or process transactions of a specific type based on transaction data.

[0059] The central server computer 108 may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception document services, and clearing and settlement services. The central server computer 108 may include VisaNet TM . Including VisaNet TM The network includes the ability to process credit card transactions, debit card transactions and other types of commercial transactions. VisaNet TM Specifically include the integrated payment system (integrated payment system) that processes authorization requests and the Base II system that performs clearing and settlement services. The payment processing network can use any suitable wired or wireless network, including the Internet.

[0060] The central server computer 108 may process the transaction request message and determine the appropriate destination (eg, an authentication computer) for the transaction request message. The central server computer 108 may also process and / or facilitate clearing and settlement of transactions.

[0061] Authorizing entity computer 110 is typically associated with a business entity (e.g., a bank) that issues and maintains consumer accounts for consumers (e.g., user 103). Authorizing entity computer 110 can issue payment devices, including credit and debit cards, for customer accounts.

[0062] After the authorization entity computer or a third-party entity acting on behalf of the authorization entity receives the authorization request message, the authorization entity computer 110 or the third-party entity acting on behalf of the issuer can determine that the PAN will be used for the transaction. For example, the authorization entity computer 110 can determine that an ambiguous PAN is being used in the authorization request message, the merchant type indication of the authorization request message includes the PAN, and / or the transaction type indication of the authorization request message includes the PAN. In some embodiments, the PAN included in the authorization request message can be checked against a mapping of known secondary account identifiers (SANs), and if identified, the authorization request message can be rejected. In some embodiments, if the PAN in the authorization request message is not included in the mapping of known SANs (e.g., it is not a SAN), the message can also be processed. Once it is determined that the PAN is being used, the authorization entity computer can process the authorization request message to approve or reject the transaction. The authorization entity computer can send an authorization response message back to the central server computer 108 to indicate whether the current transaction is authorized (or not authorized). Then, the central server computer 108 forwards the authorization response message back to the transmitting computer 106. Then, the transmitting computer 106 sends a response message back to the resource provider computer 104.

[0063] After the resource provider computer 104 receives the authorization response message, the access device 118 at the resource provider computer 104 may then provide the authorization response message to the user 103. The response message may be displayed by the access device 118, or may be printed on a receipt.

[0064] At the end of the day, conventional clearing and settlement processes may be performed by the system 100. The clearing process refers to the process of exchanging financial details between acquirers and issuers to facilitate postings to the user's account and reconciliation of the user's settlement position.

[0065] In another exemplary embodiment, the user 103 may utilize the user device 102 to initiate an offline transaction. For example, the user 103 may present the user device 102 at an access device 118 having a specific terminal type (e.g., a transit turnstile and / or fare inspection device indicating permitted / restricted access to the transit system). In some embodiments, the access device may be a contactless reader and the user device 102 may be a contactless device such as a contactless card. In some embodiments, the access device 118 may request authentication data from the user device 102 upon presentation of the user device 102. Because the access device 118 has a specific terminal type, the user device may provide information such as a SAN stored in the CRM 112 at the user device 102. Additionally, the user device may provide an encrypted version of the PAN within the data provided to the access device 118.

[0066] After the authorization entity computer or a third-party entity acting on behalf of the authorization entity receives the authorization request message, the authorization entity computer 110 or the third-party entity acting on behalf of the issuer may be configured to determine that the SAN is included in the authorization request message. As an example, the authorization entity computer 110 may determine to include the SAN in the authorization request message based at least in part on determining that the data in the account number field included in the message does not end with 7 zeros, determining that the requesting merchant is associated with a specific merchant type (e.g., a transit merchant type), and / or that the authorization request message indicates the type of transaction (e.g., a transit transaction), and / or the type of terminal from which the authorization request message is generated (e.g., a transit terminal). The authorization entity computer may be configured to reject any authorization request message that includes the SAN in a transaction that does not allow the use of the SAN. If the SAN is included in the message for a transaction that is allowed by the SAN (e.g., a transit transaction, a fare transaction, etc.), the authorization entity computer may continue to process the authorization request message to approve or reject the transaction. The authorization entity computer may send an authorization response message back to the central server computer 108 to indicate whether the current transaction is authorized (or not authorized). The central server computer 108 then forwards the authorization response message back to the transmitting computer 106. The transmitting computer 106 then sends a response message back to the resource provider computer 104 .

[0067] In at least one embodiment, an authorized entity may perform a personalization process on the user device 102. During this personalization process, a master derivation key (MDK), a PAN, and a SAN may be stored at the user device 102 (e.g., within the CRM 112). The user device 102 may be configured to perform functionality to derive one or more unique derivation keys from the master key. In some embodiments, the user device 102 may derive a UDK using at least a portion of the master key and the PAN. For example, the UDK may be derived using the master key and the leftmost 8 digits of the PAN. In some embodiments, the leftmost 8 digits of the PAN may be associated with a bank identification number (BIN).

[0068] Once generated, the UDK may be used to generate an encrypted identifier and / or an obfuscated identifier at any suitable time. In some embodiments, the UDK may encrypt the entire identifier (e.g., PAN) as well as dynamic values ​​such as counters, dates, times, and / or transaction amounts. As an example, the PAN may be concatenated with a dynamic value (e.g., a transaction counter) stored on the user device 102 and encrypted using the UDK and an encryption algorithm. In some embodiments, a portion of the encrypted identifier (e.g., the rightmost 7 digits) may be identified and used to generate an obfuscated identifier. In some embodiments, the obfuscated identifier may include the original 8 digits of the PAN (corresponding to the BIN), a portion of the encrypted identifier, and a checksum value (e.g., corresponding to the Luhn checksum). In still other embodiments, the obfuscated identifier may include the original 8 digits of the PAN (corresponding to the BIN), any suitable number of padding values ​​(e.g., 7 zeros), and a checksum value. The obfuscated identifier and / or the encrypted identifier may be stored at the user device 102.

[0069] At the initialization of a transaction (e.g., a non-transit transaction), or at another suitable time, the user device 102 can be configured to provide an obfuscated value and an encrypted identifier in the form of a data track. The data track can be formatted as a Track 1 or Track 2 data track. Track 1 ("International Air Transport Association") stores more information than Track 2 and contains the cardholder's name and account number and other autonomous data. This track is sometimes used by airlines when obtaining a reservation with a credit card. Track 2 ("American Banking Association" (ABA)) is currently the most commonly used. Track 2 can be read by ATMs and credit card validators. ABA designed the specifications for Track 2, and all world banks must comply. It contains the cardholder's account, encrypted PIN, and other autonomous data.

[0070] In some embodiments, the obfuscated value may be provided in a data field of the Track 2 data track that traditionally includes the user account number (e.g., tag 57). In some embodiments, the encrypted identifier may be provided in a different portion of the Track 2 data track (e.g., in tag 9F1F (arbitrary data tag), in tag 9F7C (customer specific data tag), in tag 9F10 (issuer application data), or in any suitable portion of the Track 2 data, or in any suitable combination of the above).

[0071] In other embodiments, upon initialization of a transaction (e.g., a transit transaction), or at another suitable time, the user device 102 may be configured to provide the SAN and the encrypted identifier in the form of a data track. In some embodiments, the SAN may be provided in a data field of the Track 2 data track that traditionally includes the user's account number (e.g., tag 57). In some embodiments, the encrypted identifier may be provided in a different portion of the Track 2 data track (e.g., in tag 9F1F (arbitrary data tag), in tag 9F7C (customer-specific data tag), in tag 9F10 (issuer application data), or in any suitable portion of the Track 2 data, or in any suitable combination of the above).

[0072] According to conventional transaction processing, access device 118 may receive the track 2 data track and provide the data to resource provider computer 104, which may then forward at least a portion of the track 2 data via an authorization request message to transmitting computer 106. In some embodiments, access device 118 may: generate an authorization request message; include at least a portion of the track 2 data; and forward the authorization request message directly to transmitting computer 106.

[0073] Upon receipt or at another suitable time, the transmitting computer 106 may forward the authorization request message to the central server computer 108. The central server computer 108 may determine that an encrypted value is present in the authorization request message. The central server computer 108 may retrieve a stored UDK and / or derive the UDK using a master export key and a portion of the obfuscated identifier (also included in the authorization message). The UDK may be used by the central server computer 108 to decrypt the encrypted value to obtain the entire unencrypted PAN. In some embodiments, the central server computer 108 may modify the authorization request message to include the unencrypted PAN and transmit the modified authorization request message to the authorization entity computer 110 for further processing.

[0074] In other embodiments, the central server computer 108 and / or the authorized entity computer 110 may utilize at least a portion of the obfuscated identifier (e.g., the first 8 digits corresponding to the BIN) to forward the unaltered authorization request message to the authorized entity computer 110. The authorized entity computer 110 may retrieve a stored UDK and / or derive the UDK using a master export key and a portion of the obfuscated identifier or SAN (also included in the authorization message). The UDK may be utilized by the central server computer 110 to decrypt the encrypted identifier to obtain the entire unencrypted PAN. The central server computer 108 and / or the authorized entity may utilize the SAN to consult a mapping indicating known PAN / SAN associations in order to retrieve the associated PAN. The associated PAN may be compared to the unencrypted PAN to validate the authorization request message.

[0075] The authorization entity computer 110 may process the authorization request message and transmit an authorization response message back to the central server computer 108. In some embodiments, the authorization response message may include the obfuscated identifier and the encrypted value, and may not include the unencrypted identifier.

[0076] The central server computer 108 may forward the authorization response message back to the resource provider computer 104 via the transmitting computer 106. After the resource provider computer 104 receives the authorization response message, the access device 118 at the resource provider computer 104 may then provide the authorization response message to the user 103. The response message may be displayed by the access device 118 or may be printed on a receipt.

[0077] At the end of the day, regular clearing and settlement processes may be performed by system 100.

[0078] By using the techniques described herein, a more secure way to transmit sensitive data (e.g., PAN) is achieved. For transactions that require a static identifier (e.g., to confirm or deny access based on a block list), a SAN can be used to perform the transaction. By utilizing the SAN and ensuring that the SAN can only be utilized in specific types of transactions (e.g., transit transactions, fare transactions, etc.), the SAN is protected from fraudsters. Even if a fraudster is able to eavesdrop to gain access to the SAN, the system will ensure that the SAN can only be used for certain types of transactions and not other transactions. For other transactions (e.g., non-transit transactions), the PAN is encrypted and provided in a non-traditional data field, and the traditional data field that would normally include the PAN instead includes an obfuscated value from which it is impossible to determine the PAN. The obfuscated value can still include the original BIN to ensure that the traditional routing technology used for authorization request / response messages remains unchanged. If possible, the techniques described herein make it difficult to identify the PAN from the authorization request / response message. In addition, in some embodiments, the PAN is encrypted using a dynamic value that changes continuously. Therefore, the encrypted value and the obfuscated value can change for each authorization request, making it difficult to track transactions of a particular user over time if possible. Therefore, using the techniques discussed in this article, privacy protection and security for transmitting sensitive data are improved.

[0079] Figure 2 Describes a method for transmitting data to a user device (e.g., Figure 1 Method 200 for generating and storing data at a user device 102 of a computer system. Method 200 may begin at 202, where an authorized entity computer (e.g., authorized entity computer 110) may obtain a master export key. In some embodiments, a master export key (MDK) may be utilized to derive one or more unique export keys. Authorized entity computer 110 may ensure that the MDK for a user device is unique to the user device. Therefore, authorized entity computer 110 may manage many master export keys that may correspond to various user devices (e.g., user device 102).

[0080] At 204, the authorized entity computer 110 may obtain a personal account number (PAN) corresponding to the user for whom the user device is to be personalized. In at least one embodiment, the PAN may be associated with a financial account of the user that is managed by the authorized entity on behalf of the user.

[0081] At 206, the authorization entity computer 110 may obtain and / or generate a secondary account number (SAN). As discussed throughout, the SAN may be limited by the authorization entity computer 110 such that the SAN may be utilized only in one or more specific types of transactions. As an example, a situation may be that in a transit system or fare checking system, etc., a user must be authenticated quickly (e.g., in real time or near real time). Given the context of the system, it may not be possible to perform an online authentication of the user quickly enough to enable access to a resource (e.g., a transit resource) in near real time. Therefore, some authentication systems perform an offline authentication at the access device and follow up with an authorization request message at a later time for the relevant transaction. This SAN may be generated to be utilized in such an offline authentication scenario.

[0082] At 208, the authorization entity computer 110 may maintain an account mapping indicating the relationship between the PAN and the SAN. The authorization entity computer 110 may be configured to Figure 5 The use of mappings for validation purposes is discussed in more detail.

[0083] At 210, the authorization entity computer 110 may transmit the data to the user device 102. As an example, the authorization entity computer 110 may transmit the MDK, PAN, and SAN to the user device 102. In some embodiments, the authorization entity computer 110 may transmit the data to an intermediate device, which may then transfer the data to the user device 102.

[0084] At 212, the data may be stored at the user device 102 within the CRM 112. At 214, the user device 102 may use the MDK to generate one or more unique derived keys. Figure 3 Detailed description of the process described in more detail herein is used to generate a unique derived key (UDK). It should be appreciated that one or more UDKs may be generated and each UDK may be utilized for a specific purpose. For example, a UDK may be generated for message authentication, another UDK may be generated for encryption, another UDK may be generated for password generation, and the UDKs may be generated based on the UDK. Figure 3 It should be appreciated that the user device 102 may generate any suitable number of UDKs, or such UDKs may alternatively be generated by the authorization entity computer 110 at 202 or at any suitable time.

[0085] At 216, the user device 102 may be activated by the authorization entity computer 110. Upon activation, the user device 102 may be used at an access device or online to perform various transactions.

[0086] Figure 3Describes a method for generating a unique derived key from data residing on a user device (e.g., a smart card) according to some embodiments. The method may be performed by Figure 1 The user device 102 uses one or more processors of the user device 102 to execute.

[0087] In at least one embodiment, before performing a personalization process (e.g., Figure 2 During the method 200 of ), a master derivation key (MDK) 302 and an identifier 304 are stored at the user device 102. In some embodiments, the identifier 304 may be an example of a personal account number. The UDK 306 may be derived from such data present on the user device 102.

[0088] As an example, the user device 102 may be configured to recognize a portion of the identifier 308. In some embodiments, the portion of the identifier 308 may include less than the entire identifier 304. For example, the portion of the identifier 308 may include the leftmost 8 digits of the identifier 304. In some embodiments, the leftmost 8 digits of the identifier 304 may correspond to a bank identification number (BIN) that may be used for routing purposes within a payment processing network (e.g., system 100).

[0089] In some embodiments, the portion of the identifier 308 may be concatenated with a number of padding bits (e.g., padding 310) to create a string of predetermined fixed length. In some examples, the length of the concatenated value may be 128 bits, where the padding includes 64 bits and the portion of the identifier 308 includes another 64 bits (each including 8 numbers of 8 bits), but the concatenated value is not limited to this length. The concatenated value may be provided as well as the MDK 302 as input to the data encryption algorithm 312.

[0090] The data encryption algorithm 312 may include any suitable encryption methodology. For example, the data encryption algorithm 312 may utilize a triple DES encryption algorithm. In some embodiments, the value resulting from encryption performed by the data encryption algorithm 312 is the UDK 306.

[0091] Figure 4 A method 400 for performing offline authentication according to some embodiments is depicted. The method may begin at 402, where a discovery process may be performed by an access device 118. For example, Figure 1 The reader 120 may poll for the presence of a contactless card that may have entered the reader's RF field.

[0092] At 404, the access device 118 may initiate an application selection process with the user device 102. The application selection process may be performed immediately following activation of the user device 102 and is a process of determining which of the applications supported by both the user device 102 and the access device 118 (or reader 120) will be used to conduct the transaction. As an example, the access device 118 (e.g., the reader 120 of the access device 118) may build a candidate list of mutually supported applications. A single application from the candidate list may be identified and selected to process the transaction.

[0093] At 406, application processing may be initiated. For example, the access device 118 (or reader 120) may signal to the user device 102 that transaction processing is beginning. In some embodiments, the start of transaction processing may be signaled by sending a get processing options command from the access device 118 (reader 120) to the user device 102. When issuing this command, the access device 118 may provide any suitable data element. In some embodiments, contactless paths mutually supported by the user device 102 and the access device 118 (reader 120) may be determined and a contactless path may be selected to process the transaction. Subsequent transaction processing may be performed in accordance with the selected contactless path.

[0094] At 408, the user device 102 may provide the application data back to the access device 118 (reader 120). In some embodiments, the user device 102 may first receive a get processing option. In response to the command, the user device 102 may generate any suitable application data. As an example, a counter stored at the user device 102 may be modified (e.g., incremented, decremented, etc.). The user device 102 may utilize the counter and the stored PAN to generate an encrypted PAN that may also be stored at the user device 102. If the get processing option command indicates that the access device 118 is a specific terminal type (e.g., a non-transit terminal type or a terminal type in a first set of terminal types stored at the user device, etc.), the user device 102 may generate an obfuscated PAN from a portion of the stored PAN and a portion of the encrypted identifier. The obfuscated PAN and the encrypted identifier may be provided as application data in this use case. However, if the get processing options command indicates that the access device 118 is another specific terminal type (e.g., a transit terminal type or a terminal type in a second set of terminal types stored at the user device, etc.), the user device 102 can provide the stored SAN and encryption identifier as application data.

[0095] At 410, when access device 118 (reader 120) has read the application data necessary to process the transaction, the reading of the application data may be considered complete. During the read time, access device 118 may determine whether all mandatory data elements for the transaction are returned by the card. If not all mandatory data elements are returned or if redundant data is returned (e.g., more than one specific value for a data element is returned), access device 118 (reader 120) may terminate the transaction.

[0096] At 412, the access device 118 (reader 120) may process the restriction. As examples, the access device 118 (reader 120) may check application expiration dates, application usage, and / or may check if the SAN is on a termination exception file (TEF). The TEF may be considered a blacklist of SANs that are not allowed to access resources. If the SAN appears in the termination exception file, the access device 118 (reader 120) may be configured to deny access to the user device 102 (e.g., a turnstile managed by the access device 118) and not proceed further.

[0097] However, if the SAN is not included in the TEF, the method 400 may proceed to 414, where offline data authentication may be performed. Offline data authentication may be implemented for offline transactions supported by the access device (reader), and may be performed for offline transactions requested by the user device. During offline data authentication, the access device 118 (reader 120) may verify the dynamic signature returned by the user device 102 and may authenticate the data from the user device 102.

[0098] In some embodiments, the access device 118 (reader 120) can support online transactions. In these embodiments, the access device 118 (reader 120) can send an authorization request message to the authorization entity computer 110 at 416 (e.g., via Figure 1 The authorization request message may include the SAN stored at the user device 102 and the encrypted identifier.

[0099] Upon receipt of the authorization request message at 418, or at any suitable time, the authorization entity computer 110 reviews and authorizes or denies the transaction using predetermined host-based risk management parameters. In some embodiments, the authorization entity computer 110 may be configured to determine that the transaction includes a SAN. In some embodiments, the value of the account identifier field of the authorization request message may be retrieved and compared to a mapping that includes all known SANs mapped to corresponding PANs. If the value of the account identifier field is equal to a known SAN, it may be determined that the transaction is utilizing a SAN. In some embodiments, the authorization entity computer 110 may be configured to allow utilization of a SAN only in transactions where the access device (e.g., access device 118) initiating the transaction is of a particular type, or the merchant associated with the access device is a particular merchant type, or the transaction type of the authorization request message indicates an allowed transaction type. As a non-limiting example, the authorization entity computer 110 may be configured to deny online processing utilizing the SAN in transactions involving access devices associated with a non-transit terminal type (e.g., access devices operated by a non-transit merchant), while allowing online processing utilizing the SAN for transactions involving access devices associated with a transit terminal type (e.g., access devices 120 operated by a transit merchant).

[0100] In some embodiments, the SAN included in the authorization request message may be associated with a PAN corresponding to the encrypted identifier. The authorization entity computer 110 may be configured to retrieve the leftmost 8 digits of the SAN corresponding to a bank identification number (BIN). The authorization entity computer 110 may derive a UDK using the BIN and PAN associated with the SAN as stored in a map maintained by the authorization entity computer 110. Using the derived UDK, the authorization entity computer 110 may decrypt the encrypted identifier of the authorization message to determine a decrypted PAN. The decrypted PAN may be compared to the PAN stored in the map and associated with the SAN of the message. If the decrypted PAN matches the stored PAN, the message may be considered valid, otherwise invalid. The authorization entity computer 110 may also perform traditional online fraud and credit checks, perform online card authentication using a card-generated password, and the like.

[0101] Figure 5 1 shows a flow chart of a method 500 for securely transmitting sensitive data according to some embodiments. The method 500 can be performed by a computing device (e.g., Figure 1 The computing device may include one or more processors and one or more memories storing computer executable instructions, wherein the one or more processors execute the computer executable instructions so that the computing device performs the method 500. Figure 5 The steps shown and described below can be used with Figure 1 The description of transaction processing in and its corresponding description are used in conjunction with each other. Those descriptions are incorporated herein by reference. The computing device may store one or more UDKs, first identifiers (e.g., secondary account number (SAN)), second identifiers (e.g., primary account number (PAN)), dynamic values, or any suitable data in a memory of the computing device.

[0102] The encrypted identifier may be encrypted (e.g., by a computing device) in any suitable format (e.g., as described above with respect to Figure 4 The computing device may generate an encrypted identifier by encrypting the second identifier (e.g., PAN) and a dynamic value (e.g., counter, date, time, etc.) using a unique derived key (e.g., UDK 206). In some embodiments, the second identifier and the dynamic value may be concatenated together and / or concatenated with additional filler values ​​before being encrypted. In some embodiments, the encrypted identifier may be stored at the computing device (e.g., as part of Track 1 and / or Track 2 data such as tag 9F7C (customer-specific data tag) and / or tag 9F10 (issuer application data)), in tag 9F1F (any data tag), or in any part of Track 1 and / or Track 2 data, or in any suitable combination of the above. Additionally, or alternatively, the encrypted identifier may be provided as part of a data field that may be available in any of the above tags and is reserved for future use or as another suitable part of Track 1 and / or Track 2 data.

[0103] Method 500 may begin at block 502, where a request message may be received by a computing device (e.g., a smart card) from an access device (e.g., a turnstile). In some embodiments, the request message may correspond to the request message as described above in Figure 4 The access device may be any suitable device configured to request data from a user device.

[0104] At 504, the computing device may determine a type indicator for the requesting access device based at least in part on the request message. As an example, the request message may include a type indicator indicating that the request is initiated by a particular type of terminal / access device. As a non-limiting example, the request message may indicate that the requesting device is a turnstile within a transit system such as a subway system. The computing device may determine whether the type indicator belongs to a first type set (e.g., a first type set that includes a transit type).

[0105] At 506, if the type indicator is determined to be included in the first type set or it is determined that the request message is initiated by a terminal / access device of a specific type, the computing device may send a second message (e.g., to the access device), the second message including at least the first identifier (e.g., SAN) and an encrypted identifier generated / derived from the PAN. According to some embodiments, the message may be provided to the access device, which enables a user of the computing device to be allowed or denied access to a resource. As a non-limiting example, an access device such as a turnstile in a transit station may allow or deny access to a user based on the first identifier (e.g., SAN). As described above with respect to Figure 4 As described, in some embodiments, the access device (or associated resource provider computer) may then generate an authorization request message. The authorization request message may include, among other things, a first data field containing a first identifier (SAN) and a second data field containing an encrypted identifier. In some embodiments, the authorization request message is transmitted to a central server computer (e.g., Figure 1 central server computer 108) for further authorization processing.

[0106] At 508, if the type indicator is determined to be not included in the first type set or is determined to be not a specific type of terminal / access device, an obfuscated identifier can be generated (e.g., by user device 102). In some embodiments, the obfuscated identifier can include the first 8 digits of the second identifier (PAN), 7 zeros, and a Luhn checksum value. In other embodiments, the obfuscated identifier can be generated based at least in part on a portion of the second identifier (e.g., PAN) and a portion of the encrypted identifier. As an example, the obfuscated identifier can be generated to include the first 8 digits of the identifier and the last 7 digits of the encrypted identifier (or any suitable number of zeros). This is just an example, and more or less digits of the identifier and more or less digits of the encrypted identifier can be used. Similarly, the obfuscated identifier can include 16 digits or any suitable number of digits. In some embodiments, the Luhn checksum value can be calculated based on the obfuscated identifier, and the Luhn checksum value is included as part of the obfuscated identifier (e.g., the last digit in the ongoing example, i.e., digit 16).

[0107] At 510, a second message (e.g., a Track 2 message) may be provided (e.g., by user device 102). In some embodiments, the message may include at least an obfuscated identifier and an encrypted identifier. According to some embodiments, the message may be provided to an access device (e.g., access device 118), which causes an authorization request message to be generated (e.g., by Figure 1The authorization request message may include, among other things, a first data field containing an obfuscated identifier and a second data field containing an encrypted identifier. In some embodiments, the authorization request message is transmitted to a central server computer (e.g., Figure 1 central server computer 108) for further authorization processing.

[0108] Figure 6 An exemplary recording format 600 for use in some embodiments is depicted. For example, the recording format 600 may include Track 2 data (e.g., authentication data) including a SAN and an encryption identifier. The recording format 600 may be about Figure 5 506. In one non-limiting example, PAN 601 may be associated with a user and stored on a user's device (e.g., a smart card). In some embodiments, SAN 602 may be associated with a user and stored on a user's device. Figure 6 As illustrated, PAN 601 and SAN 602 may each include 16 digits. In some embodiments, PAN 601 is stored at tag 57 of the Track 2 Data as defined by the Track 2 Data. In some embodiments, SAN 602 is stored at tag 5A of the Track 2 Data as defined by the Track 2 Data.

[0109] The first 16 digits of the record format 600 (e.g., identifier data field 603) may be conventionally reserved for the SAN 602 (e.g., numbers 1-16). Next, a separator data field 604 provides a buffer between the account identifier and the expiration date data field 606. A service code data field 608 may follow the expiration date data field 606. A personal identification number verification indicator (PVKI) data field 610 and a PIN verification information data field 614 follow. Next, a dCVV data field 614, a transaction counter data field 616, and a contactless indicator data field 618 are included. Finally, an arbitrary data field 620 follows. The arbitrary data fields may include an encrypted value data field 621 and a cryptographic version number data field 623. The encrypted value data field 621 and the cryptographic version number data field 623 may include any suitable number of digits, and need not be Figure 6 Figures depicted in .

[0110] According to some embodiments, an encrypted value (e.g., an encrypted identifier) ​​may first be generated using PAN 601. As an example, Figure 1 The user device 102 may be configured to retrieve from storage Figure 3PAN 601 and UDK 306. In some embodiments, a transaction counter (or other dynamic value) may also be retrieved. The PAN and transaction counter (or other dynamic value) may be utilized together with the UDK 306 as input into the encryption algorithm to generate an encrypted value. In some embodiments, the PAN and transaction counter (or other dynamic value) may be concatenated prior to input. The resulting encrypted value may be stored in the record format 600. As an example, the resulting encrypted value may be stored within the encrypted value data field 621 of the arbitrary data field 620 as depicted. In some embodiments, the arbitrary data field 620 corresponds to a specific tag defined by the Track 2 standard (e.g., in tag 9F1F (arbitrary data tag), tag 9F7C (customer-specific data tag), in tag 9F10 (issuer application data), in any suitable portion of the Track 2 data, or in any suitable combination of the above).

[0111] In some embodiments, the cryptographic version number data field 623 may store a number within the encrypted value data field 621 indicating that any data field 620 includes an encrypted value.

[0112] According to some embodiments, user device 102 may be configured to provide SAN 602 in identifier data field 603. Digit 16 of identifier data field 603 may include a checksum value (e.g., a Luhn checksum / value) that may be utilized (e.g., upon receipt) to verify that identifier data field 603 has not been altered. In some embodiments, SAN 602 may be provided within identifier data field 603 when user device 102 has determined that the requestor of track 2 data is associated with a particular terminal type (e.g., a transit terminal type, a terminal type associated with offline authentication, etc.).

[0113] Once a transaction has been initiated, the SAN 602 contained within the identifier data field 603 and the encrypted value within the arbitrary data field 620 (e.g., at the encrypted value data field 621) can be provided (e.g., to an access device as described above). In some embodiments, a transaction counter can be incremented (or decremented) and / or a new dynamic value can be generated and stored in the transaction counter data field 716. If another transaction is initiated by the user device 102, the process discussed herein can be repeated using the new transaction counter / dynamic value and PAN 701 to generate a new encrypted value and a new obfuscated identifier that can then be provided in subsequent transactions.

[0114] Figure 7Another exemplary recording format 700 for use in some embodiments is depicted. For example, recording format 700 may include track 2 data (e.g., payment data) including obfuscated identifiers and encrypted identifiers. Record format 600 may be about Figure 5 510 describes an example of a second message. In one non-limiting example, PAN 701 can be associated with a user and stored on the user's device (e.g., a smart card). In some embodiments, SAN 702 can also be associated with a user and stored on the user's device. Figure 7 As illustrated, PAN 701 and SAN 702 may each include 16 digits. In some embodiments, PAN 701 is stored at tag 57 of the Track 2 Data as defined by the Track 2 Data. In some embodiments, SAN 702 may be stored at tag 5A of the Track 2 Data as defined by the Track 2 Data.

[0115] The first 16 digits of the record format 700 (e.g., identifier data field 703) (e.g., digits 1-16) may be reserved for an obfuscated version of the account identifier (e.g., obfuscated PAN 703, obfuscated version of PAN 701). Next, a delimiter data field 704 provides a buffer between the account identifier and the expiration date data field 706. A service code data field 708 may follow the expiration date data field 706. A personal identification number verification indicator (PVKI) data field 710 and a PIN verification information data field 712 may follow. Next, a dCVV data field 714, a transaction counter data field 716, and a contactless indicator data field 718 may be included. Finally, an arbitrary data field 720 may follow. The arbitrary data fields may include an encrypted value data field 721 and a cryptographic version number data field 723. The encrypted value data field 721 and the cryptographic version number data field 723 may include any suitable number of digits, and need not be Figure 7 Figures depicted in .

[0116] According to some embodiments, an encrypted value (e.g., an encrypted identifier) ​​may first be generated using PAN 701. As an example, Figure 1 The user device 102 may be configured to retrieve from storage Figure 3PAN 701 and UDK 306. In some embodiments, a transaction counter (or other dynamic value) may also be retrieved. The PAN 701 and transaction counter (or other dynamic value) may be utilized together with the UDK 306 as input into the encryption algorithm to generate an encrypted value. In some embodiments, the PAN 701 and transaction counter (or other dynamic value) may be concatenated prior to input. The resulting encrypted value may be stored in the record format 700. As an example, the resulting encrypted value may be stored within the encrypted value data field 721 of the arbitrary data field 720 as depicted. In some embodiments, the arbitrary data field 720 corresponds to a specific tag defined by the Track 2 standard (e.g., in tag 9F1F (arbitrary data tag), tag 9F7C (customer-specific data tag), in tag 9F10 (issuer application data), in any suitable portion of the Track 2 data, or in any suitable combination of the above).

[0117] In some embodiments, the cryptographic version number data field 723 may store a number within the encrypted value data field 721 indicating that any data field 720 includes an encrypted value.

[0118] According to some embodiments, the user device 102 may be configured to generate the obfuscated PAN 703. As an example, the user device 102 may obtain the first 8 digits of the PAN 701 and store this information in digits 1-8 of the identifier data field 703. In some embodiments, digits 9-15 of the identifier data field 703 may include a padding value such as zeros. Alternatively, the user device 102 may be configured to obtain a portion of the encrypted value and store that portion within the record format 700. For example, the last 7 digits of the encrypted value may be obtained and stored as digits 9-15 of the identifier data field 703. Digit 16 of the identifier data field 703 may include a checksum value (e.g., a Luhn checksum / value) that may be utilized (e.g., upon receipt) to verify that the identifier data field 703 has not been altered.

[0119] Once a transaction has been initiated, the obfuscated PAN 703 and the encrypted value within the arbitrary data field 720 (e.g., at the encrypted value data field 721) can be provided (e.g., to an access device as described above). The transaction counter can be incremented (or decremented) and / or a new dynamic value can be generated and stored in the transaction counter data field 716. If another transaction is initiated by the user device 102, the process discussed herein can be repeated using the new transaction counter / dynamic value and PAN 701 to generate a new encrypted value and a new obfuscated identifier that can then be provided in subsequent transactions.

[0120] Figure 8800 is a flowchart of a method for performing data validation according to some embodiments. Figure 1 The computing device may include one or more processors and one or more memories storing computer executable instructions, wherein the computer executable instructions are executed by one or more processors so that the computing device performs the method 800.

[0121] Method 800 may begin at block 802, where a message (eg, an authorization request message) may be received. In some embodiments, the message may include a first identifier (eg, a SAN) and an encrypted identifier. Figure 8 The steps shown and described below can be used with Figure 1 The description of transaction processing in and its corresponding description are used in conjunction with each other. Those descriptions are incorporated herein by reference.

[0122] At block 804, the computing device may verify the type associated with the requesting device that initiated the authorization request message. In some embodiments, the computing device may compare the value contained in the authorization request message (e.g., merchant name, address, type indicator, terminal type, etc.) with data stored at or accessible to the computing device (e.g., a value that allows the use of the SAN). If the value contained in the authorization request message is contained in the stored data, the computing device may allow further processing of the authorization request message. If the value is not contained in the authorization request message, the computing device may reject the authorization request message and transmit an authorization response message to the requestor indicating the authorization request message.

[0123] At 806, the first identifier (eg, SAN) may be utilized to obtain the expected identifier (eg, primary PAN). In some embodiments, the computing device may consult a mapping that indicates known associations between PANs and SANs.

[0124] At 808, the computing device may generate a decryption identifier using the encrypted identifier and the unique derived key. In some embodiments, the computing device may derive a unique derived key (UDK) from a portion of the first identifier (e.g., SAN). In some embodiments, the UDK may be previously derived and retrieved from a storage device. As an example, the computing device may retrieve the leftmost 8 digits of the first identifier and use those digits as input to a predetermined encryption algorithm to generate the UDK. The leftmost 8 digits may correspond to a bank identification number (BIN). Once the UDK is generated, it may be used to decrypt the encrypted identifier.

[0125] At 810, the computing device may be configured to verify that the decrypted identifier matches the expected identifier 510. That is, the decrypted identifier corresponds to the primary PAN associated with the first identifier (eg, SAN) as defined within a mapping maintained by the computing device.

[0126] At 812, the message may be processed by a computing device using the decrypted identifier. As an example, the computing device may be a central server computer (e.g., Figure 1 In this case, processing the message (e.g., the authorization request message) may include modifying the message to include the decrypted identifier and transmitting the message to an authorization entity computer (e.g., authorization entity computer 110) for further processing. In some embodiments, the computing device may be the authorization entity computer 110. In this case, processing the message may include using the message data including the decrypted identifier to authorize the transaction. Processing may also include generating an authorization response message indicating that the transaction is approved or denied. The authorization response message may include the encrypted identifier and may be transmitted to the ... Figure 1 The above processing, for example, transmits the authorization response message to the central server computer 108.

[0127] Fig. 9 900 is a flowchart of a method for performing data validation according to some embodiments. Figure 1 The computing device may include one or more processors and one or more memories storing computer executable instructions, wherein the computer executable instructions are executed by one or more processors so that the computing device performs the method 900.

[0128] Method 900 may begin at block 902, where a message (eg, an authorization request message) may be received. In some embodiments, the message may include an obfuscated identifier and an encrypted identifier. Fig. 9 The steps shown and described below can be used with Figure 1 The description of transaction processing in and its corresponding description are used in conjunction with each other. Those descriptions are incorporated herein by reference.

[0129] At block 904, the computing device may identify that the message includes an encrypted identifier. In some embodiments, identifying that the message includes an encrypted identifier may include checking for a particular data field (e.g., Figure 3 If the data field contains a non-zero value, the computing device can infer that the encrypted value is present in the message. In some embodiments, identifying that the message includes an encrypted identifier can include checking a particular data field (e.g., Figure 3Whether the password version number data field 323) has a non-zero value (or a specific value).

[0130] At block 906, the computing device may generate a decrypted identifier using the encrypted identifier and the unique derived key. In some embodiments, the computing device may derive a unique derived key (UDK) from a portion of the obfuscated identifier. In some embodiments, the UDK may be previously derived and retrieved from a storage device. As an example, the computing device may retrieve the leftmost 8 digits of the obfuscated identifier and use those digits as input to a predetermined encryption algorithm to generate the UDK. Once the UDK is generated, it may be used to decrypt the encrypted identifier.

[0131] At block 908, the message may be processed by a computing device using the decrypted identifier. As an example, the computing device may be a central server computer (e.g., Figure 1 In this case, processing the message (e.g., the authorization request message) may include modifying the message to include the decrypted identifier and transmitting the message to an authorization entity computer (e.g., authorization entity computer 110) for further processing. In some embodiments, the computing device may be the authorization entity computer 110. In this case, processing the message may include using the message data including the decrypted identifier to authorize the transaction. Processing may also include generating an authorization response message indicating that the transaction is approved or denied. The authorization response message may include the encrypted identifier and may be transmitted to the ... Figure 1 The above processing, for example, transmits the authorization response message to the central server computer 108.

[0132] Technical improvements

[0133] By using the techniques described herein, a more secure way to transmit sensitive data (e.g., PAN) is achieved. Not only is the PAN encrypted and provided in a non-traditional data field, but the traditional data field that typically includes the PAN instead includes an obfuscated value from which it is unlikely to determine the PAN. The obfuscated value can still include the original BIN to ensure that traditional routing techniques for authorization request / response messages remain unchanged. If possible, the techniques described herein make it difficult to identify the PAN from the authorization request / response message. In addition, in some embodiments, the PAN is encrypted using a dynamic value that changes continuously. Therefore, the encrypted value can change for each authorization request, making it difficult to track a particular user's transactions over time, if possible. Therefore, these methods provide improvements in personal data privacy by ensuring that a particular user and / or account cannot be identified from the authorization request / response message.

[0134] Any computing device described herein may be an example of a computer system that can be used to implement any of the above-mentioned entities or components. The subsystems of such a computer system may be interconnected via a system bus. Additional subsystems include a printer, a keyboard, a storage device, and a monitor that is coupled to a display adapter. Peripheral devices and input / output (I / O) devices are coupled to an I / O controller and may be connected to a computer system by any of a number of means known in the art (e.g., a serial port). For example, an I / O port or external interface may be used to connect a computer device to a wide area network (e.g., the Internet), a mouse input device, or a scanner. Interconnection via a system bus may allow a central processing unit to communicate with each subsystem and control the execution of instructions from a system memory or storage device, as well as information exchange between subsystems. System memory and / or storage device may embody a computer-readable medium.

[0135] As described, the services of the present invention may involve the implementation of one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, operations, or method steps may be implemented as a result of executing an instruction set or software code by a suitably programmed computing device, microprocessor, data processor, etc. The instruction set or software code may be stored in a memory or other form of data storage element accessed by a computing device, microprocessor, etc. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0136] Any software components or functions described in this application can be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques and using any suitable computer language (e.g., Java, C++, or Perl). The software code can be stored as a series of instructions or commands on a computer-readable medium such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard drive or floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices within a system or network.

[0137] The above description is illustrative rather than restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalents.

[0138] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0139] Unless expressly indicated to the contrary, the articles "a," "an," or "the" are intended to mean "one or more."

[0140] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A computer-implemented method for transmitting sensitive data, the method comprising: transmitting, by the access device, a first message to a user device, the first message including a terminal type indicator, the user device storing a first identifier, a second identifier, and an encrypted identifier generated by the user device using a portion of the second identifier; Based on the terminal type indicator indicating the first terminal type: Receiving, by the access device, a first request message from the user device, the first request message including the first identifier and the encrypted identifier generated by the user device; determining whether to allow access to a resource managed by the access device based at least in part on receiving the first request message; as well as Based on the terminal type indicator indicating the second terminal type: receiving, by the access device, from the user device, a second request message including an obfuscated identifier and the encrypted identifier, the obfuscated identifier being generated by the user device based on a first portion of the second identifier and a second portion of the encrypted identifier; as well as A transaction is initiated based at least in part on receiving the second request message.

2. The computer-implemented method of claim 1 , wherein the encrypted identifier is also generated using a counter value stored at the user device, the user device being further configured to generate a modified counter value in response to transmitting the first request message or the second request message.

3. The computer-implemented method of claim 2, wherein generating the encrypted identifier further comprises encrypting the second identifier and the modified counter value with a unique derived key stored at the user device.

4. The computer-implemented method of claim 1, wherein the second portion of the encrypted identifier comprises the rightmost seven digits of the encrypted identifier.

5. The computer-implemented method of claim 1, wherein the first portion of the second identifier comprises leftmost eight digits of the second identifier.

6. The computer-implemented method of claim 1, wherein the first identifier is a static identifier, wherein the second identifier is a primary account number, and wherein the first portion of the second identifier comprises an identification number associated with an acquirer.

7. The computer-implemented method of claim 1 , wherein receiving the first request message including the first identifier and the encrypted identifier causes the access device to perform operations including: comparing the first identifier to a plurality of stored identifiers; rejecting the first request message when the first identifier is included in the plurality of stored identifiers, wherein rejecting the first request message causes the user device to be denied access to resources managed by the access device; and The first request message is approved when the plurality of stored identifiers do not include the first identifier, wherein approving the first request message causes the user device to be permitted to access resources managed by the access device.

8. The computer-implemented method of claim 1 , wherein receiving the first request message including the first identifier and the encrypted identifier further causes the access device to perform operations including: generating an authorization request message including the first identifier and the encrypted identifier; and The authorization request message is transmitted to an authorization entity computer.

9. The computer-implemented method of claim 8, wherein the authorization entity computer is configured to: receiving the authorization request message including the first identifier and the encrypted identifier; identifying a stored identifier associated with the first identifier; generating a decrypted identifier from the encrypted identifier; comparing the stored identifier to the decrypted identifier; and The authorization request message is processed based at least in part on comparing the stored identifier to the decrypted identifier.

10. The computer-implemented method of claim 1 , wherein initiating the transaction comprises: generating an authorization request message including the obfuscated identifier and the encrypted identifier; and transmitting the authorization request message to an authorization entity computer, wherein transmitting the authorization request message including the obfuscated identifier and the encrypted identifier causes the authorization entity computer to: deriving a derivation key based at least in part on a specific portion of the obfuscated identifier; generating a decrypted identifier from the encrypted identifier using the derived key; as well as The authorization request message is processed using the decryption identifier.

11. An access device, comprising: one or more processors; as well as one or more memories storing computer-executable instructions for transmitting sensitive data, wherein execution of the computer-executable instructions by the one or more processors causes the access device to: transmitting a first message including a terminal type indicator to a user device, the user device being configured to store a first identifier, a second identifier, and an encrypted identifier generated by the user device using a portion of the second identifier; Based on the terminal type indicator indicating the first terminal type: receiving a first request message from the user device, the first request message including the first identifier and the encrypted identifier generated by the user device; as well as determining whether to allow access to a resource managed by the access device based at least in part on receiving the first request message; as well as Based on the terminal type indicator indicating the second terminal type: receiving, from the user device, a second request message including an obfuscated identifier and the encrypted identifier, the obfuscated identifier being generated by the user device based on a first portion of the second identifier and a second portion of the encrypted identifier; as well as A transaction is initiated based at least in part on receiving the second request message.

12. The access device of claim 11, wherein the first terminal type indicates that the access device is associated with a branch office.

13. The access device of claim 11, wherein determining whether to allow access to the resource managed by the access device is performed in near real time.

14. The user device of claim 11, wherein a first leftmost eight digits of the first identifier matches a second leftmost eight digits of the second identifier.

15. The user device of claim 11, wherein the access device is a contactless reader.

16. A user device according to claim 11, wherein executing the computer-executable instructions also causes the access device to transmit an authorization request message including the first identifier and the encrypted identifier to an authorization entity computer, the authorization request message being transmitted at least in part based on receiving the first request message, the authorization request message including a transaction type value.

17. A user device according to claim 16, wherein the first identifier is a static account identifier, and wherein the authorization entity computer is configured to identify that the first identifier of the authorization request message is the static account identifier based at least in part on identifying that the first identifier does not end with seven zeros.

18. A user device according to claim 11, wherein the first message includes a data field, the data field includes the first identifier and a checksum value, the checksum value indicates that the first identifier has not changed, and wherein determining whether to allow access to the resource managed by the access device is at least partially based on determining that the checksum value indicates that the first identifier has not changed.

19. The user device of claim 18, wherein determining whether to allow access to the resource managed by the access device based at least in part on receiving the first request message further comprises: comparing the first identifier to a stored blacklist indicating identifiers for which the requested access is to be denied; as well as When the first identifier is included in the stored blacklist, the access to the resource is denied.

20. The user device of claim 11, wherein the obfuscated identifier comprises the first eight digits of the second identifier, seven zeros, and a checksum value.

Images