Systems and methods for parallel manufacturing and verification of one-time password authentication cards

Abstract

The disclosed system and method are directed to a novel implementation of cryptographic service provisioning that eliminates the need for network communication between a card manufacturing / personalization entity and a validation entity during the card personalization phase. The proposed solution separates the operational flows associated with OTP card personalization (performed by a manufacturing HSM) and OTP card cryptogram verification (as performed by a separate validation HSM). This is achieved by generating and distributing a third master key that allows the personalization HSM and validation HSM to independently derive shared secret values ​​used in generating and verifying transaction cryptograms associated with OTP card operations.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) 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.

[0002] The present disclosure relates to systems and methods for streamlining the provision of cryptographic services, and more particularly to systems and methods for enabling parallel personalization and validation of one-time password authentication cards. [Background technology]

[0003] Creating a card with a cryptographic key requires that certain card-specific cryptographic parameters, such as a shared secret value, be shared between the card personalization and / or manufacturing entity and a validation partner, allowing the validation partner to decrypt and verify encrypted messages generated and transmitted by the card at runtime. This is typically handled by pushing an embossed record generated during the card personalization phase to a validating Hardware Security Module (HSM). However, in some cases, the validation partner may be separate and distinct from the manufacturing and / or personalization entity. In that case, the only option is to communicate the card personalization record to the validating entity during the card personalization phase, thereby risking exposing critical cryptographic parameters to the network.

[0004] These and other deficiencies exist. Therefore, there is a need for a system and method that enables parallelized personalization and verification processes associated with the operation of one-time password authentication cards. Summary of the Invention

[0005] One aspect of this disclosure is directed to an automated process for parallelized encryption and personalization at a card manufacturing HSM and decryption and verification at an independent (possibly remote) card verifying HSM. This process may be initiated through a series of operations performed by a cryptographic service provider to enable independent generation of cryptographic parameters, such as a shared secret value, by the verifying HSM. Thus, the verifying HSM can perform decryption and verification of transaction ciphers associated with one-time password (OTP) authentication card operations without accessing or communicating with the card manufacturing HSM.

[0006] Therefore, security features associated with the aforementioned systems and processes include the elimination of network transmissions related to sensitive data (decryption-related data) between the personalization HSM and the validation HSM. For purposes of this disclosure, manufacturing entity and personalization entity are used interchangeably.

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

[0008] The embossed file further comprises a first unique key (UDK1) derived by encrypting a globally unique card identifier (UID) with a first master key and a second unique key (UDK2) derived by encrypting the globally unique card identifier (UID) with a second master key. In some embodiments, a shared secret (SS) master key, for example corresponding to a third master key, may be distributed to the personalization and verification HSMs as a cryptographic function.

[0009] A send ciphertext message is then generated by the OTP authentication card (interchangeably referred to as a contactless card) and sent to the verifying HSM at runtime (corresponding to the initiation of an authentication transaction using the OTP card). Because the verifying HSM possesses the first key, the second key, and the shared secret master key, it can receive the send ciphertext message generated by the OTP card (during runtime or active operation of the OTP card) and verify the transaction ciphertext contained therein without prior communication with the personalization HSM. The send ciphertext message consists of the transaction ciphertext, a unique secret identifier (e.g., a shared secret value uniquely generated by the personalization HSM and the verifying HSM using the shared secret master key), and a globally unique card identifier (UID). The send ciphertext message may further include runtime-generated data, such as a transaction counter value, which is updated for each authentication transaction facilitated by the OTP card. The unique secret identifier, along with the UID and transaction counter value, can then be used to facilitate decryption of the transaction ciphertext and verification of the MAC using one or more master keys stored in the verifying HSM. For example, the unique secret identifier (e.g., SS value) generated by the personalization HSM and stored on the OTP card is uniquely derived by the validating entity using the SS master key and matched with the SS value sent by the OTP card. The cryptographic process for generating the unique secret identifier can correspond to the (cryptographic) combination of a globally unique card identifier (UID) and the SS master key using a diversification function.

[0010] In some embodiments, the MAC may be generated by combining a first unique key (UDK1), a unique secret identifier (e.g., a shared secret value), and a transaction counter value using a diversification function corresponding to an exclusive-or (XOR) logical operation. The MAC can then be combined with the transmit (data) payload, and the resulting data packet can be encrypted with a second unique key (UDK2) and the transaction counter value to generate a transaction ciphertext (e.g., an OTP ciphertext). The transaction ciphertext, along with the SS value and UID, is included in a transmit ciphertext message and sent to the HSM for validation.

[0011] In some embodiments, the send ciphertext message may further include a routing code that identifies the verifying HSM and information related to a set of key identifiers as references to the first, second and SS master keys.

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

