System and method for dynamic integration of user-provided data with one-time password authentication password

Abstract

The disclosed systems and methods are directed to improving operational security associated with a one-time password (OTP) authentication card. The proposed solution involves incorporating data values provided by a user, such as a Personal Identity (PIN) and / or password, into a cryptographic process flow for generating a Message Authentication Code (MAC) associated with an OTP Authentication Password. One key operation aspect corresponds to scrambling of data stored by a unique card, such as a shared secret value, with runtime data provided externally by the user. In this manner, the proposed system and method incorporates two identification factors associated with data elements stored by the card and known to the user into the OTP card authentication password.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. patent application Ser. No. 18 / 114,072, filed on February 24, 2023, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to systems and methods for improving the security of an encrypted one-time password (OTP) authentication process associated with an OTP authentication card, and more particularly, to systems and methods for dynamic integration of real-time user-provided data to improve the authentication security associated with OTP card transactions. Background Art

[0004] In electronic communications, verification of the transmission source is a critical step in authenticating the message being sent. This is typically achieved through the encrypted exchange of data records that securely identify the source of incoming electronic transmissions, for example, by uniquely associating a specific incoming password with a particular card. In some cases, the data associated with the encryption process may be generated during the card personalization phase and statically stored, for example, on a one-time password (OTP) authentication card, to facilitate runtime generation of the authentication password, which is then sent to a verification entity. The verification entity decrypts and verifies the authentication password using the data statically stored on the OTP card and one or more data dynamically generated (and sent) by the card at runtime. This cryptographic approach involving both static and dynamic card-stored encrypted data is susceptible to security risks, both in terms of network exposure of the encrypted data and data breaches, which could provide hackers with all the data needed to generate and verify the OTP card password message.

[0005] These and other deficiencies exist. Therefore, there is a need to improve the security of the OTP authentication process. Summary of the Invention

[0006] One aspect of the present disclosure relates to an automated process for improving the security of an encrypted authentication process associated with the operation of an OTP authentication card. The improved security measure can be achieved by incorporating a user-supplied secret data value, such as a user personal identification number (PIN) and / or password, for cryptographically diversifying (e.g., scrambling) one or more cryptographic data parameters (e.g., a shared secret value) associated with the generation and verification of an OTP authentication password.

[0007] Therefore, some embodiments relate to a method for improving the operational security associated with an OTP authentication card, which may include: inserting a challenge signature instruction by an authentication application as part of a runtime command sequence issued when initiating an electronic transaction using the OTP authentication card into a first near field communication (NFC) transmittable command. The challenge signature instruction may be operable to prompt a user-provided response value. In some embodiments, the command sequence may also include a challenge response in addition to or in lieu of the prompted user-provided response value. For example, a first NFC transmittable message provided in response to a challenge signature user prompt may be sent to an OTP authentication card (the OTP authentication card may correspond to a contactless card with an integrated NFC tag that is communicatively coupled to a user transceiver device) along with a personal identification number (PIN) entered by the user. The PIN may not be stored on the OTP authentication card, but may be used directly in the calculation of a MAC used when generating the OTP authentication password. The OTP (contactless) authentication card can then generate a modified message authentication code (MAC) by combining the response value (e.g., PIN) provided by the user with a secret data value (e.g., shared secret value) stored on the OTP card, for example, during the card imprinting phase, using a diversification function through a small program stored thereon. The shared secret value and / or data identifier corresponding to the response value provided by the user can also be stored separately by the corresponding verification process and / or server. The generated modified MAC can then be appended to the data packet.

[0008] Upon receiving the second NFC transmittable message, the data packet with the modified MAC attached may be encrypted by the applet on the contactless card using the second unique session key to generate a modified authentication password. The modified authentication password may then be sent to the corresponding verification server and / or process. The verification server and / or process may then proceed to decrypt the password using previously stored identifier values ​​(such as response values ​​provided by one or more users and / or challenge response values ​​provided by the system and / or application). Following verification of the OTP authentication password, the verification process may also send a verification message to the user via, for example, a user transceiver device, confirming the successful verification of the OTP authentication password.

[0009] In some embodiments of the present disclosure, a first near field communication (NFC) transmittable message may correspond to a write instruction for writing a user-provided response value and / or a system-provided challenge response to an OTP authentication card for use in the calculation of a modified MAC. Accordingly, a second NFC transmittable message may correspond to a read instruction for retrieving an OTP authentication password including a modified MAC from an OTP (contactless) authentication card. In some embodiments, the first NFC transmittable message corresponding to a write instruction for inserting a system- and / or user-provided data value may be part of a (modified) read command sequence associated with initiation of an OTP card authentication transaction.

[0010] Some embodiments of the present disclosure relate to a system for secure authentication of encrypted data, the system comprising: a computer hardware device including an OTP (contactless text messaging) card with an integrated near-field communication (NFC) tag, the OTP card communicatively coupled to an authentication application running on a transceiver device, the authentication application communicating with a corresponding application running on a verification server. The hardware device is configured to cause the authentication application running on the transceiver device to insert a challenge signature instruction into a first NFC Data Exchange Format (NDEF) transmission to the OTP card, wherein the challenge signature instruction operates to prompt for a user-provided response value. In some embodiments, the challenge signature instruction may also include a challenge response, which is sent to the OTP card in place of or in addition to a user-provided response value (e.g., a user PIN and / or password). A first NFC transmittable message along with the user-provided response value may then be sent to the OTP authentication card along with the user-provided response value (e.g., entered via the transceiver device) and / or a system-generated challenge response value. Using the transmitted information including the user PIN and / or challenge response value, the applet stored on the OTP authentication card can generate a modified message authentication code (MAC) by combining the user-provided response value and / or the system-provided challenge response value with a first unique session key stored on the OTP card using a diversification function. According to some embodiments, the first unique session key can correspond to the authentication session key used to generate the MAC. The user-provided PIN and / or challenge response can be used to scramble the unique card-stored parameter value (such as a shared secret value) before incorporating the now-modified unique card-stored parameter value into the calculation of the MAC. The system can also be configured such that the applet on the OTP authentication card (e.g., a contactless card with an NFC tag that stores user identification data in Near Field Communication Data Exchange Format (NDEF)) uses a second unique session key generated by the applet to encrypt the data packet to which the MAC is appended to provide a modified OTP authentication password.

