Methods, systems, and computer program products for remote secure key exchange based on multi-party computation
By using a remote secure key exchange method based on multi-party computation, the security and complexity issues of key distribution and management in symmetric key cryptography are solved, enabling secure key distribution and management without face-to-face interaction, thus improving both security and efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- VISA INTERNATIONAL SERVICE ASSOCIATION
- Filing Date
- 2023-10-27
- Publication Date
- 2026-06-16
AI Technical Summary
In symmetric-key cryptography, the distribution and management of secret keys present security and management complexity issues, especially when face-to-face meetings or trusted messengers are required, making keys vulnerable to theft and difficult to manage.
A remote secure key exchange method based on multi-party computation is adopted. By authenticating the identifier of the key custodian, verifying the availability of a legal quantity, generating and distributing components of the secure cryptographic key, encrypting them and sending them to each party respectively, and using digital signature and authorization mechanisms to ensure security.
It enables the secure distribution and management of symmetric keys without the need for face-to-face meetings, simplifying key management and improving security and efficiency.
Smart Images

Figure CN122228643A_ABST
Abstract
Description
Technical Field
[0001] The disclosed subject matter generally relates to methods, systems, and products for secure multi-party computation applications, and in some specific embodiments or aspects, to methods, systems, and computer program products for remote secure key exchange based on multi-party computation to distribute information between different parties and / or locations. Background Technology
[0002] Computer security (such as network security, digital security, and information technology security (IT security)) refers to protecting computer systems and networks from attacks by malicious actors that could lead to unauthorized disclosure of information, theft or damage of hardware, software, or data, and disruption or misuse of the services provided by such hardware, software, or data. In many cases, cryptography can form a fundamental aspect of the computer security paradigm.
[0003] Cryptography (e.g., cryptography) can refer to the practice and / or research of techniques used for secure communication in the presence of hostile acts. Generally, cryptography can involve constructing and / or analyzing protocols to prevent third parties and / or the public from reading private communications, and involves disciplines such as computer science, information security, electrical engineering, and digital signal processing. Practical applications of cryptography can include e-commerce, chip-based payment cards, digital currencies, computer cryptography, and / or military communications. Symmetric-key cryptography is used in many modern applications. Symmetric-key cryptography can refer to encryption methods where the sender and receiver share the same key, or where the sender and receiver have different keys but are related in an easily computable manner.
[0004] However, in symmetric-key cryptography, each party in the scenario may need to possess a secret key, which must be exchanged before any encryption is used. The distribution of secret keys can be problematic because it involves face-to-face meetings and / or the use of a trusted messenger, which can be impractical and insecure. While the secret key is being transmitted, it can be stolen and / or copied by the other party, who could then be able to decrypt any ciphertext encrypted using that secret key. Another issue is the potential for a large number of secret keys between the communicating parties. A large number of secret keys quickly becomes difficult to manage. Summary of the Invention
[0005] Therefore, the objective of the subject matter disclosed here is to provide methods, systems, and computer program products for remote secure key exchange based on multi-party computation, which overcome some or all of the defects identified above.
[0006] According to a non-limiting embodiment or aspect, a computer-implemented method for remote secure key exchange based on multi-party computation is provided, 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 the first key custodian by the at least one processor based on the identifier associated with the first key custodian; authenticating the second key custodian by the at least one processor based on the identifier associated with the second key custodian; verifying, by the at least one processor, that a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; and verifying, by the at least one processor, that a quorum of key custodians is available based on the quorum of key custodians. A certain number of key management operations can be established to be performed by a first key custodian and a second key custodian; at least one processor receives a collaborative key generation request associated with the first key custodian and the second key custodian; at least one processor generates a secure cryptographic key; at least one processor encrypts a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key, and encrypts a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; at least one processor sends the first component encrypted secure cryptographic key to the first key custodian; and at least one processor sends the second component encrypted secure cryptographic key to the second key custodian.
[0007] According to a non-limiting embodiment or aspect, receiving a collaborative key generation request associated with a first key custodian and a second key custodian includes: 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 using the first key custodian's private key 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 using the second key custodian's private key to provide a digital signature of the second key custodian; and verifying the collaborative request between the first key custodian and the second key custodian for generating a secure cryptographic key based on the digital signatures of the first key custodian and the second key custodian.
[0008] According to a non-limiting embodiment or aspect, the method further includes receiving an authorization request for a key management operation from a first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receiving an authorization request for a key management operation from a second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determining, based on the first request identifier of the first key custodian, that the first key custodian is authorized to perform a key management operation; determining, based on the second request identifier of the second key custodian, that the second key custodian is authorized to perform a key management operation; 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 the authorization of the key management operation.
[0009] According to a non-limiting embodiment or aspect, the method further includes, before establishing the key management operation to be performed by the first key custodian and the second key custodian: authorizing the first key custodian to perform the key management operation based on an identifier associated with the first key custodian, wherein authorizing the first key custodian to perform the key management operation includes: matching the identifier associated with the first key custodian with a first request identifier associated with the first key custodian stored in a data structure associated with the authorization of the key management operation; and authorizing the second key custodian to perform the key management operation based on an identifier associated with the second key custodian, wherein authorizing the second key custodian to perform the key management operation includes: matching the identifier associated with the second key custodian with a second request identifier associated with the second key custodian stored in a data structure associated with the authorization of the key management operation.
[0010] According to a non-limiting embodiment or aspect, receiving the identifier associated with the first key custodian and the identifier associated with the second key custodian includes: receiving a key request from the issuing system, wherein the key request includes the identifier associated with the first key custodian and the identifier associated with the second key custodian. According to a non-limiting embodiment or aspect, authenticating the first key custodian includes: authenticating the first key custodian by at least one processor of the Hardware Security Module (HSM) based on the identifier associated with the first key custodian; wherein authenticating the second key custodian includes: authenticating the second key custodian by at least one processor of the HSM based on the identifier associated with the second key custodian.
[0011] According to a non-restrictive implementation scheme or aspect, the secure cryptographic key is a symmetric key.
[0012] According to a non-limiting embodiment or aspect, a system for remote secure key exchange based on multi-party computation is provided, 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 that 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 the verifiable quorum of key custodians; 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 encrypt a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; send the first component encrypted secure cryptographic key to the first key custodian; and send the second component encrypted secure cryptographic key to the second key custodian.
[0013] According to a non-limiting embodiment or aspect, when a collaborative key generation request is received, at least one processor is further programmed or configured to: receive a first key generation request associated with a first key custodian from a first key custodian, wherein the first key generation request is signed using the 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 a second key custodian from a second key custodian, wherein the second key generation request is signed using the private key of the second key custodian to provide a digital signature of the second key custodian; and verify the collaborative request between the first key custodian and the second key custodian for generating a secure cryptographic key based on the digital signatures of the first key custodian and the second key custodian.
[0014] According to a non-limiting embodiment or aspect, at least one processor is further programmed or configured to: receive an authorization request for a key management operation from a first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for a key management operation from a second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine, based on the first request identifier of the first key custodian, that the first key custodian is authorized to perform a key management operation; determine, based on the second request identifier of the second key custodian, that the second key custodian is authorized to perform a key management operation; 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 the authorization of the key management operation.
[0015] According to a non-limiting embodiment or aspect, at least one processor is further programmed or configured to: before establishing a key management operation to be performed by a first key custodian and a second key custodian: authorize the first key custodian to perform the key management operation based on an identifier associated with the first key custodian, wherein when authorizing the first key custodian to perform the key management operation, at least one processor is programmed or configured to: match the identifier associated with the first key custodian with a first request identifier associated with the first key custodian stored in a data structure associated with the authorization of the key management operation; and authorize the second key custodian to perform the key management operation based on an identifier associated with the second key custodian, wherein when authorizing the second key custodian to perform the key management operation, at least one processor is programmed or configured to: match the identifier associated with the second key custodian with a second request identifier associated with the second key custodian stored in a data structure associated with the authorization of the key management operation.
[0016] According to a non-limiting embodiment or aspect, when receiving an identifier associated with a first key custodian and an identifier associated with a second key custodian, at least one processor is programmed or configured to: receive a key request from the issuing system, wherein the key request includes the identifier associated with the first key custodian and the identifier associated with the second key custodian.
[0017] According to a non-limiting embodiment or aspect, at least one processor includes at least one processor of a hardware security module (HSM), and wherein when authenticating a first key custodian, at least one processor is programmed or configured to: authenticate the first key custodian via at least one processor of the HSM based on an identifier associated with the first key custodian; wherein when authenticating the first key custodian, at least one processor is programmed or configured to: authenticate a second key custodian via at least one processor of the HSM based on an identifier associated with a second key custodian.
[0018] According to a non-restrictive implementation scheme or aspect, the secure cryptographic key is a symmetric key.
[0019] According to a non-limiting embodiment or aspect, a computer program product is provided for remote secure key exchange based on multi-party computation. The computer program product includes at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium including one or more instructions, which, when executed by at least one processor, cause 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; and verify that a quorum of key custodians is available. The quorum includes at least a first key custodian and a second key custodian; the quorum of verification key custodians can be used to establish key management operations to be performed by the first key custodian and the second key custodian; receiving collaborative key generation requests associated with the first key custodian and the second key custodian; generating a secure cryptographic key; encrypting a first part of the secure cryptographic key to provide a first component encrypted secure cryptographic key, and encrypting a second part of the secure cryptographic key to provide a second component encrypted secure cryptographic key; sending the first component encrypted secure cryptographic key to the first key custodian; and sending the second component encrypted secure cryptographic key to the second key custodian.
[0020] According to a non-limiting embodiment or aspect, one or more instructions cause at least one processor to receive a collaborative key generation request, causing at least one processor to: receive a first key generation request associated with a first key custodian, wherein the first key generation request is signed using the 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 a second key custodian, wherein the second key generation request is signed using the private key of the second key custodian to provide a digital signature of the second key custodian; and verify the collaborative request between the first key custodian and the second key custodian for generating a secure cryptographic key based on the digital signatures of the first and second key custodians.
[0021] According to a non-limiting embodiment or aspect, one or more instructions further cause at least one processor to: receive an authorization request for a key management operation from a first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for a key management operation from a second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine, based on the first request identifier of the first key custodian, that the first key custodian is authorized to perform the key management operation; determine, based on the second request identifier of the second key custodian, that the second key custodian is authorized to perform the key management operation; 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 the authorization of the key management operation.
[0022] According to a non-limiting embodiment or aspect, one or more instructions further cause at least one processor to: before establishing a key management operation to be performed by a first key custodian and a second key custodian: authorize the first key custodian to perform the key management operation based on an identifier associated with the first key custodian, wherein one or more instructions causing at least one processor to authorize the first key custodian to perform the key management operation cause at least one processor to: match the identifier associated with the first key custodian with a first request identifier associated with the first key custodian stored in a data structure associated with the authorization of the key management operation; and authorize the second key custodian to perform the key management operation based on an identifier associated with the second key custodian, wherein one or more instructions causing at least one processor to authorize the second key custodian to perform the key management operation cause at least one processor to: match the identifier associated with the second key custodian with a second request identifier associated with the second key custodian stored in a data structure associated with the authorization of the key management operation.
[0023] According to a non-limiting embodiment or aspect, one or more instructions cause at least one processor to receive an identifier associated with a first key custodian and an identifier associated with a second key custodian, causing at least one processor to: receive a key request from the issuing system, wherein the key request includes an identifier associated with the first key custodian and an identifier associated with the second key custodian.
[0024] According to a non-limiting embodiment or aspect, at least one processor includes at least one processor of a hardware security module (HSM), and wherein one or more instructions causing at least one processor to authenticate a first key custodian cause at least one processor to: authenticate the first key custodian via the at least one processor of the HSM based on an identifier associated with the first key custodian; wherein one or more instructions causing at least one processor to authenticate a first key custodian cause at least one processor to: authenticate a second key custodian via the at least one processor of the HSM based on an identifier associated with a second key custodian.
[0025] Other non-restrictive embodiments or aspects will be set forth in the following numbered clauses: Clause 1: A computer-implemented method for remote secure key exchange based on multi-party computation, 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 the first key custodian by the at least one processor based on the identifier associated with the first key custodian; authenticating the second key custodian by the at least one processor based on the identifier associated with the second key custodian; verifying, by the at least one processor, that a quorum of key custodians is available, wherein the quorum includes at least the first key custodian and the second key custodian; and verifying, by the at least one processor, that the quorum of key custodians is available for... The process involves establishing key management operations to be performed by the first key custodian and the second key custodian; receiving a collaborative key generation request associated with the first key custodian and the second key custodian by at least one processor; generating a secure cryptographic key by at least one processor; encrypting a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key by at least one processor, and encrypting a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key by at least one processor; sending the first component encrypted secure cryptographic key to the first key custodian by at least one processor; and sending the second component encrypted secure cryptographic key to the second key custodian by at least one processor.
[0026] Clause 2: A computer-implemented method as described in 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 using the 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 using the private key of the second key custodian to provide a digital signature of the second key custodian; and verifying the collaborative request between the first key custodian and the second key custodian for generating the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.
[0027] Clause 3: The computer-implemented method as described in Clauses 1 and 2 further comprises: receiving an authorization request for a key management operation from a first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receiving an authorization request for a key management operation from a second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determining, based on the first request identifier of the first key custodian, that the first key custodian is authorized to perform a key management operation; determining, based on the second request identifier of the second key custodian, that the second key custodian is authorized to perform a key management operation; 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 the authorization of the key management operation.
[0028] Clause 4: The computer-implemented method as described in Clauses 1 to 3 further comprises: before establishing a key management operation to be performed by the first key custodian and the second key custodian: authorizing the first key custodian to perform the key management operation based on the identifier associated with the first key custodian, wherein authorizing the first key custodian to perform the key management operation comprises: matching the identifier associated with the first key custodian with a first request identifier associated with the first key custodian stored in the data structure associated with the authorization of the key management operation; and authorizing the second key custodian to perform the key management operation based on the identifier associated with the second key custodian, wherein authorizing the second key custodian to perform the key management operation comprises: matching the identifier associated with the second key custodian with a second request identifier associated with the second key custodian stored in the data structure associated with the authorization of the key management operation.
[0029] Clause 5: A computer-implemented method as described in Clauses 1 to 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 an issuer system, wherein the key request includes the identifier associated with the first key custodian and the identifier associated with the second key custodian.
[0030] Clause 6: A computer-implemented method as described in Clauses 1 to 5, wherein authenticating the first key custodian comprises: authenticating the first key custodian by at least one processor of a hardware security module (HSM) based on the identifier associated with the first key custodian; wherein authenticating the second key custodian comprises: authenticating the second key custodian by at least one processor of the HSM based on the identifier associated with the second key custodian.
[0031] Clause 7: A computer-implemented method as described in Clauses 1 to 6, wherein the secure cryptographic key is a symmetric key.
[0032] Clause 8: A system for remote secure key exchange based on multi-party computation, 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 that 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 the verifiable quorum of key custodians; 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 encrypt a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; send the first component encrypted secure cryptographic key to the first key custodian; and send the second component encrypted secure cryptographic key to the second key custodian.
[0033] Clause 9: The system as described in Clause 8, wherein upon 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 using the 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 using the private key of the second key custodian to provide a digital signature of the second key custodian; and verify the collaborative request between the first key custodian and the second key custodian for generating the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.
[0034] Clause 10: The system as described in Clauses 8 and 9, wherein the at least one processor is further programmed or configured to: receive an authorization request for a key management operation from a first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for a key management operation from a second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine, based on the first request identifier of the first key custodian, that the first key custodian is authorized to perform a key management operation; determine, based on the second request identifier of the second key custodian, that the second key custodian is authorized to perform a key management operation; 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 the authorization of the key management operation.
[0035] Clause 11: The system as described in Clauses 8 to 10, wherein the at least one processor is further programmed or configured to: before establishing a key management operation to be performed by the first key custodian and the second key custodian: authorize the first key custodian to perform the key management operation based on the identifier associated with the first key custodian, wherein when authorizing the first key custodian to perform the key management operation, the at least one processor is programmed or configured to: match the identifier associated with the first key custodian with a first request identifier associated with the first key custodian stored in the data structure associated with the authorization of the key management operation; and authorize the second key custodian to perform the key management operation based on the identifier associated with the second key custodian, wherein when authorizing the second key custodian to perform the key management operation, the at least one processor is programmed or configured to: match the identifier associated with the second key custodian with a second request identifier associated with the second key custodian stored in the data structure associated with the authorization of the key management operation.
[0036] Clause 12: A system as described in Clauses 8 to 11, 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 the issuing system, wherein the key request includes the identifier associated with the first key custodian and the identifier associated with the second key custodian.
[0037] Clause 13: A system as described in Clauses 8 to 12, wherein the at least one processor includes 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 the first key custodian via the at least one processor of the HSM 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 the second key custodian via the at least one processor of the HSM based on the identifier associated with the second key custodian.
[0038] Clause 14: A system as described in Clauses 8 to 13, wherein the secure cryptographic key is a symmetric key.
[0039] Clause 15: A computer program product for remote secure key exchange based on multi-party computation, the computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions, the one or more instructions, when executed by at least one processor, causing 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 that a quorum of key custodians is available, wherein the quorum includes up to The system includes: a first key custodian and a second key custodian; establishing key management operations to be performed by the first key custodian and the second key custodian based on the legally valid number of verified key custodians; receiving a collaborative key generation request associated with the first key custodian and the second key custodian; generating a secure cryptographic key; encrypting a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key, and encrypting a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; sending the first component encrypted secure cryptographic key to the first key custodian; and sending the second component encrypted secure cryptographic key to the second key custodian.
[0040] Clause 16: A computer program product as described in Clause 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 is signed using the 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 using the private key of the second key custodian to provide a digital signature of the second key custodian; and verify the collaborative request between the first key custodian and the second key custodian for generating the secure cryptographic key based on the digital signature of the first key custodian and the digital signature of the second key custodian.
[0041] Clause 17: A computer program product as described in Clauses 15 and 16, wherein one or more instructions further cause the at least one processor to: receive an authorization request for a key management operation from a first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for a key management operation from a second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine, based on the first request identifier of the first key custodian, that the first key custodian is authorized to perform a key management operation; determine, based on the second request identifier of the second key custodian, that the second key custodian is authorized to perform a key management operation; 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 the authorization of the key management operation.
[0042] Clause 18: A computer program product as described in Clauses 15 to 17, wherein one or more instructions further cause the at least one processor to: authorize the first key custodian to perform the key management operation based on the identifier associated with the first key custodian, prior to establishing a key management operation to be performed by the first key custodian and the second key custodian, wherein the one or more instructions causing the at least one processor to authorize the first key custodian to perform the key management operation cause the at least one processor to: match the identifier associated with the first key custodian with a first request identifier associated with the first key custodian stored in the data structure associated with the authorization of the key management operation; and authorize the second key custodian to perform the key management operation based on the identifier associated with the second key custodian, wherein the one or more instructions causing the at least one processor to authorize the second key custodian to perform the key management operation cause the at least one processor to: match the identifier associated with the second key custodian with a second request identifier associated with the second key custodian stored in the data structure associated with the authorization of the key management operation.
[0043] Clause 19: A computer program product as described in Clauses 15 to 18, wherein one or more instructions causing 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 one processor to: receive a key request from the issuing system, wherein the key request includes the identifier associated with the first key custodian and the identifier associated with the second key custodian.
[0044] Clause 20: A computer program product as described in Clauses 15 to 19, wherein the at least one processor includes at least one processor of a hardware security module (HSM), and wherein the one or more instructions causing the at least one processor to authenticate the first key custodian cause the at least one processor to: authenticate the first key custodian via the at least one processor of the HSM based on the identifier associated with the first key custodian; wherein the one or more instructions causing the at least one processor to authenticate the first key custodian cause the at least one processor to: authenticate the second key custodian via the at least one processor of the HSM based on the identifier associated with the second key custodian.
[0045] These and other features and characteristics of the subject matter currently disclosed, as well as the operational methods and functions of combinations of related structural elements and parts, and the economics of manufacture, will become more apparent when considering the following description and appended claims, all of which form part of this specification, wherein the same reference numerals denote corresponding parts in the figures. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be a definition of limitation on the disclosed subject matter. Unless the context clearly specifies otherwise, the singular forms “a” and “said” as used in this specification and claims include plural indicators. Attached Figure Description
[0046] Additional advantages and details of the disclosed subject matter are explained in more detail below with reference to exemplary embodiments or aspects illustrated in the accompanying drawings, in which: Figures 1A to 1B A diagram is a non-limiting embodiment or aspect of an environment in which the methods, systems and / or computer program products described herein are implemented based on the principles of the currently disclosed subject matter; Figure 2 yes Figure 1A A diagram of a non-limiting embodiment or aspect of a component of one or more devices; Figure 3 It is a flowchart of a non-limiting implementation or aspect of a process for remote secure key exchange based on multi-party computation; and Figures 4A to 4D It is a diagram illustrating a non-limiting implementation or aspect of a process for remote secure key exchange based on multi-party computation, according to some non-limiting implementation or aspect. Detailed Implementation
[0047] For descriptive purposes, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and their derivatives, shall apply to the orientation of the disclosed subject matter as shown in the accompanying drawings. However, it should be understood that the disclosed subject matter may take various alternative variations and sequences of steps, except where explicitly specified otherwise. It should also be understood that the specific devices and processes shown in the accompanying drawings and described in the following description are merely exemplary embodiments or aspects of the disclosed subject matter. Therefore, unless otherwise indicated, specific dimensions and other physical characteristics associated with the embodiments or aspects disclosed herein should not be considered limiting.
[0048] The terms "aspect," "component," "element," "structure," "action," "step," "function," and "instruction" used herein should not be construed as critical or essential unless explicitly stated otherwise. Furthermore, as used herein, the articles "a" and "an" are intended to include one or more items and are interchangeable with "one or more" and "at least one." Additionally, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, etc.) and is interchangeable with "one or more" or "at least one." The term "a" or similar language is used where only one item is intended. Moreover, as used herein, the terms "has," "have," and "having" are intended to be open-ended terms. Additionally, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on."
[0049] As used herein, the terms "communication" and "transmission" can refer to the receiving, accepting, sending, transmitting, or providing of information (e.g., data, signals, messages, instructions, commands, etc.). For one unit (e.g., a device, system, component of a device or system, a combination thereof, etc.) to communicate with another unit means that the first unit is able to receive information directly or indirectly from and / or send information to the other unit. This can refer to a direct or indirect connection that is inherently wired and / or wireless (e.g., a direct communication connection, an indirect communication connection, and / or the like). Furthermore, the two units can communicate with each other even though the transmitted information may be modified, processed, relayed, and / or routed between them. For example, the first unit can communicate with the second unit even if it passively receives information and does not actively send information to the second unit. As another example, the first unit can communicate with the second unit if at least one intermediate unit (e.g., a third unit located between the first and second units) processes information received from the first unit and transmits the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet that includes data (e.g., a data packet, etc.). It should be understood that many other arrangements are possible.
[0050] As used herein, the terms “issuer institution,” “portable financial device issuer,” “issuer,” or “issuer bank” may refer to one or more entities that provide customers with accounts for conducting transactions (e.g., payment transactions) (e.g., initiating credit and / or debit payments). For example, an issuer institution may provide customers with an account identifier, such as a primary account number (PAN), that uniquely identifies one or more accounts associated with said customer. The account identifier may be implemented 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 issuer institution, 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 transactions.
[0051] As used herein, the term "account identifier" can include one or more types of identifiers (e.g., PAN, card number, payment card number, payment token, etc.) associated with a user account. In some non-limiting embodiments or aspects, the issuing authority may provide the user with an account identifier (e.g., PAN, payment token, etc.) that uniquely identifies one or more accounts associated with the user. The account identifier may be embodied in a physical financial instrument (e.g., portable financial instrument, payment card, credit card, debit card, etc.) and / or may be electronic information transmitted to the user enabling the user to make electronic payments. In some non-limiting embodiments or aspects, the account identifier may be an original account identifier, wherein the original account identifier is provided to the user when an account associated with the account identifier is created. In some non-limiting embodiments or aspects, the account identifier may be an account identifier provided to the user after the original account identifier has been provided to the user (e.g., a supplementary account identifier). For example, if the original account identifier is forgotten, stolen, etc., a supplementary account identifier may be provided to the user. In some non-limiting embodiments or aspects, the account identifier may be associated directly or indirectly with the issuing authority, such that the account identifier may be a payment token mapped to a PAN or other type of identifier. The account identifier may be any combination of alphanumeric characters, characters, and / or symbols, etc. The issuing authority may be associated with a Bank Identification Number (BIN) that uniquely identifies the issuing authority.
[0052] As used herein, the term "payment token" or "token" may refer to an identifier used as an alternative or replacement identifier for an account identifier, such as a PAN. A token may be associated with a PAN or other account identifier in one or more data structures (e.g., one or more databases, etc.) such that the token can be used to conduct transactions (e.g., payment transactions) without the direct use of the account identifier, such as the PAN. In some examples, an account identifier, such as a PAN, may be associated with multiple tokens for different individuals, different uses, and / or different purposes. For example, a payment token may include a string of numeric and / or alphanumeric characters that can be used as a replacement for the original account identifier. For example, the payment token "4900 0000 0000 0001" may be used in place of the PAN "4147 0900 0000 1234". In some non-limiting embodiments or aspects, the payment token may be "reserved format" and may have a numerical format consistent with account identifiers used in existing payment processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some non-limiting embodiments or aspects, a payment token may replace a PAN for initiating, authorizing, settling, or resolving payment transactions, or represent the original credential in other systems where the original credential is typically provided. In some non-limiting embodiments or aspects, a token value may be generated such that the original PAN or other account identifier may not be computably recovered from the token value (e.g., using a one-way hash or other cryptographic function). Furthermore, in some non-limiting embodiments or aspects, the token format may be configured to allow an entity receiving the payment token to identify it as a payment token and to recognize the entity issuing the token.
[0053] As used herein, the term "merchant" may refer to one or more entities (e.g., an operator of a retail business that provides goods and / or services and / or access to goods and / or services to users (e.g., customers, consumers, the merchant's customers, etc.) based on transactions (e.g., payment transactions). As used herein, the term "merchant system" may refer to one or more computer systems operated by or on behalf of the 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 the merchant.
[0054] As used herein, the term "transaction service provider" can refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment guarantees through an agreement between the transaction service provider and the issuing institution. In some non-limiting embodiments or aspects, a transaction service provider may include credit card companies, debit card companies, etc. As used herein, the term "transaction service provider system" can also refer to one or more computer systems operated by or on behalf of the transaction service provider, such as a transaction processing server executing one or more software applications. The 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 the transaction service provider.
[0055] As used herein, the term "acquiring party" can refer to an entity licensed and approved by the transaction service provider to initiate transactions (e.g., payment transactions) using portable financial devices associated with the transaction service provider. As used herein, the term "acquiring party system" can also refer to one or more computer systems, computer devices, etc., operated by or on behalf of the acquiring party. Transactions can include payment transactions (e.g., purchases, original credit transactions (OCT), account-based financing transactions (AFT), etc.). In some non-restrictive implementations or aspects, the acquiring party may be authorized by the transaction service provider to contract with merchants or service providers to initiate transactions using the transaction service provider's portable financial devices. The acquiring party may contract with payment service providers to enable them to provide initiation services to merchants. The acquiring party may monitor the compliance of payment service providers in accordance with the transaction service provider's regulations. The acquiring party may conduct due diligence on payment service providers and ensure appropriate due diligence is performed before contracting with merchants to whom initiation is made. The acquiring party may be responsible for all transaction service provider programs operated or initiated by the acquiring party. The acquiring party can be responsible for the actions of the acquiring payment service provider, merchants initiated by the acquiring payment service provider, etc. In some non-restrictive implementation schemes or aspects, the acquiring party can be a financial institution, such as a bank.
[0056] As used herein, the terms "client" and "client device" can refer to one or more client-side devices or systems (e.g., remote from the transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). As examples, "client device" can refer to one or more POS devices used by a merchant, one or more acquiring host computers used by an acquiring party, one or more mobile devices used by a user, etc. In some non-limiting embodiments or aspects, a client device can be an electronic device configured to communicate with one or more networks and initiate or facilitate transactions. For example, a client device can include one or more computers, laptops, laptops, tablets, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), PDAs, etc. Furthermore, "client" can also refer to an entity (e.g., a merchant, acquiring party, etc.) that owns, utilizes, and / or operates a client device for initiating transactions (e.g., for initiating transactions with a transaction service provider).
[0057] As used herein, the term "computing device" can refer to one or more electronic devices configured to communicate directly or indirectly with or on one or more networks. A computing device can be a mobile device, a desktop computer, and / or any other similar device. Furthermore, the term "computer" can refer to any computing device that includes the necessary components for receiving, processing, and outputting data and typically includes a display, processor, memory, input devices, and network interfaces. As used herein, the term "server" can refer to or include one or more processors or computers, storage devices, or similar computer arrangements operated by or facilitating communication and processing by multiple parties in a network environment such as the Internet; however, it should be understood that communication can be facilitated through one or more public or private network environments, and various other arrangements are also possible. Furthermore, multiple computers (e.g., servers or other computerized devices) communicating directly or indirectly in a network environment can constitute a "system."
[0058] As used herein, the term “processor” can refer to 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.
[0059] As used herein, the term "system" may refer to one or more computing devices or a combination of computing devices (e.g., processor, server, client device, software application, components of such devices, etc.). As used herein, references to "device," "server," "processor," etc., may refer to a previously stated device, server, or processor, different servers or processors, and / or combinations of servers and / or processors, described as performing a prior step or function. For example, as used in the specification and claims, a first server or first processor described as performing a first step or a first function may refer to the same or different server or the same or different processor described as performing a second step or a second function.
[0060] As used herein, the term "Payment Card Industry Data Security Standard" (PCI-DSS) can refer to the information security standards used by organizations to process branded credit cards from major card brand networks. PCI-DSS is mandated by payment card companies but is administered by the Payment Card Industry Security Standards Committee.
[0061] As used herein, "public-key encryption" involves encoding a message by passing it through a mathematical function (called a "cryptography") to protect it from unintended viewers. This mathematical function uses a key to hide the original values within the message, and decoding the message depends on having a key that returns the values to their original state, thus allowing the message to be read. In public-key encryption (such as asymmetric encryption), the key used to encode the message and the key used to decode the message are different (i.e., asymmetric). This can be called public-key encryption or cryptography because one key is widely available ("public key"), while another key is kept private ("private key") to ensure the security of the message. Public-key encryption relies on the private key remaining secure, secret, and unavailable to those who could intercept, attack, or tamper with the message. Whether the public key is used to encrypt or verify the message depends on the nature of the message. For example, a private key is often used to sign messages that anyone can read but cannot tamper with (at least not invalidate the signature). In a scenario where everyone can encrypt a message but cannot open it (e.g., it is not easily decrypted if intercepted by the wrong person, etc.), the message is encrypted using a public key but can only be decrypted using the associated private key.
[0062] As used herein, a "symmetric key" (e.g., shared key, secret key, symmetric encryption key, etc.) refers to a cryptographic key used for both encrypting and decrypting data. Such keys are used to protect sensitive information and ensure data confidentiality. When data is stored on a storage device, these keys can be used to send secure messages back and forth between parties in a communication channel, and so on. They are also called secret keys because the keys are typically kept secret and are known only to the parties who need to know them (e.g., parties involved in communication, parties storing sensitive information, parties participating in transactions, parties sending electronic money, parties exchanging electronic money, etc.). Symmetric keys are generated, managed, and distributed, and can involve multiple authorized key custodians. Typically, symmetric keys are shared between the sender and receiver of encrypted messages. The key must be kept secret to effectively protect confidential, sensitive, and private information, but the key must be known to both parties to ensure secure communication.
[0063] As used in this paper, “hashing” (e.g., hash functions) involves cryptographic methods designed to be irreversible. A hash function is a one-way algorithm based on a mathematical function that takes an arbitrary input message and produces a deterministic output (e.g., a message digest). The one-way nature of a hash function means that, given an output, it is difficult to determine the input that generated that output. As used in this paper, hashing a message typically serves one of two purposes: protecting the confidentiality of secret information (e.g., verifying the correctness of a password) or confirming that the message has not been modified (e.g., verifying the integrity of downloaded software). In the first case, when a message digest is created by hashing a message (e.g., a document, multiple data fields, etc.) for storage or transmission, in the event of an attack, everything stolen by the hacker is an unreadable, scrambled value (e.g., hash value, hash code, digest, hash, etc.). In the second case, message integrity can be determined by hashing a copy of the original message and comparing the result with the digest value of the original message. It is not necessary to read the message itself to determine that the message has not been modified; only the output of the hash (e.g., the message digest) is needed.
[0064] As used in this article, a threshold can refer to a value that is greater than, more than, higher than, greater than or equal to, less than, less than, lower than, less than or equal to, or equal to a threshold (e.g., a fraction, power consumption, etc.).
[0065] Symmetric keys can be essential for ensuring confidential communication between financial institutions and payment processors. Since symmetric key encryption involves using the same key to encrypt and decrypt data, each symmetric key should be kept secret and protected from unauthorized access to ensure security. Furthermore, ensuring there are no single points of failure or vulnerabilities in the key generation process is crucial. For example, relying on a single custodian to maintain the symmetric keys may be impractical and insecure.
[0066] However, securely exchanging and integrating symmetric keys between different entities while adhering to the dual control principle (where no single entity possesses the symmetric key) can introduce considerable complexity to existing key exchange systems. In the payments industry, the secure and confidential transmission of information is essential, and systems designed to securely exchange and / or integrate symmetric encryption key components between different parties while maintaining dual control introduce problems and difficulties.
[0067] For example, implementing a security protocol for securely exchanging symmetric keys may require physically providing key components to various custodians and / or relying on a trusted messenger service to transmit the key components. However, the complexities exacerbated by situations such as pandemics and natural disasters can render this approach cumbersome and impractical due to the need for physical presence to ensure security.
[0068] Additionally, the security of the keys used for transmission (such as the Secure Sockets Layer (SSL) protocol and others) provides an encryption and security layer for data transmission, but it is not without its vulnerabilities and attack risks (e.g., the use of potential attack vectors). Furthermore, other application protocols may focus only on one aspect of security, such as protecting data during transmission, but in situations where operations such as secure communication rely on the availability of cryptographic keys, such application protocols may not address the challenges associated with the secure generation, sharing, and / or management of cryptographic keys.
[0069] Non-limiting embodiments or aspects of the disclosed subject matter relate to methods, systems, and computer program products for remote secure key exchange based on multi-party computation. 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 that 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 encrypt a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; send the first component encrypted secure cryptographic key to the first key custodian; and send 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.
[0070] In some non-limiting embodiments or aspects, when receiving a collaborative key generation request, the key management system may: receive a first key generation request associated with a first key custodian, wherein the first key generation request is signed using the 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 a second key custodian, wherein the second key generation request is signed using the private key of the second key custodian to provide a digital signature of the second key custodian; and verify the collaborative request between the first key custodian and the second key custodian for generating a secure cryptographic key based on the digital signatures of the first and second key custodians.
[0071] In some non-limiting embodiments or aspects, the key management system may: receive an authorization request for a key management operation from a first key custodian, wherein the authorization request includes a first request identifier of the first key custodian; receive an authorization request for a key management operation from a second key custodian, wherein the authorization request includes a second request identifier of the second key custodian; determine, based on the first request identifier of the first key custodian, that the first key custodian is authorized to perform the key management operation; determine, based on the second request identifier of the second key custodian, that the second key custodian is authorized to perform the key management operation; 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 the authorization of the key management operation.
[0072] In some non-limiting embodiments or aspects, the key management system may authorize the first key custodian to perform key management operations based on an identifier associated with the first key custodian before establishing key management operations to be performed by the first key custodian and the second key custodian. In some non-limiting embodiments or aspects, when authorizing the first key custodian to perform key management operations, the key management system may match the identifier associated with the first key custodian with a first request identifier associated with the first key custodian stored in a data structure associated with the authorization of the key management operation, and authorize the second key custodian to perform 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 to perform key management operations, the key management system may match the identifier associated with the second key custodian with a second request identifier associated with the second key custodian stored in a data structure associated with the authorization of the key management operation.
[0073] In some non-limiting embodiments or aspects, when receiving an identifier associated with a first key custodian and an identifier associated with a second key custodian, the key management system can receive a key request from the issuing system, wherein the key request includes the identifier associated with the first key custodian and the identifier associated with the second key custodian.
[0074] In some non-limiting embodiments or aspects, the key management system may include a hardware security module (HSM), and when authenticating a first key custodian, the key management system may authenticate the first key custodian via the HSM based on an identifier associated with the first key custodian. In some non-limiting embodiments or aspects, when authenticating a first key custodian, the key management system may authenticate a second key custodian via the HSM based on an identifier associated with a second key custodian.
[0075] In this way, the key management system can implement dual controls to ensure the existence of a quorum of authorized custodians and provide collaboration for the generation, management, and / or exchange of cryptographic keys and / or key components. This eliminates the possibility of single points of failure and enhances the overall security of operations involving cryptographic keys, including the generation, management, and / or exchange of cryptographic keys and / or key components. By ensuring a quorum of key custodians participating in key operations and implementing dual controls, vulnerabilities can be reduced, and channel attacks can be prevented or mitigated.
[0076] In addition, the key management system reduces the risks associated with theft, tampering, and unauthorized access to key materials, while also providing protection against cybersecurity threats such as man-in-the-middle attacks (where an attacker intercepts and alters communications between parties, thereby potentially gaining access to keys during the exchange between parties, etc.) and attackers who gain access and can tamper with the process to generate weaker or compromised keys.
[0077] Now for reference Figure 1A , Figure 1A This is a diagram of an example environment 100 in which the devices, systems, and / or methods described herein may be implemented. Figure 1A As shown, environment 100 includes a key management system 102, a first key custodian device 104-1, a second key custodian device 104-2, an Nth key custodian device 104-N (where appropriate, individually referred to as key custodian device 104, and collectively as key custodian device 104), an issuer system 106, a transaction service provider system 108, a communication network 110, and a data source 112. The key management system 102, key custodian devices 104, transaction service provider system 108, issuer system 106, and / or data source 112 can be interconnected (e.g., establishing connections for communication) via wired connections, wireless connections, or a combination of wired and wireless connections.
[0078] The key management system 102 may include one or more devices configured to communicate via a communication network 110 with the key custodian device 104, the issuer system 106, and / or the transaction service provider system 108. For example, the key management system 102 may include a server, a server cluster, and / or other similar devices. In some non-limiting embodiments or aspects, the key management system 102 may be associated with the issuer system 106. For example, the key management system 102 may be operated by the issuer system 106. In another example, the key management system 102 may be a component of the issuer system 106. In some non-limiting embodiments or aspects, the key management system 102 may communicate with a data source 112, which may be local or remote to the key management system 102. In some non-limiting embodiments or aspects, the key management system 102 may be able to receive (e.g., retrieve via pull) information from the data source 112, store information in the data source, send information to the data source, and / or search for information stored in the data source. In some non-limiting embodiments or aspects, the key management system 102 may include a hardware security module (HSM). In some non-restrictive implementations or aspects, the HSM may be designed with physical and / or logical security measures to resist tampering, enabling the HSM to provide a platform for handling sensitive cryptographic operations and / or cryptographic keys.
[0079] Key custodian device 104 may include one or more devices configured to communicate via communication network 110 with key management system 102, other key custodian devices, issuer system 106, and / or transaction service provider system 108. For example, key custodian device 104 may include a server, server cluster, and / or other similar devices. In another example, key custodian device 104 may include computing devices such as desktop computers, portable computers (e.g., tablet computers, laptop computers, etc.), mobile devices (e.g., cellular phones, smartphones, personal digital assistants, wearable devices, etc.), and / or other similar 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 the private key in a public-private key pair.
[0080] In some non-limiting embodiments or aspects, the key custodian device 104 can be authenticated by the key management system 102 through various processes. For example, cryptographic proofs, digital signatures, and / or other authentication mechanisms can be used to verify the identity of the key custodian device 104 (e.g., the identity of the key custodian associated with the key custodian device 104). In this way, only authorized key custodians are allowed to participate in the key generation process, as described herein.
[0081] In some non-limiting embodiments or aspects, each key custodian device in key custodian device 104 may be associated with a designated key custodian. A key custodian may refer to an entity (e.g., an individual, financial institution, messenger, etc.) responsible for generating, securing, transmitting, and / or otherwise protecting information about cryptographic keys. The key custodian may manage and / or use the cryptographic keys on key custodian device 104 for protecting information based on cryptographic techniques (e.g., encryption, decryption, etc.). In some non-limiting embodiments or aspects, key custodian device 104 may utilize the cryptographic keys to perform encryption techniques to encrypt information (e.g., sensitive data such as personally identifiable information (PII)) in a manner that ensures the security and confidentiality of the information. Key custodian device 104 may be configured to securely load cryptographic keys and / or cryptographic key components for further use (e.g., during payment processing).
[0082] In some non-limiting embodiments or aspects, each key custodian associated with key custodian device 104 can initiate, operate, respond to, and / or execute remote key generation actions (e.g., key generation, authentication, key exchange, etc.). In some examples, a key custodian can operate key custodian device 104 to authenticate the corresponding key custodian, sign messages (e.g., digitally sign), authenticate key generation requests, etc.
[0083] In some non-limiting embodiments or aspects, each key custodian associated with key custodian device 104 may perform a multi-party computation (MPC) protocol to jointly compute a value (e.g., a cryptographic value) that confirms the identity (e.g., presence, ownership, etc.) of the key custodian associated with key custodian device 104 during authorization. This value can be computed without disclosing any private information of any key custodian associated with key custodian device 104 (e.g., information provided as input, such as input used to compute the value).
[0084] The issuer system 106 may include one or more devices configured to communicate via a communication network 110 with the key management system 102, the key custodian device 104, and the transaction service provider system 108. For example, the issuer system 106 may include computing devices such as servers, server clusters, and / or other similar devices. In some non-limiting embodiments or aspects, the issuer system 106 may be associated with an issuer (e.g., a financial institution that issues accounts to account holders). For example, the issuer system 106 may be operated by the issuer. In some non-limiting embodiments or aspects, the key custodian device 104 may be a component of the issuer system 106, or vice versa.
[0085] Transaction service provider system 108 may include one or more devices configured to communicate via communication network 110 with key management system 102, key custodian device 104, and / or issuer system 106. In some non-limiting embodiments or aspects, transaction service provider system 108 may include servers, server clusters, and / or other similar devices. In some non-limiting embodiments or aspects, transaction service provider system 108 is associated with a transaction service provider and / or payment processor. For example, transaction service provider system 108 may be operated by the transaction service provider and / or 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.
[0086] The communication network 110 may include one or more wired and / or wireless networks. For example, the communication network 110 may include cellular networks (e.g., Long Term Evolution (LTE) networks, third-generation (3G) networks, fourth-generation (4G) networks, fifth-generation (5G) networks, Code Division Multiple Access (CDMA) networks, etc.), Public Land Mobile Networks (PLMN), Local Area Networks (LAN), Wide Area Networks (WAN), Metropolitan Area Networks (MAN), Telephone Networks (e.g., Public Switched Telephone Network (PSTN), etc.), Private Networks, Ad Hoc Networks, Intranets, the Internet, Fiber-based Networks, Cloud Computing Networks, etc., and / or combinations of some or all of these or other types of networks.
[0087] Provided as an example Figure 1A The number and arrangement of systems, devices, and / or networks are shown. Additional systems, devices, and / or networks may exist; fewer systems, devices, and / or networks may exist; different systems, devices, and / or networks may exist; and / or networks may be associated with... Figure 1A The different arrangements of systems, devices, and / or networks are shown. Furthermore, implementation can be achieved within a single system or device. Figure 1A The two or more systems or devices shown, or Figure 1A The single system or device shown may be implemented as multiple distributed systems or devices. Additionally or alternatively, a group of systems (e.g., one or more systems) and / or a group of devices (e.g., one or more devices) of environment 100 may perform one or more functions described as being performed by another group of systems or another group of devices of environment 100.
[0088] Now for reference Figure 1B , Figure 1B This is a diagram of a non-limiting implementation or aspect of the key management system 102. For example... Figure 1B As shown, the key management system 102 may include a remote key generation engine 102A.
[0089] In some non-limiting embodiments or aspects, the remote key generation engine 102A can generate cryptographic keys and / or key components for key custodian devices 104. In some non-limiting embodiments or aspects, the remote key generation engine 102A is configured to operate according to an MPC protocol for virtual remote key exchange involving key custodian devices 104. For example, the remote key generation engine 102A performs the MPC protocol necessary for communication between key custodian devices 104. In this example, the remote key generation engine 102A can receive input (e.g., input associated with a cryptographic key request) from a first key custodian device 104-1, a second key custodian device 104-2, and / or an Nth key custodian device 104-N. Upon receiving the input, the remote key generation engine 102A can jointly compute a function based on the input while maintaining the confidentiality of the input.
[0090] In some non-limiting embodiments or aspects, an MPC protocol can refer to a key management technique that allows multiple parties to collaboratively compute functions without disclosing the individual inputs of each party. MPC protocols can be used to generate cryptographic keys in a distributed and secure manner. MPC can be used to generate keys using threshold cryptography, such that the cryptographic keys can be fragmented and distributed among a group of key custodians (e.g., a group of key custodians associated with key custodian device 104). The fragmentation of the cryptographic keys can be distributed in a manner that allows only a specific number of key custodians (e.g., a quorum, selection, etc.) to collaborate in performing cryptographic operations.
[0091] In some non-limiting embodiments or aspects, the remote key generation engine 102A can generate and / or provide a set of cryptographic key parameters. For example, the remote key generation engine 102A can generate and / or provide cryptographic parameters for a first key custodian device 104-1, a second key custodian device 104-2, and / or an 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 asymmetric cryptosystems, such as E. G.A., Diffie-Hellman, etc.), commitment schemes, cryptographic primitives (e.g., key length, algorithm, operating mode, initialization vector, etc.). In some non-limiting embodiments or aspects, the remote key generation engine 102A can receive one or more key generation requests from the key custodian device 104 (e.g., key generation requests including the private key of the key custodian device 104). In some non-limiting embodiments or aspects, the remote key generation engine 102A can generate and / or provide a set of cryptographic key parameters based on receiving one or more key generation requests.
[0092] In some examples, the remote key generation engine 102A can verify the signature of one or more key generation requests. In such examples, based on the key generation requests, the remote key generation engine 102A can generate commitments to the key generation requests and each requester (e.g., one or more key custodian devices 104). In some non-limiting embodiments or aspects, the remote key generation engine 102A initiates an MPC protocol involving each designated key custodian device 104. For example, the remote key generation engine 102A can request (e.g., invite, prompt, etc.) each designated key custodian device 104 to perform secure authentication. In such examples, the key custodian device 104 can use its private key to authenticate, thereby securely sharing authentication information and / or status.
[0093] In some non-limiting embodiments or aspects, the remote key generation engine 102A can generate a shared secure cryptographic key by dividing the complete cryptographic key into key fragments to be distributed among key custodian devices 104. The resulting key fragments can be constructed in a manner that requires a minimum number of key custodian devices 104 (e.g., a quorum of key custodian devices 104) to collaboratively reconstruct the complete cryptographic key. In some non-limiting embodiments or aspects, the remote key generation engine 102A can generate an MPC secure cryptographic key, which is divided into shared cryptographic keys for a group of key custodian devices (e.g., a quorum of key custodian devices 104). The remote key generation engine 102A can generate and / or provide multiple shared cryptographic keys in a manner that allows only a specified number of key custodians (e.g., a quorum) to perform cryptographic operations on the MPC secure cryptographic key (e.g., collaborate to perform cryptographic operations).
[0094] In some non-limiting embodiments or aspects, the remote key generation engine 102A can generate and provide cryptographic keys for a secure and encrypted communication channel (e.g., each direction, route, etc.) between the issuing system 106 and the transaction service provider system 108 (e.g., entities in a payment network). This ensures that any data transmitted between the issuing system 106 and the transaction service provider system 108 is protected from eavesdropping or tampering by unauthorized parties. In some non-limiting embodiments or aspects, the remote key generation engine 102A can encrypt and / or decrypt information (e.g., sensitive data) exchanged between the issuing system 106 and the transaction service provider system 108. For example, when the transaction service provider system 108 sends electronic transaction information (e.g., an authorization request) to the issuing system 106, the remote key generation engine 102A can encrypt the data using a secure cryptographic key before sending the electronic transaction information. The issuing system 106 can use the same secure cryptographic key to decrypt and access the information.
[0095] like Figure 1B The document further illustrates that the remote key generation engine 102A may include multiple subsystems that implement the operations described herein. For example, the remote key generation engine 102A may include a remote secure exchange protocol subsystem 102A-1, which may include a cryptographic engine 102A-1A, a key manager 102A-1B, an authentication control 102A-1C, an access control 102A-1D, a secure communication interface 102A-1E, and an integration interface 102A-1F.
[0096] In some non-limiting embodiments or aspects, the cryptographic engine 102A-1A can perform various cryptographic operations, including key generation, encryption, decryption, signing, and verification. For example, the cryptographic engine 102A-1A can securely generate, manipulate, and protect cryptographic keys and / or cryptographic key components. In some examples, the cryptographic engine 102A-1A can generate cryptographic parameters for a secure key generation process (such as the secure key generation process involved in the MPC protocol).
[0097] In some non-limiting embodiments or aspects, key manager 102A-1B can perform management operations of cryptographic keys, including key generation, storage, distribution, rotation, and / or deletion. In some examples, key manager 102A-1B can securely store cryptographic keys (e.g., the private key in a public-private key pair) because these cryptographic keys are associated with key custodian devices 104 (e.g., assigned to these key custodian devices). In some non-limiting embodiments or aspects, key manager 102A-1B can generate cryptographic key components required by the 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-1B can securely distribute cryptographic keys and / or cryptographic key components based on encryption protocols, available secure channels, authentication or authorization status, etc. In some non-limiting embodiments or aspects, the key manager 102A-1B may include a random number generator subsystem for generating random numbers for cryptographic operations such as cryptographic key generation and / or initialization vectors.
[0098] In some non-limiting embodiments or aspects, authentication control 102A-1C can control the execution of processes for authenticating users and devices accessing the remote key generation engine 102A. In some non-limiting embodiments or aspects, authentication control 102A-1C can authorize individuals such as custodians and administrators to interact with the remote key generation engine 102A. In some non-limiting embodiments or aspects, authentication control 102A-1C can authenticate key custodian device 104 before it can initiate a key generation request. In some non-limiting embodiments or aspects, if key custodian device 104 is not authenticated, the key generation process may not execute (e.g., it may fail). In some non-limiting embodiments or aspects, authentication control 102A-1C can control the execution of processes involving biometric authentication (e.g., biometric authentication using fingerprints, facial recognition, etc.), unique identifiers (e.g., personal identification numbers (PINs)), etc.
[0099] In some non-limiting embodiments or aspects, access control 102A-1D can control the process of accessing the remote key generation engine 102A to prevent unauthorized access (e.g., in the form of data leakage). In some non-limiting embodiments or aspects, access control 102A-1D may include a policy management system. For example, access control 102A-1D may include a policy management system that enforces rules and / or policies related to quorum requirements, authentication processes, and / or responses to key generation requests. In some non-limiting embodiments or aspects, access control 102A-1D may interface with the HSM and / or other subsystems to ensure compliance with the process of accessing the remote key generation engine 102A.
[0100] In some non-limiting embodiments or aspects, the secure communication interface 102A-1E can communicate with external entities of the key management system 102 (e.g., the remote key generation engine 102A of the key management system 102). For example, the secure communication interface 102A-1E can communicate with key custodian device 104 and / or other devices and systems.
[0101] In some non-limiting embodiments or aspects, the integrated interface 102A-1F may provide integrated interfaces such as application programming interfaces (APIs) and communication protocols, which allow external entities to interact with the cryptographic capabilities of the remote key generation engine 102A (e.g., an HSM). In some examples, the integrated interface 102A-1F may allow the key custodian device 104 to access user interfaces and / or applications for initiating key generation requests, providing authorization, and managing processes involving cryptographic operations.
[0102] Now for reference Figure 2 , Figure 2This is a diagram illustrating example components of 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.
[0103] like Figure 2 As shown, device 200 may include bus 202, processor 204, memory 206, storage unit 208, input unit 210, output unit 212, and communication interface 214. Bus 202 may include components that allow communication between components of device 200. In some non-limiting embodiments 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 processors (e.g., central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), etc.), microprocessors, digital signal processors (DSPs), and / or any processing unit that can be programmed to perform a function (e.g., field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.). 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, etc.) that stores information and / or instructions for use by processor 204.
[0104] 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 hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, solid-state disk, etc.), compressed optical disk (CD), digital versatile optical disk (DVD), floppy disk, cassette tape, magnetic tape and / or another type of computer-readable medium, and corresponding drives.
[0105] Input component 210 may include components that allow device 200 to receive information, such as via user input (e.g., a touchscreen display, keyboard, keypad, mouse, button, switch, microphone, camera, etc.). Additionally or alternatively, input component 210 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, accelerometer, gyroscope, actuator, etc.). Output component 212 may include components that provide output information from device 200 (e.g., a display, speaker, one or more light-emitting diodes (LEDs), etc.).
[0106] Communication interface 214 may include transceiver components (e.g., transceiver, separate receiver and transmitter, etc.) that enable device 200 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 214 may allow 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, a universal serial bus (USB) interface, a Wi-Fi® interface, a Bluetooth® interface, a Zigbee® interface, a cellular network interface, etc.
[0107] Device 200 can perform one or more processes described herein. Device 200 can perform these processes based on software instructions stored in a computer-readable medium, such as memory 206 and / or storage unit 208, executed by processor 204. Computer-readable medium (e.g., non-transitory computer-readable medium) is defined herein as a non-transitory memory device. A non-transitory memory device includes memory space located within a single physical storage device or memory space distributed across multiple physical storage devices.
[0108] Software instructions can be read from another computer-readable medium or from another device into memory 206 and / or storage unit 208 via communication interface 214. When executed, the software instructions stored in memory 206 and / or storage unit 208 can cause processor 204 to perform one or more processes described herein. Alternatively or additionally, hard-wired circuitry can be used in place of or in combination with the software instructions to perform one or more processes described herein. Therefore, the embodiments or aspects described herein are not limited to any particular combination of hardware circuitry and software.
[0109] Provided shown in Figure 2 The number and arrangement of components are shown as an example. In some non-limiting embodiments or aspects, device 200 may include components shown in [example missing]. Figure 2The components in the device 200 may be fewer, different, or arranged differently than other components. Alternatively or additionally, a group of components (e.g., one or more components) of the device 200 may perform one or more functions described as being performed by another group of components of the device 200.
[0110] Now for reference Figure 3 , Figure 3 This is a flowchart of a non-limiting embodiment or aspect of a process 300 for remote secure key exchange based on multi-party computation. In some non-limiting embodiments or aspects, one or more steps of process 300 may be performed (e.g., wholly, partially, etc.) by a 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 steps of process 300 may be performed by another device or group of devices separate from or including key management system 102 (e.g., one or more devices of key management system 102), a first key custodian device 104-1, a second key custodian device 104-2, an Nth key custodian device 104-N, an issuer system 106, and / or a transaction service provider system 108 (e.g., one or more devices of transaction service provider system 108) (e.g., wholly, partially, etc.).
[0111] like Figure 3 As shown, at step 302, process 300 includes authenticating a first key custodian and a second key custodian. For example, key management system 102 can authenticate both the first and second key custodians. In some non-limiting embodiments or aspects, key management system 102 can receive identification data (such as an identifier) associated with first key custodian device 104-1 (e.g., the 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., the second key custodian associated with second key custodian device 104-2). In some non-limiting embodiments or aspects, key management system 102 can authenticate the 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 can authenticate the second key custodian device 104-2 based on the identification data associated with second key custodian device 104-2.
[0112] In some non-limiting embodiments or aspects, the key management system 102 may receive identification data associated with multiple key custodian devices 104 for use in authentication and / or authorization processes. By knowing the identities of the involved custodians, the key management system 102 may authorize only those key custodian devices 104 participating in the key generation process, which may be part of an MPC protocol. In this way, the key management system 102 can provide security measures to prevent unauthorized entities from interfering with the key generation process and to prevent the leakage of sensitive information, while also distributing trust among multiple key custodian devices 104 to prevent any single point of failure in the key generation process.
[0113] In some non-limiting embodiments or aspects, the key management system 102 can authenticate the key custodian device 104 (e.g., first key custodian device 104-1, second key custodian device 104-2, etc.) by determining whether the identification data associated with the key custodian device 104 corresponds to the authentication data stored for the key custodian device 104 (e.g., authentication data stored in the data source 112). For example, if the key management system 102 determines that the identification data associated with the key custodian device 104 corresponds to the authentication data stored for the key custodian device 104 (e.g., stored identification data, stored credential data, stored address data, etc.), then the key management system 102 can determine that the key custodian device 104 is authenticated. In this example, if the key management system 102 determines that the identification data associated with the key custodian device 104 does not correspond to the authentication data stored for the key custodian device 104, then the key management system 102 can determine that the key custodian device 104 is not authenticated. In some non-limiting implementations or aspects, the additional key custodian device 104 may be authenticated in the same or similar manner.
[0114] In some non-limiting embodiments or aspects, the key management system 102 may receive key requests (e.g., key generation requests) from one or more key custodian devices 104, issuer systems 106, and / or transaction service provider systems 108. In some non-limiting embodiments or aspects, the key request may include identification data associated with a first key custodian device 104-1 and / or identification data associated with a second key custodian device 104-2. In some non-limiting embodiments or aspects, one or more key custodian devices 104 may send the key request to the key management system 102, issuer systems 106, and / or transaction service provider systems 108.
[0115] In some non-limiting embodiments or aspects, the key management system 102 can monitor one or more inputs provided by the key custodian device 104 and can determine that the key custodian device 104 is following a protocol. For example, the remote key generation engine 102A can use zero-knowledge proofs to verify one or more inputs of the key custodian device 104 without leaking one or more inputs to other key custodian devices 104.
[0116] like Figure 3 As shown, at step 304, process 300 includes verifying the availability of a quorum. For example, the key management system 102 may verify that a quorum (e.g., the quorum of key custodians, the quorum of key custodians associated with key custodian device 104, the quorum of key custodians associated with key custodian device 104 and key management system 102, etc.) is available for a protocol such as the MPC protocol. In some non-limiting embodiments or aspects, the key management system 102 may verify the availability of a quorum based on identification data associated with key custodian device 104. For example, the key management system 102 may determine that identification data has been received from multiple key custodian devices 104, and the 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, the key management system 102 may determine that the quorum of key custodian devices 104 is available. If the number of key custodian devices 104 does not correspond to the threshold statutory quantity requirement, the key management system 102 can determine that the statutory quantity of key custodian devices 104 is unavailable.
[0117] In some non-limiting embodiments or aspects, the key management system 102 may establish a minimum number of key custodian devices 104 that must exist and participate in the MPC protocol (e.g., multiple key custodian devices 104, two key custodian devices 104, three key custodian devices 104, etc.). In some non-limiting embodiments or aspects, the key management system 102 may verify the availability of the quorum based on the security requirements of the protocol. In one example, if there are a total of N key custodian devices in the MPC protocol and the quorum is defined as K, then at least K key custodian devices must be available (e.g., exist, threshold levels are met, etc.).
[0118] In some non-limiting embodiments or aspects, the key management system 102 may block the key generation process when the quorum is unavailable. For example, the key management system 102 may block the key generation process unless the required number of quorum participants have been authenticated and participated in the collaboration of the key generation request. In some non-limiting embodiments or aspects, if the key management system 102 determines that the quorum of the key custodian device 104 is available, the key management system 102 may continue the key generation process. If the key management system 102 determines that the quorum of the key custodian device 104 is unavailable, the key management system 102 may block the key generation process from continuing.
[0119] In some non-limiting embodiments or aspects, the key management system 102 may receive authorization requests for key management operations from multiple key custodian devices 104. For example, the key management system 102 may receive authorization requests for key management operations from a first key custodian device 104-1 and from a second key custodian device 104-2. In some non-limiting embodiments or aspects, the authorization request may include a request identifier of the key custodian device 104 providing the authorization request. In the example above, the first authorization request may include a first request identifier of the first key custodian device 104-1, and the second authorization request may include a second request identifier of the second key custodian device 104-2.
[0120] In some non-limiting embodiments or aspects, the key management system 102 may determine that the key custodian device 104 is authorized to perform key management operations based on an authorization request (e.g., a request identifier included in the authorization request of the key custodian device 104). In the example above, the key management system 102 may determine that the first key custodian device 104-1 is authorized to perform key management operations based on a first request identifier of the first key custodian device 104-1, and determine that the second key custodian device 104-2 is authorized to perform key management operations based on a second request identifier of the second key custodian device 104-2.
[0121] In some non-limiting embodiments or aspects, the key management system 102 may store the request identifier of the key custodian device 104 in a data structure associated with the authorization of the key management operation (e.g., a data structure in the data source 112). In the example above, the key management system 102 may store the first request identifier of the first key custodian device 104-1 and the second request identifier of the second key custodian device 104-2 in a data structure associated with the authorization of the key management operation.
[0122] In some non-limiting embodiments or aspects, the key management system 102 may establish key management operations (e.g., key management operations of the HSM of the key management system 102) to be performed by the first key custodian device 104-1 (e.g., the first key custodian associated with the first key custodian device 104-1) and the second key custodian based on the verification of a quorum (e.g., the quorum of the key custodian device 104-1).
[0123] In some non-limiting embodiments or aspects, the key management system 102 may authorize one or more key custodian devices 104 to perform key management operations based on identification data associated with the one or more key custodian devices 104 before establishing key management operations to be performed by the one or more key custodian devices 104. For example, the key management system 102 may authorize the first key custodian device 104-1 to perform key management operations based on identification data associated with the first key custodian device 104-1 and / or the second key custodian device 104-2 to perform key management operations based on identification data associated with the first key custodian device 104-1.
[0124] In some non-limiting embodiments or aspects, the key management system 102 may authorize one or more key custodian devices 104 to perform key management operations by matching identification data associated with one or more key custodian devices 104 with request identifiers associated with one or more key custodian devices 104 stored in a data structure associated with authorization of key management operations. For example, the key management system 102 may match identification data associated with a first key custodian device 104-1 with a first request identifier associated with the first key custodian device 104-1 stored in a data structure, and may match identification data associated with a second key custodian device 104-2 with a second request identifier associated with the second key custodian device 104-2 stored in a data structure.
[0125] like Figure 3 As shown, at step 306, process 300 includes receiving a collaborative key generation request. For example, key management system 102 may receive a 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).
[0126] In some non-limiting embodiments or aspects, the key management system 102 may receive a first key generation request from the first key custodian device 104-1. For example, the key management system 102 may receive a first key generation request for a first key custodian associated with the first key custodian device 104-1. In some non-limiting embodiments or aspects, the first key generation request may be signed using the private key of the first key custodian device 104-1 (e.g., the private key of the first key custodian associated with the first key custodian device 104-1) to provide a digital signature for the first key custodian device 104-1.
[0127] In some non-limiting embodiments or aspects, the key management system 102 may receive a second key generation request from the second key custodian device 104-2. For example, the key management system 102 may receive a first key generation request for a second key custodian associated with the second key custodian device 104-2. In some non-limiting embodiments or aspects, the second key generation request may be signed using the private key of the second key custodian device 104-2 (e.g., the private key of the second key custodian associated with the second key custodian device 104-2) to provide a digital signature of the second key custodian device 104-2.
[0128] In some non-limiting embodiments or aspects, the key management system 102 can verify the collaboration request for generating a secure cryptographic key between the first key custodian device 104-1 (e.g., the first key custodian associated with the first key custodian device 104-1) and the second key custodian device 104-2 (e.g., the second key custodian associated with the second key custodian device 104-2) based on the digital signatures of the first key custodian device 104-1 and the second key custodian device 104-2.
[0129] like Figure 3 As shown, at step 308, process 300 includes generating a secure cryptographic key. For example, a key management system 102 can generate a 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.
[0130] In some non-limiting embodiments or aspects, the key management system 102 may generate secure cryptographic keys based on a valid quorum (e.g., a quorum of key custodian devices 104) available. Additionally or alternatively, the key management system 102 may generate secure cryptographic keys based on receiving a collaborative key generation request (e.g., a collaborative key generation request as part of an MPC protocol).
[0131] In some non-limiting embodiments or aspects, the key management system 102 can generate secure cryptographic keys based on the process of creating cryptographic keys. These cryptographic keys can be used for various security-related operations, such as encryption, decryption, and digital signatures. This is done in a way that makes the cryptographic keys extremely difficult for unauthorized parties to predict or guess. In some non-limiting embodiments or aspects, the key management system 102 can generate secure cryptographic keys based on a hashing process (e.g., a hash function).
[0132] In some non-limiting embodiments or aspects, the key management system 102 can generate secure cryptographic keys such that a single key custodian device 104 does not have access to the complete secure cryptographic key. In this way, the key management system 102 ensures that no single key custodian device 104 has full knowledge of the secure cryptographic key, which can improve the overall security of the key generation process.
[0133] like Figure 3 As shown, at step 310, process 300 includes encrypting portions of the secure cryptographic key to provide component-encrypted secure cryptographic keys. For example, the key management system 102 may encrypt two or more portions of the secure cryptographic key (e.g., two or more equal portions, two or more unequal portions, etc.) to provide two or more component-encrypted secure cryptographic keys. In some non-limiting embodiments or aspects, the key management system 102 may encrypt two or more portions of the secure cryptographic key based on the generation of the secure cryptographic key. In one example, the key management system 102 may encrypt a first portion of the secure cryptographic key to provide a first component-encrypted secure cryptographic key, and encrypt a second portion of the secure cryptographic key to provide a second component-encrypted secure cryptographic key.
[0134] In some non-limiting embodiments or aspects, the key management system 102 may utilize a shared cryptographic key to encrypt a portion of the secure cryptographic key. For example, the key management system 102 may utilize a shared cryptographic key shared among the key custodian devices 104 to encrypt a portion of the secure cryptographic key. In some non-limiting embodiments or aspects, the key management system 102 may utilize a shared cryptographic key (e.g., a shared cryptographic key shared among the key custodian devices 104) to encrypt the secure cryptographic key (e.g., the entire secure cryptographic key) to provide an encrypted secure cryptographic key.
[0135] In some non-limiting embodiments or aspects, the key management system 102 may use the public key from a public-private key pair associated with key custodian device 104 to encrypt a portion of the secure cryptographic key, and may use the public key from a public-private key pair associated with another key custodian device 104 to encrypt another portion of the secure cryptographic key. In the example above, the key management system 102 may use the first public key from a first public-private key pair associated with the first key custodian device 104-1 to encrypt a first portion of the secure cryptographic key, and may use the second public key from a second public-private key pair associated with the second key custodian device 104-2 to encrypt a second portion of the secure cryptographic key.
[0136] like Figure 3 As shown, at step 312, process 300 includes sending a component-encrypted secure cryptographic key. For example, the key management system 102 may send a component-encrypted secure cryptographic key. In some non-limiting embodiments or aspects, the key management system 102 may send the component-encrypted secure cryptographic key based on encrypting a portion of the secure cryptographic key. In some non-limiting embodiments or aspects, the key management system 102 may send multiple component-encrypted secure cryptographic keys (e.g., as part of an MPC protocol) to multiple key custodian devices 104. For example, the key management system 102 may send a first component-encrypted secure cryptographic key to a first key custodian device 104-1, and / or send a second component-encrypted secure cryptographic key to a second key custodian device 104-2. In some non-limiting embodiments or aspects, the key management system 102 may send the component-encrypted secure cryptographic key as ciphertext. In some non-limiting embodiments or aspects, the key management system 102 may send an encrypted secure cryptographic key as ciphertext.
[0137] In some non-limiting embodiments or aspects, the key management system 102 may receive indications confirming that multiple key custodian devices 104 have received multiple component-encrypted security cryptographic keys. For example, the first key custodian device 104-1 and the second key custodian device 104-2 may respectively receive the first component-encrypted security cryptographic key and the second component-encrypted security cryptographic key, and the first key custodian device 104-1 and the second key custodian device 104-2 may each send an acknowledgment message to the key management system 102.
[0138] In some non-limiting embodiments or aspects, the key custodian device 104 may use a component-encrypted security key or an encrypted security key during the electronic payment processing. For example, the key custodian device 104 may use a component-encrypted security key or an encrypted security key to encrypt authorization messages (such as authorization response messages) during the electronic payment processing.
[0139] Now for reference Figures 4A to 4D , Figures 4A to 4D This is a diagram illustrating a non-limiting embodiment or aspect of an implementation 400 related to a process (e.g., process 300) for remote secure key exchange based on multi-party computation. In some non-limiting embodiments or aspects, one or more steps of the process may be performed (e.g., wholly, partially, etc.) by a key management system 102 (e.g., one or more devices of the key management system 102). In some non-limiting embodiments or aspects, one or more steps of the process may be performed by another device or group of devices separate from or including the key management system 102 (e.g., one or more devices of the key management system 102), a first key custodian device 104-1, a second key custodian device 104-2, an Nth key custodian device 104-N, an issuer system 106, and / or a transaction service provider system 108 (e.g., one or more devices of the transaction service provider system 108) (e.g., wholly, partially, etc.).
[0140] like Figure 4A As shown by reference numeral 405 in the accompanying drawings, the key management system 102 can receive an identifier associated with a first key custodian and an identifier associated with a second key custodian. For example... Figure 4A The accompanying reference numeral 410 further illustrates that the key management system 102 can authenticate the first key custodian and the second key custodian.
[0141] like Figure 4B As indicated by reference numeral 415 in the attached diagram, the key management system 102 can verify the availability of a quorum. (As shown in the attached diagram...) Figure 4B Reference numeral 420 in the accompanying drawings further illustrates that the key management system 102 can establish key management operations to be performed. For example... Figure 4C As shown by reference numeral 425 in the attached figure, the key management system 102 can receive collaborative key generation requests. For example... Figure 4C As further illustrated by reference numeral 430 in the accompanying drawings, the key management system 102 can generate secure cryptographic keys.
[0142] like Figure 4D As shown by reference numeral 435 in the attached figure, the key management system 102 can encrypt the first part and the second part of the secure cryptographic key. For example... Figure 4D Reference numeral 440 in the accompanying drawings further illustrates that the key management system 102 can send the first component encryption security key to the first key custodian device 104-1. For example... Figure 4D As further shown by reference numeral 445 in the figure, the key management system 102 can send the first component encrypted security key to the second key custodian device 104-2.
[0143] Although the disclosed subject matter has been described in detail for illustrative purposes based on embodiments or aspects currently considered most practical and preferred, it should be understood that such details are for said purposes only, and the disclosed subject matter is not limited to the disclosed embodiments or aspects, but rather is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the currently disclosed subject matter contemplates, as far as possible, the possibility of combining one or more features of any embodiment or aspect with one or more features of any other embodiment or aspect.
Claims
1. A computer-implemented method for remote secure key exchange based on multi-party computation, comprising: At least one processor receives an identifier associated with a first key custodian and an identifier associated with a second key custodian; The first key custodian is authenticated by at least one processor based on the identifier associated with the first key custodian; The second key custodian is authenticated by at least one processor based on the identifier associated with the second key custodian; The availability of a quorum of key custodians is verified by at least one processor, wherein the quorum includes at least the first key custodian and the second key custodian; At least one processor can establish key management operations to be performed by the first key custodian and the second key custodian based on the legal number of verified key custodians; At least one processor receives a collaborative key generation request associated with the first key custodian and the second key custodian; The secure cryptographic key is generated by at least one processor; At least one processor encrypts a first portion of the secure cryptographic key to provide a first component encrypted secure cryptographic key, and encrypts a second portion of the secure cryptographic key to provide a second component encrypted secure cryptographic key; At least one processor sends the encryption security key for the first component to the custodian of the first key. as well as The second component encryption security key is sent by at least one processor to the custodian of the second key.
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: 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 using the private key of the first key custodian to provide the first key custodian's digital signature. 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 using the private key of the second key custodian to provide the digital signature of the second key custodian; as well as The collaboration request between the first key custodian and the second key custodian for generating the secure cryptographic key is verified based on the digital signatures of the first key custodian and the second key custodian.
3. The computer-implemented method as described in claim 1, further comprising: 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; The first request identifier of the first key custodian determines that the first key custodian is authorized to perform key management operations; The second request identifier of the second key custodian determines that the second key custodian is authorized to perform key management operations; The first request identifier of the first key custodian and the second request identifier of the second key custodian are stored in a data structure associated with the authorization of the key management operation.
4. The computer-implemented method as described in claim 3, further comprising: Before establishing the key management operations to be performed by the first key custodian and the second key custodian: Authorizing the first key custodian to perform key management operations based on the identifier associated with the first key custodian, wherein authorizing the first key custodian to perform key management operations includes: The identifier associated with the first key custodian is matched against the first request identifier associated with the first key custodian, which is stored in the data structure associated with the authorization of the key management operation; and Authorizing the second key custodian to perform key management operations based on the identifier associated with the second key custodian, wherein authorizing the second key custodian to perform key management operations includes: The identifier associated with the second key custodian is matched with the second request identifier associated with the second key custodian, which is stored in the data structure associated with the authorization of the key management operation.
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: A key request is received from the issuer's system, wherein the key request includes 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: The first key custodian is authenticated by at least one processor of the Hardware Security Module (HSM) based on the identifier associated with the first key custodian; The authentication of the second key custodian includes: The second key custodian is authenticated by at least one processor of the HSM 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 remote secure key exchange based on multi-party computation, comprising: At least one processor, said at least one processor being programmed or configured to: Receive the identifier associated with the first key custodian and the identifier associated with the second key custodian; The first key custodian is authenticated based on the identifier associated with the first key custodian; The second key custodian is authenticated based on the identifier associated with the second key custodian; The legal number of key custodians is available, wherein the legal number includes at least the first key custodian and the second key custodian; The legally mandated number of key custodians can be used to establish key management operations to be performed by the first key custodian and the second key custodian; Receive collaborative key generation requests associated with the first key custodian and the second key custodian; Generate a secure cryptographic key; The first part of the secure cryptographic key is encrypted to provide a first component encrypted secure cryptographic key, and the second part of the secure cryptographic key is encrypted to provide a second component encrypted secure cryptographic key; Send the first component's encryption security key to the first key custodian; and The second component encryption security key is sent to the second key custodian.
9. The system of claim 8, wherein upon receiving the cooperation 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 using the private key of the first key custodian to provide the first key custodian's digital signature. Receives a second key generation request associated with the second key custodian, wherein the second key custodian's private key is used to sign the second key generation request to provide the second key custodian's digital signature; and The collaboration request between the first key custodian and the second key custodian for generating the secure cryptographic key is verified based on the digital signatures of the first key custodian and 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; The first request identifier of the first key custodian determines that the first key custodian is authorized to perform key management operations; The second request identifier of the second key custodian determines that the second key custodian is authorized to perform key management operations; The first request identifier of the first key custodian and the second request identifier of the second key custodian are stored in a data structure associated with the authorization of the key management operation.
11. The system of claim 10, wherein the at least one processor is further programmed or configured to: Before establishing the key management operations to be performed by the first key custodian and the second key custodian: Authorizing the first key custodian to perform key management operations based on the identifier associated with the first key custodian, wherein when authorizing the first key custodian to perform key management operations, the at least one processor is programmed or configured to: The identifier associated with the first key custodian is matched against the first request identifier associated with the first key custodian, which is stored in the data structure associated with the authorization of the key management operation; and Authorizing the second key custodian to perform key management operations based on the identifier associated with the second key custodian, wherein when authorizing the second key custodian to perform key management operations, the at least one processor is programmed or configured to: The identifier associated with the second key custodian is matched with the second request identifier associated with the second key custodian, which is stored in the data structure associated with the authorization of the key management operation.
12. The system of claim 8, wherein upon 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: A key request is received from the issuer's system, wherein the key request includes 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 the at least one processor is programmed or configured to: The first key custodian is authenticated via the at least one processor of the HSM based on the identifier associated with the first key custodian; When authenticating the first key custodian, the at least one processor is programmed or configured to: The at least one processor of the HSM authenticates 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 remote secure key exchange based on multi-party computation, the computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions, the one or more instructions causing the at least one processor, when executed by at least one processor, to: Receive the identifier associated with the first key custodian and the identifier associated with the second key custodian; The first key custodian is authenticated based on the identifier associated with the first key custodian; The second key custodian is authenticated based on the identifier associated with the second key custodian; The legal number of key custodians is available, wherein the legal number includes at least the first key custodian and the second key custodian; The legally mandated number of key custodians can be used to establish key management operations to be performed by the first key custodian and the second key custodian; Receive collaborative key generation requests associated with the first key custodian and the second key custodian; Generate a secure cryptographic key; The first part of the secure cryptographic key is encrypted to provide a first component encrypted secure cryptographic key, and the second part of the secure cryptographic key is encrypted to provide a second component encrypted secure cryptographic key; Send the first component's encryption security key to the first key custodian; and The second component encryption security key is sent 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 cooperative 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 using the private key of the first key custodian to provide the first key custodian's digital signature. Receives a second key generation request associated with the second key custodian, wherein the second key custodian's private key is used to sign the second key generation request to provide the second key custodian's digital signature; and The collaboration request between the first key custodian and the second key custodian for generating the secure cryptographic key is verified based on the digital signatures of the first key custodian and 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; The first request identifier of the first key custodian determines that the first key custodian is authorized to perform key management operations; The second request identifier of the second key custodian determines that the second key custodian is authorized to perform key management operations; The first request identifier of the first key custodian and the second request identifier of the second key custodian are stored in a data structure associated with the authorization of the key management operation.
18. The computer program product of claim 17, wherein the one or more instructions further cause the at least one processor to: Before establishing the key management operations to be performed by the first key custodian and the second key custodian: Authorizing the first key custodian to perform 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 to perform key management operations cause the at least one processor to: The identifier associated with the first key custodian is matched against the first request identifier associated with the first key custodian, which is stored in the data structure associated with the authorization of the key management operation; and Authorizing the second key custodian to perform 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 to perform key management operations cause the at least one processor to: The identifier associated with the second key custodian is matched with the second request identifier associated with the second key custodian, which is stored in the data structure associated with the authorization of the key management operation.
19. The computer program product of claim 15, wherein the one or more instructions causing 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 one processor to: A key request is received from the issuer's system, wherein the key request includes 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: The first key custodian is authenticated via the at least one processor of the HSM based on the identifier associated with the first key custodian; The one or more instructions that enable the at least one processor to authenticate the first key custodian enable the at least one processor to: The at least one processor of the HSM authenticates the second key custodian based on the identifier associated with the second key custodian.