Method, system, and computer program product for multi-party computation based remote secure key exchange

The method addresses the challenge of secret key distribution in symmetric key cryptography by implementing a multi-party computation based remote secure key exchange, enabling secure and efficient key management without physical meetings.

WO2025090090A1PCT designated stage expired Publication Date: 2025-05-01VISA INTERNATIONAL SERVICE ASSOCIATION
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/US2023/078031
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-10-27
Publication Date
2025-05-01

AI Technical Summary

Technical Problem

The distribution of secret keys in symmetric key cryptography is challenging due to the need for face-to-face meetings or trusted couriers, making it impractical and insecure, especially when a large number of keys are required.

Method used

A computer-implemented method for multi-party computation based remote secure key exchange, which involves receiving identifiers for key custodians, authenticating them, verifying a quorum, establishing key management operations, generating a secure cryptographic key, encrypting it, and transmitting encrypted components to the key custodians.

Benefits of technology

This solution enables secure and efficient remote key exchange without the need for physical meetings, ensuring that no single entity possesses the complete key, thus enhancing security and reducing the risk of key management complexities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2023078031_01052025_PF_FP_ABST
    Figure US2023078031_01052025_PF_FP_ABST
Patent Text Reader

Abstract

Provided are methods for multi-party computation based remote secure key exchange, that include authenticating a first key custodian based on an identifier associated with the first key custodian and a second key custodian based on an identifier associated with the second key custodian, verifying a quorum is available, establishing key management operations to be performed based on verifying that the quorum is available, receiving a collaborative key generation request, generating a secure cryptographic key, encrypting a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key, and transmitting the first component encrypted secure cryptographic key to the first key custodian the second component encrypted secure cryptographic key to the second key custodian. Systems and computer program products are also disclosed.
Need to check novelty before this filing date? Find Prior Art

Description

METHOD, SYSTEM, AND COMPUTER PROGRAM PRODUCT FOR MULTIPARTY COMPUTATION BASED REMOTE SECURE KEY EXCHANGEBACKGROUND1. Field

[0001] The disclosed subject matter relates generally to methods, systems, and products for secure multi-party computation applications and, in some particular embodiments or aspects, to methods, systems, and computer program products for multi-party computation based remote secure key exchange to distribute information among different parties and / or locations.2. Technical Considerations

[0002] Computer security (e.g., cyber security, digital security, information technology security (IT security), etc.) may refer to the protection of computer systems and networks from attacks by malicious actors that may result in unauthorized information disclosure, theft of, or damage to hardware, software, or data, as well as from the disruption or misdirection of the services they provide. In many situation, cryptography may form a fundamental aspect of a computer security paradigm.

[0003] Cryptography (e.g., cryptology) may refer to the practice and / or study of techniques for secure communication in the presence of adversarial behavior. In general, cryptography may involve constructing and / or analyzing protocols that prevent third parties and / or public from reading private communication and involve disciplines such as computer science, information security, electrical engineering, digital signal processing, and / or the like. Practical applications of cryptography may include electronic commerce, chip-based payment cards, digital currencies, computer passwords, and / or military communications. In many modern situations, symmetric key cryptography has been used. Symmetric key cryptography may refer to encryption methods in which both a sender and a receiver share the same key, or in which the keys of the sender and the receiver are different, but related in an easily computable way.

[0004] However, in symmetric key cryptography, each party to a scenario may need to possess a secret key, which must be exchanged prior to using any encryption. Distribution of secret keys can be problematic in that the distribution involves face-to- face meeting and / or use of a trusted courier, which may be impractical and unsafe. While the secret keys are in transit, the secret keys could be stolen and / or copied bya another party and the other party may then be able to decrypt any cipher texts encrypted with the secret key. Another problem is that a large number of secret keys may be needed between communicating parties. The large number of secret keys quickly becomes difficult to manage.SUMMARY

[0005] Accordingly, it is an object of the presently disclosed subject matter to provide methods, systems, and computer program products for multi-party computation based remote secure key exchange that overcome some or all of the deficiencies identified above.

[0006] According to non-limiting embodiments or aspects, provided is a computer- implemented method for multi-party computation based remote secure key exchange, including receiving, by at least one processor, an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticating, by at least one processor, the first key custodian based on the identifier associated with the first key custodian; authenticating, by at least one processor, the second key custodian based on the identifier associated with the second key custodian; verifying, by at least one processor, a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establishing, by at least one processor, key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receiving, by at least one processor, a collaborative key generation request associated with the first key custodian and the second key custodian; generating, by at least one processor, a secure cryptographic key; encrypting, by at least one processor, a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmitting, by at least one processor, the first component encrypted secure cryptographic key to the first key custodian; and transmitting, by at least one processor, the second component encrypted secure cryptographic key to the second key custodian.

[0007] According to non-limiting embodiments or aspects, receiving the collaborative key generation request associated with the first key custodian and the second key custodian comprises: receiving a first key generation request associatedwith the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian; receiving a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validating a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

[0008] According to non-limiting embodiments or aspects, further includes receiving an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receiving an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determining the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determining the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and storing the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

[0009] According to non-limiting embodiments or aspects, further including prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorizing the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein authorizing the first key custodian for key management operations comprises: matching the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorizing the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein authorizing the second key custodian for key management operations comprises: matching the identifier associated with the second key custodian to the second request identifier associated with the second keycustodian stored in the data structure associated with authorization of key management operations.

[0010] According to non-limiting embodiments or aspects, wherein receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian comprises: receiving a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian. According to non-limiting embodiments or aspects, wherein authenticating the first key custodian comprises: authenticating, by at least one processor of a hardware security module (HSM), the first key custodian based on the identifier associated with the first key custodian; wherein authenticating the second key custodian comprises: authenticating, by at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

[0011] According to non-limiting embodiments or aspects, wherein the secure cryptographic key is a symmetric key.

[0012] According to non-limiting embodiments or aspects, provided is a system for multi-party computation based remote secure key exchange, including at least one processor programmed or configured to: receive an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticate the first key custodian based on the identifier associated with the first key custodian; authenticate the second key custodian based on the identifier associated with the second key custodian; verify a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establish key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receive a collaborative key generation request associated with the first key custodian and the second key custodian; generate a secure cryptographic key; encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmit the first component encrypted secure cryptographic key to the first key custodian; and transmit the second component encrypted secure cryptographic key to the second key custodian.

[0013] According to non-limiting embodiments or aspects, when receiving the collaborative key generation request, the at least one processor is further programmed or configured to: receive a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian; receive a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validate a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

[0014] According to non-limiting embodiments or aspects, the at least one processor is further programmed or configured to: receive an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determine the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and store the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

[0015] According to non-limiting embodiments or aspects, the at least one processor is further programmed or configured to: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorize the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein, when authorizing the first key custodian for key management operations, the at least one processor is programmed or configured to: match the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; andauthorize the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein, when authorizing the second key custodian for key management operations, the at least one processor is programmed or configured to: match the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

[0016] According to non-limiting embodiments or aspects, when receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian, the at least one processor is programmed or configured to: receive a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

[0017] According to non-limiting embodiments or aspects, the at least one processor comprises at least one processor of a hardware security module (HSM), and wherein, when authenticating the first key custodian, the at least one processor is programmed or configured to: authenticate, via the at least one processor of the HSM, the first key custodian based on the identifier associated with the first key custodian; wherein, when authenticating the first key custodian, the at least one processor is programmed or configured to: authenticate, via the at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

[0018] According to non-limiting embodiments or aspects, the secure cryptographic key is a symmetric key.

[0019] According to non-limiting embodiments or aspects, provided is a computer program product for multi-party computation based remote secure key exchange, the computer program product including at least one non-transitory computer-readable medium including one or more instructions that, when executed by at least one processor, cause the at least one processor to: receive an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticate the first key custodian based on the identifier associated with the first key custodian; authenticate the second key custodian based on the identifier associated with the second key custodian; verify a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian;establish key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receive a collaborative key generation request associated with the first key custodian and the second key custodian; generate a secure cryptographic key; encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmit the first component encrypted secure cryptographic key to the first key custodian; and transmit the second component encrypted secure cryptographic key to the second key custodian.

[0020] According to non-limiting embodiments or aspects, the one or more instructions that cause the at least one processor to receive the collaborative key generation request, cause the at least one processor to: receive a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian; receive a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validate a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

[0021] According to non-limiting embodiments or aspects, the one or more instructions further cause the at least one processor to: receive an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determine the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and store the first request identifier of the first key custodian and the second request identifier of thesecond key custodian in a data structure associated with authorization of key management operations.

[0022] According to non-limiting embodiments or aspects, the one or more instructions further cause the at least one processor to: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorize the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein, the one or more instructions that cause the at least one processor to authorize the first key custodian for key management operations, cause the at least one processor to: match the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorize the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein, the one or more instructions that cause the at least one processor to authorize the second key custodian for key management operations, cause the at least one processor to: match the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

[0023] According to non-limiting embodiments or aspects, the one or more instructions that cause the at least one processor to receive the identifier associated with the first key custodian and the identifier associated with the second key custodian, cause the at least processor to: receive a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