[0011] Once the OTP card generates the password, it can send a password transmission message to the verification server, which includes the modified OTP password and one or more data generated by the OTP authentication card at runtime (for example, ATC value). The verification server can separately store one or more encryption parameters and identifier data used by the OTP card encryption process to generate the password. Using the stored information (for example, the master encryption key, the shared secret value, the user PIN and / or the challenge response) and the transmission data included in the password transmission message and the OTP authentication password, the verification server can decrypt the received OTP authentication password to extract the data packet and the modified MAC. The modified MAC can then be verified using the first unique session key and an identifier from a plurality of identifiers that corresponds to the response value provided by the user.

[0012] Some embodiments of the present disclosure relate to a non-transitory computer-readable medium comprising instructions for execution by a computer hardware device, the computer hardware device comprising an OTP authentication card having an integrated near-field communication (NFC) tag, the NFC tag being communicatively coupled to an authentication application, the authentication application having one or more components running on a transceiver device associated with a user, and one or more components running on a verification server. Upon executing the instructions, the computer hardware device is configured to execute a program comprising the following steps: inserting, by the authentication application, a challenge signature instruction into a first near-field communication (NFC) transmittable message, the challenge signature instruction operating to prompt the transceiver device for a user-provided challenge response value, wherein the first NFC transmittable message corresponds to a write instruction for writing the user-provided challenge response value to the OTP authentication card. Upon receiving the user-provided challenge response value, the authentication application may proceed to send the first NFC transmittable message along with the user-provided challenge response value to an applet on the OTP authentication card. Upon receiving the sent data, the applet may use a diversification function to combine the response value provided by the user with the first unique session key to generate a modified message authentication code (MAC), which is appended to the data packet to generate a modified data packet. Upon receiving the NFC read instruction, the applet may continue to use the second unique session key to encrypt the modified data packet to generate a modified OTP authentication password, which is sent to the verification server, wherein the verification server stores multiple identifiers including the response value provided by the user. Upon receiving the sent information, the verification server may continue to decrypt the modified OTP authentication password to extract the modified data packet including the data packet and the modified MAC, and verify the modified MAC using the first unique session key and an identifier from the multiple identifiers corresponding to the response value provided by the user. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Various embodiments of the present disclosure, as well as other objects and advantages, may be best understood by referring to the following description taken in conjunction with the accompanying drawings.

[0014] Figure 1 A general overview of OTP card configuration and runtime operations associated with generating and verifying OTP card cryptograms using static card-stored data and dynamic card-generated data is shown.

[0015] Figure 2 A security flaw is shown involving OTP card functionality that provides single factor authentication based on static card stored data and dynamic card generated data stored internally on the OTP card.

[0016] Figure 3 An exemplary process flow diagram for generating a two-factor strong OTP authentication password based on internally stored card data and externally provided user input according to some embodiments of the present disclosure is shown.

[0017] Figures 4A-4C Various exemplary embodiments are shown relating to a set of command sequences issued to an OTP card at runtime that incorporate the writing of an externally provided data record into the calculation of an OTP authentication password, according to some embodiments of the present disclosure.

[0018] Figure 5 An exemplary flow chart of an OTP authentication password decryption and verification process according to some embodiments of the present disclosure is shown.

[0019] Figure 6 A flow chart is provided of an OTP card runtime operation sequence based on a modified NDEF read process according to some embodiments of the present disclosure, the process including a pre-read write operation for writing an external user-supplied value into the calculation of the OTP card secret code.

[0020] Figure 7 An exemplary implementation is provided involving a two-round diversified OTP card encryption process utilizing different data values ​​corresponding to a challenge response value provided by the system / application and a PIN value entered by a user at runtime, according to some embodiments of the present disclosure.

[0021] Figure 8 is an illustration of an exemplary block diagram of an exemplary system according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0022] The following description of the embodiments provides reference numbers to particularly describe non-limiting representative examples of features and teachings of different aspects of the present invention. The described embodiments should be considered capable of being implemented separately from or in combination with other embodiments in the description of the embodiments. Those of ordinary skill in the art who have read the description of the embodiments should be able to learn and understand the different described aspects of the present invention. The description of the embodiments should contribute to an understanding of the present invention to the extent that other implementations not specifically covered but within the knowledge of those skilled in the art who have read the description of the embodiments will be understood to be consistent with the application of the present invention.

[0023] Furthermore, the features of the embodiments may be combined in any suitable manner. One of ordinary skill in the art will recognize that an embodiment may be practiced without one or more specific features of an embodiment. In other cases, additional features may be recognized in certain embodiments that may not be present in all embodiments. One of ordinary skill in the art will understand that the described features of any embodiment may be interchangeably combined with features of any other embodiment.

[0024] Figure 1 An overview of OTP card configuration and / or personalization and runtime operations involving sending cryptographic messages to a verification server and / or process 130 is shown. As shown in example 100, the OTP card configuration and / or personalization process may involve generating and storing one or more imprint records on an OTP authentication card 120. The master cryptographic key used to generate the one or more imprint records may be distributed by, for example, a system of record (SOR) to the card manufacturer and / or personalization and verification entity (if separate from the card manufacturer). The card-stored (imprint) data may correspond to a set of uniquely derived card keys (UDK1, UDK2), a globally unique card identifier (UID), and a shared secret value generated, for example, by a card personalization HSM (110) during the card imprinting phase. The shared secret value may also be shared with a backend verification process and / or server 130. In the case where the verification server is associated with a third-party verification HSM, the (shared) secret value may be transmitted to the third-party verification HSM across a network 127.

[0025] Return to reference Figure 1 , runtime operation of the OTP card may involve generating and sending a cryptographic message to the verification server and / or process 130, the cryptographic message may also include runtime card data (e.g., ATC value) and a globally unique identifier (UID) associated with the OTP card 120. The OTP authentication cryptogram (e.g., Figure 2) can be performed, for example, by a MAC verification process 135 stored on the verification server using the stored master keys (MK1, MK2) and the shared secret value (SS) and the card data received via the password transmission message 137. The card stored data sent at runtime can, for example, correspond to the latest ATC value and the globally unique card identifier (UID) recorded by the OTP card 120. For example, the runtime operation can be initiated by performing an OTP card read operation (e.g., by a reader of a mobile device using the NDEF protocol). As described above, at Figure 2 , a process flow for generating an OTP authentication password is also shown.

[0026] Figure 2 The process flow associated with the generation of an OTP cryptogram (e.g., a cryptogram 210 using static card-stored data such as UDK1, UDK2, UID, and a shared secret (SS) value, and dynamic card-stored data such as an application transaction counter (ATC) value, the static card-stored data being generated and stored on the OTP authentication card during imprinting phase operations 201, 202, and 203, and the dynamic card-stored data being generated by the OTP authentication card at runtime) is shown. The aforementioned static and dynamic card-stored data are used to generate first and second unique session keys, which are used, respectively, for the generation of a message authentication code (MAC) and for the encryption of a data packet 209 created by concatenating the MAC with a data payload 208. Figure 2 As shown, an OTP authentication password 210 generated from static and dynamic card stored data 211 (eg, data stored internally on an OTP authentication card) provides single factor authentication based on card specific data.

