Techniques for securely performing offline authentication

Abstract

To provide systems and methods for securely communicating sensitive data (e.g., interaction data) during a process for offline authentication.SOLUTION: A data packet may be received by an access device from a user device in a one-way communication. The data packet may be converted to obtain interaction data comprising a digital certificate certified by a certificate authority and a digital signature value generated by the user device. A second public key associated with the user device may be obtained utilizing the digital certificate and a first public key associated with the certificate authority. The validity of the interaction data may be determined based at least in part on the digital signature value and the second public key associated with the user device. When it is determined that the interaction data is valid, an identifier of the interaction data may be authorized and access may be provided based on this authorization.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This international application claims priority to U.S. patent application Ser. No. 16 / 226,583, filed Dec. 19, 2018, the disclosure of which is incorporated herein by reference in its entirety for all purposes.

[0002] Embodiments of the present disclosure relate to securely providing sensitive data during the process of offline authentication. In some contexts, offline authentication is preferred over online authentication due to timing constraints of the receiving device (e.g., terminal). For example, many high-volume, fast-paced authentication systems (e.g., transportation terminals, ticket systems, etc.) require that a user be authenticated by the receiving device with minimal time delay. [Background technology]

[0003] Information provided by user devices (e.g., mobile phones) may contain sensitive data. As a result, security measures are needed to protect users from sophisticated fraudsters who may intercept this information. This sensitive data may be transmitted from one device to another, which may cause problems with current technologies. Not only do these technologies introduce delays in communication, but they may also allow fraudsters to intercept the communication. The size of the sensitive data may be too large to use other conventional methods. Summary of the Invention [Problem to be solved by the invention]

[0004] Embodiments of the present invention address these and other problems, both individually and collectively. [Means for solving the problem]

[0005] Embodiments of the present invention are directed to methods, systems, devices, and computer-readable media that can be used to securely communicate sensitive data (e.g., authentication information, account data, etc.) to a receiving device. Advantageously, in embodiments of the present invention, the sensitive data is communicated in a manner that is secure (e.g., prevents criminals from intercepting and / or obtaining the data) and does not require updating existing infrastructure in any significant way.

[0006] One embodiment of the present invention is directed to a method for performing offline authentication. The method may include receiving, at the access device, a first public key associated with a certification authority. Additional steps of the method may occur while the access device is operating in an offline mode. The method may further include obtaining, by the access device, a data packet from the user device from the one-way communication. The method may further include converting, at the access device, the data packet to obtain interaction data including a digital certificate authenticated by the certification authority and a digital signature value generated by the user device. The method may further include obtaining, at the access device, a second public key associated with the user device utilizing the digital certificate associated with the certification authority and the first public key. The method may further include determining, at the access device, validity of the interaction data based at least in part on the digital signature value and the second public key associated with the user device. The method may further include approving, at the access device, an identifier of the interaction data if the interaction data is determined to be valid. The method may further include providing access, by the access device, based at least in part on a determination that the identifier of the interaction data is approved.

[0007] Another embodiment of the present invention is directed to an access device comprising one or more memories storing computer-executable instructions that, when executed by one or more processors, cause the access device to perform operations. The operations may include receiving, at the access device, a first public key associated with a certification authority. The operations may further include obtaining, by the access device (e.g., while operating in an offline mode), a data packet from the user device from the one-way communication. The operations may further include converting, at the access device (e.g., while operating in an offline mode), the data packet to obtain interaction data including a digital certificate authenticated by the certification authority and a digital signature value generated by the user device. The operations may further include obtaining, at the access device (e.g., while operating in an offline mode), a second public key associated with the user device utilizing the digital certificate associated with the certification authority and the first public key. The operations may further include determining, at the access device (e.g., while operating in an offline mode), validity of the interaction data based at least in part on the digital signature value and the second public key associated with the user device. The operations may further include, if the interaction data is determined to be valid, approving, at the access device (e.g., while operating in an offline mode), an identifier of the interaction data. The operations may further include, at the access device (e.g., while operating in an offline mode), providing access based at least in part on determining that the identifier of the interaction data is approved.

[0008] Another embodiment of the invention is directed to a (non-transitory) computer readable medium. The computer readable medium includes code for performing the methods discussed herein. In some embodiments, a computing device, such as a portable user device, may comprise the computer readable medium.

[0009] These and other embodiments of the invention are described in further detail below with reference to the drawings. [Brief description of the drawings]

[0010] [Figure 1] 1 illustrates a block diagram of a system for providing sensitive data for offline authentication, according to some embodiments. [Diagram 2] 1 illustrates a method for registration according to some embodiments. [Diagram 3] 1 illustrates an exemplary certificate specification, according to some embodiments. [Figure 4] 1 illustrates a flowchart of a method for implementing offline authentication for secure transfer of sensitive data according to some embodiments. [Diagram 5] 1 illustrates an example data specification for generated code according to some embodiments. [Figure 6] 1 illustrates a flowchart of a method for performing offline authentication, according to some embodiments. [Figure 7] FIG. 1 shows a block diagram illustrating a transaction processing system. [Figure 8] FIG. 1 shows a block diagram illustrating a building access system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] In a traditional transaction (e.g., a payment transaction), an account identifier (e.g., a personal account identifier) ​​may be passed from a portable consumer device, such as a mobile phone, to an access device (e.g., a POS terminal), and ultimately through a traditional payment processing network. In some traditional techniques, the account identifier may be encrypted and / or obfuscated, but the encrypted / obfuscated data may still be provided in the transaction message, and the data fields are easily identifiable to a potential fraudster.

[0012] The processes described herein may be used to protect sensitive data (e.g., account data such as an account identifier) ​​when this data is provided to a receiving device (e.g., a terminal device at a transportation gate). As described in more detail below, embodiments of the present invention generate a digital signature using one or more data fields of the sensitive data and a cryptographic algorithm (e.g., an elliptic curve cryptography algorithm). The sensitive data and digital signature may be converted into a Quick Response (QR) code and presented at a user's device (e.g., via a mobile phone display). The terminal device reads the QR code to obtain the underlying data and verifies the digital signature to ensure that the sensitive data has not been altered. Unlike conventional systems, embodiments herein may utilize a one-way transfer of data such that the terminal device need only obtain the QR code from the display of the user's device without any communication between the terminal device and the user's device occurring. Thus, the sensitive data may be communicated securely and efficiently such that an offline authentication process may be performed with reduced risk of interception.

[0013] Before discussing detailed embodiments of the invention, some clarification of specific terminology may be useful.

[0014] A "computing device" (also called a "user device") may be any suitable device capable of performing computations and communicating with other devices. A portable computing device, such as a mobile phone, is an example of a computing device. Other types of computing devices may not be portable.

[0015] A "Quick Response (QR) Code" may include a multidimensional array of black and white squares that contain machine-readable data. QR Codes are sometimes called matrix barcodes.

[0016] An "Elliptic Curve Cryptography (ECC) algorithm" may include a public key cryptography algorithm that is based on the algebraic structure of elliptic curves over finite fields. ECC may require a smaller cryptographic key than a non-ECC cryptographic algorithm (such as the Ravest-Shamir-Adleman (RSA) algorithm) to provide equivalent security.

[0017] An "encrypted value" may include any suitable encrypted version of a value. An encrypted value may be generated from a value (e.g., an identifier) ​​using any suitable encryption technique, for example, using symmetric and / or asymmetric encryption techniques.

[0018] The "interaction data," also referred to as "sensitive data," may include any suitable data utilized for an interaction between a user device and an access device. By way of example, the interaction data may include any suitable data fields depicted in FIG. 3, including, but not limited to, Track 2 equivalent data (as defined in ISO 7813), timestamp information, a certification authority (CA) public key index, a public key certificate associated with a particular user device and certified by a particular CA, a digital signature generated utilizing other data fields in the interaction data, etc.