[0024] According to non-limiting embodiments or aspects, wherein the at least one processor comprises at least one processor of a hardware security module (HSM), and wherein, the one or more instructions that cause the at least one processor to authenticate the first key custodian, cause the at least one processor to: authenticate, via the at least one processor of the HSM, the first key custodian based on the identifier associated with the first key custodian; wherein, the one or more instructions that cause the at least one processor to authenticate the first key custodian, cause the at least one processor to: authenticate, via the at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

[0025] Other non-limiting embodiments or aspects will be set forth in the following numbered clauses:

[0026] Clause 1 : A computer-implemented method for multi-party computation based remote secure key exchange, comprising: receiving, by at least one processor, an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticating, by at least one processor, the first key custodian based on the identifier associated with the first key custodian; authenticating, by at least one processor, the second key custodian based on the identifier associated with the second key custodian; verifying, by at least one processor, a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establishing, by at least one processor, key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receiving, by at least one processor, a collaborative key generation request associated with the first key custodian and the second key custodian; generating, by at least one processor, a secure cryptographic key; encrypting, by at least one processor, a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmitting, by at least one processor, the first component encrypted secure cryptographic key to the first key custodian; and transmitting, by at least one processor, the second component encrypted secure cryptographic key to the second key custodian.

[0027] Clause 2: The computer-implemented method of clause 1 , wherein receiving the collaborative key generation request associated with the first key custodian and the second key custodian comprises: receiving a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian; receiving a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validating a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

[0028] Clause 3: The computer-implemented method of clauses 1 and 2, further comprising: receiving an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receiving an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determining the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determining the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and storing the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

[0029] Clause 4: The computer-implemented method of clauses 1 -3, further comprising: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorizing the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein authorizing the first key custodian for key management operations comprises: matching the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorizing the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein authorizing the second key custodian for key management operations comprises: matching the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

[0030] Clause 5: The computer-implemented method of clauses 1 -4, wherein receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian comprises: receiving a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

[0031] Clause 6: The computer-implemented method of clauses 1 -5, wherein authenticating the first key custodian comprises: authenticating, by at least one processor of a hardware security module (HSM), the first key custodian based on theidentifier associated with the first key custodian; wherein authenticating the second key custodian comprises: authenticating, by at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

[0032] Clause 7: The computer-implemented method of clauses 1 -6, wherein the secure cryptographic key is a symmetric key.

[0033] Clause 8: A system for multi-party computation based remote secure key exchange, comprising: at least one processor programmed or configured to: receive an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticate the first key custodian based on the identifier associated with the first key custodian; authenticate the second key custodian based on the identifier associated with the second key custodian; verify a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establish key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receive a collaborative key generation request associated with the first key custodian and the second key custodian; generate a secure cryptographic key; encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmit the first component encrypted secure cryptographic key to the first key custodian; and transmit the second component encrypted secure cryptographic key to the second key custodian.

[0034] Clause 9: The system of clause 8, wherein, when receiving the collaborative key generation request, the at least one processor is further programmed or configured to: receive a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian; receive a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validate a collaborative request of the first key custodian and the second key custodian for generation of the securecryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

[0035] Clause 10: The system of clauses 8 and 9, wherein the at least one processor is further programmed or configured to: receive an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determine the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and store the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

[0036] Clause 11 : The system of clauses 8-10, wherein the at least one processor is further programmed or configured to: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorize the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein, when authorizing the first key custodian for key management operations, the at least one processor is programmed or configured to: match the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorize the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein, when authorizing the second key custodian for key management operations, the at least one processor is programmed or configured to: match the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

[0037] Clause 12: The system of clauses 8-1 1 , wherein, when receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian, the at least one processor is programmed or configured to:receive a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

[0038] Clause 13: The system of clauses 8-12, wherein the at least one processor comprises at least one processor of a hardware security module (HSM), and wherein, when authenticating the first key custodian, the at least one processor is programmed or configured to: authenticate, via the at least one processor of the HSM, the first key custodian based on the identifier associated with the first key custodian; wherein, when authenticating the first key custodian, the at least one processor is programmed or configured to: authenticate, via the at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

[0039] Clause 14: The system of clauses 8-13, wherein the secure cryptographic key is a symmetric key.

[0040] Clause 15: A computer program product for multi-party computation based remote secure key exchange, the computer program product including at least one non-transitory computer-readable medium including one or more instructions that, when executed by at least one processor, cause the at least one processor to: receive an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticate the first key custodian based on the identifier associated with the first key custodian; authenticate the second key custodian based on the identifier associated with the second key custodian; verify a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establish key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receive a collaborative key generation request associated with the first key custodian and the second key custodian; generate a secure cryptographic key; encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmit the first component encrypted secure cryptographic key to the first key custodian; and transmit the second component encrypted secure cryptographic key to the second key custodian.

[0041] Clause 16: The computer program product of clause 15, wherein, the one or more instructions that cause the at least one processor to receive the collaborativekey generation request, cause the at least one processor to: receive a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian; receive a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validate a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

[0042] Clause 17: The computer program product of clauses 15 and 16, wherein the one or more instructions further cause the at least one processor to: receive an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determine the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and store the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

[0043] Clause 18: The computer program product of clauses 15-17, wherein the one or more instructions further cause the at least one processor to: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorize the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein, the one or more instructions that cause the at least one processor to authorize the first key custodian for key management operations, cause the at least one processor to: match the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorize the second key custodian for key management operations based on the identifier associated with the secondkey custodian, wherein, the one or more instructions that cause the at least one processor to authorize the second key custodian for key management operations, cause the at least one processor to: match the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

[0044] Clause 19: The computer program product of clauses 15-18, wherein, the one or more instructions that cause the at least one processor to receive the identifier associated with the first key custodian and the identifier associated with the second key custodian, cause the at least processor to: receive a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

[0045] Clause 20: The computer program product of clauses 15-19, wherein the at least one processor comprises at least one processor of a hardware security module (HSM), and wherein, the one or more instructions that cause the at least one processor to authenticate the first key custodian, cause the at least one processor to: authenticate, via the at least one processor of the HSM, the first key custodian based on the identifier associated with the first key custodian; wherein, the one or more instructions that cause the at least one processor to authenticate the first key custodian, cause the at least one processor to: authenticate, via the at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

[0046] These and other features and characteristics of the presently disclosed subject matter, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture will become more apparent upon consideration of the following description and the appended claims, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the disclosed subject matter. As used in the specification and the claims, the singular form of “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise.BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Additional advantages and details of the disclosed subject matter are explained in greater detail below with reference to the exemplary embodiments or aspects that are illustrated in the accompanying figures, in which:

[0048] FIGS. 1 A-B are diagrams of a non-limiting embodiment or aspect of an environment in which methods, systems, and / or computer program products, described herein, may be implemented according to the principles of the presently disclosed subject matter;

[0049] FIG. 2 is a diagram of a non-limiting embodiment or aspect of components of one or more devices of FIG. 1 A;

[0050] FIG. 3 is a flowchart of a non-limiting embodiment or aspect of a process for multi-party computation based remote secure key exchange; and

[0051] FIGS. 4A-4D are diagrams of non-limiting embodiments or aspects of an implementation of a process for multi-party computation based remote secure key exchange according to some non-limiting embodiments or aspects.DETAILED DESCRIPTION

[0052] For purposes of the description hereinafter, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and derivatives thereof shall relate to the disclosed subject matter as it is oriented in the drawing figures. However, it is to be understood that the disclosed subject matter may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary embodiments or aspects of the disclosed subject matter. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting unless otherwise indicated.

[0053] No aspect, component, element, structure, act, step, function, instruction, and / or the like used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more” and “at least one.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related andunrelated items, and / or the like) and may be used interchangeably with “one or more” or “at least one.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based at least partially on” unless explicitly stated otherwise.

[0054] As used herein, the terms “communication” and “communicate” may refer to the reception, receipt, transmission, transfer, provision, and / or the like of information (e.g., data, signals, messages, instructions, commands, and / or the like). For one unit (e.g., a device, a system, a component of a device or system, combinations thereof, and / or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and / or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. Additionally, two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and / or routed between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be in communication with a second unit if at least one intermediary unit (e.g., a third unit located between the first unit and the second unit) processes information received from the first unit and communicates the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet and / or the like) that includes data. It will be appreciated that numerous other arrangements are possible.

[0055] As used herein, the terms “issuer institution,” “portable financial device issuer,” “issuer,” or “issuer bank” may refer to one or more entities that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution may provide an account identifier, such as a primary account number (PAN), to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument, e.g., a payment card, and / or may be electronic and used for electronic payments. The terms “issuer institution” and “issuer institution system” may also refer to one or more computer systems operated by or on behalf of an issuerinstitution, such as a server computer executing one or more software applications. For example, an issuer institution system may include one or more authorization servers for authorizing a transaction.

