System and method for parallel manufacturing and authentication of one-time password authentication cards

Abstract

The disclosed systems and methods relate to a novel embodiment provided by an encryption service that eliminates the need for network communication between a card manufacturing / personalization entity and a verification entity during a card personalization phase. The proposed solution decouples the operational procedures associated with personalization of the OTP card (performed by a manufacturing HSM) and verification of the OTP card password (performed by a different verification HSM). This is accomplished by generating and distributing a third master key that enables the personalized HSM and the verification HSM to independently derive a shared secret value for use in the generation and verification of a transaction password associated with OTP card operation.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. patent application No. 18 / 094,238, filed January 6, 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 simplifying the provision of cryptographic services, and more particularly, to systems and methods for implementing concurrent personalization and verification of one-time password authentication cards. Background Art

[0004] Creating a card with cryptographic keys requires sharing certain card-specific cryptographic parameters, such as a shared secret value, between the card personalization and / or manufacturing entity and the verifier, enabling the verifier to decrypt and verify the encrypted messages generated and transmitted by the card at runtime. This is typically handled by pushing the imprint record generated during the card personalization phase to a verification hardware security module (HSM). However, in some cases, the verifier may be separate and distinct from the manufacturing and / or personalization entity. Therefore, the only option is to communicate the card personalization record to the verification entity during the card personalization phase, thereby exposing critical cryptographic parameters to the risk of network exposure.

[0005] These and other deficiencies exist.Therefore, what is needed is a system and method for implementing a parallel personalization and verification process associated with the operation of a one-time password authentication card. Summary of the Invention

[0006] One aspect of the present disclosure relates to an automated process for parallel encryption and personalization at a card manufacturer's HSM and decryption and verification at an independent (possibly remotely located) card validator HSM. The process can be initiated via a set of operations performed by a cryptographic service provider to enable cryptographic parameters, such as a shared secret value, to be independently generated by the validating HSM. Thus, the validating HSM can perform decryption and verification of transaction cryptograms associated with one-time password (OTP) card authentication operations without requiring access to or communication with the card manufacturing HSM.

[0007] Thus, a security feature associated with the aforementioned systems and processes involves eliminating network transmissions associated with sensitive (decryption-related data) between the personalization HSM and the verification HSM.For purposes of this disclosure, manufacturing entity and personalization entity are used interchangeably.

[0008] Accordingly, some embodiments are directed to a method for parallelizing the generation and verification processes associated with a one-time password (OTP) password generated by an OTP authentication card, the method comprising: distributing, via secure communication from a cryptographic service provider, a shared secret master key to a personalization hardware security module (HSM) associated with a manufacturing entity and a verification HSM associated with a verification entity, wherein the manufacturing HSM and the verification HSM are distinct and store, respectively, a first master key (MK1) for generating a message authentication code (MAC) and a second master key (MK2) for encrypting a concatenation of the MAC and a data payload. The method can further comprise generating, by the personalization HSM, a unique secret identifier by encrypting a globally unique card identifier (UID) associated with the OTP card with the shared secret master key.

[0009] The unique secret identifier can then be stored in an imprint file on the OTP card during a personalization phase, wherein the imprint file can further include a first unique key (UDK1) derived by encrypting the globally unique card identifier (UID) with the first master key, and a second unique key (UDK2) derived by encrypting the globally unique card identifier (UID) with the second master key. In some embodiments, a shared secret (SS) master key, e.g., corresponding to a third master key, can be distributed to the personalization HSM and the verification HSM as an encryption function.

[0010] A password transmission message can then be generated by the OTP authentication card (interchangeably referred to as a contactless card) and transmitted to the verification HSM at runtime (corresponding to an authentication transaction initiated using the OTP card). The verification HSM, which possesses the first master key, the second master key, and the shared secret master key, can then receive the password transmission message generated by the OTP card (during runtime or active operation of the OTP card) and verify the transaction password included therein without any prior communication with the personalization HSM. The password transmission message can include the transaction password, the unique secret identifier (e.g., a shared secret value independently generated by the personalization HSM and the verification HSM using the shared secret master key), and the globally unique card identifier (UID). The password transmission message can further include runtime-generated data, such as a transaction counter value, which can be updated for each authentication transaction facilitated by the OTP card. In addition to the UID and the transaction counter value, the unique secret identifier can be used to facilitate decryption of the transaction password and verification of the MAC using one or more master keys stored on the verification HSM. For example, the unique secret identifier (e.g., the SS value) generated by the personalization HSM and stored on the OTP card can be independently derived by the verification entity using the SS master key and verified against the SS value transmitted by the OTP card. The encryption process used to generate the unique secret identifier can correspond to a (cryptographic) combination of the globally unique card identifier (UID) and the SS master key using a diversification function.

[0011] In some embodiments, the MAC can generate by using a diversification function to combine the first unique key (UDK1), the unique secret identifier (e.g., shared secret value), and the transaction counter value, where the diversification function corresponds to an exclusive OR (XOR) logical operation. The MAC can then be concatenated with the transport (data) payload, and the resulting data packet is encrypted with the second unique key (UDK2) and the transaction counter value to generate a transaction cryptogram (e.g., OTP cryptogram). The transaction cryptogram can then be included in the cryptogram transport message along with the SS value and the UID, and transmitted to the verification HSM.