[0019] For purposes of this application, "payment data" may include, for financial applications, those data elements used by the payment service to execute a transaction, and, for non-financial transactions, any data elements necessary outside of the present invention. For example, in some embodiments, "payment data" may include track 1 and / or track 2 data, such as a primary account number, expiration date, service code, and optional data, as would be understood by one of ordinary skill in the credit card industry. "Payment data" may also include a unique card identification number or a service provider unique identification number. Payment data may reside in memory located on a user device (e.g., a mobile phone, etc.).

[0020] A "digital signature" may contain a value that can be used to verify the authenticity of a digital message. A valid digital signature can give a recipient reason to believe that it was created by a known sender, why the sender cannot deny having sent the message, and why the message was not altered in transit.

[0021] An "approving entity" may be an entity that approves a request. Examples of an approving entity may be an issuer, a government agency, a document repository, an access administrator, etc. An "issuer" may typically refer to a business entity that holds a user's account (e.g., a bank). An issuer may also issue a payment certificate to a consumer, which is stored on a user device such as a mobile phone, smart card, tablet, or laptop. An "approving entity computer" may be operated by or on behalf of the approving entity.

[0022] An "acquirer" may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular retailer or other entity. Some entities may act as both an issuer and an acquirer. Some embodiments may include such a single entity issuer-acquirer. Acquirers may operate acquirer computers, which may collectively be referred to as "transfer computers."

[0023] A "resource provider" may be an entity that can provide resources, such as goods, services, information, and / or access. Examples of resource providers include retailers, access devices, secure data access points, etc. A "retailer" may typically be an entity that engages in commerce and sells goods or services or can 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.

[0024] A "processing network computer" (also called a central server computer) may include a server computer used to process network data. In some embodiments, a processing network computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing to service requests from one or more client computers. A processing network computer may comprise one or more computing devices and may use any of a variety of computer structures, arrangements, and compilations to service requests from one or more client computers. In some embodiments, a processing network computer may operate multiple server computers. In such embodiments, each server computer may be configured to process transactions for a given region or to handle a particular type of transaction based on the transaction data.

[0025] The processing network computer may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary processing network computer may include VisaNet™. A network including VisaNet™ can process credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ includes an Integrated Payments system that processes authorization requests and a Base II system that performs clearing and settlement services. The processing network computer may use any suitable wired or wireless network, including the Internet.

[0026] An "authorization request message" may be an electronic message sent to a transaction processing computer and / or an approving entity computer (e.g., a payment card issuer) requesting authorization for a transaction. An authorization request message according to some embodiments may conform to ISO 8583, a standard for systems for exchanging electronic transaction information associated with payments made by consumers using a payment device or payment account. The authorization request message may include an issuer account identifier, which may be associated with the 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, a 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, a retailer identifier, a retailer location, etc., as well as any other information that may be utilized in determining whether to identify and / or approve the transaction.

[0027] An "authorization response message" may be an electronic message generated by an approving entity computer or a transaction processing computer in response to an authorization request message. The authorization response message may include one or more of the following status indicators, by way of example only: Approved - the transaction has been approved; Denied - the transaction has not been approved; or Call Center - the response is pending more information and the retailer must call a toll-free authentication telephone number. The authorization response message may also include an authorization code, which may be a code that the approving entity (e.g., an issuer bank) sends back in an electronic message to the resource provider computer (either directly or via the transaction processing computer) in response to the authorization request message indicating approval of the transaction. The code may serve as proof of approval. In some embodiments, the transaction processing computer may generate the authorization response message or forward it to the resource provider.

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

[0029] A "processor" may refer to any suitable data computing device or devices. A processor may comprise one or more microprocessors working together to achieve a desired function. A processor may include a CPU comprising at least one high speed data processor suitable for executing program components that perform user and / or system generated requests. A 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 processors, Intel's Celeron, Itenium, Pentium, Xeon, and / or XScale, and / or similar processors.

[0030] A "memory" may be any suitable device or devices capable of storing electronic data. Suitable memories may include non-transitory computer-readable media that store instructions executable by a processor to perform a desired method. Examples of memories may include one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic modes of operation.

[0031] FIG. 1 illustrates a block diagram of a system 100 for providing sensitive data for offline authentication, according to some embodiments. The system 100 may be used to facilitate data communication utilizing various computers shown in FIG. 1 for authentication, access control, and / or approval of financial and / or non-financial transactions. The system 100 includes a user device 102, a resource provider computer 104, a transfer computer 106, a central server computer 108, and an approval entity computer 110. Each of these systems and computers may be in operative communication with one another. For ease of explanation, a certain number of components are shown in FIG. 1. However, it is to be understood that embodiments of the invention may include more than one of each component. Additionally, some embodiments of the invention may include fewer or more than all of the components shown in FIG. 1. Additionally, the components of FIG. 1 may communicate over any suitable communication medium (including the Internet) using any suitable communication protocol.

[0032] The user device 102 may be in any suitable form. For example, the user device 102 may include a mobile phone, a personal digital assistant (PDA), a netbook, a smart watch, a laptop computer, a pager, a smart media device, and the like.

[0033] In some embodiments, the user device 102 may include circuitry used to enable certain device functions, such as telephony. Functional elements for enabling these functions may include one or more processors capable of executing instructions to perform the functions and operations of the user device 102. The processor may access memory of the user device 102 to obtain instructions or data used in executing the instructions, such as serving scripts and mobile applications. The user device 102 may include input / output elements, such as a keyboard, a display, a speaker, a microphone, and / or a touch screen. These I / O elements may be used to enable a user to operate the user device 102 and input data. These input / output elements may also be configured to output data, for example, via the device's speaker. The user device 102 may also output data using a display.

[0034] The user device 102 may include memory that may include applications (e.g., application 116) and / or any other suitable modules or data. The user device 102 may have any number of applications installed or stored in the memory. The memory of the user device 102 may also include code executable by one or more processors to implement the methods described herein. In some embodiments, the memory may be configured to store sensitive data (e.g., payment data (e.g., track 2 data), a private key of a public / private key pair, a certificate including the public key of the public / private key pair). The application 116 may be configured to receive a certificate including the private key and / or the corresponding public key. The public / private key pair may be provided by a certificate authority (e.g., central server computer 108), and the certificate may be authenticated by the certificate authority. In some embodiments, the certificate may be digitally signed using the certificate authority's public key such that the user device's 102 public key may be obtained using the certificate authority's public key and a cryptographic algorithm.

[0035] In some embodiments, the application 116 may be configured to cause a processor of the user device 102 to generate a code (e.g., a QR code, voice-embedded data, etc.) that includes the sensitive data. Once generated, the code may be presented on a display (and / or speaker) of the user device 102 such that the code can be retrieved by a receiving device (e.g., the access device 118).

[0036] The resource provider computer 104 may be operated by or on behalf of a resource provider (e.g., a retailer, etc.), and the transfer computer may be associated with the resource provider. For example, the transfer computer may be operated by an acquirer (e.g., a financial institution) that is responsible for managing accounts associated with the resource provider. The approving entity computer 110 may be operated by an issuer (e.g., another financial institution). In some embodiments, an entity is both an acquirer and an issuer, and embodiments of the present invention include such entities.

[0037] The central server computer 108 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ may process credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ includes the VIP system (Visa Integrated Payments system), which processes authorization requests, and the Base 11 system, which performs the clearing and settlement services.

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