[0013] In some embodiments, the SS master key distributed by the cryptographic service provider may be stored by the validating entity along with one or more mapping records for matching globally unique card identifiers (UIDs) with corresponding user accounts. The UIDs may be provided to the validating HSM as part of a send ciphertext message generated by the OTP card.

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

[0015] In one iteration of this disclosure, a unique secret identifier may be sent in place of the UID in the ciphertext transmission message. In such a scenario, the UID can be derived by the verifying HSM by decrypting the unique secret identifier with an SS master key that is pre-stored in the verifying HSM. The decryption process may include combining the SS master key and the unique secret identifier using a diversification function.

[0016] Some embodiments of the present disclosure are directed to a system for securely providing cryptographic services for processing OTP card transactions, the system including a computer hardware device configured to generate, by a central key processing device, a shared secret (SS) master key in addition to an authentication master key and an encryption master key, the SS master key being used to generate a unique secret identifier. The system may be further configured to distribute, by the central key processing device, the shared secret master key, along with the authentication master key and the encryption master key, to a personalization hardware security module (HSM) associated with a card manufacturing entity and a verifying HSM associated with a verifying entity, thereby enabling the verifying HSM to independently derive a unique secret identifier (e.g., an SS value) using data provided in a ciphertext send message. The system may be further configured to provide, in the ciphertext send message, information related to a routing code for identifying the verifying HSM and instructions for inserting a set of key identifiers as references to the first, second, and SS master keys.

[0017] In some embodiments, the unique covert identifier is generated by an OTP (contactless) card and sent to the validating HSM at runtime via a Send Ciphertext message. The validating HSM can verify the unique covert identifier using the SS master key and validate the transaction ciphertext, eliminating the need for network communication between the personalization HSM and the validating HSM during the contactless card personalization stage.

[0018] Some embodiments of the present disclosure are directed to a non-transitory computer-readable medium comprising instructions for execution by a computer hardware configuration, which upon execution of the instructions causes the computer hardware configuration to perform steps including: distributing, via secure communications from a cryptographic service provider, a shared secret master key to a personalization hardware security module (HSM) associated with the manufacturing entity and a validation HSM associated with the validation entity, the manufacturing HSM and the validation HSM being distinct and storing the first master key and the second master key, respectively; generating a unique secret identifier by encrypting, with a personalization HSM, a globally unique card identifier associated with the contactless card with a shared secret master key; During the personalization phase, storing a unique secret identifier in an embossed file of the contactless card, the embossed file comprising a globally unique card identifier and Further including a first unique key (UDK1) obtained by encrypting a globally unique card identifier with a first master key (MK1), and a second unique key (UDK2) obtained by encrypting the globally unique card identifier with a second master key (MK2); generating, by the contactless card, a transaction cryptogram including a message authentication code (MAC), the MAC being generated by encrypting a unique secret identifier and a runtime-generated transaction counter value with a first unique key; transmitting, by the contactless card, a ciphertext send message to a validating HSM, the ciphertext send message comprising a transaction cipher, a unique secret identifier, a transaction counter value, and a globally unique card identifier; verifying, by the verifying HSM, the unique secret identifier using the shared secret master key, and verifying, by the verifying HSM, the MAC using the unique secret identifier, the first unique key, and the transaction counter; is configured to execute The non-transitory computer-readable medium may further comprise instructions for the personalization HSM to insert information related to a routing code for identifying a validating HSM and a set of key identifiers as references to the first, second, and third master keys.

[0019] The various embodiments of the present disclosure, together with further objects and advantages, may best be understood by reference to the following description taken in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 illustrates the drawbacks of a conventional OTP card manufacturing cycle, which involves the network exchange of embossed records during the OTP card personalization stage. [Figure 2] FIG. 2 illustrates an exemplary system implementation for parallelizing cryptographic processing across different personalization and validation HSMs, in accordance with some embodiments of the present disclosure. [Figure 3] FIG. 3 is an example flow diagram of an OTP card ciphertext encryption and generation process involved during operation of an OTP authentication card, according to some embodiments of the present disclosure. [Figure 4] FIG. 4 illustrates an exemplary OTP card ciphertext and transmission message according to some embodiments of the present disclosure. [Figure 5] FIG. 5 is a flow diagram of an exemplary OTP card ciphertext decryption and verification process according to some embodiments of the present disclosure. [Figure 6] FIG. 6 is a flowchart of an OTP card execution sequence enabled by parallelized process flows in separate personalization and verification HSMs in accordance with some embodiments of the present disclosure. [Figure 7] FIG. 7 is a timing sequence diagram for parallelized and independent OTP card personalization and verification according to some embodiments of the present disclosure. [Figure 8] FIG. 8 is an illustration of an example block diagram of an example system according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0021] The following description of the embodiments provides non-limiting representative examples that refer to numerals to particularly explain the features and teachings of different aspects of the present invention. It should be recognized from the description of the embodiments that the described embodiments can be implemented separately or in combination with other embodiments. Those skilled in the art who review the description of the embodiments should be able to learn and understand the various described aspects of the present invention. The description of the embodiments is not specifically exhaustive, but should facilitate understanding of the present invention to the extent that other embodiments within the knowledge of those skilled in the art who read the description of the embodiments will be understood to be consistent with the application of the present invention.