[0012] In some embodiments, the cryptogram transport message can also include information associated with a routing code for identifying the verification HSM, and a set of key identifiers as references to the first master key, the second master key, and the SS master key.

[0013] According to some embodiments of the present disclosure, the SS master key can be stored on the contactless card and used by an applet running on the contactless card to derive the unique secret identifier (e.g., SS value) at runtime. This can be done by encrypting the globally unique card identifier (UID) with the SS master key.

[0014] In some embodiments, the SS master key distributed by the encryption service provider can be stored by the verification entity in conjunction with one or more mapping records used to match the globally unique card identifier (UID) with a corresponding user account. The UID can be provided to the verification HSM as part of the cryptogram transport message generated by the OTP card.

[0015] The unique secret identifier can then be derived by the verification HSM (independently) by combining the first master key with the UID during authentication of the MAC associated with the OTP transaction cryptogram. Once the MAC is authenticated and the transaction cryptogram is verified, a verification response message can be transmitted back to the requesting entity by the verification HSM and / or a verification server associated with the verification entity.

[0016] One iteration of the present disclosure can involve transmitting the unique secret identifier in the cryptogram transport message instead of the UID. In this case, the UID can be derived by the verification HSM by decrypting the unique secret identifier with the SS master key previously stored on the verification HSM. The decryption process can involve using a diversification function to combine the SS master key with the unique secret identifier.

[0017] Some embodiments of the present disclosure relate to a system for providing cryptographic services for processing OTP card transactions securely, the system comprising a computer hardware apparatus configured to: generate, by a central key processing device, a shared secret (SS) master key in addition to an authentication and encryption master key, wherein the SS master key is used to generate a unique secret identifier. The system can also be configured to distribute, by the central key processing device, the shared secret master key to a personalization hardware security module (HSM) associated with a card manufacturing entity and a verification HSM associated with a verification entity along with the authentication master key and the encryption master key. This enables the verification HSM to independently derive the unique secret identifier (e.g., SS value) using data provided in a cryptogram transmission message. The system can also be configured to provide instructions for inserting into the cryptogram transmission message: information associated with a routing code used to identify the verification HSM, and a set of key identifiers that are references to the first master key, the second master key, and the SS master key.

[0018] In some embodiments, the unique secret identifier can be generated by the OTP (contactless) card and communicated to the verification HSM at runtime via a cryptogram transmission message. The verification HSM can then verify the unique secret identifier using the SS master key and verify the transaction cryptogram, thereby eliminating the need for network communication between the personalization HSM and the verification HSM during the personalization phase of the contactless card.

[0019] Some embodiments of the present disclosure relate to a non-transitory computer readable medium comprising instructions for execution by a computer hardware device, wherein, upon execution of the instructions, the computer hardware device is configured to perform a process comprising: distributing, via a secure communication from a cryptographic service provider, a shared secret master key to a personalization hardware security module (HSM) associated with a manufacturing entity and to a verification HSM associated with a verification entity, wherein the manufacturing HSM and the verification HSM are distinct and store a first master key and a second master key, respectively; generating, by the personalization HSM, a unique secret identifier by encrypting a globally unique card identifier associated with a contactless card with the shared secret master key; storing the unique secret identifier in an imprint file on the contactless card during a personalization phase, wherein the imprint file further comprises the globally unique card identifier, a first unique key (UDK1) derived by encrypting the globally unique card identifier with the first master key (MK1), and a second unique key (UDK2) derived by encrypting the globally unique card identifier with the second master key (MK2); generating, by the contactless card, a transaction cryptogram comprising a message authentication code (MAC) generated by encrypting the unique secret identifier with the first unique key and a transaction counter value generated at runtime; transmitting, by the contactless card, a cryptogram transmission message to the verification HSM, the cryptogram transmission message comprising the transaction cryptogram, the unique secret identifier, the transaction counter value, and the globally unique card identifier; verifying, by the verification HSM, the unique secret identifier using the shared secret master key; and verifying, by the verification HSM, the MAC using the unique secret identifier, the first unique key, and the transaction counter. The non-transitory computer readable medium can further comprise instructions for inserting, by the personalization HSM, information associated with a routing code for identifying the verification HSM, and a set of key identifiers as references to the first master key, the second master key, and a third master key. BRIEF DESCRIPTION OF DRAWINGS

[0020] Various embodiments of the present disclosure, as well as other objects and advantages thereof, are best understood with reference to the following description and drawings.

[0021] Figure 1 The drawbacks of a conventional OTP card production cycle involving network exchange of imprint records during a personalization phase of the OTP card are illustrated.

[0022] Figure 2 An exemplary system implementation for parallelizing cryptogram operations at different personalization HSMs and verification HSMs is illustrated in accordance with some embodiments of the present disclosure.

[0023] Figure 3 An exemplary flowchart of an OTP card cryptogram encryption and generation process associated with runtime operations of an OTP authentication card is illustrated in accordance with some embodiments of the present disclosure.