[0039] In some embodiments, the central server computer 108 (or another suitable system) may be configured to be a certification authority. Operating as a certification authority, the central server computer 108 may be configured to generate public / private key pairs for any suitable number of user devices and generate corresponding certificates that include the public key of each key pair. In some embodiments, the central server computer 108 may digitally sign each certificate utilizing a public key associated with the central server computer 108. The central server computer 108 may be further configured to distribute the public key to any suitable number of devices (e.g., the access devices 118).

[0040] The resource provider computer 104 may also have an access device 118 capable of interacting with the user device 102 or receiving communications from the access device 118. In FIG. 1, the access device 118 is located at the resource provider computer 104. However, it 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 retailer). In some embodiments, the resource provider computer 104 may include one or more server computers that may host one or more websites associated with the resource provider (e.g., a retailer). In some embodiments, the resource provider computer 104 may be configured to send data via the forwarding computer 106 to the central server computer 108 as part of a payment verification and / or authentication process for a transaction between a user (e.g., a consumer) and the resource provider. The resource provider computer 104 may also be configured to generate an authorization request message for a transaction between the resource provider and the user 103 and route the authorization request message to the approving entity computer 110 (e.g., via the central server computer 108) for further transaction processing.

[0041] An access device according to an embodiment of the present invention may be in any suitable form. Examples of access devices include a point of sale (POS) device, a mobile phone, a PDA, a personal computer (PC), a tablet PC, a turnstile, a handheld dedicated reader, a set-top box, an electronic cash register (ECR), an automated teller machine (ATM), a virtual cash register (VCR), a kiosk, a security system, an access system, and the like. The access device 118 may include an input / output (I / O) device 120, a processor 122, and a computer-readable medium 124. The I / O device 120 may include an imaging device (e.g., a camera), a digital scanner, a barcode reader, a microphone, and the like, configured to interact with the user device 102. In some embodiments, the access device 118 may be configured to manage access to a resource. As an example, the access device 118 may be located at a turnstile at a transportation gate of a transportation station, and the access device 118 may manage the operation of the turnstile to enable access to a portion of the transportation station.

[0042] In a typical access transaction, the user 103 may utilize the application 116 to generate a visual and / or audio code (e.g., QR code, audio embedded data, etc.) on the user device 102. For example, the application 116 may be utilized to generate a QR code 114 and / or audio 115. To generate the visual and / or audio code (e.g., QR code 114, audio 115, etc.), the user device 102 may obtain interaction data (e.g., payment data such as track 2 data defined in ISO 7813, a certification authority (CA) public key index, a public key certificate associated with the user device 102, a token / ciphertext, etc.) stored in a memory of the user device 102. At least a portion of the interaction data may be stored in response to a registration process performed on the user device 102 with the certification authority (e.g., the central server computer 108) prior to initiation of the access transaction. The user device 102 may further be configured to generate a digital signature utilizing at least a portion of the data fields of the interaction data and a cryptographic algorithm (e.g., an elliptic curve cryptography algorithm). The interaction data and digital signature may be converted into a visual and / or code (e.g., QR code 114 and / or audio 115) and presented on the user device 102 (e.g., via a display and via a speaker, respectively). The user 103 may hold the user device 102 close to the access device 118 such that an I / O device 120 (e.g., a QR scanner, microphone, etc.) may be utilized to capture the visual and / or audio code. A processor 122 of the access device 118 may be configured to convert the captured code to obtain the underlying data (e.g., the interaction data embedded in the QR code 114 and / or audio 115).

[0043] Once converted, the processor 122 of the access device 118 can obtain the CA public key index from the interaction data. The CA public key index may be associated with a particular CA and associated with a particular public key stored in the memory of the access device 118. In some embodiments, the access device 118 may store multiple public keys, each corresponding to a particular CA and each associated with a unique CA public key index. Using the CA public key index of the interaction data, the access device 118 can identify the certificate authority (and its stored public key) of the public key certificate included in the interaction data. The obtained CA public key can be utilized along with the public key certificate of the interaction data as input to a cryptographic algorithm to obtain a public key associated with the user device 102, authenticated by a CA (e.g., the central server computer 108).

[0044] Once obtained, the public key obtained from the certificate and associated with the user device 102 may be utilized to verify the digital signature of the interaction data. In some embodiments, the access device 118 may utilize the digital signature and public key of the user device 102 as inputs to a cryptographic algorithm (such as an elliptic curve cryptography algorithm) to obtain a hash value corresponding to one or more data fields of the interaction data. The one or more corresponding data fields of the interaction data may be rehashed by the access device 118 and the resulting value may be compared to the obtained hash value. If the resulting hash matches the obtained hash, the access device 118 may determine that the interaction data is valid (e.g., unaltered). If the hashes do not match, the access device 118 may determine that the interaction data is invalid (e.g., altered) and no further processing occurs.

[0045] In some embodiments, if the interaction data is determined to be valid, the access device 118 may be configured to compare the timestamp data of the interaction data to the current time to determine whether the visual and / or audio code was generated within a predetermined threshold period (e.g., within the last 10 minutes, within the last 5 minutes, etc.). In some embodiments, if the timestamp data of the interaction data is stale (e.g., indicates a generation time outside the predetermined threshold period), the access device 118 may deny access and no further processing may occur. If the timestamp data of the interaction data indicates a time within the predetermined threshold period, the access device 118 may be configured to obtain an identifier (e.g., an account identifier) ​​from the interaction data. This identifier may be compared by the access device 118 to a stored restriction list (e.g., a list of account identifiers for which access is immediately denied). If the identifier from the interaction data does not match any of the identifiers in the stored restriction list, the access device 118 may be configured to grant access to the user device 102. As an example, if the access device 118 is a ticket barrier at a transportation gate at a transportation station, the access device 118 may enable the ticket barrier to rotate so that the user 103 can access a portion of the transportation station.

[0046] At any suitable time subsequent to enabling access for the user 103 and / or the user device 102, the access device 118 may be configured to have the resource provider computer 104 perform an online authorization process utilizing at least a portion of the interaction data acquired during the offline authentication process. For example, the resource provider computer 104 (or the access device 118) may be configured to generate an "authorization request message" and forward this message to the transfer computer 106. The transfer computer 106 is typically associated with a business entity (e.g., a commercial bank) that has a business relationship with a particular resource provider (e.g., a retailer) or other entity and may be involved in the process of a transaction. The transfer computer 106 may issue and manage accounts for the resource provider and exchange funds with the approving entity computer 110 on behalf of the resource provider. Some entities may perform the functions of both the approving entity computer 110 and the transfer computer 106. An embodiment of the present invention includes an issuer-acquirer computer of such a single entity. After receiving the authorization request message, the transfer computer 106 may transmit the authorization request message to the central server computer 108. The central server computer 108 may then forward the authorization request message to the approving entity computer 110 of the user device 102 or to a third party entity acting on behalf of the approving entity.

[0047] The central server computer 108 may be a network that includes or operates at least one server computer used for processing (e.g., payment processing). The server computer in the central server computer 108 may include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform the functions described herein. In some embodiments, the server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing to service requests from one or more client computers. The server computer may comprise one or more computing devices and may use any of a variety of computer structures, arrangements, and compilations to service requests from one or more client computers. In some embodiments, the central server computer 108 may operate multiple server computers. In such embodiments, each server computer may be configured to process transactions for a given area or to handle a particular type of transaction based on transaction data.

[0048] The central server computer 108 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. The central server computer 108 may include VisaNet™. A network including VisaNet™ can process credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ includes an Integrated Payments system that processes authorization requests and a Base II system that performs clearing and settlement services. The payment processing network may use any suitable wired or wireless network, including the Internet.

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