[0022] In conventional examples, the operational cycle of a one-time password (authentication) card corresponds to the runtime generation and verification of an authentication transaction cryptogram, which may be performed by a separate card personalization and verification entity. In such cases, for example, when a third-party remote OTP card verification device is involved, one drawback is the necessary network interaction between the OTP card manufacturing and personalization entity and the OTP card verification device to enable runtime verification of the OTP authentication transaction (e.g., verification of the OTP transaction cryptogram). Such an apparatus is shown in prior art FIG. 1.

[0023] 1, two master keys, corresponding for example to an authentication master key (MK1) and an encryption master key (MK2), are provided to both the personalization HSM (120) and the validation HSM (140). MK1 and MK2 are used to generate message authentication codes (MACs) and OTP transaction ciphertexts, respectively. As shown in FIG. 1, the card embossed record (150) may be used by the personalization HSM (120) to generate a shared secret value (MAC) transmitted to the verifying HSM, for example, during the OTP card personalization phase. Communication of such a record may be necessary to enable runtime verification of the OTP authentication cryptogram (e.g., the OTP transaction cryptogram) by the verifying entity. As described, such an embossed record may be communicated in encrypted and / or clear form to a remote verifying entity (e.g., the verifying HSM 140) during the OTP card personalization phase. However, as shown in FIG. 1, this arrangement poses security risks involving network exposure (e.g., unauthorized interception) of the transmitted (shared) embossed record. These and other deficiencies exist. Therefore, what is needed is a system and method for decoupling the respective operations of the personalization HSM and the verifying HSM to enable runtime operation of the OTP authentication card without exposing sensitive cryptographically related card embossed data.

[0024] One aspect of the present disclosure is directed to a novel cryptography provisioning service that enables a third-party verification entity to independently perform decryption and verification of transaction cryptograms associated with (personalized) OTP authentication cards without network communication with a personalization / manufacturing entity. The proposed system and method provides valuable utility from a security perspective by eliminating the need for network communication (sharing of cryptography-related data) during the card personalization stage. An additional utility provided by the proposed system and method is streamlining the outsourcing of authentication / verification services for transaction processing involving OTP authentication cards.

[0025] 2 illustrates an exemplary system (200) for decoupling the OTP transaction ciphertext decryption and verification process (e.g., performed by a validation HSM) from the card personalization process that facilitates the generation of the OTP transaction ciphertext. According to some embodiments of the proposed solution, this can be achieved by introducing a separate master key for the generation of the shared secret data. The shared secret (SS) master key is distributed to both the personalization HSM and the validation HSM, enabling independent derivation of the (shared) secret value by each Hardware Security Module (HSM).

[0026] 2, the cryptographic service provider distributes first and second master keys (MK1 and MK2 for MAC generation and encryption, respectively) along with an additional shared secret master key (MK3) that can be used by the personalization HSM (240) to generate a unique secret identifier (e.g., a shared secret value), represented in example 200 as UDK3. 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 ciphertext verification process. According to some embodiments, the personalization HSM (240) can generate a set of unique card keys (UDK1, UDK2, UDK3) by encrypting a globally unique card identifier (UID) with each master key (e.g., MK1, MK2, MK3), as represented by a process (242) executed on the personalization HSM (240), for example. Personalization information consisting of a unique card key and a globally unique card identifier (UID) can then be stored on the OTP card (e.g., in a memory (212) integrated into the contactless card (210)).

[0027] In some embodiments, the verifying entity may also store instructions embedded in the verification function on how to use the master key to decrypt and verify a received ciphertext message generated by an OTP card (e.g., contactless card 210). In some embodiments, the OTP card may correspond to a uniquely configured contactless card (210) with an integrated processor (211) and an NFC tag (213) that stores NFC-transmittable user authentication data (e.g., readable by a mobile device equipped with a reader component and running a corresponding application). The contactless card (210) may further 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 the generation of OTP authentication ciphertext. In some embodiments, the transaction counter value is updated for each OTP transaction initiated by the contactless card. An exemplary process flow (300) for generating an encrypted authentication message (e.g., an OTP authentication ciphertext) by an OTP card is shown in FIG. 3.