[0024] Figure 4 An exemplary OTP card secret code and transmission message according to some embodiments of the present disclosure are shown.

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

[0026] Figure 6 A flowchart is provided for implementing an OTP card runtime operation sequence by parallel process flows at different personalization HSMs and verification HSMs according to some embodiments of the present disclosure.

[0027] Figure 7 A timing diagram illustrating concurrent and independent personalization and verification of an OTP card according to some embodiments of the present disclosure is shown.

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

[0029] The following description of the embodiments provides non-limiting representative examples of reference numbers to particularly describe the features and teachings of different aspects of the present invention. The described embodiments should be considered capable of being implemented alone or in combination with other embodiments in the description of the embodiments. Those of ordinary skill in the art who 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 promote understanding of the present invention to the extent that other implementations that are not specifically covered but are 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.

[0030] In some conventional cases, the operational cycle of a one-time password (authentication) card, corresponding to the runtime generation and verification of the authentication transaction password, may be performed by different card personalization and verification entities. One disadvantage of such a scenario involving, for example, a third-party remote OTP card validator is the necessary network interaction between the OTP card manufacturing and personalization entity and the OTP card validator for implementing the runtime verification of the OTP authentication transaction (e.g., verification of the OTP transaction password). The aforementioned arrangement in Figure 1 This is shown in , which is the prior art.

[0031] refer to Figure 1 In the embodiment 100, two master keys are provided to both the personalization HSM (120) and the verification HSM (140), for example corresponding to the authentication master key (MK1) and the encryption master key (MK2). MK1 and MK2 can be used to generate a message authentication code (MAC) and an OTP transaction password, respectively. Figure 1As shown, the card imprint record (150), such as a shared secret value, can be used by the personalization HSM (120) to generate a MAC, which is shared to the verification HSM during, for example, the OTP card personalization phase. It can be necessary to communicate such a record to enable the verification entity to perform runtime verification of the OTP authentication password (e.g., OTP transaction password). As described, during the personalization phase of the OTP card, such an imprint record can be communicated to the remote verification entity (e.g., verification HSM 140) in encrypted and / or plaintext form. However, as Figure 1 As shown, such an arrangement presents a security risk involving network exposure (e.g., unauthorized interception) of the transmitted (shared) imprint record. There are these and other deficiencies. Accordingly, there is a need for systems and methods that decouple the respective operations of different personalization HSMs and verification HSMs to enable runtime operations of OTP authentication cards without exposing critical encryption-related card imprint data.

[0032] One aspect of the present disclosure relates to a novel encryption provisioning service that enables third-party verification entities to independently perform decryption and verification of transaction passwords associated with (personalized) OTP authentication cards without requiring network communication with the personalization / manufacturing entity. From a security perspective, the proposed systems and methods provide a valuable utility by eliminating the need for network communication (for sharing encryption-related data) during the card personalization phase. Additional utilities provided by the proposed systems and methods include simplifying outsourcing of authentication / verification services involved in transaction processing of OTP authentication cards.

[0033] Figure 2 An example system (200) is shown for decoupling the decryption and verification process of OTP transaction passwords (e.g., performed by a verification HSM) from the card personalization process, which facilitates generation of the OTP transaction password. According to some embodiments of the proposed solution, this can be accomplished by introducing a different master key for generating shared secret data. Distribution of a shared secret (SS) master key di to both the personalization HSM and the verification HSM enables the respective hardware security modules (HSMs) to independently derive (shared) secret values, thereby enabling parallel operations at different personalization entities and verification entities for facilitating secure OTP card transactions.

[0034] Reference is made to Figure 2The encryption service provider distributes an additional shared secret master key (MK3) along with the first and second master keys (MK1 and MK2, respectively, for MAC generation and encryption) that can be used by the personalization HSM (240) to generate a unique secret identifier (e.g., shared secret value), denoted as UDK3 in example 200. The verification HSM (250) is operable to generate a matching unique secret identifier using the previously stored shared secret master key (MK3) to facilitate the OTP password verification process. According to some embodiments, the personalization HSM (240) can generate a set of unique card keys (UDK 1, UDK 2, UDK 3) by encrypting a globally unique card identifier (UID) with each respective master key (e.g., MK1, MK2, MK3), as represented, for example, by a process (242) running on the personalization HSM (24). The personalization information including the unique card keys and the globally unique card identifier (UID) can then be stored on the OTP card (e.g., on the memory (212) integrated onto the contactless card (210)).

[0035] In some embodiments, the verification entity can also store instructions built into the verification function regarding how to use the master keys to decrypt and verify incoming password messages generated by the OTP card (e.g., contactless card 210). In some embodiments, the OTP card can correspond to a uniquely configured contactless card (210) having an integrated processor (211) and an NFC tag (213) that stores NFC transmittable user authentication data (e.g., readable by a mobile device having a reader component and running a corresponding application). The contactless card (210) can also include a counter, also referred to as an application transaction counter (ATC), for tracking OTP transactions initiated by the contactless card, and one or more applets for facilitating generation of OTP authentication passwords. In some embodiments, the transaction counter value can be updated for each OTP transaction initiated by the contactless card. Figure 3 An exemplary process flow (300) is shown for generating an encrypted authentication message (e.g., OTP authentication password) by the OTP card.