[0050] The accepting entity computer 110 is typically associated with a business entity (e.g., a bank) that issues and maintains consumer accounts for consumers. The accepting entity computer 110 may also issue payment devices for the consumer accounts, including credit cards, debit cards, and the like.

[0051] After the approving entity computer, or a third party entity acting on behalf of the approving entity, receives the authorization request message, the approving entity computer 110, or a third party entity acting on behalf of the issuer, may send an authorization response message back to the central server computer 108 to indicate whether the current transaction is approved (or not approved). The central server computer 108 then forwards the authorization response message back to the forwarding computer 106. The forwarding computer 106 may then send the response message back to the resource provider computer 104. In some embodiments, the resource provider computer 104 may notify the user device 102 of the transaction (e.g., via a notification, email, or any suitable electronic communication means).

[0052] At the end of the day, the normal clearing and settlement process can be performed by the system 100. The clearing process is the process whereby financial details are exchanged between the acquirer and the issuer to facilitate posting to the user's account and reconciliation of the user's payment status.

[0053] Utilizing the techniques described herein allows for a more secure method for communicating sensitive data. The sensitive data may be embedded in visual and / or audio codes to protect such data from the eyes and ears of unauthorized actors. Additionally, the sensitive data is communicated directly via the reader and / or microphone of the receiving device, reducing the possibility of the data being intercepted and altered or stolen. Utilizing the techniques described herein allows for a reduction in the overall data footprint of the sensitive data while ensuring the same level of security as with conventional techniques. Through the communication of this data, a method of offline authentication is enabled that allows a user to be authenticated on a receiving device in a minimal amount of time without obtaining additional data from a server regarding the user and / or the user device.

[0054] FIG. 2 illustrates a registration method (e.g., method 200) according to some embodiments. Of course, the steps of method 200 may be performed in any suitable order. In the example provided in FIG. 2, the central server computer 108 may act as a certificate authority. Thus, the central server computer 108 may be configured to generate its own public / private key pair and distribute its public key to any suitable number of devices. The central server computer 108 acting as a certificate authority may further be configured to generate public / private key pairs for one or more devices (e.g., user device 102) and distribute certificates including the private key and the corresponding public key to the respective devices. These functions may be accomplished by method 200.

[0055] As an example, the method 200 may begin at step 1, where data may be exchanged between the central server computer 108 (acting as a certification authority) and the access device 118. The access device 118 may request the public key of the central server computer 108, for example, via any suitable user interface and / or application programming interface and / or message. Through receipt of this request, the central server computer 108 may be configured to maintain a mapping indicating that future public keys generated for the central server computer 108 will be provided to the access device 118. In some embodiments, the central server computer 108 may generate a new public / private key pair periodically (e.g., every 24 hours, every 12 hours, etc.). The central server computer 108 may associate its public key with the certification authority's public key index. This index may be any suitable alphanumeric value that uniquely identifies the central server computer 108 from other potential certification authorities.

[0056] In step 2, the central server computer 108 may provide its public key and a certification authority (CA) public key index to the access device 118. This may occur in response to a request from the access device 118. In some embodiments, the public key may be provided within some threshold period of time of creation; that is, the public key may be provided independent of a request from the access device 118. Rather, the new public key may be provided by the central server computer 108 immediately after it is generated.

[0057] In step 3, the access device 118 may store the received public key in local memory along with an association to a CA public key index. In some embodiments, the access device 118 may be configured to store multiple CA public key indexes associated with various certification authorities in a mapping, database, or other suitable storage container. The CA public key index can be used to obtain the associated public key of the CA that corresponds to the CA public key index.

[0058] In step 4, the user device 102 may register with the central server computer 108 (acting as a certification authority). The registration process performed in step 4 may utilize any suitable user interface, application programming interface, or any suitable communication means. By way of example only, the user device 102 may utilize an application (e.g., application 116 of FIG. 1) to provide account information such as name, address, government identification identifier, payment data, and / or the like.

[0059] In step 5, by receiving such data or requesting it directly from the user device 102, the central server computer 108 may be configured to generate a public / private key pair for the user device 102. In some embodiments, the central server computer 108 may generate a public key certificate from a public key associated with the user device 102. Figure 3 shows an example certificate specification 300 (e.g., a public key certificate for the user device 102) according to some embodiments.

[0060] The public key certificate of the user device 102 may include the same, more, or fewer data fields than those shown in Figure 3. Although some of the data fields 1-8 are shown with particular data sizes (in bytes), it should be understood that the data fields may have different data sizes than those illustrated.

[0061] In some embodiments, the public key certificate may include a data field 1 corresponding to a certificate type. In some embodiments, the certificate type may identify a particular formatting specification for the certificate. As an example, the public key certificate may utilize type "14" as shown in FIG.

[0062] In some embodiments, the public key certificate may include a data field 2 that corresponds to a certificate encoding. In the example shown in Figure 3, the public key certificate may utilize an encoding of "00".

[0063] In some embodiments, the public key certificate may include a data field 3 that corresponds to a suite indicator. In the example illustrated in FIG. 3, the suite indicator may identify the algorithm suite to be used with the certified public key associated with the user device 102.

[0064] In some embodiments, the public key certificate may include a data field 4 that corresponds to a certificate expiration date. The certificate expiration date may indicate a date (e.g., in the format of YYYYMMDD, UTC) after which the certificate may be considered expired and unusable. The public key certificate may further include a data field 5 that is the certificate expiration date. The certificate expiration date may indicate a time (e.g., in the format of HHMM, UTC, or any suitable format) associated with the certificate expiration date after which the certificate may be considered expired and unusable.

[0065] In some embodiments, the public key certificate may include a data field 6 corresponding to a certificate serial number. The certificate serial number may be any suitable alphanumeric value that identifies the CA private key used to create the certificate.

[0066] In some embodiments, the public key certificate may include data field 7 corresponding to a public key associated with a device (e.g., user device 102). In some embodiments, the public key associated with the device may be generated based on an elliptic curve algorithm corresponding to the suite indicator (e.g., data field 3). In some embodiments, data field 7 may correspond to the x-coordinate of the public key point on the curve identified by the suite indicator.

[0067] In some embodiments, the public key certificate may include a data field 8 that corresponds to a signature of the public key certificate. Data field 8 may include a digital signature generated by the certification authority utilizing a private key associated with the certification authority. In some embodiments, a digital signature may be associated with each of data fields 1-7 (or any suitable combination of the data fields of the certificate). As a non-limiting example, data fields 1-7 may be hashed using any suitable hash algorithm, and the resulting hash value may be used along with the certification authority's private key as input to a cryptographic algorithm (e.g., an elliptic curve cryptography algorithm) that corresponds to the suite indicator (e.g., data field 3). The resulting value may be stored in data field 8 as the digital signature of the certificate.

[0068] 2, the generated digital certificate and private key associated with the user device 102 may be provided to the user device 102 in step 6. In step 7, the user device 102 may store the digital certificate and private key in local memory for later use.

[0069] At step 8, a user of the user device 102 (e.g., user 103 of FIG. 1 ) may enter any suitable portion of the sensitive data utilizing any suitable user interface of the user device 102 (e.g., a user interface provided by the application 116). As an example, the user may enter payment data (e.g., examples of sensitive data) such as a debit / credit card number, expiration date, and / or associated CVV code. In some embodiments, a camera of the user device 102 may be utilized to capture an image of the debit and / or credit card, and the payment data may be extracted from the image utilizing any suitable image recognition technique. In this context, “payment data” may include any suitable portion of Track 2 equivalent data as defined in ISO 7813. The payment data (and / or any suitable portion of the sensitive data entered by the user) may be stored in a local memory of the user device 102.