[0056] As used herein, the term “account identifier” may include one or more types of identifiers associated with a user account (e.g., a PAN, a card number, a payment card number, a payment token, and / or the like). In some non-limiting embodiments or aspects, an issuer institution may provide an account identifier (e.g., a PAN, a payment token, and / or the like) to a user that uniquely identifies one or more accounts associated with that user. The account identifier may be embodied on a physical financial instrument (e.g., a portable financial instrument, a payment card, a credit card, a debit card, and / or the like) and / or may be electronic information communicated to the user that the user may use for electronic payments. In some non-limiting embodiments or aspects, the account identifier may be an original account identifier, where the original account identifier was provided to a user at the creation of the account associated with the account identifier. In some non-limiting embodiments or aspects, the account identifier may be an account identifier (e.g., a supplemental account identifier) that is provided to a user after the original account identifier was provided to the user. For example, if the original account identifier is forgotten, stolen, and / or the like, a supplemental account identifier may be provided to the user. In some non-limiting embodiments or aspects, an account identifier may be directly or indirectly associated with an issuer institution such that an account identifier may be a payment token that maps to a PAN or other type of identifier. Account identifiers may be alphanumeric, any combination of characters and / or symbols, and / or the like. An issuer institution may be associated with a bank identification number (BIN) that uniquely identifies the issuer institution.

[0057] As used herein, the terms “payment token” or “token” may refer to an identifier that is used as a substitute or replacement identifier for an account identifier, such as a PAN. Tokens may be associated with a PAN or other account identifiers in one or more data structures (e.g., one or more databases and / or the like) such that they can be used to conduct a transaction (e.g., a payment transaction) without directly using the account identifier, such as a PAN. In some examples, an account identifier, such as a PAN, may be associated with a plurality of tokens for different individuals, different uses, and / or different purposes. For example, a payment token may include a series of numeric and / or alphanumeric characters that may be used as a substitutefor an original account identifier. For example, a payment token “4900 0000 0000 0001 ” may be used in place of a PAN “4147 0900 0000 1234.” In some non-limiting embodiments or aspects, a payment token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format). In some non-limiting embodiments or aspects, a payment token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some non-limiting embodiments or aspects, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived (e.g., with a one-way hash or other cryptographic function). Further, in some non-limiting embodiments or aspects, the token format may be configured to allow the entity receiving the payment token to identify it as a payment token and recognize the entity that issued the token.

[0058] As used herein, the term “merchant” may refer to one or more entities (e.g., operators of retail businesses that provide goods and / or services, and / or access to goods and / or services, to a user (e.g., a customer, a consumer, a customer of the merchant, and / or the like) based on a transaction (e.g., a payment transaction)). As used herein, the term “merchant system” may refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications. As used herein, the term “product” may refer to one or more goods and / or services offered by a merchant.

[0059] As used herein, the term “transaction service provider” may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and the issuer institution. In some non-limiting embodiments or aspects, a transaction service provider may include a credit card company, a debit card company, and / or the like. As used herein, the term “transaction service provider system” may also refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing server may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[0060] As used herein, the term “acquirer” may refer to an entity licensed by the transaction service provider and approved by the transaction service provider to originate transactions (e.g., payment transactions) using a portable financial device associated with the transaction service provider. As used herein, the term “acquirer system” may also refer to one or more computer systems, computer devices, and / or the like operated by or on behalf of an acquirer. The transactions may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funding transactions (AFTs), and / or the like). In some non-limiting embodiments or aspects, the acquirer may be authorized by the transaction service provider to assign merchant or service providers to originate transactions using a portable financial device of the transaction service provider. The acquirer may contract with payment facilitators to enable the payment facilitators to sponsor merchants. The acquirer may monitor compliance of the payment facilitators in accordance with regulations of the transaction service provider. The acquirer may conduct due diligence of the payment facilitators and ensure that proper due diligence occurs before signing a sponsored merchant. The acquirer may be liable for all transaction service provider programs that the acquirer operates or sponsors. The acquirer may be responsible for the acts of the acquirer’s payment facilitators, merchants that are sponsored by an acquirer’s payment facilitators, and / or the like. In some non-limiting embodiments or aspects, an acquirer may be a financial institution, such as a bank.

[0061] As used herein, the terms “client” and “client device” may refer to one or more client-side devices or systems (e.g., remote from a transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). As an example, a “client device” may refer to one or more POS devices used by a merchant, one or more acquirer host computers used by an acquirer, one or more mobile devices used by a user, and / or the like. In some non-limiting embodiments or aspects, a client device may be an electronic device configured to communicate with one or more networks and initiate or facilitate transactions. For example, a client device may include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, and / or the like), PDAs, and / or the like. Moreover, a “client” may also refer to an entity (e.g., a merchant, an acquirer, and / or the like) that owns, utilizes, and / or operates a client device for initiating transactions (e.g., for initiating transactions with a transaction service provider).

[0062] As used herein, the term “computing device” may refer to one or more electronic devices that are configured to directly or indirectly communicate with or over one or more networks. A computing device may be a mobile device, a desktop computer, and / or any other like device. Furthermore, the term “computer” may refer to any computing device that includes the necessary components to receive, process, and output data, and normally includes a display, a processor, a memory, an input device, and a network interface. As used herein, the term “server” may refer to or include one or more processors or computers, storage devices, or similar computer arrangements that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computers, e.g., servers, or other computerized devices, directly or indirectly communicating in the network environment may constitute a “system.”

[0063] The term “processor,” as used herein, may represent any type of processing unit, such as a single processor having one or more cores, one or more cores of one or more processors, multiple processors each having one or more cores, and / or other arrangements and combinations of processing units.

[0064] As used herein, the term “system” may refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of such, and / or the like). Reference to “a device,” “a server,” “a processor,” and / or the like, as used herein, may refer to a previously-recited device, server, or processor that is recited as performing a previous step or function, a different server or processor, and / or a combination of servers and / or processors. For example, as used in the specification and the claims, a first server or a first processor that is recited as performing a first step or a first function may refer to the same or different server or the same or different processor recited as performing a second step or a second function.

[0065] As used herein, the term “Payment Card Industry Data Security Standard” (PCI-DSS) may refer to an information security standard for organizations that handle branded credit cards from the major card schemes. The PCI-DSS is mandated by the payment card companies but administered by the Payment Card Industry Security Standards Council.

[0066] As used herein, “public key encryption” involves encoding a message to protect it from unwanted viewers by passing the message through a mathematical function (called a “cipher”) which uses a key to hide the original values in the message, and decoding the message depends on having the key that returns the values back to their original state, allowing the message to be read. In public key encryption (e.g., asymmetric encryption), the key that encodes the message and the one that decodes it are different (i.e., asymmetrical). It may be called public key encryption or cryptography, because one key is made widely available (the “public key”) while the other is kept private (the “private key”) to ensure the security of the message. Public key encryption relies on private keys being kept secure, secret, and unavailable to those who may intercept, attack, or adulterate messages. Whether the public key is used to encrypt or verify the message depends on the nature of the message. For example, the private key is often used to sign a message anyone can read, but cannot tamper with, at least without invalidating the signature. In cases where everyone is able to encrypt a message, but not open it (e.g., not easily decrypted if intercepted by the wrong person, etc.), it is encrypted with the public key, but only decrypted with the associated private key.

[0067] As used herein, “symmetric key” (e.g., a shared key, a secret key, a symmetric encryption key, etc.) refers to a cryptographic key that is used for both encryption and decryption of data. Such keys are used to secure sensitive information and ensure data confidentiality, may be used to transmit secure information back and forth between parties of a communication channel when data is at rest in a storage device, and / or the like. Also known as a secret key for the fact that the key is normally maintained as a secret and known only to parties with a need to know the secret key (e.g., parties involved in the communication, parties storing sensitive information, parties participating in a transaction, parties transmitting electronic currency, parties exchanging electronic currency, etc.). The symmetric key is generated, managed, distributed, and may involve multiple authorized key custodians. Often, a symmetric key is shared between the sender and the receiver of encrypted messages. The key must be kept secret in order to effectively protect the secret, sensitive, and private information, but must be known by both parties to ensure secure communication.

[0068] As used herein, “hashing” (e.g., a hash function) involves a method of cryptography that is designed to be irreversible. Hash functions are one-way algorithms based on a mathematical function which takes an arbitrary input messageand produces a deterministic output (e.g. a message digest). The one-way nature of the hash function means given the output, makes it difficult to determine the input that generated it. As used herein, hashing a message commonly serves one of two purposes, to protect the confidentiality of secret information (e.g. to validate the correctness of a password) or to confirm a message has been unmodified (e.g. to confirm the integrity of downloaded software). In the first case, when a message digest is created by hashing a message (e.g., a document, a number of data fields, etc.) for storage or transmission, in the event of an attack, all the hacker has stolen is unreadable, scrambled values (e.g., hash values, hash codes, digests, hashes, etc.). In the second case, message integrity can be determined, by hashing a copy of the original message and comparing the result to the original message’s digest value. One does not need to read the message itself to determine that the message has not been modified, just need the output of hashing the message (e.g., message digest).

[0069] As used herein, satisfying a threshold may refer to a value (e.g., a score, a power consumption, etc.) being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.

[0070] Symmetric keys may be necessary to ensure confidential communication between financial institutions and payment processors. As symmetric key encryption involves using the same key for both encryption and decryption of data, to ensure security, each symmetric key should be kept secret and protected from unauthorized access. In addition, ensuring that no single point of failure or vulnerability exists in the key generation process is important. For example, reliance on a single custodian to maintain a symmetric key may be impractical and insecure.