[0036] As described above, with respect to some embodiments, the personalization HSM can generate a unique secret identifier (e.g., shared secret value) by encrypting a globally unique card identifier (UID) associated with the OTP card using a shared secret (SS) master key corresponding to the third master key (MK3), as represented, for example, by a process (242) running on the personalization HSM (24). Figure 2The unique secret identifier can then be stored in an imprint file on the OTP card during the card personalization phase, where the imprint file can also include a first unique key derived by encrypting the global unique card identifier (UID) with the first master key (MK1) and a second unique key derived by encrypting the global unique card identifier (UID) with the second master key (MK2). In some embodiments, a shared secret (SS) master key corresponding to the third master key (MK3) can be distributed to the personalization HSM and the verification HSM as an encryption function.

[0037] According to example 300, the specific encryption inputs required to generate a transaction cryptogram (e.g., SS value, UDK1, UDK2) can be generated by processes 301 (corresponding to generating a unique secret identifier (304) by encrypting a combination of MK3 and UID), 302 (corresponding to generating a first unique card key (UDK1) by encrypting a combination of MK1 and UID), and 303 (corresponding to generating a second unique card key (UDK2) by encrypting a combination of MK2 and UID), respectively. According to some embodiments, processes 301, 302, and 303 can be performed by a personalization hardware security module (HSM), writing only the output values (e.g., SS value 304, UDK1, and UDK2) to the OTP card. According to other embodiments, the above processes can be performed on the OTP card at runtime (e.g., when a transaction is initiated using the OTP card). In this case, the corresponding master keys (MK1, MK2, and MK3) can be stored on the OTP card’s integrated memory and used accordingly by an applet stored on the OTP card to generate the card-specific encryption inputs (e.g., SS value, UDK1, and UDK2).

[0038] Referring back to example process flow 300, runtime-generated data such as an application transaction counter (ATC) value can then be used to diversify UDK1, which is further encryptively combined with the output of process 301 (e.g., shared secret value 304) to create an authentication session key (306). The authentication session key (306) is then used to generate a message authentication code (MAC). As further shown in example process flow 300, the generated MAC (308) can be added to a payload message (310) to create a data packet (312). The resulting data packet (312) can then be encrypted by an encryption session key (314) to generate the OTP card (transaction) cryptogram, which is generated at runtime by diversifying the output of process 303 (e.g., UDK2) with the ATC value.

[0039] As Figure 4As shown, the cryptogram transmission message (404) including the transaction cryptogram (402) with multi-layer encryption can be transmitted to the verification HSM at runtime (e.g., when a transaction is initiated using an OTP card). Figure 4 The exemplary transaction cryptogram (402) as shown can include a data payload and a MAC (generated by diversifying UDK1 with the ATC and a unique secret identifier (e.g., SS value 304)). The unique secret identifier (interchangeably referred to as SS value and / or UDK3) can be generated by the personalization HSM during the OTP card personalization phase (by encrypting the UID with the SS master key), or by the OTP card at runtime. According to some embodiments, the MAC can be independently derived and verified by the verification entity at runtime.

[0040] With respect to Figure 4 In the example 400 in FIG. 4A, the transaction cryptogram (402) is generated at runtime using information stored on the OTP card. Thus, the unique (derived) card keys UDK1 and UDK2 are derived by combining MK1 and MK2 with the UID and ATC values using one or more diversification algorithms. As shown, the ATC value can be used as a diversification parameter at runtime (referred to as tap time for a contactless OTP card) with the unique card keys (e.g., UDK1 and UDK2) to create an authentication session key (306) and an encryption session key (314). In some embodiments, the diversification algorithm can be implemented by performing an exclusive OR (XOR) logical operation. The authentication session key (306) can then be used to generate a MAC, while the encryption session key can be used to encrypt a concatenation of the payload and the MAC (e.g., data packet 312) to generate the transaction cryptogram (402). In some embodiments, the payload can correspond to an 8-byte random number, and the shared secret value (304) can correspond to the most entropic four bytes associated with encrypting a globally unique card identifier (UID) with MK3 (e.g., output of process 301). Figure 4

[0041] Thus, according to some embodiments, the generation of the MAC can correspond to two rounds of encryption, one round using the authentication session key (derived by scrambling and / or diversifying UDK1 with the ATC value and the shared secret value 304), and the other round using the encryption session key (derived by scrambling or diversifying UDK2 with the ATC value) that occurs after the MAC is concatenated with the payload.

[0042] From Figure 4 ​As can be seen in the illustrated cryptogram transfer message (404), the shared (encryption related) data values (e.g., data parameters that the verification entity must possess in order to decrypt and authenticate the OTP transaction cryptogram) correspond to data that is generated and / or provided at runtime, such as the UID and ATC values. Then, in the cryptogram transfer message (404), the required runtime generated data can be transferred to the verifier along with the transaction cryptogram (402). According to exemplary embodiments of the disclosed system / method, the verifier can use the stored master keys and the data received at runtime in the cryptogram transfer message (404) to independently derive one or more required data that can not be provided at runtime, such as the SS value (304). Reference is made to Figures 5-7 The verification process associated with embodiments of the proposed solution is further described.