[0070] 4 illustrates a flowchart of a method 400 for securely communicating sensitive data to perform offline authentication, according to some embodiments. Method 400 may be performed at any suitable time following performing method 200 of FIG.

[0071] Method 400 may begin at 402, where user device 102 may generate a visual and / or audio code (e.g., QR code 114 of FIG. 1, audio 115 of FIG. 1, etc.). In some embodiments, the generated code may include / embed at least a portion of sensitive data stored in a local memory of user device 102. As an example, by performing step 8 of method 200, the sensitive data may be stored in the local memory. The sensitive data may include any suitable Track 2 equivalent data defined in ISO 7813 and / or any suitable data related to a user. FIG. 5 illustrates an example data specification 500 for a generated code, according to some embodiments.

[0072] In some embodiments, the generated code may include any suitable combination of data fields included in data specification 500. Although a particular data size may be indicated for each data field in data specification 500, it should be understood that these sizes may vary.

[0073] In some embodiments, the generated code may include a payload format indicator. The payload format indicator may be identified with the tag "85" (or any suitable identifier) ​​and / or may define the version of the generated code. As an example, if the generated code is a QR code, the version of the QR code may be indicated using the payload format indicator (e.g., the value "CPV01"). If the generated code is in audio format, the version of the generated code may be indicated using a different payload format indicator. In some embodiments, multiple versions of the generated code may be employed. Thus, the payload format indicator may be utilized by a receiving device (e.g., the access device 118 of FIG. 1) to determine the format of the code.

[0074] In some embodiments, the generated code may include an application template as provided by data specification 500. The application template may be identified with tag "61" (or any suitable identifier) ​​and may serve as a container for application-specific data. By way of example, the application template data field may include one or more subfields, such as an application name field. In some embodiments, the application name field may be identified with tag "4F" (or any suitable identifier). In some embodiments, the application name field may identify a type and / or name of an application that may process and / or generate the data included in data specification 500.

[0075] In some embodiments, the generated code may include a common data template (e.g., a portion of the data specification 500) as provided by the data specification 500. The common data template may be identified with tag "62" (or any suitable identifier) ​​and may be utilized as a container for application data that may be common across various types of applications. As an example, the common data template may include one or more subfields, such as a track 2 equivalent data field, an application exchange profile data field, an application data field, an application cryptogram data field, one or more timestamp data fields, a certification authority public key index, a public key certificate data field, and a digital signature data field.

[0076] The Track 2 equivalent data field may be identified with a tag of "57" (or another suitable identifier). The Track 2 equivalent data field may include any Track 2 data defined in ISO 7813. By way of example, the Track 2 equivalent data may include a Personal Account Number (PAN), as well as an expiration date, a CVV code, a transaction counter, etc. In some embodiments, the Track 2 equivalent data field may vary in size up to some predetermined size (e.g., 19 bytes).

[0077] The application exchange profile data field of the common data template may be identified with a tag of "82" (or another suitable identifier). The application data field may also be included in the common data template. The application data field may be identified with a tag of "9F10" (or another suitable identifier). The application exchange profile data field and / or the application data field may each contain data for the approving entity (e.g., the approving entity computer 110 of FIG. 1) and / or the central server computer (e.g., the central server computer 108 of FIG. 1), respectively. Each of these fields may vary in size. For example, the application exchange profile data field may be 2 bytes long, while the application data field may vary in size up to a predetermined size (e.g., 32 bytes).

[0078] The application cryptogram of the common data template may be identified with a tag of "9F26" (or another suitable identifier). In some embodiments, the cryptogram value may be generated by the user device to identify a particular code. The cryptogram may be unique to the code for which it is generated. In some embodiments, the cryptogram may be of any suitable size (e.g., up to 8 bytes).

[0079] The common data template may include one or more timestamp data fields. For example, the timestamp data may be stored in two data fields. Each of these data fields may be identified by the tags "9F36" and "9F27" (or other suitable identifiers), respectively. The combined data of these two data fields may include the date and / or time the code was generated. In some embodiments, a single data field may be utilized to store such timestamp data.

[0080] The common data template may include a certification authority public key index data field. This data field may be identified by tag "8F" (or another suitable identifier). The certification authority public key index may include a value that identifies the certification authority that generated the public key certificate included in the public key certificate field. In some embodiments, the certification authority public key index may be obtained from this data field and utilized to identify a particular public key corresponding to the certification authority.

[0081] The common data template may include a public key certificate data field. This data field may be identified by the tag "9F46" (or another suitable identifier). In some embodiments, the public key certificate data field may include a digital certificate (e.g., a digital certificate formatted according to the certificate specification 300 of FIG. 3). The public key certificate data field may be of any suitable size to include any suitable combination of the data fields of FIG. 3 that correspond to a public key certificate associated with a particular device (or a particular user and / or account).

[0082] The common data template may further include a digital signature data field. This data field may be identified by the tag "9F4B" (or any suitable identifier). The digital signature data field may include a value corresponding to a digital signature of one or more other data fields of the code. As an example, the user device may be configured to hash all (or a portion) of the values ​​of the other data fields discussed in FIG. 5 to generate a hashed value. The user device may then utilize a private key and a cryptographic algorithm (e.g., an elliptic curve cryptography algorithm) to generate a digital signature value. This value may be stored in the digital signature data field for a subsequent verification process.

[0083] Returning to FIG. 4, at step 402, the user device 102 may generate a code from the sensitive data (e.g., the sensitive data corresponding to the data fields of the data specification 500 of FIG. 5). The sensitive data may be collected from a local memory of the device. In some embodiments, the user device 102 may generate at least a portion of the sensitive data. As an example, the user device 102 may hash any suitable number of data fields of the sensitive data (e.g., the shaded fields shown in FIG. 5 corresponding to the track 2 equivalent data field, the application exchange profile data field, the application data field, and one or more timestamp data fields). The hash value and the user device 102's private key (stored in local memory) may be utilized in a cryptographic algorithm to generate a digital signature. This digital signature may be included in the sensitive data before it is converted into a code and / or utilized in code generation. In some embodiments, the code may be visual, such as a Quick Response (QR) code. In some embodiments, the data discussed in connection with the data specification 500 may be converted into a QR code utilizing any suitable process.

[0084] As a non-limiting example of a conversion / code generation process, the data (e.g., sensitive data) indicated in the data specification 500 may be converted to a base 64 encoded string (e.g., as defined in RFC 4648) and then converted to an ISO 18004 compliant QR Code symbol. In some embodiments, this conversion may utilize the default extended channel interpretation and byte mode. This conversion may further utilize error correction levels L, M, Q, or H, and values ​​of p defined in ISO 18004. In some embodiments, the conversion may determine the minimum QR Code version that will accommodate the data indicated in the data specification 500 (or rather the actual data being converted). Data masking may be performed during this conversion as defined in ISO 18004, and normal orientation and normal reflection arrangement may be utilized in accordance with ISO 18004.

[0085] In some embodiments, rather than (or in addition to) a visual code, the user device 102 may generate an audio code. As a non-limiting example, the user device 102 may utilize any suitable frequency shift keying (FSK) and / or frequency modulation scheme to convert the sensitive data into audio. FSK and / or frequency modulation are intended to refer to techniques whereby digital data may be represented by changes in the frequency (or pitch) of audio tones. This digital data is transmitted as audio, and the embedded data is extracted through interpretation of these pitch changes / modulations.