[0071] However, securely exchanging and integrating symmetric keys between different entities while upholding the principle of dual control, where no single entity possesses the symmetric key, may inject significant complexity into existing key exchanges. In the payment industry, where secure and confidential communication of information is necessary, systems for securely exchanging and / or integrating symmetric encryption key components between different parties while maintaining dual control introduce problems and difficulties.

[0072] For example, achieving a security protocol for securely exchanging symmetric keys may require physically providing key components to variouscustodians and / or relying on trusted courier services to transport key components. However, complications exacerbated by circumstances such as a pandemics and natural disasters can make this approach cumbersome and infeasible due to the need for physical presence to assure security.

[0073] Additionally, security for transporting keys, such as secure socket layer (SSL) protocol and other protocols, provide a layer of encryption and security for data transmission, but are not without their vulnerabilities and risks of attacks (e.g., using potential attack vectors, etc.). Further, other application protocols may focus on only one aspect of security such as securing data during transmission, but such application protocols may not address challenges associated with secure generation, sharing, and / or management of cryptographic keys in scenarios where operations, such as secure communications, depend on the availability of cryptographic keys.

[0074] Non-limiting embodiments or aspects of the disclosed subject matter are directed to methods, systems, and computer program products for multi-party computation based remote secure key exchange. In some non-limiting embodiments or aspects, a key management system may receive an identifier associated with a first key custodian and an identifier associated with a second key custodian, authenticate the first key custodian based on the identifier associated with the first key custodian, authenticate the second key custodian based on the identifier associated with the second key custodian, verify a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian, establish key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available, receive a collaborative key generation request associated with the first key custodian and the second key custodian, generate a secure cryptographic key, encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key, transmit the first component encrypted secure cryptographic key to the first key custodian, and transmit the second component encrypted secure cryptographic key to the second key custodian. In some non-limiting embodiments or aspects, the secure cryptographic key may include a symmetric key.

[0075] In some non-limiting embodiments or aspects, when receiving the collaborative key generation request, the key management system may receive a firstkey generation request associated with the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian, receive a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian, and validate a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

[0076] In some non-limiting embodiments or aspects, the key management system may receive an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian, receive an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian, determine the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian, determine the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian, and store the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

[0077] In some non-limiting embodiments or aspects, the key management system may, prior to establishing key management operations to be performed by the first key custodian and the second key custodian, authorize the first key custodian for key management operations based on the identifier associated with the first key custodian. In some non-limiting embodiments or aspects, when authorizing the first key custodian for key management operations, the key management system may match the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations and authorize the second key custodian for key management operations based on the identifier associated with the second key custodian. In some non-limiting embodiments or aspects, when authorizing the second key custodian for key management operations, the key management system may match the identifierassociated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

[0078] In some non-limiting embodiments or aspects, when receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian, the key management system may receive a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

[0079] In some non-limiting embodiments or aspects, the key management system may include a hardware security module (HSM), and, when authenticating the first key custodian, the key management system may authenticate, via the HSM, the first key custodian based on the identifier associated with the first key custodian. In some nonlimiting embodiments or aspects, when authenticating the first key custodian, the key management system may authenticate, via the HSM, the second key custodian based on the identifier associated with the second key custodian.

[0080] In this way, the key management system may enforce dual control, ensuring that a quorum of authorized custodians exists and provide collaboration that is used to generate, manage, and / or exchange cryptographic keys and / or components of cryptographic keys. In this way, the key management system may eliminate a likelihood of a single point of failure and enhance overall security of operations involving cryptographic keys, including generation, management, and / or exchange of cryptographic keys and / or components of cryptographic keys. Vulnerabilities may be reduced and channel attacks may be stopped or reduced by ensuring that a quorum of key custodians participate in key operations, enforcing dual control.

[0081] Furthermore, key management system reduces risk associated with theft, tampering, unauthorized access to the key materials, and / or the like, while also providing for protection against cyber security threats, such as man-in-the-middle attacks (e.g., where an attacker intercepts and alters the communication between parties, potentially gaining access to keys during their exchange, and / or the like) and against attackers who gain access and can tamper with the process to generate weak or compromised keys.

[0082] Referring now to FIG. 1 A, FIG. 1A is a diagram of an example environment 100 in which devices, systems, and / or methods, described herein, may be implemented. As shown in FIG. 1 A, environment 100 includes key managementsystem 102, first key custodian device 104-1 , second key custodian device 104-2, Nthkey custodian device 104-N (referred to individually as key custodian device 104 and collectively as key custodian devices 104, where appropriate) issuer system 106, transaction service provider system 108, communication network 1 10, and data source 1 12. Key management system 102, key custodian devices 104, transaction service provider system 108, issuer system 106, and / or data source 1 12 may interconnect (e.g., establish a connection to communicate) via wired connections, wireless connections, or a combination of wired and wireless connections.

[0083] Key management system 102 may include one or more devices configured to communicate with key custodian devices 104, issuer system 106, and / or transaction service provider system 108 via communication network 1 10. For example, key management system 102 may include a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, key management system 102 may be associated with issuer system 106. For example, key management system 102 may be operated by issuer system 106. In another example, key management system 102 may be a component of issuer system 106. In some non-limiting embodiments or aspects, key management system 102 may be in communication with data source 1 12, which may be local or remote to key management system 102. In some non-limiting embodiments or aspects, key management system 102 may be capable of receiving (e.g., retrieving via a pull) information from, storing information in, transmitting information to, and / or searching information stored in data source 1 12. In some non-limiting embodiments or aspects, key management system 102 may include a hardware security module (HSM). In some non-limiting embodiments or aspects, the HSM may be designed with physical and / or logical security measures to resist tampering, so that HSM provides a platform for handling sensitive cryptographic operations and / or cryptographic keys.

[0084] Key custodian device 104 may include one or more devices configured to communicate with key management system 102, other key custodian devices, issuer system 106, and / or transaction service provider system 108 via communication network 1 10. For example, key custodian device 104 may include a server, a group of servers, and / or other like devices. In another example, key custodian device 104 may include a computing device, such as a desktop computer, a portable computer (e.g., a tablet computer, a laptop computer, and / or the like), a mobile device (e.g., a cellular phone, a smartphone, a personal digital assistant, a wearable device, and / orthe like), and / or other like devices. In some non-limiting embodiments or aspects, key custodian device 104 may be associated with a user (e.g., an individual operating key custodian device 104). In some non-limiting embodiments or aspects, key custodian device 104 may be configured to securely store a private key of a public-private key pair.

[0085] In some non-limiting embodiments or aspects, key custodian devices 104 may be authenticated by key management system 102 through various procedures. For example, an identification of key custodian device 104 (e.g., an identity of a key custodian associated with key custodian device 104) may be verified using cryptographic proofs, digital signatures, and / or other authentication mechanisms. In this way, only authorized key custodians are allowed to contribute to a key generation process, as described herein.

[0086] In some non-limiting embodiments or aspects, each of key custodian devices 104 may be associated with a designated key custodian. A key custodian may refer to an entity (e.g., an individual, a financial institution, a courier, etc.) that is responsible for generating, safeguarding, transmitting, and / or otherwise securing information regarding cryptographic keys. A key custodian may manage and / or use cryptographic keys on key custodian device 104 for securing information based on cryptographic techniques (e.g., encryption, decryption, etc.). In some non-limiting embodiments or aspects, key custodian devices 104 may execute encryption techniques with cryptographic keys to encrypt information (e.g., sensitive data, such as personal identification information (PH)) in a way that ensures the security and confidentiality of the information. Key custodian devices 104 may be configured to securely load cryptographic key and / or cryptographic key components for further use (e.g., during payment processing).

[0087] In some non-limiting embodiments or aspects, each key custodian associated with key custodian devices 104 may initiate, operate, respond to, and / or execute remote key generation actions (e.g., steps of a key generation, authentication, key exchange, etc.). In some examples, key custodians may operate key custodian devices 104 to authenticate a respective key custodian, sign (e.g., digitally sign) messages, authenticate key generation requests, and / or the like.

[0088] In some non-limiting embodiments or aspects, each key custodian associated with key custodian devices 104 may execute a multi-party computation (MPC) protocol to jointly compute a value (e.g., a cryptographic value) that confirmsthe identity (e.g., presence, possession, etc.) of a key custodian associated with key custodian device 104 during authorization. The value may be computed without revealing private information (e.g., information provided as an input, such as an input to compute the value) of any key custodian associated with key custodian devices 104.

[0089] Issuer system 106 may include one or more devices configured to communicate with key management system 102, key custodian devices 104, transaction service provider system 108 via communication network 1 10. For example, issuer system 106 may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, issuer system 106 may be associated with an issuer (e.g., a financial institution that issues accounts to accountholders). For example, issuer system 106 may be operated by an issuer. In some non-limiting embodiments or aspects, key custodian device 104 may be a component of issuer system 106 or vice versa.