[0043] According to exemplary embodiment 400, the cryptogram transfer message (404) can also include information associated with a verifier routing code (406) for identifying the corresponding verification HSM.

[0044] In some embodiments, the master key reference information (408) (e.g., one or more key identifiers used in generating the MAC and encrypting the MAC-attached payload) can be inserted into the cryptogram transfer message (404) along with the transaction cryptogram (402) and the verifier routing code (406). The foregoing configuration can correspond to an enhanced HSM functionality whereby the master key derivation functionality can be built into the functionality for MAC verification.

[0045] Figure 5 Exemplary runtime verification operations, for example, performed by the verification HSM (250) are illustrated. The runtime verification process can run on the verification entity, as illustrated, for example, by process 502. Process 502 can utilize the stored master keys (MK1, MK2, MK3) to decrypt the transaction cryptogram (402) included in the cryptogram transfer message (404) and authenticate the MAC (308). Figure 5 An exemplary runtime process flow (503) associated with the verification process (502) is illustrated in FIG. 5B. The stored master keys (MK1, MK2, and MK3) can be used according to process flow (503) to process incoming cryptogram transfer messages (404) (e.g., according to Figure 3 and Figure 4 to decrypt the transaction cryptogram (402) and authenticate the MAC.

[0046] The process flow diagram (503) illustrates an example scheme that applies the stored master keys MK1, MK2, and MK3 in combination with information (e.g., UID and latest ATC value) conveyed in the OTP card password transmission message (404) to derive an encryption session key (314) for decrypting the transaction password (402) and extracting the (pre-encrypted) MAC (e.g., with an additional encryption layer associated with UDK1) from the decrypted data packet (312). The payload concatenated with the MAC (pre-encrypted with a first layer using UDK1) can also be extracted (505) from the decrypted data packet and verified (242) by the verification HSM. As shown in the process flow (503), an encryption session key (504) can be generated by the runtime verification process by cryptographically combining the conveyed ATC value with UDK2, which is derived by encrypting the conveyed UID with the stored MK2 (e.g., stored on a database of the verification HSM and / or communicatively coupled with the verification HSM).

[0047] The unique secret identifier (509) can then be independently derived by the verification HSM (250) by encrypting the UID with an SS master key (e.g., MK3) stored locally on the verification HSM and verified against the unique secret identifier (304) provided in the password transmission message (404). Upon determining a match between the independently derived SS value (509) and the conveyed SS value (304), the unique secret identifier (e.g., SS value) can be used to derive an authentication session key (313), which is then used to decrypt and verify the MAC. The authentication session key (313) can be computed by the verification HSM (250) by cryptographically combining UDK1 and the shared secret value (509) with the runtime-conveyed TC value, as shown in the process flow (503).

[0048] In some embodiments, the SS master key distributed by the central encryption service provider can be stored by the verification HSM in combination with one or more mapping records used to match a globally unique card identifier (UID) with a corresponding user account. The UID can be provided to the verification HSM as part of the password transmission message generated by the OTP card.

[0049] Figure 6A flowchart (600) is shown that provides an exemplary overview of operations for parallelizing the operational flow (602) performed by a personalization HSM (604) during a personalization phase of an OTP card (e.g., involving steps 605 for deriving unique card keys (UDK1 and UDK2) and shared secret values, and step 606 for storing the generated card imprint record onto the OTP card) and the operational flow (607) performed by a verification HSM during the personalization phase (602) of the OTP card. As shown in the flowchart (600), the operational flow 607 simply involves the step of storing the distributed master keys (including shared secret master keys for independent derivation of unique secret identifiers) by the verification HSM. As shown in the flowchart (600), step 607 can be performed in parallel (independently) of the operational flow (602).

[0050] Referring back to Figure 6 , the exemplary process (600) can begin with the distribution of a set of cryptographic master keys (including shared secret keys for independent derivation of shared secret values (e.g., unique secret identifiers) by the personalization and verification HSMs (HSM2). This is represented by data communication path 603 in the flowchart 600. The described parallelization scheme for implementing OTP card encryption services (e.g., during the OTP card personalization phase) enables the runtime verification process (steps (623)-(625)) involving cryptographic message decryption and verification to be performed by the independent verification HSM (608) using only the runtime information conveyed in the cryptographic transport messages (e.g., acquired by steps 621 and 622). Steps 621 and 622 representing the runtime operations of the OTP card (e.g., enabled by the personalization process flow) can correspond to the generation (621) and transmission (622) of the cryptographic transport messages.

[0051] Referring to Figure 6 As shown by steps 605 and 606, the OTP card personalization phase can involve the generation and storage of imprint records (e.g., shared secret values, UDK1, UDK2, and UID) onto the integrated memory of the OTP card. As shown in the flowchart 600, the role of the verification entity, including the storage of master keys as part of the cryptographic verification function (step 607), can be implemented in parallel with the personalization phase to facilitate the runtime operational sequence (620) including the generation (621), transmission (622), and verification (623-625) of the OTP cryptographic messages. In some embodiments, the OTP cryptographic messages can also include a routing code for identifying the destination verification HSM (e.g., verification HSM 608).

[0052] As shown in step 621, the generation of the OTP transaction cryptogram can include generating a secret unique identifier by cryptographically diversifying the UDK1 with the ATC value and the shared secret identifier to derive a session authentication key (step 621.1), generating a MAC using the session authentication key and appending the MAC to the payload (step 621.2), and encrypting the MAC- appended payload with a session encryption key generated by cryptographically diversifying the UID with the UDK2 stored on the card (step 621.3). The diversification function can correspond to an exclusive OR (XOR) logical operation. In some embodiments, the payload can correspond to a randomly generated 8-byte number.

[0053] As shown in the example flowchart 600, the runtime verification of the OTP cryptogram can also include step 623 for deriving an encryption session key and decrypting the cryptogram, step 624 for deriving a shared secret value (e.g., a unique secret identifier) to use with the UDK1 to compute the MAC, and step 625 for authenticating the MAC and verifying the payload associated with the OTP card transaction cryptogram. In some embodiments, the instructions for decrypting and authenticating an incoming cryptogram using a set of reference master keys can be integrated into a cryptogram verification process running on the verification HSM.

[0054] As shown in the operational flowchart (600) according to example embodiments of the present disclosure, no communication and / or network transmission can be required between the different personalization HSM and verification HSM to implement the runtime sequence of operations (620) associated with the OTP card transaction (e.g., the generation / transmission and verification of the authenticated cryptogram message).

[0055] Figure 7 An example timing diagram (700) is shown for parallelizing the operational flow associated with the personalization and verification of an OTP card by different personalization and verification entities without communication between the three. Referring to Figure 7 The process can be initiated by a cryptographic service provider (702) that communicates a set of master cryptogram keys (703) to both the personalization HSM (710) and the verification HSM (720). As shown in the example timing diagram (700), the personalization HSM (710) and the verification HSM (720) can each generate a unique secret identifier (711, 721) by cryptographically diversifying the UID with the shared secret identifier (712, 722) and the ATC value (713, 723) to derive a session authentication key (714, 724). The session authentication key can be used to generate a MAC (715, 725) and append the MAC to a payload (716, 726). The MAC- appended payload can be encrypted (717, 727) with a session encryption key (718, 728) generated by cryptographically diversifying the UID with the UDK2 (719, 729) stored on the card. Figure 7corresponding to the creation of secret unique identifiers (operation 711) and the generation of unique derived card keys UDK1 and UDK2 (operations 712 and 713) using a shared secret master key (e.g., MK3). The created imprint record can then be written to the OTP card at operation step 714 to complete the personalization of the OTP card. The personalization process (depicted by operation steps 711-714) enables the OTP card to generate unique encrypted authentication messages (e.g., password transmission messages) at runtime that can be verified and authenticated by the verification entity (720).

[0056] The generated imprint record written to the OTP card at step (714) can also be stored on the database (715) of the personalization HSM (710) and / or communicatively coupled to the personalization HSM (710).

[0057] According to the exemplary timing diagram (700), during the personalization phase of the OTP card, the operational flow executed by the verification HSM can proceed independently of the operations executed by the HSM (710). For example, after the master key (703) is distributed by the encryption service provider (702), the verification entity (720) can proceed to store the received master key (704) corresponding to operation step 721 for enabling a runtime password verification process that involves decryption, verification, and authentication of an incoming password transmission message (716) that can be generated by the OTP card (705) at runtime (e.g., upon initiation of an OTP card transaction).

[0058] As described above with respect to the exemplary timing diagram (700), the personalization HSM can generate a card imprint record (714) to be stored on the OTP card (705). The imprint record can include one or more globally unique card identifiers (UIDs) and a set of unique card keys UDK1 and UDK2 that are derived by encrypting the UIDs using the (first) authentication master key and the (second) encryption master key distributed to the personalization HSM (710) and the verification HSM (720) by the encryption service provider (702). As further discussed above according to some embodiments of the present disclosure, a third master key (MK3) can also be distributed to the personalization HSM and the verification HSM via communication 703. The third master key (MK3) can correspond to an encryption function used to scramble the globally unique card identifiers (UIDs) to generate secret unique identifiers (shared secret values) that can be stored on the card and used at runtime to derive authentication session keys for generating MACs that are appended to payload messages.

[0059] The verification HSM (720) using the stored master key (e.g., step 721, which can be performed in parallel with the OTP card personalization steps 711-715) can independently derive the shared secret value (as part of the process of computing the authentication session key) in order to decrypt and authenticate the MAC associated with the OTP transaction cryptogram and verify the payload included in the cryptogram transport message (716). The cryptogram transport message (716) can be transmitted by the OTP card (705) at a particular time when the OTP card is actively used to facilitate an electronic authentication transaction.

[0060] Thus, as shown in the example timing (700), decryption and verification of an incoming (authentication) cryptogram can be performed by the verification HSM (720) using the commonly distributed master key (stored in step 721) and data included in the runtime OTP card cryptogram transport message (716). In some embodiments, the data can include a globally unique card identifier (UID) as well as an application transaction counter (ATC) value recorded by the OTP card. The recorded ATC value is then incremented for each subsequent OTP authentication transaction initiated by the contactless card. In some embodiments, a verifier routing code can be included in the cryptogram transport message (716) in order to correctly identify the corresponding verification HSM (e.g., verification HSM 720). Upon receipt of the cryptogram transport message (716), the verification entity can decrypt, authenticate, and verify the incoming transport using the stored master key using a MAC verification function as part of the decryption process. Reference is made to Figure 7 With reference to the example timing diagram (700) shown in FIG. 7, the (runtime) verification process triggered upon receipt of the cryptogram transport message (716) can be represented by a series of operations corresponding to decrypting the received cryptogram transport message to obtain the payload and the encrypted MAC (corresponding to step 722), deriving a unique secret identifier using the stored MK3 in conjunction with the UID (step 723), and subsequently decrypting and authenticating the MAC (step 724). Upon successful verification of the cryptogram payload and authentication of the MAC, a verification response (725) can be transmitted back to the requestor associated with the OTP card transaction.

[0061] In some embodiments, the encryption service provider can correspond to a central key processing device configured to generate and distribute shared master keys to personalization entities and verification entities in addition to authenticating and encrypting master keys.

[0062] Figure 8A 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 can be performed by a processing device and / or computing device (e.g., a computer hardware device) 805. Such a processing device and / or computing device 805 can 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 can 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).

[0063] like Figure 8 As 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 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 certain exemplary processes, procedures, and methods, for example, as described above.

[0064] Additionally, the exemplary processing device 805 may be equipped with or include an input / output port 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 certain 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.

[0065] 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.

[0066] The systems and methods described herein can provide secure retrieval of sensitive user information, or enable simplified 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, without limitation, 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), access point transactions (e.g., building access and secure storage access transactions), transportation transactions (e.g., ticketing and boarding transactions), and other transactions.