[0086] At 404, the generated code may be provided to an I / O device of the user device. If the generated code is a visual code (e.g., a QR code embedding sensitive data), the generated code may be provided to a display of the user device 102. If the generated code is an audio code (e.g., an audio embedding sensitive data), the generated code may be presented via a speaker of the user device 102. In some embodiments, the user device 102 may generate a visual code and an audio code and present each of the generated codes via the display and speaker of the user device 102, respectively.

[0087] At 406, the code may be acquired by the access device 118. As an example, the access device 118 may include a barcode reader, scanner, camera, or any suitable input / output (I / O) device configured to capture a visual code (e.g., QR code 114 of FIG. 1). In some embodiments, the visual code may be presented on a display of the user device 102 and read by an I / O device of the access device 118. In some embodiments, the access device 118 may include a microphone or another suitable I / O device configured to capture an audio code (e.g., audio 115 of FIG. 1). Once acquired, the code (or codes) may be transformed according to a predetermined scheme. As an example, a QR code may be converted into binary data to extract the embedded sensitive data. If the code is in the form of audio, various modulations of the audio may be interpreted according to a predetermined scheme to extract the embedded sensitive data.

[0088] At 408, the access device 118 may verify the data extracted from the code. In some embodiments, the access device 118 may obtain a certificate public key index value from the secret data extracted from the code. The access device 118 may utilize the obtained certificate public key index value to perform a lookup and / or search for a public key associated with the certificate public key index value. The access device 118 may potentially store multiple public keys, each associated with a different certificate authority. The certificate public key index value may be utilized to ensure that the correct public key associated with the authenticating certificate authority (e.g., a certificate authority trusted in generating the public key certificate included in the extracted secret data) is used. Once the CA public key is obtained, a cryptographic algorithm (e.g., an elliptic curve cryptography algorithm) may be used to verify that the secret public key certificate has not been altered. By way of example, the CA public key and the certificate's digital signature (e.g., data field 8 of FIG. 3) may be provided as input to the cryptographic algorithm. In some embodiments, the particular cryptographic algorithm used may be specified in the certificate. For example, data field 3 of FIG. 3 may specify the particular algorithm suite utilized to verify the certificate's digital signature. Given the above inputs, the cryptographic algorithm may output a resulting value. The access device 118 may hash one or more data fields (e.g., data fields 1-7 of FIG. 3) of the digital certificate according to a predetermined scheme to calculate a hash value. If the calculated hash value matches the resulting value obtained from the cryptographic algorithm, the certificate may be considered valid (e.g., unaltered). If the calculated hash value does not match the resulting value, the certificate may be considered invalid (e.g., unaltered). If the certificate is invalid, the access device 118 may deny access to the user device 102 and terminate processing.

[0089] If the certificate is determined to be valid, the access device 118 may extract a public key (e.g., data field 7) associated with the user device 102 from the certificate. Using the retrieved public key associated with the user device 102, the access device 118 may verify the sensitive data. For example, the public key associated with the user device 102, a digital signature included with the sensitive data, and / or any suitable portion of the sensitive data may be utilized to verify the sensitive data (e.g., to determine whether the sensitive data has been altered). As a non-limiting example, the public key associated with the user device 102 and the digital signature may be provided as inputs to a cryptographic algorithm (e.g., the same or different cryptographic algorithm utilized above) to obtain a resulting value. A predetermined combination of data fields (e.g., the shaded data fields in FIG. 5 corresponding to the track 2 equivalent data field, the application exchange profile data field, the application data field, and one or more timestamp data fields) may be hashed by the access device 118 to generate a calculated hash value, and the calculated hash value may be compared to the resulting value. If the values ​​match, the access device 118 may be configured to determine that the sensitive data extracted from the code is valid (e.g., unaltered). If the values ​​do not match, the access device 118 may be configured to deny access and terminate processing.

[0090] At 410, the access device 118 may (optionally) process timing constraints. As an example, it may be predetermined that a valid code (e.g., visual or audio code) must be generated within a predefined time period of an access request. That is, it may be predetermined that the code must be generated within 10 minutes, 5 minutes, 30 seconds before the access device 118 obtains and / or processes the code for the code to be valid. Thus, the access device 118 may be configured to compare the current time to the time indicated by one or more timestamp data fields of the sensitive data. In some embodiments, as described above, one or more timestamp data fields of the sensitive data may indicate the date and / or time the code was generated. Of course, in some embodiments, one timestamp data field may indicate the date and another timestamp data field may indicate the time. In some embodiments, a combination of the two timestamp data fields may be utilized to identify the date and / or time the code was generated. If the comparison indicates that the code was generated outside the allotted time period (e.g., more than 10 minutes before the current time), the access device 118 may be configured to deny access and terminate processing. If the comparison indicates that the code was generated within the allotted time period (eg, within 10 minutes before the current time), the access device 118 may perform further actions.

[0091] Instead of or in addition to processing timing constraints, the access device 118 may be configured to process restrictions at 412. In some embodiments, the access device 118 may maintain a list of restricted identifiers that correspond to identifiers for which access is denied. In some embodiments, the access device 118 may extract any suitable identifier from the sensitive data (e.g., an account identifier included in the Track 2 equivalent data field). The extracted identifier may be compared to the list of restricted identifiers. If the extracted identifier matches an identifier on the list, the access device 118 may deny access and terminate processing. If the extracted identifier does not match any of the identifiers on the list, the access device 118 may perform further operations.

[0092] At 414, the access device 118 may be configured to allow or deny access to the user device 102 based on any suitable combination of the operations of 408-412. For example, the access device 118 may be configured to deny access to the user device 102 if the sensitive data is determined to be invalid and / or if the code is determined to be stale (e.g., older than an allotted time period) and / or if the identifier included in the sensitive data matches a restricted identifier. If the sensitive data is valid, the code is generated in a timely manner (if timing constraints are enforced) and the access device 118 may be configured to allow access if the identifier included in the sensitive data does not appear on a restricted list (if a restricted list is used).

[0093] In some embodiments, the access device 118 may support online transactions. In these embodiments, the access device 118 may send an authorization request message at 416 to the approving entity computer 110 (e.g., via the transfer computer 106 and / or the central server computer 108 of FIG. 1). The authorization request message may be any suitable portion of sensitive data. In some embodiments, the authorization request message may include an amount corresponding to payment for permitted access. The approving entity computer 110 may process the data at 418 to generate an authorization response message that may be returned to the access device 118 at any suitable time. This process may be discussed in more depth in connection with FIG. 7.

[0094] FIG. 6 illustrates a flowchart of a method for performing offline authentication, according to some embodiments. Method 600 may be performed by a computing device (e.g., access device 118 of FIG. 1). The computing device may include one or more processors and one or more memories that store computer-executable instructions, where execution of the computer-executable instructions by the one or more processors causes the computing device to perform method 600. The steps illustrated in FIG. 6 and described below may be used in conjunction with the transaction processing description of FIG. 1 and corresponding descriptions thereof, which descriptions are incorporated herein by reference.

[0095] Method 600 may begin at block 602, where a first public key associated with a certification authority (e.g., central server computer 108 of FIG. 1 acting in part as a certification authority) may be received. In some embodiments, the first public key may be distributed by the certification authority in any suitable manner (e.g., by method 200 of FIG. 2).

[0096] The remaining steps of method 600 may be performed by the access device 118 while operating in an offline mode. In some embodiments, the access device 118 may operate in an offline mode to perform its processes when it is not in communication with a remote device (e.g., a resource provider computer, a transfer computer, a central server computer, an approving entity computer, etc.) to perform its processes.

[0097] The method may proceed to 604 where a data packet may be obtained in a one-way communication from a user device (e.g., user device 102 of FIG. 1). The data packet may include any suitable portion of sensitive data and may be in the form of a visual and / or audio code. As an example, the data packet may include the data field of data specification 500 of FIG. 5 and may be in the form of a QR code, audio, or any suitable visual and / or audio code.