[0028] As described above, for some embodiments, the personalization HSM may generate a unique secret identifier (e.g., a shared secret value) by encrypting a globally unique card identifier (UID) associated with the OTP card with a shared secret (SS) master key corresponding to a third master key (MK3), as shown in Figure 2. The embossed file further comprises a first unique key obtained by encrypting the globally unique card identifier (UID) with the first master key (MK1) and a second unique key obtained by encrypting the globally unique card identifier (UID) with a second master key (MK2). In some embodiments, the shared secret (SS) master key corresponding to the third master key (MK3) may be distributed to the personalization HSM and the verification HSM as a cryptographic function.

[0029] According to example 300, the specific cryptographic inputs (e.g., SS value, UDK1, UDK2) required to generate the transaction ciphertext are generated by process 301 (corresponding to generating a unique secret identifier (304) by cryptographically combining MK3 and the UID), process 302 (corresponding to generating a first unique card key (UDK1) by cryptographically combining MK1 and the UID), and process 303 (corresponding to generating a second unique card key (UDK2) by cryptographically combining MK2 and the UID), respectively. According to some embodiments, processes 301, 302, and 303 may be performed by a personalization hardware security module (HSM), with only the output values ​​(e.g., SS value 304, UDK1, and UDK2) written to the OTP card. According to other embodiments, the aforementioned processes may be performed on the OTP card at runtime (e.g., at the initiation of a transaction using the OTP card). In such a scenario, the corresponding master keys (MK1, MK2, MK3) are stored in the OTP card's internal memory and are used as appropriate by an applet stored on the OTP card to generate card-specific cryptographic inputs (SS value, UDK1, UDK2, etc.).

[0030] Referring back to the exemplary process flow 300, runtime-generated data, such as an application transaction counter (ATC) value, may then be used to diversify UDK1. UDK1 is further cryptographically 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 used to generate a message authentication code (MAC). As further shown in the exemplary process flow 300, the generated MAC (308) may be appended to the payload message (310) to create a data packet (312). The resulting data packet (312) is encrypted with an encryption session key (314) generated at runtime by diversifying the output of process 303 (e.g., UDK2) with the ATC value to generate an OTP card (transaction) cryptogram.

[0031] As shown in FIG. 4, a send ciphertext message (404) consisting of a transaction ciphertext (402) with multiple encryption layers can be sent to a validating HSM at runtime (e.g., at the initiation of a transaction using an OTP card). The exemplary transaction ciphertext (402) shown in FIG. 4 may consist of 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 (compatible with the SS value and / or UDK3) may be generated by the personalization HSM during the OTP card's personalization phase (by encrypting the UID with the SS master key) or by the OTP card at runtime. According to one embodiment, the MAC may be independently derived and verified by the validating entity at runtime.