[0090] Transaction service provider system 108 may include one or more devices configured to communicate with key management system 102, key custodian devices 104, and / or issuer system 106 via communication network 1 10. In some non-limiting embodiments or aspects, transaction service provider system 108 may include a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, transaction service provider system 108 is associated with a transaction service provider and / or a payment processor. For example, transaction service provider system 108 may be operated by a transaction service provider and / or a payment processor. In some non-limiting embodiments or aspects, key management system 102 may be a component of transaction service provider system 108 or vice versa.

[0091] Communication network 1 10 may include one or more wired and / or wireless networks. For example, communication network 1 10 may include a cellular network (e.g., a long-term evolution (LTE) network, a third-generation (3G) network, a fourthgeneration (4G) network, a fifth-generation (5G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the public switched telephone network (PSTN) and / or the like), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-basednetwork, a cloud computing network, and / or the like, and / or a combination of some or all of these or other types of networks.

[0092] The number and arrangement of systems, devices, and / or networks shown in FIG. 1 A are provided as an example. There may be additional systems, devices, and / or networks; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or differently arranged systems, devices, and / or networks than those shown in FIG. 1 A. Furthermore, two or more systems or devices shown in FIG. 1 A may be implemented within a single system or device, or a single system or device shown in FIG. 1 A may be implemented as multiple, distributed systems or devices. Additionally or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of environment 100.

[0093] Referring now to FIG. 1 B, FIG. 1 B is a diagram of a non-limiting embodiment or aspect of key management system 102. As shown in FIG. 1 B, key management system 102 may include remote key generation engine 102A.

[0094] In some non-limiting embodiments or aspects, remote key generation engine 102A may generate a cryptographic key and / or key component for key custodian devices 104. In some non-limiting embodiments or aspects, remote key generation engine 102A is configured to operate according to MPC protocols for a virtual remote key exchange involving key custodian devices 104. For example, remote key generation engine 102A executes the MPC protocols that are necessary for communication among key custodian devices 104. In such an example, remote key generation engine 102A may receive an input (e.g., inputs associated with cryptographic key requests) from first key custodian device 104-1 , second key custodian device 104-2, and / or Nth key custodian device 104-N. After receiving the input, remote key generation engine 102A may jointly compute a function based on the input while preserving the privacy of the input.

[0095] In some non-limiting embodiments or aspects, MPC protocol may refer to a key management technique that allows multiple parties to collaboratively compute a function without revealing individual inputs of the parties. MPC protocol may be used to generate cryptographic keys in a distributed and secure manner. MPC may be used to generate a key using threshold cryptography, such that a cryptographic key can be divided into shares and distributed among a group of key custodians (e.g., a group ofkey custodians associated with key custodian devices 104). The shares of the cryptographic key can be distributed in such a way that only a certain number of key custodians (e.g., a quorum, a selection, etc.) can collaborate to perform cryptographic operations.

[0096] In some non-limiting embodiments or aspects, remote key generation engine 102A may generate and / or provide a set of cryptographic key parameters. For example, remote key generation engine 102A may generate and / or provide cryptographic parameters for first key custodian device 104-1 , second key custodian device 104-2, and / or Nth key custodian device 104-N. In some non-limiting embodiments or aspects, the cryptographic key parameters may include cryptographic keys, such as public keys (e.g., public keys of an asymmetric cryptographic system, such as El Gamal, Diffie Hellman, etc.), commitment schemes, cryptographic primitives (e.g., key lengths, algorithms, modes of operation, initialization vectors, etc.), and / or the like. In some non-limiting embodiments or aspects, remote key generation engine 102A may receive one or more key generation requests (e.g., key generation request that includes a private key of key custodian device 104) from key custodian devices 104. In some non-limiting embodiments or aspects, remote key generation engine 102A may generate and / or provide a set of cryptographic key parameters based on receiving the one or more key generation requests.

[0097] In some examples, remote key generation engine 102A may verify a signature of one or more key generation requests. In such an example, based on the key generation requests, remote key generation engine 102A may generate a commitment to the key generation request and each requesting party (e.g., one or more key custodian devices 104). In some non-limiting embodiments or aspects, remote key generation engine 102A initiates an MPC protocol involving each designated key custodian device 104. For example, remote key generation engine 102A may request (e.g., invites, prompts, etc.) each designated key custodian device 104, to securely authenticate. In such an example, key custodian device 104 may authenticate using a private key to share authentication information and / or status in a secure manner.

[0098] In some non-limiting embodiments or aspects, remote key generation engine 102A may generate a shared secure cryptographic key by dividing a complete cryptographic key into key shares that is to be distributed among key custodian devices 104. The resulting key shares may be structured in a way that a minimumnumber of key custodian devices 104 (e.g., a quorum of key custodian devices 104) are required to collaboratively reconstruct the complete cryptographic key. In some non-limiting embodiments or aspects, remote key generation engine 102A may generate an MPC secure cryptographic key that is divided into share cryptographic keys for a group of key custodian devices (e.g., a quorum of key custodian devices 104). Remote key generation engine 102A may generate and / or provide a plurality of share cryptographic keys in such a way that only a specified number of key custodians (e.g., a quorum) performs cryptographic operations (e.g., collaborate to perform cryptographic operations) on the MPC secure cryptographic key.

[0099] In some non-limiting embodiments or aspects, remote key generation engine 102A may generate and provide cryptographic keys for secure and encrypted communication channels between (e.g., each direction, way, etc.) issuer system 106 and transaction service provider system 108 (e.g., entities in a payment network). This ensures that any data transmitted between issuer system 106 and transaction service provider system 108 is protected from eavesdropping or tampering by unauthorized parties. In some non-limiting embodiments or aspects, remote key generation engine 102A may encrypt and / or decrypt information (e.g., sensitive data) exchanged between issuer system 106 and transaction service provider system 108. For example, when transaction service provider system 108 transmits electronic transaction information (e.g., authorization requests) to issuer system 106, remote key generation engine 102A may encrypt the data using a secure cryptographic key before transmitting the electronic transaction information. Issuer system 106 may use the same secure cryptographic key to decrypt and access the information.

[0100] As further shown in FIG. 1 B, remote key generation engine 102A may include a plurality of subsystems that carry out the operations described herein. For example, remote key generation engine 102A may include remote secure exchange protocol subsystems 102A-1 , which may include crypto engine 102A-1 A, key manager 102A-1 B, authentication control 102A-1 C, access control 102A-1 D, secure communication interface 102A-1 E, and integration interfaces 102A-1 F.

[0101] In some non-limiting embodiments or aspects, cryptographic engine 102A- 1 A may perform various cryptographic operations, including key generation, encryption, decryption, signing, verification, and / or the like. For example, cryptographic engine 102A-1 A may securely generate, manipulate, and protect cryptographic keys and / or cryptographic key components. In some examples,cryptographic engine 102A-1 A may generate cryptographic parameters for a secure key generation process (e.g., a secure key generation process involved in an MPC protocol).

[0102] In some non-limiting embodiments or aspects, key manager 102A-1 B may perform management operations of cryptographic keys, including key generation, storage, distribution, rotation, and / or deletion. In some examples, key manager 102A- 1 B may securely store cryptographic keys (e.g., private keys of public-private key pairs) as they are associated with (e.g., assigned to) key custodian devices 104. In some non-limiting embodiments or aspects, key manager 102A-1 B may generate cryptographic key components required for an MPC protocol and / or distribute the cryptographic key components to authorized parties (e.g., first key custodian device 104-1 and second key custodian device 104-2). In some non-limiting embodiments or aspects, key manager 102A-1 B may securely distribute cryptographic keys and / or cryptographic key components based on encryption protocols, available secure channels, authentication or authorization status, and / or the like. In some non-limiting embodiments or aspects, key manager 102A-1 B may include a random number generator subsystem that generates random numbers for cryptographic operations, such as cryptographic key generation and / or initialization vectors.

[0103] In some non-limiting embodiments or aspects, authentication control 102A- 1 C may control the execution of processes for authentication of users and devices accessing remote key generation engine 102A. In some non-limiting embodiments or aspects, authentication control 102A-1 C may authorize individuals, such as custodians and administrators, to interact with remote key generation engine 102A. In some non-limiting embodiments or aspects, authentication control 102A-1 C may authenticate key custodian devices 104 before key custodian devices 104 may be able to initiate key generation requests. In some non-limiting embodiments or aspects, key custodian devices 104 are not authenticated, a key generation process may not execute (e.g., may fail). In some non-limiting embodiments or aspects, authentication control 102A-1 C may control the execution of processes that involve biometric authentication (e.g., biometric authentication involving the use of fingerprints, facial recognition, etc.), unique identifiers (e.g., personal identification numbers (PINs)), and / or the like.

[0104] In some non-limiting embodiments or aspects, access control 102A-1 D may control procedures for access of remote key generation engine 102A to preventunauthorized access (e.g., in the form of a data breach). In some non-limiting embodiments or aspects, access control 102A-1 D may include a policy management system. For example, access control 102A-1 D may include a policy management system that executes rules and / or policies related to quorum requirements, authentication processes, and / or responses to key generation requests. In some nonlimiting embodiments or aspects, access control 102A-1 D may interface with an HSM and / or other subsystems to ensure compliance with procedures for access of remote key generation engine 102A.

[0105] In some non-limiting embodiments or aspects, secure communication interface 102A-1 E may communicate with external entities to key management system 102 (e.g., remote key generation engine 102A of key management system 102). For example, secure communication interface 102A-1 E may communicate with key custodian devices 104 and / or other devices and systems.

[0106] In some non-limiting embodiments or aspects, integration interfaces 102A- 1 F may provide integration interfaces, such as application programming interfaces (APIs), communication protocols, and / or the like, which allow external entities to interact with cryptographic capabilities of remote key generation engine 102A (e.g., an HSM). In some examples, integration interfaces 102A-1 F may allow key custodian devices 104 to access user interfaces and / or applications for initiating key generation requests, providing authorizations, and managing processes involving cryptographic operations.

[0107] Referring now to FIG. 2, FIG. 2 is a diagram of example components of a device 200. Device 200 may correspond to one or more devices of key management system 102 (e.g., one or more devices of key management system 102), key custodian device 104, issuer system 106 (e.g., one or more devices of issuer system 106), and / or transaction service provider system 108 (e.g., one or more devices of transaction service provider system 108). In some non-limiting embodiments or aspects, key management system 102, key custodian device 104, issuer system 106, and / or transaction service provider system 108 may include at least one device 200 and / or at least one component of device 200.

[0108] As shown in FIG. 2, device 200 may include bus 202, processor 204, memory 206, storage component 208, input component 210, output component 212, and communication interface 214. Bus 202 may include a component that permits communication among the components of device 200. In some non-limitingembodiments or aspects, processor 204 may be implemented in hardware and / or any combination of hardware and software (e.g., firmware, etc.). For example, processor 204 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), and / or the like), a microprocessor, a digital signal processor (DSP), and / or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or the like), and / or the like, which can be programmed to perform a function. Memory 206 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, and / or the like) that stores information and / or instructions for use by processor 204.