[0098] At 606, the data packet may be transformed to obtain the interaction data (e.g., sensitive data contained in the data packet, data fields specified in the data specification 500 of FIG. 5). For example, the data packet may comprise at least a digital certificate authenticated by a certificate authority (e.g., the central server computer 108) and a digital signature value generated by a user device (e.g., the user device 102).

[0099] At 608, a second public key associated with the user device (e.g., the user device 102) may be obtained utilizing a digital certificate associated with a certification authority and the first public key. As an example, the certificate included in the data packet may be verified in a manner similar to that described in 406 of FIG. 4. The first public key and the digital signature of the digital certificate may be input into a cryptographic algorithm to obtain a resultant value. Corresponding data fields of the certificate may be hashed to generate a hash value. If the resultant value matches the hash value, the certificate may be considered valid (e.g., unaltered). If valid, the access device may be configured to obtain a second public key associated with the user device from the certificate.

[0100] At 610, the access device may determine the validity of the interaction data based at least in part on the digital signature value and the second public key associated with the user device. As described above, in connection with 406 of FIG. 4, the second public key and the digital signature value included in the data packet may also be provided to a cryptographic algorithm to generate a resultant value. One or more data fields of the data packet may also be hashed to generate a hash value. If the resultant value matches the hash value, the data packet may be determined to be valid. If the resultant value does not match the expected value, the data packet may be determined to be invalid and no further processing may be performed.

[0101] At 612, when the interaction data is determined to be valid, the access device may be configured to accept an identifier in the interaction data. As an example, an identifier, such as an account identifier, may be obtained from the interaction data (e.g., the transformed data packet data). The access device may maintain a list of restricted identifiers. If the account identifier is found on the list of restricted identifiers, the access device may be configured to deny access and terminate processing.

[0102] At 614, access may be provided by the access device based at least in part on determining that the identifier of the interaction data is authorized (e.g., the account identifier is not on a list of restricted identifiers).

[0103] FIG. 7 illustrates a block diagram of a transaction processing system 700. FIG. 7 illustrates a user 706 (e.g., user 103, FIG. 1) that can operate a user device 710 (e.g., an example of user device 102, FIGS. 1-6). The user 706 can use the user device 710 to pay for goods or services, such as tickets, at a resource provider, such as a retailer. The retailer can operate a resource provider computer 730 and / or an access device 720 (e.g., an example of access device 118, FIGS. 1-6). The retailer can communicate with an approving entity computer 760 (e.g., approving entity computer 110, FIG. 1) operated by an issuer via a transfer computer 740 (e.g., transport computer 106) operated by an acquirer and processing network computer 750 (e.g., an example of central server computer 108, FIG. 1) operating as part of a payment processing network.

[0104] A payment processing network may include data processing subsystems, networks, and operations used to support and deliver authentication services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. A payment processing network such as VisaNet™ may process credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ includes the VIP system (Visa Integrated Payment system), which processes authorization requests, and the Base II system, which performs the clearing and settlement services. A payment processing network may use any suitable wired or wireless network, including the Internet.

[0105] A typical payment transaction flow using the user device 710 at an access device 720 (e.g., a transit ticket barrier) can be described as follows: The user device 710 and the access device 720 can perform the steps of method 400, as described above. If the user device 710 is granted access, a transaction message can be generated by the access device 720 to proceed with a payment associated with the granted access. In some embodiments, the transaction message generated by the access device 720 can include any suitable data, such as any suitable portion of the sensitive data to which access was granted. As an example, the transaction message can include track 2 data indicated in a code generated by the user device 710 and obtained by the access device 720. The transaction message can further indicate an amount (e.g., a payment price) corresponding to the granted access.

[0106] The resource provider computer 730 may receive this information from the access device 720 via an external communications interface. The resource provider computer 730 may generate an approval request message that includes at least a portion of the information received from the access device 720 and electronically transmit this message to the transfer computer 410. The transfer computer 740 may receive, process, and forward the approval request message to the processing network computer 750 for approval.

[0107] Typically, prior to a credit or debit card transaction occurring, the processing network computer 750 has an established protocol with each issuer for how the issuer's transaction should be approved. In some cases, such as when the transaction amount is below a threshold, the processing network computer 750 may be configured to approve the transaction based on information it has about the user's account without generating and sending an authorization request message to the approving entity computer 760. In other cases, such as when the transaction amount is greater than a threshold, the processing network computer 750 may receive the authorization request message, determine the issuer associated with the user device 710, and forward the authorization request message for the transaction to the approving entity computer 760 for verification and approval. Once the transaction is approved, the approving entity computer 760 may generate an approval response message (which may include an approval code indicating that the transaction has been approved or denied) and send this electronic message to the processing network computer 750 via the external communications interface. The processing network computer 750 can then forward the approval response message to the forwarding computer 740, which can send an electronic message including an approval indication to the resource provider computer 730 and subsequently to the access device 720.

[0108] At the end of the day, or at other suitable time intervals, a clearing and settlement process between the resource provider computer 730, the transfer computer 740, the processing network computer 750, and / or the approving entity computer 760 may occur for the transaction.

[0109] FIG. 8 shows a block diagram of a building access system 800. FIG. 8 shows a user device 810 (e.g., user device 102 of FIG. 1) operated by a user 806 (e.g., user 103 of FIG. 1). The user device 810 can interact with an access device 820 (e.g., an example of an access device 118 of the above figure) and pass sensitive data in the form of a code (e.g., a visual and / or audio code) as described above in connection with the method 400 of FIG. 4. The access device 820 can be configured to obtain the sensitive data from the user device 810 via a microphone, scanner, imaging device, or the like. The access device 820 can extract the sensitive data by translating the code in the manner described above. The sensitive data can include a digital certificate associated with the user device 810 and authenticated by a certificate authority, the identity of which can be indicated in the sensitive data (e.g., via a CA public key index). By obtaining and utilizing a public key associated with a certificate authority and stored in a local memory of the access device 820, the access device 820 may obtain a public key associated with the user device 810 from a digital certificate included in the sensitive data. The public key associated with the user device 810 may be utilized to determine whether the sensitive data is valid (e.g., unaltered). For example, a digital signature value generated by the user device 810 and included in the sensitive data may be extracted utilizing a public key associated with the user device 810 and a cryptographic algorithm (e.g., an elliptic curve cryptography algorithm). A number of predefined data fields of the sensitive data may be hashed, and the hash value may be compared to the extracted digital signature value. If the values ​​match, the access device 820 may be configured to determine that the sensitive data is valid (e.g., unaltered). If the values ​​do not match, the access device 820 may be configured to determine that the sensitive data is invalid (e.g., altered). If the data is invalid, the access device 820 may deny access to the building 830.If the data is valid, the access device 820 may grant access to the building 830 or perform further processing.

[0110] In some embodiments, even if the data is determined to be valid, the access device 820 may be configured to perform additional processing. For example, the timestamp data of the sensitive data may be utilized to determine the date and / or time when the code including the sensitive data was generated by the user device 810. If the date and / or time of the code generation is more than a predetermined period before the current time, the access device 820 may deny access to the building 830. If the date and / or time of the code generation is a predetermined period before the current time, the access device 820 may allow access to the building 830 or may perform further processing. For example, instead of or in addition to the timing processing described above, the access device 820 may be configured to check the identifier included in the sensitive data against a list of restricted identifiers. The list of restricted identifiers may include all identifiers for which access is denied. In some embodiments, if the access device 820 determines that the identifier included in the sensitive data is not included in the list of restricted identifiers, the access device 820 may allow access to the building 830. However, if the identifier included in the sensitive data is also included in the list of restricted identifiers, the access device 820 may deny the user 806 access to the building 830 . Technical improvements