[0032] With reference to example 400 in FIG. 4 , the transaction ciphertext (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 in FIG. 4 , the ATC value is used as a diversification parameter along with the unique card keys (e.g., UDK1 and UDK2) at runtime (referred to as tap time for contactless OTP cards) to create the authentication session key (306) and encryption session key (314). In some embodiments, the diversification algorithm may be implemented by performing an exclusive-or (XOR) logical operation. The authentication session key (306) is used to generate a MAC, and the encryption session key is used to encrypt the combination of the payload and MAC (e.g., data packet 312) to generate the transaction ciphertext (402). In some embodiments, the payload corresponds to an 8-byte random number, and the shared secret value (304) corresponds to the most entropic 4 bytes associated with the encryption of a globally unique card identifier (UID) with MK3 (e.g., the output of process 301).

[0033] Thus, according to some embodiments, the generation of the MAC can correspond to two rounds of encryption: once with the authentication session key (generated by scrambling and / or diversifying UDK1 with the ATC value and the shared secret value 304), and again with the encryption session key (obtained by scrambling and / or diversifying UDK2 with the ATC value), which occurs after the MAC is concatenated with the payload.

[0034] As can be seen from the Send Ciphertext Message (404) shown in FIG. 4, shared (cryptography-related) data values ​​(e.g., data parameters that the verifying entity must possess to decrypt and authenticate the OTP transaction ciphertext) correspond to data generated and / or provided at runtime, such as the UID and ATC values. The required runtime-generated data is transmitted to the verification device in the Send Ciphertext Message (404) along with the transaction ciphertext (402). In accordance with an exemplary implementation of the disclosed system / method, one or more required data that may not be provided at runtime, such as the SS value (304), can be independently derived by the verification device at runtime using a stored master key and the data received in the Send Ciphertext Message (404). The verification process associated with an embodiment of the proposed solution is further described with reference to FIGS. 5-7.

[0035] According to the exemplary embodiment 400, the ciphertext send message (404) may further include information related to a verification device routing code (406) for identifying a corresponding verifying HSM.

[0036] In some embodiments, a master key reference (408) (e.g., one or more key identifiers used to generate a MAC and encrypt a MAC appended payload) can be inserted into the ciphertext send message (404) along with the transaction ciphertext (402) and the verification device routing code (406). The above configuration represents enhanced HSM functionality by incorporating the master key derivation function into the MAC verification function.

[0037] Figure 5 illustrates exemplary runtime verification operations performed, for example, by a verifying HSM (250). The runtime verification process is executed on the verifying entity, for example, as shown by process 502. Process 502 utilizes stored master keys (MK1, MK2, MK3) to decrypt the transaction ciphertext (402) included in the ciphertext send message (404) and authenticate the MAC (308). An exemplary runtime process flow (503) associated with the verification process (502) is shown in Figure 5. A received ciphertext send message (404) (e.g., generated according to Figures 3 and 4) is processed using the stored master keys (MK1, MK2, MK3) according to process flow (503) to decrypt the transaction ciphertext (402) and authenticate the MAC.

[0038] The process flow diagram (503) illustrates an exemplary scheme for applying the stored master keys MK1, MK2, MK3 in combination with information (e.g., UID and latest ATC value) sent in the OTP Card Send Ciphertext message (404) to derive an encrypted session key (314) for decrypting the transaction ciphertext (402) and extracting a (pre-encrypted) MAC (e.g., adding an additional layer of encryption to UDK1) from the decrypted data packet (312). The MAC and concatenated payload (pre-encrypted at a first layer using UDK1) may also be extracted from the decrypted packet (505) and verified by the verifying HSM (242). As illustrated by process flow (503), the encrypted session key (504) can be generated by the runtime verification process by cryptographically combining the transmitted ATC value with a UDK2 derived by encrypting the transmitted UID and a stored MK2 (e.g., stored in the verification HSM and / or a database communicatively coupled to the verification HSM).

[0039] A unique secret identifier (509) is then independently derived by the verifying HSM (250) by encrypting the UID with an SS master key (e.g., MK3), storing it locally on the verifying HSM, and matching it with the unique secret identifier (304) provided in the ciphertext transmit message (404). Upon determining a match between the independently derived SS value (509) and the transmitted SS value (304), the unique secret identifier (e.g., SS value) is used to derive an authentication session key (313). The authentication session key (313) may be calculated by the verifying HSM (250) by cryptographically combining the UDK1 and shared secret value (509) with the transmitted TC value at runtime, as shown in process flow (503).

[0040] In some embodiments, the SS master key distributed by the central cryptographic service provider may be stored in the validating HSM along with one or more mapping records for matching a globally unique card identifier (UID) with a corresponding user account. The UID may be provided to the validating HSM as part of a send ciphertext message generated by the OTP card.

[0041] 6 is a flow diagram (600) presenting an exemplary operational overview for parallelizing the operational flow (602) performed by the personalization HSM (604) during the personalization phase of the OTP card (e.g., including step 605 for deriving unique card keys (UDK1 and UDK2) and step 606 for storing the generated card embossment record on the OTP card) and the operational flow (607) performed by the verification HSM during the personalization phase of the OTP card (602). As shown in flow diagram (600), the operational flow 607 simply includes the verification HSM storing a distributed master key that includes a shared secret master key for independently deriving a unique secret identifier. As flow diagram (600) shows, step 607 can be performed in parallel (independently) with the operational flow (602).

[0042] Returning to FIG. 6 , the exemplary process (600) can begin with distribution of a set of cryptographic master keys, including a shared secret key for independent derivation of a shared secret value (e.g., a unique secret identifier) ​​by the personalization and verification HSM (HSM2). This is represented by data communication path 603 in flow diagram 600. A parallelized scheme for implementing the OTP card encryption service (e.g., during the OTP card personalization phase) allows the runtime verification process, including decryption and verification of the ciphertext message (steps (623)-(625)), to be performed by the independent verification HSM (608) using only the runtime information transmitted in the ciphertext transmission message (e.g., obtained via steps 621 and 622). Steps 621 and 622, representing the runtime operation of the OTP card (e.g., enabled by the personalization process flow), correspond to the generation (621) and transmission (622) of the ciphertext transmission message.

[0043] 6, the OTP card personalization phase, represented by steps 605 and 606, may include the generation and storage of embossed records (e.g., shared secret values, UDK1, UDK2, and UID) in the OTP card's integrated memory. As shown in flow diagram 600, the verification entity role, consisting of storing a master key as part of the ciphertext verification function (step 607), may be performed in parallel with the personalization phase to facilitate a series of runtime operations (620) consisting of generating (621), transmitting (622), and verifying (623-625) an OTP ciphertext message. In some embodiments, the OTP ciphertext message may further include a routing code to identify the destination verification HSM (e.g., verification HSM 608).

[0044] As shown in step 621, generating an OTP transaction ciphertext consists of cryptographically diversifying UDK1 with the ATC value and the unique 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 using a session encryption key generated by cryptographically diversifying UDK2 and the UID stored on the card (step 621.3). The diversification function can correspond to an exclusive-or (XOR) logic operation. In some embodiments, the payload corresponds to a randomly generated 8-byte number.

[0045] As shown in example flow diagram 600, runtime verification of the OTP ciphertext may further include step 623 of deriving an encrypted session key and decrypting the ciphertext, step 624 of deriving a shared secret value (e.g., a unique secret identifier) ​​to use with UDK1 to calculate a MAC, and step 625 of authenticating the MAC and verifying the payload associated with the OTP card transaction ciphertext. In some embodiments, instructions for decrypting and authenticating the input ciphertext using a set of referenced master keys may be integrated into the ciphertext verification process performed in the verifying HSM.

[0046] As shown in operational flow diagram (600) according to an exemplary embodiment of the present disclosure, communication and / or network transmissions may not be required between separate personalization and verification HSMs to enable the runtime sequence of operations (620) associated with an OTP card transaction (e.g., generation / transmission and verification of an authenticated cryptographic message).

[0047] Figure 7 illustrates an exemplary timing sequence diagram (700) for parallelizing the operational flow associated with personalization and verification of an OTP card without communication between different personalization and verification entities. Referring to Figure 7, the process may begin with a cryptographic service provider (702) communicating a set of master encryption keys (703) to both the personalization HSM (710) and the verification HSM (720). As illustrated in the exemplary diagram of Figure 7, the operations performed by the HSM (710) during the card personalization phase consist of creating an embossed record corresponding to the generation of a unique covert identifier (operation 711) using a shared secret master key (e.g., MK3) and generating unique derived card keys UDK1 and UDK2 (operations 712 and 713). The created embossed record is written to the OTP card in operation step 714, completing the personalization of the OTP card. The personalization process (depicted by operational steps 711-714) enables the OTP card to generate a unique encrypted authentication message (e.g., a ciphertext transmission message) at runtime that may be verified and authenticated by a verifying entity (720).

[0048] The generated embossed record written to the OTP card in step (714) may be stored in the personalization HSM (710) and / or a database (715) communicatively coupled to the personalization HSM (710).

[0049] According to the exemplary timing diagram (700), the operational flow performed by the verifying HSM may proceed independently from the operations performed by the HSM (710) during the OTP card personalization phase. For example, following distribution of the master key (703) by the cryptographic service provider (702), the verifying entity (720) may proceed with storing the received master key (703), corresponding to operational step 721, to enable a runtime cryptographic verification process including decryption, verification, and authentication of incoming ciphertext transmission messages (716) that may be generated by the OTP card (705) at runtime (e.g., at the initiation of an OTP card transaction).

[0050] As described above with respect to the exemplary timing sequence diagram (700), the personalization HSM can generate a card embossment record (714) that is stored on the OTP card (705). The embossment record may consist of one or more globally unique card identifiers (UIDs) and a set of unique card keys (UDK1 and UDK2) derived by encrypting the UIDs with a (first) authentication master key and a (second) encryption master key distributed by the cryptographic service provider (702) to both the personalization HSM (710) and the verification HSM (720). As further described above according to some embodiments of the present disclosure, a third master key (MK3) may also be distributed to the personalization HSM and the verification HSM via communication 703. The third master key (MK3) may correspond to a cryptographic function that scrambles the globally unique card identifier (UID) to generate a secret unique identifier (shared secret value) that is used at runtime to derive an authentication session key for generating a MAC that is stored on the card and added to the payload message.

[0051] The verifying HSM (720) can independently derive a shared secret value as part of the process of calculating an authentication session key using the stored master key (e.g., step 721, which can be performed in parallel with the OTP card personalization steps 711-715), decrypt and authenticate the MAC associated with the OTP transaction ciphertext, and verify the payload contained in the ciphertext send message (716), which may be sent by the OTP card (705) at specific times when the OTP card is actively being used to facilitate an electronic authentication transaction.

[0052] Thus, as shown in the exemplary timing sequence (700), decryption and verification of the received (authentication) cipher may be performed by the verifying HSM (720) using a commonly distributed master key (stored in step 721) and data included in the runtime OTP card send ciphertext message (716). In some embodiments, the data may include a globally unique card identifier (UID) along with an application transaction counter (ATC) value recorded by the OTP card. The recorded ATC value is incremented for each subsequent OTP authentication transaction initiated by the contactless card. In some embodiments, the send ciphertext message (716) may include a verification device routing code to properly identify the corresponding verifying HSM (e.g., verifying HSM 720). Upon receiving the send ciphertext message (716), the verifying entity may use a MAC verification function as part of the decryption process to decrypt, authenticate, and verify the received transmission using the stored master key. 7, the (runtime) verification process triggered upon receipt of the Ciphertext Send Message (716) can be represented by a series of operations corresponding to decrypting the received Ciphertext Send Message to obtain the payload along with the encrypted MAC (corresponding to step 722), deriving a unique secret identifier using the stored MK3 in combination with the UID (step 723), and subsequently decrypting and authenticating the MAC (step 724). Upon successful verification of the encrypted payload and authentication of the MAC, a verification response (725) is sent back to the requesting party associated with the OTP card transaction.

[0053] In some embodiments, the cryptographic service provider may support a central key processing unit configured to generate and distribute shared master keys to personalization and verification entities, in addition to authentication master keys and encryption master keys.

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

[0055] 8, for example, computer-accessible medium 815 (e.g., a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, or a collection thereof, as described hereinabove) may be provided (e.g., in communication with processing unit 805). Computer-accessible medium 815 may include executable instructions 820 thereon. Additionally or alternatively, storage device 825 may be provided separate from computer-accessible medium 815, which may provide instructions to processing unit 805 to, for example, configure the processing unit to perform certain example procedures, processes, and methods, such as those described hereinabove.

[0056] Additionally, the exemplary processing device 805 can comprise or include input / output ports 835, which may include, for example, a wired network, a wireless network, the Internet, an intranet, data collection probes, sensors, etc. As shown in Figure 8, the exemplary processing device 805 can be in communication with an exemplary display device 830, which, according to certain exemplary embodiments of the present disclosure, may be, for example, a touchscreen configured for inputting information into the processing device in addition to outputting information from the processing device. Additionally, the exemplary display device 830 and / or storage device 825 can be used to display and / or store data in a user-accessible and / or user-readable format.

[0057] As used herein, the term "card" is not limited to any particular type of card. Rather, it is understood that the term "card" can refer to contact cards, contactless cards, or other cards unless otherwise specified. Furthermore, it is understood that the present disclosure is not limited to cards having a particular purpose (e.g., payment cards, gift cards, identification cards, membership cards, transportation cards, access cards), cards associated with a particular type of account (e.g., credit accounts, debit accounts, membership accounts), or cards issued by a particular entity (e.g., commercial organizations, financial institutions, government agencies, social clubs, etc.). Instead, the present disclosure is understood to include cards having any purpose, account association, or issuing entity.

[0058] The systems and methods described herein can provide secure retrieval of sensitive user information or streamlined communication and processing of sensitive user information to facilitate secure electronic transactions. Once a valid authentication response from an authenticated user is established, the automated data retrieval and transfer system and process can authorize, without limitation, financial transactions (e.g., credit and debit card transactions), account management transactions (e.g., card renewal, card replacement, add new card transactions), membership transactions (e.g., immigration transactions), access point transactions (e.g., building access, secure warehouse access transactions), transportation transactions (e.g., ticketing and boarding), and other transactions.

[0059] As used herein, personally identifiable information (PII) may include any sensitive data, including financial data (e.g., account information, account balance, account activity), personal 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, authentication codes, biometric data), and other information that a user wishes to avoid revealing to unauthorized persons.