[0109] Storage component 208 may store information and / or software related to the operation and use of device 200. For example, storage component 208 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, and / or the like), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of computer-readable medium, along with a corresponding drive.

[0110] Input component 210 may include a component that permits device 200 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, a camera, and / or the like). Additionally or alternatively, input component 210 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, and / or the like). Output component 212 may include a component that provides output information from device 200 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), and / or the like).

[0111] Communication interface 214 may include a transceiver-like component (e.g., a transceiver, a receiver and transmitter that are separate, and / or the like) that enables device 200 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 214 may permit device 200 to receive information from another device and / or provide information to another device. For example, communication interface 214 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, auniversal serial bus (USB) interface, a Wi-Fi® interface, a Bluetooth® interface, a Zigbee® interface, a cellular network interface, and / or the like.

[0112] Device 200 may perform one or more processes described herein. Device 200 may perform these processes based on processor 204 executing software instructions stored by a computer-readable medium, such as memory 206 and / or storage component 208. A computer-readable medium (e.g., a non-transitory computer-readable medium) is defined herein as a non-transitory memory device. A non-transitory memory device includes memory space located inside of a single physical storage device or memory space spread across multiple physical storage devices.

[0113] Software instructions may be read into memory 206 and / or storage component 208 from another computer-readable medium or from another device via communication interface 214. When executed, software instructions stored in memory 206 and / or storage component 208 may cause processor 204 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments or aspects described herein are not limited to any specific combination of hardware circuitry and software.

[0114] The number and arrangement of components shown in FIG. 2 are provided as an example. In some non-limiting embodiments or aspects, device 200 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 2. Additionally or alternatively, a set of components (e.g., one or more components) of device 200 may perform one or more functions described as being performed by another set of components of device 200.

[0115] Referring now to FIG. 3, FIG. 3 is a flowchart of a non-limiting embodiment or aspect of a process 300 for multi-party computation based remote secure key exchange. In some non-limiting embodiments or aspects, one or more of the steps of process 300 may be performed (e.g., completely, partially, etc.) by key management system 102 (e.g., one or more devices of key management system 102). In some non-limiting embodiments or aspects, one or more of the steps of process 300 may be performed (e.g., completely, partially, etc.) by another device or a group of devices separate from or including key management system 102 (e.g., one or more devices of key management system 102), first key custodian device 104-1 , second key custodiandevice 104-2, Nthkey custodian device 104-N, issuer system 106, and / or transaction service provider system 108 (e.g., one or more devices of transaction service provider system 108).

[0116] As shown in FIG. 3, at step 302, process 300 includes authenticating a first key custodian and a second key custodian. For example, key management system 102 may authenticate the first key custodian and the second key custodian. In some non-limiting embodiments or aspects, key management system 102 may receive identification data, such as an identifier, associated with first key custodian device 104- 1 (e.g., a first key custodian associated with first key custodian device 104-1 ) and identification data, such as an identifier, associated with second key custodian device 104-2 (e.g., a second key custodian associated with second key custodian device 104- 2). In some non-limiting embodiments or aspects, key management system 102 may authenticate first key custodian device 104-1 based on the identification data associated with first key custodian device 104-1. Additionally or alternatively, key management system 102 may authenticate second key custodian device 104-2 based on the identification data associated with second key custodian device 104-2

[0117] In some non-limiting embodiments or aspects, key management system 102 may receive identification data associated with a plurality of key custodian devices 104 for authentication and / or authorization procedures. By knowing the identities of the custodians involved, key management system 102 may authorize only those key custodian devices 104 that are participating in a key generation process, which may be part of an MPC protocol. In this way, key management system 102 may provide a security measure to prevent unauthorized entities from interfering with a key generation process and to prevent a compromise of sensitive information, while also distributing the trust to a plurality of key custodian devices 104 to prevent any single point of failure in the key generation process.

[0118] In some non-limiting embodiments or aspects, key management system 102 may authenticate key custodian device 104 (e.g., first key custodian device 104- 1 , second key custodian device 104-2, etc.) by determining whether identification data associated with key custodian device 104 corresponds to stored authentication data for key custodian device 104 (e.g., authentication data stored in data source 1 12). For example, if key management system 102 determines that the identification data associated with key custodian device 104 corresponds to stored authentication data (e.g., stored identification data, stored credential data, stored address data, etc.) forkey custodian device 104, key management system 102 may determine that key custodian device 104 is authenticated. In such an example, if key management system 102 determines that the identification data associated with key custodian device 104 does not correspond to stored authentication data for key custodian device 104, key management system 102 may determine that key custodian device 104 is not authenticated. In some non-limiting embodiments or aspects, additional key custodian devices 104 may be authenticated in a same or similar fashion.

[0119] In some non-limiting embodiments or aspects, key management system 102 may receive a key request (e.g., a key generation request) from one or more key custodian devices 104, issuer system 106, and / or transaction service provider system 108. In some non-limiting embodiments or aspects, the key request may include identification data associated with first key custodian device 104-1 and / or identification data associated with second key custodian device 104-2. In some non-limiting embodiments or aspects, one or more key custodian devices 104 may transmit a key request to key management system 102, issuer system 106, and / or transaction service provider system 108.

[0120] In some non-limiting embodiments or aspects, key management system 102 may monitor one or more inputs provided by key custodian devices 104 and may determine that key custodian devices 104 are following a protocol. For example, remote key generation engine 102A may utilize zero-knowledge proofs to validate the one or more inputs of key custodian device 104 without revealing the one or more inputs to other key custodian devices 104.

[0121] As shown in FIG. 3, at step 304, process 300 includes verify that a quorum is available. For example, key management system 102 may verify that a quorum (e.g., a quorum of key custodians, a quorum of key custodians associated with key custodian devices 104, a quorum of key custodians associated with key custodian devices 104 and key management system 102, etc.) is available for a protocol, such as an MPC protocol. In some non-limiting embodiments or aspects, key management system 102 may verify that a quorum is available based on identification data associated with key custodian devices 104. For example, key management system 102 may determine that identification data has been received from a number of key custodian devices 104 and key management system 102 may compare the number of key custodian devices 104 to a threshold quorum requirement. If the number of key custodian devices 104 corresponds to the threshold quorum requirement, keymanagement system 102 may determine that a quorum of key custodian devices 104 is available. If the number of key custodian devices 104 does not correspond to the threshold quorum requirement, key management system 102 may determine that a quorum of key custodian devices 104 is not available.

[0122] In some non-limiting embodiments or aspects, key management system 102 may establish a minimum number of key custodian devices 104 (e.g., a plurality of key custodian devices 104, two key custodian devices 104, three key custodian devices 104, etc.) that must be present and participate in the MPC protocol. In some non-limiting embodiments or aspects, key management system 102 may verify that a quorum is available based on security requirements of a protocol. In one example, if there are N total key custodian devices in an MPC protocol and a quorum is defined as K, then at least K key custodian devices must be available (e.g., present, a threshold level satisfied, etc.).

[0123] In some non-limiting embodiments or aspects, key management system 102 may prevent a key generation process when a quorum is not available. For example, key management system 102 may prevent the key generation process unless the required number of quorum participants have been authenticated and participating in collaboration of a key generation request. In some non-limiting embodiments or aspects, if key management system 102 determines that a quorum of key custodian devices 104 is available, key management system 102 may proceed with a key generation process. If key management system 102 determines that a quorum of key custodian devices 104 is not available, key management system 102 may prevent a key generation process from proceeding.