[0067] As used herein, personal identity information (PII) can 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 numbers, home or work addresses, birth dates, phone numbers, email addresses, passport numbers, driver’s license numbers), access information (e.g., passwords, security codes, authorization codes, biometric data), and any other information that a user can wish to avoid disclosing to unauthorized persons.

[0068] 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 are possible in light of the above teachings without departing from the spirit and scope of the disclosure. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, can be apparent to those skilled in the art from the foregoing representative description. Such modifications and variations are intended to fall within the scope of the appended representative claims and the full range of equivalents to which such representative claims are entitled. It is to be understood that the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. It is to be understood that the terms “including,” “comprising,” “consisting” and “substantially comprising” are not

[0069] It should also be noted that the systems and methods described herein can be tangibly embodied in one or more physical media, such as, but not limited to, an optical disc (CD), a digital versatile disc (DVD), a floppy disk, a hard drive, a read-only memory (ROM), a random access memory (RAM), and other physical media capable of storing data. For example, the data storage device can include random access memory (RAM) and read-only memory (ROM), which can be configured to access and store data and information and computer program instructions. The data storage device can also include storage media or other suitable type of memory (e.g., such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, flash drives, any type of tangible and non-transitory storage medium) in which files can be stored including operating systems, applications, including, for example, web browser applications, email applications, and / or other applications, and data files. The data storage device of a network-enabled computer system can include electronic information, files, and documents stored in various ways, including, for example, flat files, indexed files, hierarchical databases, relational databases, such as those created and maintained by the software from, for example Microsoft Corporation, Excel files, Access files, solid state storage devices (which can include flash arrays, hybrid arrays, or server-side products), enterprise storage (which can include online or cloud storage), or any other storage mechanism. Furthermore, the figures show various components (e.g., servers, computers, processors, etc.) separately. The functions described as being performed at the various components can be performed at other components, and the various components can be combined or separated. Other modifications can also be made.