[0111] Utilizing the techniques described herein allows for a more secure method for communicating sensitive data. The sensitive data may be embedded in visual and / or audio codes to protect such data from the eyes and ears of unauthorized actors. Additionally, the sensitive data is communicated directly via the reader and / or microphone of the receiving device, reducing the possibility of the data being intercepted and altered or stolen. Utilizing the techniques described herein allows for a reduction in the overall data footprint of the sensitive data while ensuring the same level of security as with conventional techniques. Through the communication of this data, a method of offline authentication is enabled that allows a user to be authenticated on a receiving device in a minimal amount of time without obtaining additional data from a server regarding the user and / or the user device.

[0112] Any of the computing devices described herein may be examples of computer systems that may be used to implement any of the above 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 coupled to a display adapter. Peripheral devices and I / O devices coupled to an input / output (I / O) controller may be connected to the computer system by any number of means known in the art, such as a serial port. For example, an I / O port or an external interface may be used to connect a computer device to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via a system bus may enable a central processor to communicate with each subsystem and control the exchange of information between the subsystems as well as the execution of instructions from the system memory or storage devices. The system memory and / or storage devices may embody a computer-readable medium.

[0113] As described, the services of the present invention may involve implementing 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 execution of a set of instructions or software code by a suitably programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory, or other form of data storage element, accessed by the computing device, microprocessor, or the like. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware or a dedicated processor, integrated circuit, or the like.

[0114] Any of the software components or functions described in this application may be implemented as software code executed by a processor, for example using any suitable computer language, such as, for example, Java, C++, or Perl, using conventional or object-oriented techniques. The software code may 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 a floppy disk, or an optical medium, such as a CD-ROM. Such computer-readable medium may be on or within a single computing device, or may be present on or within different computing devices within a system or network.

[0115] The above description is illustrative and not limiting. Many variations of the invention will become apparent to those skilled in the art upon review of this disclosure. Thus, the scope of the invention should not be determined with reference to the above description, but instead with reference to the appended claims, taken together with their full scope or equivalents.

[0116] 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 invention.

[0117] The terms "a," "an," or "the" are intended to mean "one or more" unless specifically indicated to the contrary.

[0118] All patents, patent applications, publications, and descriptions referred to above are incorporated herein by reference in their entirety for all purposes. None are admitted as prior art.

Claims

1. 1. A computer-implemented method for performing offline authentication, comprising: obtaining, by the access device from the one-way communication, a data packet from the user device; translating, at the access device, the data packet to obtain interaction data including a digital certificate authenticated by a certification authority, an index associated with the certification authority, and a digital signature value generated by the user device; obtaining, at the access device, a first public key associated with the certificate authority based on the index; obtaining, at the access device, a second public key associated with the user device based on the first public key and the digital certificate; determining, at the access device, the validity of the interaction data based at least in part on the digital signature value and the second public key associated with the user device; in response to the interaction data being determined to be valid, verifying at the access device whether a first identifier associated with the interaction data satisfies a first condition; in response to the first identifier satisfying the first condition, verifying at the access device whether a second identifier associated with the user device satisfies a second condition; providing, by the access device, access to a resource based at least in part on the first condition and the second condition being satisfied; A method comprising:

2. The computer-implemented method of claim 1 , wherein the data packet is obtained in the form of a Quick Response (QR) code presented via a display of the user device.

3. The computer-implemented method of claim 1 , wherein the data packets are obtained in the form of audio presented through a speaker of the user device.

4. The computer-implemented method of claim 1 , wherein the digital certificate is authenticated by the certification authority within a threshold period of time before the access device obtains the data packet.

5. The computer-implemented method of claim 1 , wherein the digital signature value is generated using an elliptic curve cryptography algorithm.

6. providing, by the access device, access to the resource based at least in part on the first condition and the second condition being satisfied; comparing, by the access device, the second identifier to a list of stored restricted identifiers; determining, by the access device, that the second identifier is removed from the list of restricted identifiers, and providing access to the resource is based at least in part on determining that the second identifier is removed from the list of restricted identifiers; The computer-implemented method of claim 1 , further comprising:

7. extracting, by the access device, from the interaction data, the first identifier corresponding to a timestamp data field of the interaction data; comparing, by the access device, the timestamp data field to a current time, and wherein providing access to the resource is further based at least in part on comparing the timestamp data field to the current time; The computer-implemented method of claim 1 , further comprising:

8. The computer-implemented method of claim 1 , further comprising the step of performing, by the access device, an online authorization request procedure with a central server computer after providing access to the resource.

9. 2. The computer-implemented method of claim 1, wherein the digital signature value is generated using an elliptic curve cryptography algorithm, a private key associated with the user device, and at least one of a timestamp data field, a public key index data field, and a public key certificate of the interaction data.

10. obtaining, by the access device, the index from the decoded interaction data; obtaining, by the access device, the first public key associated with the certificate authority based at least in part on the index; The computer-implemented method of claim 1 , further comprising:

11. one or more processors; one or more memories for storing computer-executable instructions; and wherein, by executing the computer-executable instructions by the one or more processors, the access device: receiving data packets from a user device in one-way communication; Transforming the data packet to obtain interaction data including a digital certificate authenticated by a certification authority, an index associated with the certification authority, and a digital signature value generated by the user device; Obtaining a first public key associated with the certification authority based on the index; obtaining a second public key associated with the user device based on the first public key and the digital certificate; determining validity of the interaction data based at least in part on the digital signature value and the second public key associated with the user device; responsive to the interaction data being determined to be valid, verifying whether a first identifier associated with the interaction data satisfies a first condition; verifying whether a second identifier of the user device satisfies a second condition in response to the first identifier satisfying the first condition; An access device that provides access to a resource based at least in part on the first condition and the second condition being satisfied.

12. The access device of claim 11 , wherein the data packet is obtained in the form of a Quick Response (QR) code presented via a display of the user device.

13. The access device of claim 11 , wherein the data packets are obtained in the form of audio presented through a speaker of the user device.

14. 12. The access device of claim 11, wherein the digital certificate is authenticated by the certification authority within a threshold period of time before the access device obtains the data packet.

15. The access device of claim 11 , wherein the digital signature value is generated utilizing an elliptic curve cryptography algorithm.

16. By providing access to the resource based on the first condition and the second condition being satisfied, the access device further comparing said second identifier to a list of stored restricted identifiers; determining that the second identifier is to be removed from the list of restricted identifiers; The access device of claim 11 , wherein providing access to the resource is based at least in part on determining that the second identifier is excluded from the list of restricted identifiers.

17. Execution of the computer-executable instructions by the one or more processors causes the access device to further extracting from the interaction data the first identifier corresponding to a timestamp data field of the interaction data; comparing said timestamp data field to a current time; 12. The access device of claim 11, wherein providing access to the resource is further based at least in part on comparing the timestamp data field to the current time.

18. Execution of the computer-executable instructions by the one or more processors causes the access device to further The access device of claim 11, further comprising: a central server computer that performs an online authorization request procedure after providing access to the resource.

19. 12. The access device of claim 11, wherein the digital signature value is generated using an elliptic curve cryptography algorithm, a private key associated with the user device, and at least one of a timestamp data field, a public key index data field, and a public key certificate of the interaction data.

20. Execution of the computer-executable instructions by the one or more processors causes the access device to further obtaining the index by decoding the interaction data; The access device of claim 11 , further comprising: a first public key associated with the certificate authority based at least in part on the index.

Images