[0124] In some non-limiting embodiments or aspects, key management system 102 may receive an authorization request for key management operations from a plurality of key custodian devices 104. For example, key management system 102 may receive an authorization request for key management operations from first key custodian device 104-1 and an authorization request for key management operations from second key custodian device 104-2. In some non-limiting embodiments or aspects, an authorization request may include a request identifier of key custodian device 104 that provided the authorization request. In the example above, a first authorization request may include a first request identifier of first key custodian device 104-1 and a second authorization request may include a second request identifier of second key custodian device 104-2.

[0125] In some non-limiting embodiments or aspects, key management system 102 may determine that key custodian device 104 is authorized for key management operations based on the authorization request (e.g., a request identifier of key custodian device 104 included in the authorization request). In the example above, key management system 102 may determine that first key custodian device 104-1 is authorized for key management operations based on the first request identifier of first key custodian device 104-1 and that second key custodian device 104-2 is authorized for key management operations based on the second request identifier of second key custodian device 104-2.

[0126] In some non-limiting embodiments or aspects, key management system 102 may store the request identifier of key custodian device 104 in a data structure (e.g., a data structure in data source 112) associated with authorization of key management operations. In the example above, key management system 102 may store the first request identifier of first key custodian device 104-1 and the second request identifier of second key custodian device 104-2 in the data structure associated with authorization of key management operations.

[0127] In some non-limiting embodiments or aspects, key management system 102 may establish key management operations (e.g., key management operations of an HSM of key management system 102) to be performed by first key custodian device 104-1 (e.g., a first key custodian associated with first key custodian device 104-1 ) and the second key custodian based on verifying that the quorum (e.g., the quorum of key custodian devices 104) is available.

[0128] In some non-limiting embodiments or aspects, key management system 102 may, prior to establishing key management operations to be performed by one or more key custodian devices 104, authorize the one or more key custodian devices 104 for key management operations based on identification data associated with the one or more key custodian devices 104. For example, key management system 102 may, prior to establishing key management operations to be performed by first key custodian device 104-1 and / or second key custodian device 104-2, authorize first key custodian device 104-1 for key management operations based on identification data associated with first key custodian device 104-1 and / or authorize second key custodian device 104-2 for key management operations based on identification data associated with first key custodian device 104-1 .

[0129] In some non-limiting embodiments or aspects, key management system 102 may authorize the one or more key custodian devices 104 for key management operations by matching the identification data associated with the one or more key custodian devices 104 to a request identifier associated with the one or more key custodian devices 104 stored in a data structure associated with authorization of key management operations. For example, key management system 102 may match the identification data associated with first key custodian device 104-1 to a first request identifier associated with first key custodian device 104-1 stored in the data structure and may match the identification data associated with second key custodian device 104-2 to a second request identifier associated with second key custodian device 104- 2 stored in the data structure.

[0130] As shown in FIG. 3, at step 306, process 300 includes receiving a collaborative key generation request. For example, key management system 102 may receive the collaborative key generation request from one or more key custodian devices 104 (e.g., first key custodian device 104-1 and / or second key custodian device 104-2).

[0131] In some non-limiting embodiments or aspects, key management system 102 may receive a first key generation request from first key custodian device 104-1 . For example, key management system 102 may receive a first key generation request for a first key custodian associated with first key custodian device 104-1 . In some nonlimiting embodiments or aspects, the first key generation request may be signed with a private key of first key custodian device 104-1 (e.g., a private key of first key custodian associated with first key custodian device 104-1 ) to provide a digital signature of first key custodian device 104-1 .

[0132] In some non-limiting embodiments or aspects, key management system 102 may receive a second key generation request from second key custodian device 104-2. For example, key management system 102 may receive a first key generation request for a second key custodian associated with second key custodian device 104- 2. In some non-limiting embodiments or aspects, the second key generation request may signed with a private key of second key custodian device 104-2 (e.g., a private key of second key custodian associated with second key custodian device 104-2) to provide a digital signature of second key custodian device 104-2.

[0133] In some non-limiting embodiments or aspects, key management system 102 may validate a collaborative request of first key custodian device 104-1 (e.g., afirst key custodian associated with first key custodian device 104-1 ) and second key custodian device 104-2 (e.g., a second key custodian associated with second key custodian device 104-2) for generation of a secure cryptographic key based on the digital signature of first key custodian device 104-1 and the digital signature of second key custodian device 104-2.

[0134] As shown in FIG. 3, at step 308, process 300 includes generating a secure cryptographic key. For example, key management system 102 may generate the secure cryptographic key. In some non-limiting embodiments or aspects, the secure cryptographic key includes a symmetric key. In some non-limiting embodiments or aspects, the secure cryptographic key includes an asymmetric key.

[0135] In some non-limiting embodiments or aspects, key management system 102 may generate the secure cryptographic key based on verifying that a quorum (e.g., a quorum of key custodian devices 104) is available. Additionally or alternatively, key management system 102 may generate the secure cryptographic key based on receiving a collaborative key generation request (e.g., a collaborative key generation request that is part of an MPC protocol).

[0136] In some non-limiting embodiments or aspects, key management system 102 may generate the secure cryptographic key based on a process of creating a cryptographic key that can be used for various security-related operations, such as encryption, decryption, digital signatures, and / or the like. In this way, the key is generated in a way such that the cryptographic key is extremely difficult to predict or guess by unauthorized parties. In some non-limiting embodiments or aspects, key management system 102 may generate the secure cryptographic key based on a hashing procedure (e.g., a hash function).

[0137] In some non-limiting embodiments or aspects, key management system 102 may generate the secure cryptographic key so that an individual key custodian device 104 does not have access to the complete secure cryptographic key. In this way, key management system 102 ensures that no individual key custodian device 104 has full knowledge of the secure cryptographic key, which may improve the overall security of the key generation process.

[0138] As shown in FIG. 3, at step 310, process 300 includes encrypting portions of the secure cryptographic key to provide component encrypted secure cryptographic keys. For example, key management system 102 may encrypt two or more portions (e.g., two or more equal portions, two or more unequal portions, etc.) of the securecryptographic key to provide two or more component encrypted secure cryptographic keys. In some non-limiting embodiments or aspects, key management system 102 may encrypt two or more portions of the secure cryptographic key based on generating the secure cryptographic key. In one example, key management system 102 may encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key.

[0139] In some non-limiting embodiments or aspects, key management system 102 may encrypt a portion of the secure cryptographic key with a shared cryptographic key. For example, key management system 102 may encrypt a portion of the secure cryptographic key with a shared cryptographic key that is shared among key custodian devices 104. In some non-limiting embodiments or aspects, key management system 102 may encrypt the secure cryptographic key (e.g., the entire secure cryptographic key) with a shared cryptographic key (e.g., a shared cryptographic key that is shared among key custodian devices 104) to provide an encrypted secure cryptographic key.

[0140] In some non-limiting embodiments or aspects, key management system 102 may encrypt a portion of the secure cryptographic key using a public key of a public-private key pair associated with key custodian device 104 and may encrypt another portion of the secure cryptographic key using a public key of a public-private key pair associated with another key custodian device 104. In the example above, key management system 102 may encrypt a first portion of the secure cryptographic key using a first public key of a first public-private key pair associated with first key custodian device 104-1 and a second portion of the secure cryptographic key using a second public key of a second public-private key pair associated with second key custodian device 104-2.

[0141] As shown in FIG. 3, at step 312, process 300 includes transmitting the component encrypted secure cryptographic keys. For example, key management system 102 may transmit the component encrypted secure cryptographic keys. In some non-limiting embodiments or aspects, key management system 102 may transmit the component encrypted secure cryptographic keys based on encrypting the portions of the secure cryptographic key. In some non-limiting embodiments or aspects, key management system 102 may transmit a plurality component encrypted secure cryptographic keys to a plurality of key custodian devices 104 (e.g., as part of an MPC protocol). For example, key management system 102 may transmit the firstcomponent encrypted secure cryptographic key to first key custodian device 104-1 and / or transmit the second component encrypted secure cryptographic key to second key custodian device 104-2. In some non-limiting embodiments or aspects, key management system 102 may transmit the component encrypted secure cryptographic keys as cryptograms. In some non-limiting embodiments or aspects, key management system 102 may transmit an encrypted secure cryptographic key as a cryptogram.

[0142] In some non-limiting embodiments or aspects, key management system 102 may receive an indication that confirms that the plurality of key custodian devices 104 received the plurality component encrypted secure cryptographic keys. For example, first key custodian device 104-1 and second key custodian device 104-2 may receive the first component encrypted secure cryptographic key and the second component encrypted secure cryptographic key, respectively, and first key custodian device 104-1 and second key custodian device 104-2 may each transmit a confirmation message to key management system 102.

[0143] In some non-limiting embodiments or aspects, key custodian devices 104 may use a component encrypted secure cryptographic key or encrypted secure cryptographic key during an electronic payment processing procedure. For example, key custodian devices 104 may use the component encrypted secure cryptographic key or the encrypted secure cryptographic key to encrypt authorization messages, such as authorization response messages during an electronic payment processing procedure.