[0070] In the foregoing specification, various embodiments have been described. However, it is evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the application as set forth in the following claims. The Specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method for parallelizing the generation and verification process of encrypted data associated with a contactless authentication card, the method comprising: distributing, via a secure communication from an encryption service provider, a shared secret master key to a personalization hardware security module (HSM) associated with a manufacturing entity and a verification HSM associated with a verification entity, wherein the personalization HSM and the verification HSM are distinct and store a first master key and a second master key, respectively; generating, by the personalization HSM, a unique secret identifier by encrypting a globally unique card identifier associated with a contactless card with the shared secret master key; storing, during a personalization phase, the unique secret identifier in an imprint file on the contactless card, wherein the imprint file further comprises the globally unique card identifier, a first unique key (UDK1) derived by encrypting the globally unique card identifier with the first master key (MK1), and a second unique key (UDK2) derived by encrypting the globally unique card identifier with the second master key (MK2); generating, by the contactless card, a transaction cryptogram comprising a message authentication code (MAC) generated by encrypting the unique secret identifier with the first unique key and a transaction counter value generated at runtime; transmitting, by the contactless card, a cryptogram transmission message to the verification HSM, the cryptogram transmission message comprising the transaction cryptogram, the unique secret identifier, the transaction counter value, and the globally unique card identifier; verifying, by the verification HSM, the unique secret identifier using the shared secret master key; and verifying, by the verification HSM, the MAC using the unique secret identifier, the first unique key, and the transaction counter.