[0060] The present disclosure is not limited in terms of the specific embodiments described in this application, which are intended as illustrative of various aspects. Clearly, many modifications and variations are possible without departing from the spirit and scope thereof. Functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those recited herein, will be apparent from the foregoing exemplary description. Such modifications and variations are intended to be included within the scope of the appended exemplary claims. The present disclosure is to be limited only by the terms of the appended exemplary claims, along with the full scope of equivalents to which such exemplary claims are entitled. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting.

[0061] Furthermore, it should be noted that the systems and methods described herein may be embodied in one or more physical media, such as, but not limited to, a compact 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, data storage devices include random access memory (RAM) and read-only memory (ROM), which are configured to access and store data, information, and computer program instructions. Data storage devices also include storage media or other suitable types of memory (e.g., RAM, ROM, erasable programmable read-only memory (PROM), electrically 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, etc.) on which an operating system, application programs including, for example, a web browser application, an email application and / or other applications, and files constituting data files are stored.Data storage in 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 (e.g., databases created and maintained with Oracle® Corporation software), Microsoft® Excel files, Microsoft® Access files, 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. Additionally, the figures illustrate various components (e.g., servers, computers, processors) separately. Functions described as being performed by various components may be performed by other components, and various components may be combined or separated. Other variations are possible.