[0144] Referring now to FIGS. 4A-4D, FIGS. 4A-4D are diagrams of a non-limiting embodiment or aspect of implementation 400 relating to a process (e.g., process 300) for multi-party computation based remote secure key exchange. In some non-limiting embodiments or aspects, one or more of the steps of the process may be performed (e.g., completely, partially, etc.) by key management system 102 (e.g., one or more devices of key management system 102). In some non-limiting embodiments or aspects, one or more of the steps of the process may be performed (e.g., completely, partially, etc.) by another device or a group of devices separate from or including key management system 102 (e.g., one or more devices of key management system 102), first key custodian device 104-1 , second key custodian device 104-2, Nthkey custodian device 104-N, issuer system 106, and / or transaction service provider system 108 (e.g., one or more devices of transaction service provider system 108).

[0145] As shown by reference number 405 in FIG. 4A, key management system 102 may receive an identifier associated with a first key custodian and an identifier associated with a second key custodian. As further shown by reference number 410 in FIG. 4A, key management system 102 may authenticate the first key custodian and the second key custodian.

[0146] As shown by reference number 415 in FIG. 4B, key management system 102 may verify that a quorum is available. As further shown by reference number 420 in FIG. 4B, key management system 102 may establish key management operations to be performed. As shown by reference number 425 in FIG. 4C, key management system 102 may receive a collaborative key generation request. As further shown by reference number 430 in FIG. 4C, key management system 102 may generate a secure cryptographic key.

[0147] As shown by reference number 435 in FIG. 4D, key management system 102 may encrypt a first portion of the secure cryptographic key and a second portion of the secure cryptographic key. As further shown by reference number 440 in FIG. 4D, key management system 102 may transmit first component encrypted secure cryptographic key to first key custodian device 104-1 . As further shown by reference number 445 in FIG. 4D, key management system 102 may transmit first component encrypted secure cryptographic key to second key custodian device 104-2.

[0148] Although the disclosed subject matter has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred embodiments or aspects, it is to be understood that such detail is solely for that purpose and that the disclosed subject matter is not limited to the disclosed embodiments or aspects, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the presently disclosed subject matter contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method for multi-party computation based remote secure key exchange, comprising: receiving, by at least one processor, an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticating, by at least one processor, the first key custodian based on the identifier associated with the first key custodian; authenticating, by at least one processor, the second key custodian based on the identifier associated with the second key custodian; verifying, by at least one processor, a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establishing, by at least one processor, key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receiving, by at least one processor, a collaborative key generation request associated with the first key custodian and the second key custodian; generating, by at least one processor, a secure cryptographic key; encrypting, by at least one processor, a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmitting, by at least one processor, the first component encrypted secure cryptographic key to the first key custodian; and transmitting, by at least one processor, the second component encrypted secure cryptographic key to the second key custodian.

2. The computer-implemented method of claim 1 , wherein receiving the collaborative key generation request associated with the first key custodian and the second key custodian comprises: receiving a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request issigned with a private key of the first key custodian to provide a digital signature of the first key custodian; receiving a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validating a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

3. The computer-implemented method of claim 1 , further comprising: receiving an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receiving an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determining the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determining the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and storing the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

4. The computer-implemented method of claim 3, further comprising: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorizing the first key custodian for key management operations based on the identifier associated with the first key custodian,wherein authorizing the first key custodian for key management operations comprises: matching the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorizing the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein authorizing the second key custodian for key management operations comprises: matching the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

5. The computer-implemented method of claim 1 , wherein receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian comprises: receiving a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

6. The computer-implemented method of claim 1 , wherein authenticating the first key custodian comprises: authenticating, by at least one processor of a hardware security module (HSM), the first key custodian based on the identifier associated with the first key custodian; wherein authenticating the second key custodian comprises: authenticating, by at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

7. The computer-implemented method of claim 1 , wherein the secure cryptographic key is a symmetric key.

8. A system for multi-party computation based remote secure key exchange, comprising: at least one processor programmed or configured to: receive an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticate the first key custodian based on the identifier associated with the first key custodian; authenticate the second key custodian based on the identifier associated with the second key custodian; verify a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establish key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receive a collaborative key generation request associated with the first key custodian and the second key custodian; generate a secure cryptographic key; encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmit the first component encrypted secure cryptographic key to the first key custodian; and transmit the second component encrypted secure cryptographic key to the second key custodian.

9. The system of claim 8, wherein, when receiving the collaborative key generation request, the at least one processor is further programmed or configured to: receive a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request is signed with a private key of the first key custodian to provide a digital signature of the first key custodian;receive a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validate a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

10. The system of claim 8, wherein the at least one processor is further programmed or configured to: receive an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determine the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and store the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.1 1. The system of claim 10, wherein the at least one processor is further programmed or configured to: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorize the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein, when authorizing the first key custodian for key management operations, the at least one processor is programmed or configured to:match the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorize the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein, when authorizing the second key custodian for key management operations, the at least one processor is programmed or configured to: match the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

12. The system of claim 8, wherein, when receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian, the at least one processor is programmed or configured to: receive a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

13. The system of claim 8, wherein the at least one processor comprises at least one processor of a hardware security module (HSM), and wherein, when authenticating the first key custodian, the at least one processor is programmed or configured to: authenticate, via the at least one processor of the HSM, the first key custodian based on the identifier associated with the first key custodian; wherein, when authenticating the first key custodian, the at least one processor is programmed or configured to: authenticate, via the at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

14. The system of claim 8, wherein the secure cryptographic key is a symmetric key.

15. A computer program product for multi-party computation based remote secure key exchange, the computer program product including at least one non-transitory computer-readable medium including one or more instructions that, when executed by at least one processor, cause the at least one processor to: receive an identifier associated with a first key custodian and an identifier associated with a second key custodian; authenticate the first key custodian based on the identifier associated with the first key custodian; authenticate the second key custodian based on the identifier associated with the second key custodian; verify a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; establish key management operations to be performed by the first key custodian and the second key custodian based on verifying that the quorum of key custodians is available; receive a collaborative key generation request associated with the first key custodian and the second key custodian; generate a secure cryptographic key; encrypt a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key and a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; transmit the first component encrypted secure cryptographic key to the first key custodian; and transmit the second component encrypted secure cryptographic key to the second key custodian.

16. The computer program product of claim 15, wherein, the one or more instructions that cause the at least one processor to receive the collaborative key generation request, cause the at least one processor to: receive a first key generation request associated with the first key custodian from the first key custodian, wherein the first key generation request issigned with a private key of the first key custodian to provide a digital signature of the first key custodian; receive a second key generation request associated with the second key custodian from the second key custodian, wherein the second key generation request is signed with a private key of the second key custodian to provide a digital signature of the second key custodian; and validate a collaborative request of the first key custodian and the second key custodian for generation of the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.

17. The computer program product of claim 15, wherein the one or more instructions further cause the at least one processor to: receive an authorization request for key management operations from the first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for key management operations from the second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine the first key custodian is authorized for key management operations based on the first request identifier of the first key custodian; determine the second key custodian is authorized for key management operations based on the second request identifier of the second key custodian; and store the first request identifier of the first key custodian and the second request identifier of the second key custodian in a data structure associated with authorization of key management operations.

18. The computer program product of claim 17, wherein the one or more instructions further cause the at least one processor to: prior to establishing key management operations to be performed by the first key custodian and the second key custodian: authorize the first key custodian for key management operations based on the identifier associated with the first key custodian, wherein, the one or more instructions that cause the at least one processor to authorize the firstkey custodian for key management operations, cause the at least one processor to: match the identifier associated with the first key custodian to the first request identifier associated with the first key custodian stored in the data structure associated with authorization of key management operations; and authorize the second key custodian for key management operations based on the identifier associated with the second key custodian, wherein, the one or more instructions that cause the at least one processor to authorize the second key custodian for key management operations, cause the at least one processor to: match the identifier associated with the second key custodian to the second request identifier associated with the second key custodian stored in the data structure associated with authorization of key management operations.

19. The computer program product of claim 15, wherein, the one or more instructions that cause the at least one processor to receive the identifier associated with the first key custodian and the identifier associated with the second key custodian, cause the at least processor to: receive a key request from issuer system, wherein the key request comprises the identifier associated with the first key custodian and the identifier associated with the second key custodian.

20. The computer program product of claim 15, wherein the at least one processor comprises at least one processor of a hardware security module (HSM), and wherein, the one or more instructions that cause the at least one processor to authenticate the first key custodian, cause the at least one processor to: authenticate, via the at least one processor of the HSM, the first key custodian based on the identifier associated with the first key custodian; wherein, the one or more instructions that cause the at least one processor to authenticate the first key custodian, cause the at least one processor to:authenticate, via the at least one processor of the HSM, the second key custodian based on the identifier associated with the second key custodian.

Citation Information

Patent Citations

  • Cryptographic-key generation and management

    US20060120532A1

  • Privacy controls for network data communications

    US20210192075A1

  • Techniques for virtual cryptographic key ceremonies

    US20220123929A1