[0027] As mentioned above Figure 1 and Figure 2 As described, the password generation process provided by the data stored in the OTP card can be equivalent to a single-factor authentication, which is only associated with the identification of the specific OTP card as the source of the OTP authentication transaction, and has nothing to do with the user who initiated the OTP transaction. Figure 3 An exemplary process flow associated with an OTP authentication password generation process 300 is shown that involves inserting a data value known to a user (e.g., a PIN 304) into the calculation of a first unique session key 308 used in the runtime generation of a MAC associated with the OTP authentication password, thereby facilitating two-factor strong authentication that is provided based on internally stored card data and externally provided user input.

[0028] Thus, according to the exemplary embodiment 300, externally provided runtime data (e.g., corresponding to a user PIN 304) can be used in conjunction with internally stored card data 302 to generate a modified MAC 310. This modified MAC can then be appended to a data packet to generate a modified data packet 309. This modified data packet 309 can then be encrypted by a second unique session key 311 to generate an OTP authentication password 310 having two authentication strength factors, the password being provided based on the internally stored card data 302 and the externally provided user input 304. According to some embodiments, this modified data packet can correspond to a 16-byte data packet.

[0029] According to some embodiments, the externally obtained runtime cryptographic input (such as the user PIN 304) used in calculating the modified MAC may not be sent in the OTP password transmission message, but rather stored separately by the back-end verification process. In some embodiments, the user-provided PIN may be temporarily cached by the authentication application (e.g., one or more components of the authentication application running on the user's transceiver device) until a verification response is received from the verification server. The PIN may also be cached by an applet running on the OTP authentication card until a verification response corresponding to the verification of the OTP authentication password is received from the back-end verification process and / or the remote verification server.

[0030] Figures 4A-4C An exemplary command sequence set and transmission data path for implementing an OTP authentication card to obtain an external data record in the calculation of an OTP authentication password is shown. The example provided corresponds to an NDEF command sequence set that can be issued at runtime to an applet running on an OTP authentication card to facilitate writing an externally provided data record in the calculation of an OTP authentication password with two authentication strength factors. For example, according to Figure 4A In the example, the external data obtained at runtime for scrambling the shared secret value corresponds to the challenge response and / or salt value provided with the challenge signature instruction, which may precede the read instruction in the exemplary command sequence 410.

[0031] about Figure 4B , the external data used to scramble the shared secret value obtained at runtime can be provided based on a user prompt message 409 for user input 410, which corresponds to a PIN 411 that can be entered into the user mobile device 404 at runtime. Obtaining the input value provided by the user (e.g., PIN and / or password) and writing and / or updating commands for writing the user-provided input value to the cryptographic MAC generation process can precede the execution of the command with respect to the cryptographic MAC generation process. Figure 4BThe read command in the associated exemplary command sequence 420 .

[0032] The user-supplied PIN 411 may not be stored on the OTP authentication card, but may be used directly in the calculation of the MAC. For example, this may be implemented by scrambling the card-stored shared secret value (now PIN-encrypted) with the user-supplied PIN before including the shared secret value (now PIN-encrypted) in the MAC calculation routine. The foregoing configuration facilitates the creation of a password associated with two-factor strong authentication data that combines OTP card-specific information (verification of something the user would possess) with dynamic user-entered information (e.g., a PIN, which provides verification of something the user would know).

[0033] Figure 4C An exemplary hybrid embodiment is shown in association with an exemplary command sequence 430. The exemplary command sequence 430 corresponds to two rounds of diversification and / or encryption of card stored data values ​​(e.g., shared secret values), one using a system generated data value (e.g., challenge response 412) and another using a runtime user provided PIN 411. Thus, with respect to Figure 4C The external data used to scramble the shared secret value, obtained at runtime, is provided by the system application in the form of a challenge response and, for example, a dynamically transmitted PIN number entered by a user performing an OTP authentication transaction. Thus, the (modified) MAC can be scrambled twice at runtime before being read (e.g., via a read command in command sequence 430). In some embodiments, the diversification operation can correspond to one or more mathematical operations performed on one or more data values ​​to scramble and / or encrypt one data value with another data value. For example, the diversification operation can correspond to performing a logical exclusive OR operation (XOR) between two different data values ​​to diversify / scramble one data value with another data value.

[0034] According to some embodiments, one or more of read command sequences 410, 420, and 430 may be generated by authentication application 406. Authentication application 406 may have one or more components stored on user mobile device 404 and one or more components stored on a remote verification server. Figures 4A-4C The read command sequences 410, 420, and 430 shown in FIG may correspond to modified read commands supplemented with the addition of one or more write commands inserted into the corresponding command sequence before performing the read. Thus, a read command sequence with a write value of zero (e.g., a challenge value of zero) may correspond to a read-only instruction.

[0035] In some embodiments, the OTP authentication card may correspond to a uniquely configured contactless card 402 having an integrated near-field communication (NFC) tag 403 that stores NFC-transmittable user authentication data (e.g., readable by a mobile device 404 running a corresponding application 406). The exemplary contactless card 402 may include an integrated processor 415 (e.g., one or more microprocessors) and memory 416 (e.g., RAM, ROM, and EEPROM). The memory 416 may store, for example, user identification and / or authentication information as near-field communication (NFC)-transmittable data (e.g., NFC Data Exchange Format (NDEF)). The integrated memory 416 may store one or more applets 417 that may be communicatively coupled to one or more applications (e.g., application 406 running on the user's mobile and / or computing device 404 and / or one or more applications stored on a corresponding application server (e.g., verification server 130)). The card-integrated memory 416 may also store an application transaction counter 418 to track the correct sequence of operations associated with transactions conducted using the contactless card 402. The contactless card 402 may also include a near field communication (NFC) interface 403 to facilitate NFC communication with an NFC reader (e.g., a reader component 414 of the mobile device 404). The reader component 414 of the mobile user device 404 may then directly capture the card-stored user authentication information by bringing the contactless card 402 into NFC range of the mobile device 404 (e.g., by tapping the contactless card on a reader of the user's mobile device) to initiate direct reading, processing, and subsequent verification of the user authentication information stored on the contactless card as NFC-transmittable data.

[0036] The user mobile device 404 may include a processor 407, a memory 408, and one or more applications 406. The processor 407 may be a processor, a microprocessor, or other processor, and the user device 404 may include one or more of these processors. The processor 407 may include processing circuitry that may contain additional components necessary to perform the functions described herein, including additional processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tampering hardware.

[0037] Processor 407 may be coupled to memory 408. Memory 408 may be read-only memory, write-once-read-many memory, or read / write memory, such as RAM, ROM, and EEPROM, and user mobile device 404 may include one or more of these memories. Read-only memory may be factory-programmable to read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read multiple times. Write-once-read-many memory can be programmed at some point after the memory chip leaves the factory. Once programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times. Memory 408 may be configured to store one or more software applications, such as application 406, as well as other data, such as a user's private data and financial account information. Application 406 may include, for example, a web browser with one or more browser extensions, a navigation or global positioning system (GPS) application, and one or more banking and / or data collection applications with one or more application programming interface (API) components. User (mobile) equipment 404 can also include one or more input / output (I / O) devices 413, for capturing user input and displaying one or more information records and / or notification messages to the user. For example, I / O device 413 can include at least one display and input device. Display can be the device of any type for presenting visual information, such as computer monitor, flat panel display and mobile device screen, including liquid crystal display, light emitting diode display, plasma panel and cathode ray tube display. Input device can include any device for inputting information into user mobile device 404, it is available and supported by this device such as touch screen, keyboard, mouse, cursor control device, touch screen, microphone, digital camera, video recorder or camcorder. As described herein, these devices can be used to input information and interact with contactless card 402.

[0038] The I / O device 413 associated with the user device 404 may also include an electronic reader 414 for capturing information via one or more short-range communication protocols such as near field communication (NFC). The user mobile device 404 may be configured to send one or more user-related data to the contactless card 402. The user-related data may correspond to one or more user-specified instructions and data parameters, information already stored on the mobile device, and / or user input captured in real time, such as user input requested in response to an actionable notification (such as a user PIN 304).

[0039] The user device (e.g., mobile device 404) can be a network-enabled computer device. Exemplary network-enabled computer devices include, but are not limited to, servers, network appliances, personal computers, workstations, phones, handheld personal computers, personal digital assistants, thin clients, fat clients, Internet browsers, mobile devices, kiosks, contactless cards, or other network-enabled computing or communication devices. For example, a network-enabled computing device may include iPhone, iPod, iPad or other device running Apple Any other mobile device running Microsoft's Any device running Google's Mobile operating system Any device running the operating system and / or any other smartphone, tablet computer or similar wearable mobile device. It should also be understood that the user (mobile) device can be any type of device that supports communication and display of data and user input.

[0040] Applications 406 may include one or more software applications, such as mobile applications and / or web browsers, that include instructions for execution on user device 404. In some examples, user device 404 may execute one or more applications, such as software applications, that enable network communications with, for example, contactless card 402 and / or verification server 130 to send and / or receive data, and perform the functions described herein. When executed by processor 407, one or more applications from applications 406 may provide the functionality described herein, particularly by carrying out and executing the steps and functions of the process flows described herein. Such processes may be implemented in software, such as software modules, for execution by a computer or other machine. The one or more applications may also provide a graphical user interface (GUI) through which a user may view and interact with contactless card 402 and / or verification server 130. Depending on the application used by the user to interact with contactless card 402 and / or verification server 130, the GUI may be formatted as a web page, for example, in Hypertext Markup Language (HTML), Extensible Markup Language (XML), or any other suitable format, for presentation on a display device.

[0041] Figure 5 An exemplary process flow 500 for decrypting a two-factor strong OTP authentication password generated by a contactless card 402 is shown in FIG. Figure 5, the incoming password 501 may be processed by a verification process 502 running on a verification server 503. The process 502 may utilize stored verification data corresponding to the master keys (MK1, MK2), a shared secret (SS) value, and a user PIN value corresponding to the user of a particular OTP authentication card (e.g., contactless card 402). Figure 5 Additionally shown in FIG. 5 is an exemplary runtime verification process flow 502 associated with a verification server 503 .

[0042] Process flow diagram 502 illustrates an exemplary scheme for applying stored master keys MK1, MK2, stored shared secret values, and stored data associated with a user PIN in conjunction with information included in an OTP password transmission message 501, such as the UID and the most recent ATC value required to derive the encrypted session key 311 to decrypt the OTP authentication password sent in the password transmission message 501. Once the OTP authentication password is decrypted using the encrypted session key 311, the stored verification data and the sent ATC value may be used to calculate the authentication session key 308.

[0043] like Figure 5 As shown, the encryption session key 311 can be generated by the runtime verification process 502 by cryptographically combining the transmitted ATC value with UDK2 (derived by encrypting the transmitted UID with the stored MK2). Similarly, the authentication session key 308 can be generated by cryptographically combining the transmitted ATC value with UDK1 (derived by encrypting the transmitted UID with the stored MK1), the PIN 304, and the shared secret value 303 stored on the verification server and / or a data storage device communicatively coupled to the verification server. Thus, as shown in the runtime verification process flow 502, an additional layer of encryption / decryption security can be implemented by cryptographically combining UDK1 with the shared secret value scrambled with the PIN.

[0044] According to some embodiments, the verification server 503 can be a network-enabled computer device. Exemplary network-enabled computer devices include, but are not limited to, servers, network appliances, personal computers, workstations, phones, handheld personal computers, personal digital assistants, thin clients, fat clients, Internet browsers, mobile devices, kiosks, contactless cards, or any other network-enabled computing and / or communication devices.

[0045] The verification server 503 may include a processor 504, a memory 505, and one or more applications 506. The processor 504 may be a processor, a microprocessor, or other processor, and the verification server 503 may include one or more of these processors. The processor 504 may include processing circuitry that may contain additional components necessary to perform the functions described herein, including additional processors, memory, error and parity check / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tampering hardware.

[0046] Processor 504 may be coupled to memory 505. Memory 505 may be read-only memory, write-once-read-many memory, or read / write memory, such as RAM, ROM, and EEPROM, and verification server 503 may include one or more of these memories. Read-only memory may be factory programmable to be read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read multiple times. Write-once-read-many memory may be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times. Memory 505 may be configured to store one or more software applications, such as application 506, as well as other data, such as a user's private identification data and financial account information.

[0047] Applications 506 may include one or more software applications that include instructions for execution on verification server 503. In some examples, verification server 503 may execute one or more applications, such as software applications, that enable network communications with, for example, mobile device 404 and / or contactless card 402 to send and / or receive data and perform the functions described herein. When executed by processor 504, applications 506 may provide the functionality described herein, particularly implementing and executing the steps and functions in the process flow associated with process 502. For example, applications 506 may include one or more data collection applications having one or more application programming interface (API) components to facilitate, when executed, one or more data collection operations for retrieving data values ​​from mobile device 404, contactless card 402, and / or database 507.

[0048] The database 507 may be one or more databases configured to store data, including but not limited to one or more user identification and / or financial account information and one or more merchant-specific transaction histories. The database 507 may include a relational database, a non-relational database, or other database implementations and any combination thereof, including a combination of multiple relational and non-relational databases. In some examples, the database 507 may include a desktop database, a mobile database, or an in-memory database. In addition, the database 507 may be hosted internally by the verification server 503, or may be hosted externally to the verification server 503, such as hosted by a server, a cloud-based platform, or any storage device that communicates data with the verification server 503. The database 507 may also store processed user information (e.g., related to user transaction behavior and purchasing patterns) compiled and calculated by the verification server 503 and / or user computing and / or mobile device 404.

[0049] Figure 6 A flowchart 600 is provided illustrating an exemplary OTP card runtime operation sequence 620 based on a modified NDEF read process (e.g., generated at step 610). The runtime operation sequence 620 includes a pre-read write operation 621 for inserting a data value provided by an external user into the calculation of the OTP authentication secret. When initiating an NFC read of the OTP authentication card, the user may be prompted to enter a PIN (e.g., to authenticate an online electronic transaction). The write operation may also involve inserting a challenge response and / or salt value, which may be sent to the OTP card at runtime.

[0050] Referring back to exemplary embodiment 600, step 603 illustrates the personalization phase of the OTP card associated with the configuration and runtime operation (e.g., password generation) of the OTP authentication card for generating and storing one or more imprint records. One or more imprint records (e.g., unique card key, SS value, card UID) stored on the OTP authentication card may be required in combination with one or more input data values ​​generated and / or provided at runtime to generate the OTP authentication password. Similarly, as shown in step 606, the relevant data required for the verification of the OTP authentication password may also be stored with the back-end verification process. The verification data may include the unique card key and the shared secret value, as well as one or more pre-specified data values ​​corresponding to dynamically generated (external to the card) runtime data that may be used to generate the OTP authentication password. In some embodiments associated with a third-party verification entity, the relevant password verification data may be stored on the corresponding verification HSM.

[0051] Reference Figure 6The OTP card personalization phase 603 may involve generating and storing an imprint record (e.g., a shared secret value, UDK 1, UDK 2, and UID) on the integrated memory of the OTP authentication card. As shown in flowchart 600, the role of the authentication entity, including the storage of a master key as part of the cryptographic verification function (step 606), may also be implemented by a backend verification process to implement a runtime operation sequence 620. The runtime OTP card operation sequence 620 includes the generation of a (modified) OTP authentication cryptogram (steps 621, 622, 623) and the transmission and verification of the modified OTP authentication cryptogram (steps 624 and 625).

[0052] The generation of the modified MAC at step 622 and the generation of the modified OTP authentication password at step 623 can be mediated by step 622.1 corresponding to concatenating the generated modified MAC with the data payload and step 622.2 corresponding to encrypting the resulting (modified) data packet using the session encryption key. The session encryption key can be generated by diversifying the unique card key (UDK2) stored on the OTP authentication card with the runtime generated ATC value. In some embodiments, the data payload can correspond to a randomly generated 8-byte number.

[0053] As indicated above, with respect to example 600, the runtime OTP card operation sequence 620 may also include verification of the OTP password as shown by step 624. The verification process may include (server-side) calculation of encryption and authentication session keys (e.g., Figure 5 The process flow 502 in FIG. 5 is used to extract and authenticate the modified MAC and verify the modified OTP authentication password. After successfully verifying the modified OTP authentication password, a verification response can be sent back to the request source at step 625. For example, the request source can correspond to a transceiver device (e.g., a user mobile device) that initiated the OTP authentication card read.

[0054] In some embodiments, the pre-read write operation may involve a challenge signature command issued at runtime, where a challenge response and / or salt value is included in the command sequence and sent to the OTP authentication card at runtime. The challenge response value can then be used by the associated card-stored applet to diversify and / or scramble one or more card-stored data values ​​(e.g., a shared secret value stored on the OTP authentication card during the card imprinting phase 603). The scrambled data value can then be combined with other card-stored data parameters (such as UDK1) and runtime-generated card data (such as the ATC value) to generate a MAC. This MAC can then be appended to the data payload and encrypted with the cryptographic session key to generate a cryptogram.

[0055] Figure 7FIG. 7 shows an exemplary embodiment of an OTP authentication card runtime encryption process 700 involving two rounds of diversification using different data values. Figure 7 The two rounds of diversification shown may correspond to scrambling and / or diversifying a card-stored data value (e.g., shared secret value 303) using two different external data values. In the exemplary embodiment 700, the two different data values ​​correspond to a system-generated challenge response and / or salt value 704 (which may be provided in a pre-read write and / or update instruction) and a user-provided PIN 304 (which may be entered by the user of the OTP card). As described above, such externally provided runtime data (e.g., challenge response and / or user PIN) that may be used to generate the OTP authentication secret 710 may not be included in the OTP secret transmission message, which includes, for example, the secret 710 and one or more card-stored data such as the UID and ATC values. Thus, in addition to the card-stored data, the exemplary process 700 may also incorporate the system-generated data value 704 and the user-provided data value 705 into the encryption process used to calculate the OTP authentication secret, further enhancing the security of the OTP card authentication process. In some embodiments, relevant data used in password generation (e.g., shared secret value, challenge response, user PIN) can be stored separately by the back-end verification process and / or entity and used in conjunction with the stored master keys (MK1 and MK2) and OTP transmission data (e.g., UID, ATC) to decrypt the OTP message and verify the MAC.

[0056] Figure 8 A block diagram of an exemplary embodiment of a system according to the present disclosure is shown. For example, the exemplary processes according to the present disclosure described herein may be performed by a processing device and / or computing device (e.g., a computer hardware device) 805. Such processing and / or computing device 805 may be, for example, all or part of a computer and / or processor 810, or include, but are not limited to, a computer and / or processor 810, which may include, for example, one or more microprocessors and use instructions stored on a computer-accessible medium (e.g., RAM, ROM, hard drive, or other storage device).

[0057] like Figure 8As shown, for example, a computer-accessible medium 815 (e.g., a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc., or a combination thereof, as described herein above) may be provided (e.g., in communication with the processing device 805). The computer-accessible medium 815 may contain executable instructions 820 thereon. Additionally or alternatively, a storage device 825 may be provided separately from the computer-accessible medium 815, which may provide instructions to the processing device 805 to configure the processing device to perform, for example, the exemplary programs, processes, and methods described herein above.

[0058] Additionally, the exemplary processing device 805 may be provided with or include input and / or output ports 835, which may include, for example, a wired network, a wireless network, the Internet, an intranet, data collection probes, sensors, etc. Figure 8 As shown, the exemplary processing device 805 can communicate with an exemplary display device 830. According to some exemplary embodiments of the present disclosure, the display device 830 can be a touch screen that is configured to input information to the processing device in addition to outputting information from the processing device. In addition, the exemplary display device 830 and / or the storage device 825 can be used to display and / or store data in a user-accessible format and / or a user-readable format.

[0059] In some aspects, the technology described herein relates to a method for improving the security of operations associated with an OTP authentication card, the method comprising: inserting, by an authentication application, a challenge signature instruction into a first near field communication (NFC) transmittable message, the challenge signature operation being a prompt for a user-provided challenge response value, and the first NFC transmittable message corresponding to a write instruction for writing the user-provided challenge response value to the OTP authentication card; sending, by the authentication application, the first NFC transmittable message along with the user-provided challenge response value to an applet running on the OTP authentication card having an integrated NFC tag; and combining the user-provided response value with a first unique session key using a diversification function. The first unique session key and the second unique session key are combined to generate a modified message authentication code (MAC), which is appended to the data packet to generate a modified data packet; the modified data packet is encrypted using the second unique session key to generate an OTP authentication password, which is sent to the verification server, wherein the verification server stores multiple identifiers including the response value provided by the user; the OTP authentication password is decrypted by the verification server to extract the modified data packet including the data packet and the modified MAC; and the modified MAC is verified by the verification server using the first unique session key and an identifier from the multiple identifiers corresponding to the response value provided by the user.

[0060] In some aspects, the technology described herein relates to a method in which an OTP authentication password is generated upon receiving a second NFC transmittable message corresponding to a read instruction for retrieving the OTP authentication password from an OTP authentication card.

[0061] In some aspects, the technology described herein relates to a method in which a challenge response value provided by the user corresponds to a personal identification number (PIN) entered into a transceiver device associated with the user.

[0062] In some aspects, the techniques described herein relate to a method in which the PIN is cached by one or more components of an authentication application running on a transceiver device until a verification message is received from a verification server.

[0063] In some aspects, the technology described herein relates to a method in which the PIN is cached by an applet running on an OTP authentication card until a verification message is received from a verification server.

[0064] In some aspects, the technology described herein relates to a method in which a first unique session key is generated by diversifying a corresponding first unique identifier with a shared secret value stored on an OTP authentication card and an application transaction counter (ATC) value generated at runtime for a specific OTP authentication transaction.

[0065] In some aspects, the technology described herein relates to a method wherein the challenge signing instruction further includes a challenge response value that operates to scramble the shared secret value to generate a modified MAC corresponding to two rounds of encryption.

[0066] In some aspects, the technology described herein relates to a method in which the shared secret value is generated separately by an applet stored on the OTP authentication card and the verification server.

[0067] In some aspects, the technology described herein relates to a method wherein scrambling of the shared secret value with the challenge response value included in the challenge signing instruction corresponds to a diversification function used in combining a user-supplied response with a first unique session key.

[0068] In some aspects, the technology described herein relates to a method in which the diversification function includes performing a logical exclusive-OR operation on two or more data values ​​that are concatenated.

[0069] In some aspects, the technology described herein relates to a method in which a second NFC transmittable message and a first NFC transmittable message are combined into a modified read command that includes challenge response instructions for writing a challenge response value to an OTP authentication card, wherein a challenge value of zero corresponds to a read-only instruction.

[0070] In some aspects, the technology described herein relates to a method in which a plurality of identifiers including user-provided response values ​​are stored in a database communicatively coupled to a verification server.

[0071] In some aspects, the techniques described herein relate to a method in which the modified data packet corresponds to a 16-byte data packet.

[0072] In some aspects, the technology described herein relates to a method in which a shared secret value is generated separately by an applet stored on the OTP authentication card and the verification server.

[0073] In some aspects, the technology described herein relates to a method in which an authentication password combines two authentication factors in the creation of a modified MAC by incorporating a user-provided response value and a corresponding first unique identifier stored on an OTP authentication card into the calculation of a first unique session key used to generate the modified MAC.

[0074] In some aspects, the technology described herein relates to a system for secure authentication of encrypted data, the system comprising: a computer hardware device comprising an OTP authentication card with an integrated near field communication (NFC) tag, the OTP authentication card being communicatively coupled to an authentication application, the authentication application having one or more components running on a transceiver device associated with a user, and one or more components running on a verification server, the hardware device being configured to: insert, by the authentication application, a challenge signature instruction into a first near field communication (NFC) transmittable message, the challenge signature instruction operating to prompt for a user-provided challenge response value, wherein the first NFC transmittable message corresponds to a write instruction for writing the user-provided challenge response value onto the OTP authentication card; and send, by the authentication application, the first NFC transmittable message together with the user-provided challenge response value to a small program running on the OTP authentication card, wherein wherein the challenge response value provided by the user is input via the transceiver device in response to a user prompt generated by the authentication application; combining the user-provided response value with a first unique session key using a first diversification function to generate a modified message authentication code (MAC), the modified MAC being appended to a data packet to generate a modified data packet; encrypting the modified data packet using a second unique session key to generate a two-factor strong OTP authentication password, the two-factor strong OTP authentication password being sent to a verification server, wherein the verification server stores a plurality of identifiers including the user-provided response value; decrypting the two-factor strong OTP authentication password by the verification server to extract a modified data packet including the data packet and the modified MAC; and verifying the modified MAC by the verification server using the first unique session key and an identifier from the plurality of identifiers corresponding to the user-provided response value.

[0075] In some aspects, the technology described herein relates to a system in which the two-factor strong OTP authentication password is retrieved from an OTP authentication card using a reader of a transceiver device and sent to a verification server in response to a second NFC transmittable message corresponding to an NFC read instruction.

[0076] In some aspects, the technology described herein relates to a system in which a user-provided response value corresponds to one or more of a personal identification number (PIN) and a user password entered by the user into a transceiver device.

[0077] In some aspects, the technology described herein relates to a system wherein the challenge signing instructions further include a challenge response value that operates to scramble a shared secret value used to generate a modified MAC, thereby generating a modified MAC corresponding to two rounds of diversification.

[0078] In some aspects, the technology described herein relates to a non-transitory computer-readable medium comprising instructions executed by a computer hardware device, the computer hardware device comprising an OTP authentication card having an integrated near field communication (NFC) tag, the OTP authentication card being communicatively coupled to an authentication application, the authentication application having one or more components running on a transceiver device associated with a user, and one or more components running on a verification server, wherein, when the instructions are executed, the computer hardware device is configured to perform a program comprising the following steps: inserting, by the authentication application, a challenge signature instruction into a first near field communication (NFC) transmittable message, the challenge signature instruction operating to prompt the transceiver device for a user-provided challenge response value, wherein the first NFC transmittable message corresponds to a write instruction for writing the user-provided challenge response value to the OTP authentication card; inserting, by the authentication application, a challenge signature instruction into the first NFC transmittable message, the challenge signature instruction operating to prompt the transceiver device for a user-provided challenge response value, wherein the first NFC transmittable message corresponds to a write instruction for writing the user-provided challenge response value to the OTP authentication card; C can send a message together with the challenge response value provided by the user to the applet on the OTP authentication card; use a diversification function to combine the response value provided by the user with the first unique session key to generate a modified message authentication code (MAC), and the modified MAC is attached to the data packet to generate a modified data packet; use a second unique session key to encrypt the modified data packet to generate a modified OTP authentication password, and the modified OTP authentication password is sent to the verification server, wherein the verification server stores multiple identifiers including the response value provided by the user; the modified OTP authentication password is decrypted by the verification server to extract the modified data packet including the data packet and the modified MAC; and use the first unique session key and an identifier from the multiple identifiers corresponding to the response value provided by the user to verify the modified MAC.

[0079] As used herein, the term "card" is not limited to a specific type of card. On the contrary, it will be understood that, unless otherwise specified, the term "card" may refer to a contact-based card, a contactless card, or any other card. It will also be understood that the present disclosure is not limited to cards with specific purposes (e.g., payment cards, gift cards, identification cards, membership cards, transportation cards, access cards), cards associated with specific types of accounts (e.g., credit accounts, debit accounts, membership accounts), or cards issued by specific entities (e.g., commercial entities, financial institutions, government entities, social clubs). On the contrary, it will be understood that the present disclosure includes cards with any purpose, account association, or issuing entity.

[0080] The systems and methods described herein can provide for secure retrieval of sensitive user information, or enable streamlined communication and processing of sensitive user information, for example, to facilitate secure electronic transactions. Once a valid authorization response from an authenticated user has been established, the automated data retrieval and transmission systems and processes can allow, but are not limited to, financial transactions (e.g., credit and debit card transactions), account management transactions (e.g., card refresh, card replacement, and new card addition transactions), membership transactions (e.g., join and leave transactions), point of access transactions (e.g., building access and secure store access transactions), transportation transactions (e.g., ticketing and boarding transactions), and other transactions.

[0081] As used herein, personally identifiable information (PII) may include any sensitive data, including financial data (e.g., account information, account balances, account activity), personal information and / or personally identifiable information (e.g., social security number, home or work address, date of birth, telephone number, email address, passport number, driver's license number), access information (e.g., passwords, security codes, authorization codes, biometric data), and any other information that a user may wish to avoid disclosure to unauthorized persons.

[0082] The present disclosure is not limited by the specific embodiments described in this application, which are intended to illustrate various aspects. Obviously, many modifications and variations can be made without departing from its spirit and scope. In addition to those methods and devices listed herein, functionally equivalent methods and devices within the scope of the present disclosure are apparent from the foregoing representative descriptions. Such modifications and variations are intended to fall within the scope of the appended representative claims. The present disclosure is limited only by the terms of the appended representative claims and the full range of equivalents to which such representative claims are entitled. It should also be understood that the terms used herein are merely for the purpose of describing specific embodiments and are not intended to be limiting.

[0083] It should also be noted that the systems and methods described herein may be tangibly embodied in one or more physical media, such as, but not limited to, compact discs (CDs), digital versatile discs (DVDs), floppy disks, hard disks, read-only memories (ROMs), random access memories (RAMs), and other physical media capable of storing data. For example, a data storage device may include random access memories (RAMs) and read-only memories (ROMs), which may be configured to access and store data and information as well as computer program instructions. A data storage device may also include a storage medium or other suitable type of memory (e.g., RAM, ROM, programmable read-only memories (PROMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic disks, optical disks, floppy disks, hard disks, removable cassettes, flash drives, any type of tangible and non-transitory storage media) in which files including an operating system, applications including, for example, web browser applications, email applications, and / or other applications, and data files may be stored. The data storage device of a network-enabled computer system may include electronic information, files, and documents stored in a variety of ways, including, for example, flat files, indexed files, hierarchical databases, relational databases, such as those used from, for example, Corporation's software, Excel files, Access files are created and maintained in a database, solid-state storage devices (which may include flash arrays, hybrid arrays, or server-side products), enterprise storage (which may include online or cloud storage), or any other storage mechanism. Furthermore, the figures separately illustrate various components (e.g., servers, computers, processors, etc.). Functions described as being performed at various components may be performed at other components, and the various components may be combined or separated. Other modifications are also possible.

[0084] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing and / or processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing and / or processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing and / or processing device.

[0085] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional program programming languages ​​such as "C" programming language or similar programming languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, by using the Internet of an Internet service provider). In certain embodiments, the electronic circuit comprising, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit, thereby performing aspects of the present invention.

[0086] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, executed via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified herein. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to operate in a certain manner such that the computer-readable storage medium having the instructions stored therein comprises an article of manufacture containing instructions for implementing various aspects of the functions specified herein.

[0087] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable apparatus, or other device to perform the functions specified herein.

[0088] The embodiments of the various techniques described herein may be implemented in digital electronic circuits, or in computer hardware, firmware, software, or a combination thereof. The embodiments may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, such as in a machine-readable storage device or in a propagated signal, for execution or control of its operation by a data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). Computer programs such as the computer programs described above may be written in any form of programming language (including compiled or interpreted languages) and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. The computer program may be deployed to execute on one or more computers at one location, or distributed across multiple locations and interconnected by a communication network.

[0089] The method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. The method steps may also be performed by, and the apparatus may be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0090] In the foregoing description, various embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes may be made thereto, and that additional embodiments may be implemented, without departing from the broader scope of the present invention as set forth in the appended claims. Accordingly, the description and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method for improving operational security associated with an OTP authentication card, the method comprising: inserting, by the authentication application, a challenge signature instruction into a first near field communication (NFC) transmittable message, the challenge signature instruction being operative to prompt for a user-provided challenge response value, and the first NFC transmittable message corresponding to a write instruction for writing the user-provided challenge response value to an OTP authentication card; sending, by the authentication application, the first NFC transmittable message together with the challenge response value provided by the user to an applet running on an OTP authentication card with an integrated NFC tag; combining the user-provided response value with the first unique session key using a diversification function to generate a modified message authentication code (MAC), the modified MAC being appended to the data packet to generate a modified data packet; encrypting the modified data packet using a second unique session key to generate an OTP authentication password, which is sent to a verification server, wherein the verification server stores a plurality of identifiers including the response value provided by the user; decrypting, by the verification server, the OTP authentication password to extract the modified data packet including the data packet and the modified MAC; and The modified MAC is verified by the verification server using the first unique session key and an identifier from the plurality of identifiers that corresponds to the user-supplied response value.

2. The method according to claim 1, wherein The OTP authentication password is generated upon receiving a second NFC transmittable message corresponding to a read instruction for retrieving the OTP authentication password from the OTP authentication card.

3. The method according to claim 1, wherein The challenge response value provided by the user corresponds to a personal identification number (PIN) entered into a transceiver device associated with the user.

4. The method according to claim 3, wherein: The PIN is cached by one or more components of the authentication application running on the transceiver device until a verification message is received from the verification server.

5. The method according to claim 3, wherein: The PIN is cached by the applet running on the OTP authentication card until a verification message is received from the verification server.

6. The method according to claim 1, wherein The first unique session key is generated by diversifying a corresponding first unique identifier with a shared secret value stored on the OTP authentication card and an application transaction counter (ATC) value generated at runtime for a specific OTP authentication transaction.

7. The method according to claim 6, wherein: The challenge signature instruction also includes a challenge response value that operates to scramble the shared secret value to generate a modified MAC corresponding to two rounds of encryption.

8. The method according to claim 6, wherein: The shared secret value is generated separately by the applet and the verification server and is stored in the OTP authentication card.

9. The method according to claim 7, wherein: The scrambling of the shared secret value with the challenge response value included in the challenge signing instruction corresponds to the diversification function used when combining the user-supplied response with the first unique session key.

10. The method according to claim 1, wherein The diversification function includes performing a logical exclusive-OR operation on two or more data values ​​that are combined.

11. The method according to claim 1, wherein The second NFC transmittable message and the first NFC transmittable message are combined into a modified read command, the modified read command including a challenge response instruction for writing a challenge response value to the OTP authentication card, wherein a challenge value of zero corresponds to a read-only instruction.

12. The method according to claim 1, wherein The plurality of identifiers including the user-provided response values ​​are stored in a database communicatively coupled to the authentication server.

13. The method according to claim 1, wherein The modified data packet corresponds to a 16-byte data packet.

14. The method according to claim 6, wherein The shared secret value is generated separately by the applet stored on the OTP authentication card and the verification server.

15. The method according to claim 1, wherein The authentication password combines two authentication factors in the creation of the modified MAC by incorporating the user-provided response value and the corresponding first unique identifier stored on the OTP authentication card into the calculation of the first unique session key used to generate the modified MAC.

16. A system for secure authentication of encrypted data, the system comprising: A computer hardware apparatus comprising an OTP authentication card having an integrated near field communication (NFC) tag, the OTP authentication card communicatively coupled to an authentication application having one or more components running on a transceiver device associated with a user and one or more components running on a verification server, the hardware apparatus being configured to: inserting, by the authentication application, a challenge signature instruction into a first near field communication (NFC) transmittable message, the challenge signature instruction operative to prompt for a user-provided challenge response value, wherein the first NFC transmittable message corresponds to a write instruction for writing the user-provided challenge response value onto the OTP authentication card; sending, by the authentication application, the first NFC transmittable message along with the user-provided challenge response value to an applet running on the OTP authentication card, wherein the user-provided challenge response value is entered via the transceiver device in response to a user prompt generated by the authentication application; combining the user-provided response value with a first unique session key using a first diversification function to generate a modified message authentication code (MAC), the modified MAC being appended to the data packet to generate a modified data packet; encrypting the modified data packet using a second unique session key to generate a two-factor strong OTP authentication password, which is sent to the verification server, wherein the verification server stores a plurality of identifiers including the response value provided by the user; decrypting, by the verification server, the two-factor strong OTP authentication password to extract the modified data packet including the data packet and the modified MAC; and The modified MAC is verified by the verification server using the first unique session key and an identifier from the plurality of identifiers that corresponds to the user-supplied response value.

17. The system according to claim 16, wherein: The two-factor strong OTP authentication password is retrieved from the OTP authentication card using a reader of the transceiver device and is sent to the verification server in response to a second NFC transmittable message corresponding to an NFC read command.

18. The system according to claim 16, wherein: The user-provided response value corresponds to one or more of a personal identification number (PIN) and a user password entered into the transceiver device by the user.

19. The system according to claim 16, wherein: The challenge signature instructions also include a challenge response value that operates to scramble the shared secret value used to generate the modified MAC, thereby generating a modified MAC corresponding to two rounds of diversification.

20. A non-transitory computer-readable medium comprising instructions for execution by a computer hardware apparatus comprising an OTP authentication card having an integrated near field communication (NFC) tag, the OTP authentication card communicatively coupled with an authentication application having one or more components executing on a transceiver device associated with a user and one or more components executing on a verification server, wherein: When executing the instructions, the computer hardware device is configured to perform a program comprising the following steps: inserting, by the authentication application, a challenge signature instruction into a first near field communication (NFC) transmittable message, the challenge signature instruction operative to prompt the transceiver device for a user-provided challenge response value, wherein the first NFC transmittable message corresponds to a write instruction for writing the user-provided challenge response value to the OTP authentication card; The authentication application sends the first NFC transmittable message together with the challenge response value provided by the user to the applet on the OTP authentication card; combining the user-provided response value with the first unique session key using a diversification function to generate a modified message authentication code (MAC), the modified MAC being appended to the data packet to generate a modified data packet; encrypting the modified data packet using a second unique session key to generate a modified OTP authentication password, which is sent to a verification server, wherein the verification server stores a plurality of identifiers including the response value provided by the user; decrypting, by the verification server, the modified OTP authentication password to extract the modified data packet including the data packet and the modified MAC; and The modified MAC is verified using the first unique session key and an identifier from the plurality of identifiers that corresponds to the user-supplied response value.

Images