[0062] In the foregoing specification, various embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made thereto, and additional embodiments can be made, without departing from the broad scope of the invention as defined in the following claims. The specification and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. 1. A method for parallelizing the generation and verification of encrypted data associated with a contactless authentication card, the method comprising: distributing, via secure communications 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, the personalization HSM and the verification HSM being distinct and storing 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 a shared secret master key; storing the unique covert identifier in an embossed file on the contactless card during a personalization phase, the embossed file further comprising 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), the MAC being generated by encrypting the unique secret identifier and a runtime-generated transaction counter value with the first unique key; sending, by the contactless card, a send cryptogram message to the validating HSM, the send cryptogram message including the transaction cryptogram, the unique secret identifier, the transaction counter value, and the globally unique card identifier; verifying, by the verifying HSM, the unique covert identifier using the shared secret master key; the verifying HSM verifying the MAC using the unique secret identifier, the first unique key, and the transaction counter; A method for providing

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

3. the ciphertext transmit message is sent to the verifying HSM at the start of an authentication transaction using the contactless card; The method of claim 1.

4. the ciphertext transmission message further comprises information relating to a routing code for identifying the verifying HSM and a set of key identifiers as references to first, second and shared secret master keys; The method of claim 3.

5. the shared secret master key is distributed to the personalization HSM and the verification HSM as a cryptographic function; The method of claim 1.

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

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