2. The method of claim 1, wherein, The transaction counter value is updated for each authentication transaction initiated by the contactless card.

3. The method of claim 1, wherein, The cryptogram transmission message is transmitted to the verification HSM upon initiation of an authentication transaction using the contactless card.

4. The method of claim 3, wherein, The cryptogram transmission message further comprises information associated with a routing code for identifying the verification HSM, and a set of key identifiers as references to the first master key, the second master key, and the shared secret master key.

5. The method of claim 1, wherein, The shared secret master key is distributed to the personalization HSM and the verification HSM as an encryption function.

6. The method of claim 1, wherein, The first unique key is used by the personalization HSM for generating the MAC using the unique secret identifier and the transaction counter value, and the second unique key is used with the transaction counter value for encrypting a transmission payload concatenated with the MAC to generate the transaction cryptogram.

7. The method of claim 1, wherein, The MAC is generated by combining the first unique key, the unique secret identifier, and the transaction counter value using a diversification function.

8. The method of claim 7, wherein, The diversification function corresponds to an exclusive OR (XOR) logical operation.

9. The method of claim 1, wherein, The shared secret master key is stored on the contactless card and used at runtime by a small application running on the contactless card for deriving the unique secret identifier.

10. The method of claim 1, wherein, The shared secret master key distributed by the cryptographic service provider is stored by the verification entity in conjunction with one or more mapping records used to match the globally unique card identifier to a corresponding user account.

11. The method of claim 10, wherein, The globally unique card identifier is derived by the verification HSM by decrypting the unique secret identifier with the shared secret master key, wherein the unique secret identifier is provided in the cryptogram transmission message.

12. The method of claim 11, wherein, The unique secret identifier is derived by the verification HSM by encrypting the globally unique card identifier with the shared secret master key stored on the verification HSM, wherein the globally unique card identifier is provided in the cryptogram transmission message.

13. The method of claim 1, further comprising transmitting, by a verification server associated with the verification entity, a MAC verification response message.

14. A system for providing cryptographic services for contactless card transaction security, the system comprising computer hardware apparatus configured to: generate, by a central key processing device, a shared secret master key in addition to an authentication master key and an encryption master key, wherein the shared secret master key is used to generate a shared secret value; distribute, by the central key processing device, the shared secret master key to a personalization hardware security module (HSM) associated with a card manufacturing entity and a verification HSM associated with a verification entity along with the authentication master key and encryption master key to enable the verification HSM to independently derive a shared secret value using data in an encrypted transaction message; and provide instructions for inserting into the encrypted transaction message: information associated with a routing code used to identify the verification HSM, and a set of key identifiers that are references to the authentication master key, the encryption master key, and the shared secret master key.

15. The system of claim 14, wherein, The shared secret value generated by the cryptographic function using the shared secret master key is transmitted to the verification HSM during a contactless card transaction.

16. The system of claim 15, wherein, The shared secret value is independently derived by the verification HSM using the shared secret master key.

17. The system of claim 16, wherein, The independently derived shared secret value by the verification HSM is verified against the shared secret value transmitted to the verification HSM during the contactless card transaction.

18. A non-transitory computer-readable medium comprising instructions for execution by computer hardware apparatus, wherein, The computer hardware apparatus, when executing the instructions, is configured to perform a program comprising: distributing, via secure communication from a cryptographic service provider, a shared secret master key to a personalization hardware security module (HSM) associated with a manufacturing entity and a verification HSM associated with a verification entity, wherein the manufacturing HSM and verification HSM are distinct and store first and second master keys, respectively; generating, by the personalization HSM, a unique secret identifier by encrypting a globally unique card identifier associated with a contactless card with the shared secret master key; storing the unique secret identifier in an imprint file on the contactless card during the personalization phase, wherein the imprint file further includes the globally unique card identifier, a first unique key derived by encrypting the globally unique card identifier with the first master key, and a second unique key derived by encrypting the globally unique card identifier with the second master key; generating, by the contactless card, a transaction cryptogram comprising a message authentication code (MAC), the MAC generated by encrypting the unique secret identifier with the first unique key and a transaction counter value generated at runtime; transmitting, by the contactless card to the verification HSM, a cryptogram transmission message, the cryptogram transmission message including the transaction cryptogram, the unique secret identifier, the transaction counter value, and the globally unique card identifier; verifying, by the verification HSM, the unique secret identifier using the shared secret master key; and verifying, by the verification HSM, the MAC using the unique secret identifier, the first unique key, and the transaction counter.

19. The non-transitory computer readable medium of claim 18, further comprising instructions to increment the transaction counter value each time an authentication transaction is facilitated by the contactless card.

20. The non-transitory computer-readable medium of claim 18, further comprising instructions to insert, by the personalized HSM, information associated with a routing code and a set of key identifiers into the contactless card, wherein, the routing code identifies the verification HSM, and the set of key identifiers identifies the first master key, the second master key, and the shared secret master key.

Images