8. the diversification function corresponds to an exclusive-or (XOR) logical operation; The method of claim 7.

9. the shared secret master key is stored on the contactless card and is used at run time by an applet running on the contactless card to derive the unique covert identifier; The method of claim 1.

10. the shared secret master key distributed by the cryptographic service provider is stored by the validating entity along with one or more mapping records for matching the globally unique card identifier with a corresponding user account; The method of claim 1.

11. the globally unique card identifier is derived by the verifying HSM by decrypting the unique covert identifier with the shared secret master key, and the unique covert identifier is provided in the ciphertext transmission message; The method of claim 10.

12. the unique secret identifier is derived by the verifying HSM by encrypting the globally unique card identifier with the shared secret master key stored in the verifying HSM, and the globally unique card identifier is provided in the ciphertext transmission message; The method of claim 11.

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

14. 1. A system for securely providing cryptographic services for contactless card transactions, the system comprising: generating, by the central key processing device, in addition to the authentication master key and the encryption master key, a shared secret master key, said shared secret master key being used to generate a shared secret value; distributing, by the central key processing device, the shared secret master key, along with the authentication master key and the encryption master key, to a personalization Hardware Security Module (HSM) associated with a card manufacturing entity and a verifying HSM associated with a verifying entity, enabling independent derivation of the shared secret value by the verifying HSM using data in an encrypted transaction message; providing instructions for inserting into the encrypted transaction message a routing code identifying the verifying HSM and information associated with a set of key identifiers as references to the authentication master key, the encryption master key, and the shared secret master key; The computer hardware device is configured to: system.

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

16. the shared secret value is independently derived by the verifying HSM using the shared secret master key; The system of claim 15.

17. the validating HSM's independently derived shared secret value is verified against the shared secret value sent to the validating HSM during the contactless card transaction; 17. The system of claim 16.

18. A non-transitory computer readable medium containing instructions for execution by a computer hardware device, wherein upon execution of the instructions, the computer hardware device: Distributing a shared secret master key via secure communications from a cryptographic service provider to a personalization Hardware Security Module (HSM) associated with the manufacturing entity and a validating HSM associated with the validating entity; the production HSM and the verification HSM are separate 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 a shared secret master key; the embossed file further stores a globally unique card identifier, a first unique key obtained by encrypting the globally unique card identifier with a first master key, and a second unique key obtained by encrypting the globally unique card identifier with a second master key; generating, by the contactless card, a transaction cryptogram including a message authentication code (MAC), the MAC being generated by encrypting a unique secret identifier and a runtime-generated transaction counter value with the first unique key; sending, by the contactless card, a send ciphertext message to the verifying HSM, the send ciphertext message comprising a transaction ciphertext, the unique secret identifier, the transaction counter value, and the globally unique card identifier; verifying, by the verifying HSM, the unique secret identifier using a shared secret master key; the verifying HSM verifying a MAC using the unique secret identifier, the first unique key, and a transaction counter; configured to perform a procedure comprising: A non-transitory computer-readable medium.

19. further comprising instructions for incrementing a transaction counter value with each authentication transaction facilitated by the contactless card.

20. The non-transitory computer-readable medium of claim 18.

20. and instructions for inserting, by the personalization HSM, information relating to a routing code and a set of key identifiers into the contactless card, the routing code identifying the verifying HSM and the set of key identifiers identifying a first master key, a second master key, and the shared secret master key.

20. The non-transitory computer-readable medium of claim 18.

Images