Methods, systems, and computer program products for network binding agent re-encryption and pin conversion

Abstract

A method, system, and computer program product that: generates, by a payment network, a first value (a) and a second value (ga) based on the first value (a) and a generator value (g); generates, by the payment network, a plurality of random merchant numbers (mi) for a respective plurality of merchant banks; determines, by the payment network, a merchant product (M) based on a product of the plurality of random merchant numbers (mi); generates, by the payment network, a public key (pki) based on the second value (ga), the merchant product (M), and the random merchant numbers (mi) and a random key (rki) based on the merchant product (M) and the random merchant number (mi) for each respective merchant bank; and communicates, by the payment network, the public key (pki) and the random key (rki) to at least one respective merchant bank.

Description

[0001] This application is a divisional application of the invention application filed on January 9, 2020, with application number 202080008563.9, entitled "Method, System and Computer Program Product for Re-encryption and PIN Conversion of Network Binding Proxy".

[0002] Cross-referencing related applications

[0003] This application relates to U.S. Provisional Patent Application No. 62 / 790,163, filed January 9, 2019, and U.S. Provisional Patent Application No. 62 / 929,344, filed November 1, 2019, the disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0004] The subject matter disclosed herein generally relates to methods, systems, and products for transmitting PINs and other sensitive data, and in some specific embodiments or aspects relates to methods, systems, and computer program products for securely transmitting PINs and other sensitive data. Background Technology

[0005] Credit card and debit card payment transactions are processed by numerous parties, including point-of-sale (POS) terminals, payment gateways, merchant banks, payment networks, and consumer banks. To reduce fraudulent transactions, the payment ecosystem typically deploys Personal Identification Number (PIN)-based authentication, where consumers enter their PIN into the terminal. This PIN is then sent in encrypted form along with other sensitive data, such as the main account number (PAN), through the network to the consumer's bank, which verifies the PIN before authorizing the transaction. Unsurprisingly, Payment Card Industry (PCI) regulations stipulate that PINs must never be disclosed to any party. Current deployments achieve compliance by decrypting and then encrypting the PIN at each intermediary using a Hardware Security Module (HSM) before forwarding it to the next party.

[0006] Therefore, HSMs are prevalent across all intermediaries, starting with payment gateways. This incurs significant costs, partly due to the purchase and maintenance of these HSMs, and partly due to the burden of monitoring and managing PCI compliance. Furthermore, HSMs become performance bottlenecks because the maximum throughput of payment transactions for any party depends on the number of HSMs available to that party, which can cause further problems during occasional traffic spikes, such as holiday periods. For example, some payment networks process an average of 5,000 transactions per second and are designed to handle up to 60,000 transactions per second; therefore, a large number of HSMs must be deployed to ensure sufficient hardware parallelism to handle this throughput. Summary of the Invention

[0007] Therefore, one object of this disclosure is to provide methods, systems, and computer program products for securely transmitting personal identification numbers (PINs) and other sensitive data.

[0008] According to some non-limiting embodiments or aspects, a method, system, and computer program product are provided, wherein: a first ciphertext associated with a transaction is generated by a point-of-sale (POS) terminal, the first ciphertext comprising: (i) a first ciphertext value associated with a randomly selected key (r), the first ciphertext value being encrypted based on the randomly selected key (r) and a generator value (g); and (ii) a second ciphertext value associated with a first public key (pk1) of a first pair of keys including a first public key (pk1) and a first secret key (sk1), the first public key (pk1) being generated based on the first secret key (sk1) and the generator value (g). The second ciphertext value is encrypted based on transaction data associated with the transaction, and the symmetric key (K) is generated based on the first public key (pk1) and the randomly selected key (r); the POS terminal transmits the first ciphertext to at least one payment gateway; the at least one payment gateway re-encrypts the first ciphertext value using a first re-encryption key to transform the first ciphertext value encrypted according to the first public key (pk1) into a re-encrypted first ciphertext value encrypted according to the second public key (pk2) associated with the at least one payment gateway; the at least one payment gateway then converts the re-encrypted first ciphertext value and the... The second ciphertext value is transmitted to at least one merchant bank; the at least one merchant bank re-encrypts the re-encrypted first ciphertext value encrypted with a second re-encryption key to transform the re-encrypted first ciphertext value encrypted according to the second public key (pk2) of the at least one payment gateway into a second re-encrypted first ciphertext value based on the third public key (pk3) of the at least one merchant bank; the at least one merchant bank transmits the second re-encrypted first ciphertext value and the second ciphertext value to the payment network; the payment network re-encrypts the second re-encrypted first ciphertext value encrypted with a third re-encryption key. The process involves converting the second re-encrypted first ciphertext value, encrypted according to the third public key (pk3) of the at least one merchant bank, into a third re-encrypted first ciphertext value according to the fourth public key (pk4) of the payment network; transmitting the third re-encrypted first ciphertext value and the second ciphertext value to at least one consumer bank via the payment network; determining the symmetric key (K) by the at least one consumer bank based on the third re-encrypted first ciphertext value and the consumer bank's secret key; and decrypting the second ciphertext value based on the symmetric key (K) by the at least one consumer bank to obtain the transaction data.

[0009] According to some non-limiting embodiments or aspects, a method, system, and computer program product are provided, which: receive at a payment gateway a merchant bank public key corresponding to a merchant bank private key, the merchant bank public key and the merchant bank private key being associated with a merchant bank system; transmit the merchant bank public key from the payment gateway to a point-of-sale system; receive from the point-of-sale system at least one re-encryption key, the at least one re-encryption key being based on a private key associated with the point-of-sale system and the merchant bank public key; receive from the point-of-sale system encrypted transaction data of a transaction, the encrypted transaction data including: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key, the encrypted session key including the session key encrypted with a public key associated with the point-of-sale system and corresponding to the private key associated with the point-of-sale system; determine, by the payment gateway, a re-encryption key from the at least one re-encryption key based on the encrypted transaction data; re-encrypt the encrypted session key by the payment gateway using the re-encryption key; and transmit the re-encrypted encrypted session key to the merchant bank system by the payment gateway.

[0010] According to some non-limiting embodiments or aspects, a method, system, and computer program product are provided, wherein: a point-of-sale system generates a public key and a private key associated with the point-of-sale system; a merchant bank public key corresponding to a merchant bank private key is received at the point-of-sale system, the merchant bank public key and the merchant bank private key being associated with the merchant bank system; the point-of-sale system generates at least one re-encryption key based on the private key associated with the point-of-sale system; the at least one re-encryption key is transmitted from the point-of-sale system to a payment gateway; the point-of-sale system generates encrypted transaction data of a transaction, the encrypted transaction data including: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key including the session key encrypted with the public key associated with the point-of-sale system; and the encrypted transaction data is transmitted from the point-of-sale system to the payment gateway.

[0011] According to some non-limiting embodiments or aspects, a method, system, and computer program product are provided, wherein: a merchant banking system generates a public key and a private key associated with the merchant banking system; the merchant banking system transmits the public key associated with the merchant banking system to a payment gateway; the merchant banking system receives encrypted transaction data from the payment gateway, the encrypted transaction data including: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) a re-encrypted encrypted session key including an encrypted session key encrypted with a re-encryption key, the encrypted session key including the session key encrypted with a public key associated with the point-of-sale system; and the merchant banking system decrypts the re-encrypted encrypted session key based on the private key associated with the merchant banking system.

[0012] According to some non-limiting embodiments or aspects, a method, system, and computer program product are provided, wherein: a transaction processing system receives or generates an issuer key pair including an issuer public key and a corresponding issuer private key, the issuer key pair being associated with an issuer system; the transaction processing system receives or generates a merchant bank key pair including a merchant bank public key and a corresponding merchant bank private key, the merchant bank key pair being associated with a merchant bank system; the transaction processing system generates at least one re-encryption key based at least in part on the issuer key pair and the merchant bank key pair; the transaction processing system receives encrypted transaction data of a transaction from the merchant bank system, the encrypted transaction data including: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key including a session key encrypted with the merchant bank public key; the encrypted session key is re-encrypted using the at least one re-encryption key; and the re-encrypted encrypted session key and the encrypted code are transmitted to the issuer system.

[0013] According to some non-limiting embodiments or aspects, a method, system, and computer program product are provided, wherein: a first value (a) and a second value (g) are generated by a payment network. a ), the second value (g) a The generator is generated based on the first value (a) and the generator value (g); multiple random merchant numbers (m) of the corresponding multiple merchant banks are generated by the payment network. i The payment network is based on the multiple random merchant numbers (m) of the corresponding multiple merchant banks. i The merchant product (M) is determined by the product of the second value (g) and the payment network based on the second value (g). a The merchant product (M) and the random merchant number (m) i Generate public key (pk) iAnd based on the merchant product (M) and the random merchant number (m) of each corresponding merchant bank among the plurality of merchant banks. i Generate random key (rk) i ); and the public key (pk) is transferred by the payment network. i ) and the random key (rk) i The data is transmitted to at least one corresponding merchant bank.

[0014] Other non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0015] Clause 1. A computer-implemented method comprising: generating a first ciphertext associated with a transaction by a point-of-sale (POS) terminal, the first ciphertext comprising: (i) a first ciphertext value associated with a randomly selected key (r), the first ciphertext value being encrypted based on the randomly selected key (r) and a generator value (g); and (ii) a second ciphertext value associated with a first public key (pk1) of a first pair of keys including a first public key (pk1) and a first secret key (sk1), the first public key (pk1) being generated based on the first secret key (sk1) and the generator value (g), the second ciphertext value being based on the first public key (pk1) and the generator value (g). The transaction data associated with the transaction is encrypted, and the symmetric key (K) is generated based on the first public key (pk1) and the randomly selected key (r); the POS terminal transmits the first ciphertext to at least one payment gateway; the at least one payment gateway re-encrypts the first ciphertext value using a first re-encryption key to transform the first ciphertext value encrypted according to the first public key (pk1) into a re-encrypted first ciphertext value encrypted according to a second public key (pk2) associated with the at least one payment gateway; the at least one payment gateway transmits the re-encrypted first ciphertext value and the second ciphertext value to... At least one merchant bank; the at least one merchant bank re-encrypts the re-encrypted first ciphertext value encrypted with a second re-encryption key to transform the re-encrypted first ciphertext value encrypted according to the second public key (pk2) of the at least one payment gateway into a second re-encrypted first ciphertext value based on the third public key (pk3) of the at least one merchant bank; the at least one merchant bank transmits the second re-encrypted first ciphertext value and the second ciphertext value to the payment network; the payment network re-encrypts the second re-encrypted first ciphertext value encrypted with a third re-encryption key to transform the re-encrypted first ciphertext value encrypted according to the third public key (pk3 ... payment gateway into a second re-encrypted first ciphertext value based on the third public key (pk3) of the at least one payment gateway into a second re-encrypted first ciphertext value based on the third public key (pk3) of the at least one payment gateway into a second re-encrypted first ciphertext value based on the third public key (pk3) of the at least one payment gateway into a second re-encrypted first ciphertext value based on the third public key (pk3) of the at least one payment gateway into a second re-encrypted first ciphertext value based on the third public key (pk3) of the at least one payment gateway into a second re-encrypted The second re-encrypted first ciphertext value, encrypted with the third public key (pk3) of the at least one merchant bank, is converted into a third re-encrypted first ciphertext value based on the fourth public key (pk4) of the payment network; the payment network transmits the third re-encrypted first ciphertext value and the second ciphertext value to at least one consumer bank; the at least one consumer bank determines the symmetric key (K) based on the third re-encrypted first ciphertext value and the consumer bank's secret key; and the at least one consumer bank decrypts the second ciphertext value based on the symmetric key (K) to obtain the transaction data.

[0016] Clause 2. The computer-implemented method according to Clause 1, wherein the intermediary server converts between multiple different parties by decrypting the second ciphertext value and using a portion of the transaction data to determine path selection and corresponding re-encryption keys for subsequent transmission.

[0017] Clause 3. The computer-implemented method according to Clause 1 or 2, wherein the transaction data includes at least one of a mobile personal identification number (PIN), a card verification number, or a card number associated therewith.

[0018] Clause 4. A computer-implemented method according to any one of Clauses 1 to 3, wherein the second ciphertext value is used to encrypt a personal identification number (PIN) according to the randomly selected key(r) protected by the first ciphertext value, and wherein re-encryption generates a new ciphertext value without changing the second ciphertext value.

[0019] Clause 5. A system comprising: a point-of-sale (POS) terminal including one or more processors, wherein the POS terminal is programmed and / or configured to: generate a first ciphertext associated with a transaction, the first ciphertext comprising: (i) a first ciphertext value associated with a randomly selected key (r), the first ciphertext value being encrypted based on the randomly selected key (r) and a generator value (g); and (ii) a second ciphertext value associated with a first public key (pk1) of a first pair of keys including a first public key (pk1) and a first secret key (sk1), the first public key (pk1) being generated based on the first secret key (sk1) and the generator value (g), the second ciphertext value being based on the ciphertext associated with the transaction. The transaction data is encrypted, and a symmetric key (K) is generated based on the first public key (pk1) and the randomly selected key (r); and the first ciphertext is transmitted to at least one payment gateway; the at least one payment gateway includes one or more processors, wherein the at least one payment gateway is programmed and / or configured to: re-encrypt the first ciphertext value using a first re-encryption key to transform the first ciphertext value encrypted according to the first public key (pk1) into a re-encrypted first ciphertext value encrypted according to a second public key (pk2) associated with the at least one payment gateway; and transmit the re-encrypted first ciphertext value and the second ciphertext value to at least one merchant bank; including one or more The at least one merchant bank of the processor, wherein the at least one merchant bank is programmed and / or configured to: re-encrypt the re-encrypted first ciphertext value encrypted with a second re-encryption key to transform the re-encrypted first ciphertext value encrypted according to the second public key (pk2) of the at least one payment gateway into a second re-encrypted first ciphertext value according to the third public key (pk3) of the at least one merchant bank; and transmit the second re-encrypted first ciphertext value and the second ciphertext value to a payment network; the payment network comprising one or more processors, wherein the payment network is programmed and / or configured to: re-encrypt the second re-encrypted first ciphertext value encrypted with a third re-encryption key. The value is re-encrypted to transform the second re-encrypted first ciphertext value, encrypted according to the third public key (pk3) of the at least one merchant bank, into a third re-encrypted first ciphertext value according to the fourth public key (pk4) of the payment network; and the third re-encrypted first ciphertext value and the second ciphertext value are transmitted to at least one consumer bank; and the at least one consumer bank includes one or more processors, wherein the at least one consumer bank is programmed and / or configured to: determine the symmetric key (K) based on the third re-encrypted first ciphertext value and the consumer bank's secret key; and decrypt the second ciphertext value based on the symmetric key (K) to obtain the transaction data.

[0020] Clause 6. The system pursuant to Clause 5 further includes an intermediary server, which is programmed and / or configured to transfer data between multiple different parties by decrypting the second ciphertext value and using a portion of the transaction data to determine path selection and corresponding re-encryption keys for subsequent transmission.

[0021] Clause 7. The system described in Clause 5 or 6, wherein the transaction data includes at least one of a mobile personal identification number (PIN), a card verification number, or a card number associated therewith.

[0022] Clause 8. The system according to any one of Clauses 5 to 7, wherein the second ciphertext value is used to encrypt a personal identification number (PIN) according to the randomly selected key(r) protected by the first ciphertext value, and wherein re-encryption generates a new ciphertext value without changing the second ciphertext value.

[0023] Clause 9. A computer program product comprising at least one non-transient computer-readable medium, said at least one non-transient computer-readable medium comprising program instructions that, when executed by at least one processor, cause said at least one processor to: generate a first ciphertext associated with a transaction from a point-of-sale (POS) terminal, said first ciphertext comprising: (i) a first ciphertext value associated with a randomly selected key (r), the first ciphertext value being encrypted based on said randomly selected key (r) and a generator value (g); and (ii) a second ciphertext value associated with the first public key (pk1) of a first pair of keys comprising a first public key (pk1) and a first secret key (sk1), said... A first public key (pk1) is generated based on the first secret key (sk1) and the generator value (g). The second ciphertext value is encrypted based on transaction data associated with the transaction. A symmetric key (K) is generated based on the first public key (pk1) and the randomly selected key (r). The first ciphertext is transmitted by the POS terminal to at least one payment gateway. The at least one payment gateway re-encrypts the first ciphertext value using a first re-encryption key to transform the first ciphertext value encrypted according to the first public key (pk1) into a re-encrypted first ciphertext value encrypted according to the second public key (pk2) associated with the at least one payment gateway. At least one payment gateway transmits the re-encrypted first ciphertext value and the second ciphertext value to at least one merchant bank; the at least one merchant bank re-encrypts the re-encrypted first ciphertext value encrypted with a second re-encryption key to transform the re-encrypted first ciphertext value encrypted according to the second public key (pk2) of the at least one payment gateway into a second re-encrypted first ciphertext value encrypted according to the third public key (pk3) of the at least one merchant bank; the at least one merchant bank transmits the second re-encrypted first ciphertext value and the second ciphertext value to a payment network; the payment network re-encrypts the second re-encrypted first ciphertext value encrypted with a third re-encryption key. The encrypted first ciphertext value is re-encrypted to transform the second re-encrypted first ciphertext value, which is encrypted according to the third public key (pk3) of the at least one merchant bank, into a third re-encrypted first ciphertext value according to the fourth public key (pk4) of the payment network; the third re-encrypted first ciphertext value and the second ciphertext value are transmitted by the payment network to at least one consumer bank; the at least one consumer bank determines the symmetric key (K) based on the third re-encrypted first ciphertext value and the consumer bank's secret key; and the at least one consumer bank decrypts the second ciphertext value based on the symmetric key (K) to obtain the transaction data.

[0024] Clause 10. The computer program product as described in Clause 9, wherein the intermediary server converts between multiple different parties by decrypting the second ciphertext value and using a portion of the transaction data to determine path selection and corresponding re-encryption keys for subsequent transmission.

[0025] Clause 11. The computer program product as described in Clause 9 or 10, wherein the transaction data includes at least one of a mobile personal identification number (PIN), a card verification number, or a card number associated therewith.

[0026] Clause 12. A computer program product according to any one of Clauses 9 to 11, wherein the second ciphertext value is used to encrypt a personal identification number (PIN) according to the randomly selected key(r) protected by the first ciphertext value, and wherein re-encryption generates a new ciphertext value without changing the second ciphertext value.

[0027] Clause 13. A method for encrypting an authentication code, comprising: receiving at a payment gateway a merchant bank public key corresponding to a merchant bank private key, the merchant bank public key and the merchant bank private key being associated with a merchant bank system; transmitting the merchant bank public key from the payment gateway to a point-of-sale system; receiving from the point-of-sale system at least one re-encryption key, the at least one re-encryption key being based on a private key associated with the point-of-sale system and the merchant bank public key; receiving from the point-of-sale system encrypted transaction data of a transaction, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key, the encrypted session key comprising the session key encrypted with a public key associated with the point-of-sale system and corresponding to the private key associated with the point-of-sale system; determining, by the payment gateway, a re-encryption key from the at least one re-encryption key based on the encrypted transaction data; re-encrypting, by the payment gateway, the encrypted session key using the re-encryption key; and transmitting, by the payment gateway, the re-encrypted encrypted session key to the merchant bank system.

[0028] Clause 14. The method described in Clause 13, wherein the point-of-sale system comprises at least one of the following: a point-of-sale terminal, a server computer associated with a merchant or merchant banking system, a server computer associated with a point-of-sale service provider, or any combination thereof.

[0029] Clause 15. The method according to Clause 13 or 14, wherein the at least one re-encryption key comprises a plurality of re-encryption keys, and wherein each of the plurality of re-encryption keys corresponds to a public key among a plurality of merchant bank public keys, the plurality of merchant bank public keys comprising the merchant bank public key.

[0030] Clause 16. The method according to any one of Clauses 13 to 15, wherein the at least one re-encryption key is generated by the point-of-sale system.

[0031] Clause 17. The method according to any one of Clauses 13 to 16, wherein the private key associated with the point-of-sale system corresponds to a public key, and wherein the private key and public key associated with the point-of-sale system are generated by the point-of-sale system.

[0032] Clause 18. The method according to any one of Clauses 13 to 17 further comprises: receiving or generating at a transaction processing system a public key corresponding to an issuer's private key, the public key and the private key being associated with an issuer system; generating at least one second re-encryption key by the transaction processing system based on the private key and the merchant bank's private key or a second merchant bank's private key; re-encrypting the encrypted session key with the at least one second re-encryption key; and transmitting the re-encrypted encrypted session key to the issuer system.

[0033] Clause 19. The method according to any one of Clauses 13 to 18 further includes: generating an authorization request message by the merchant banking system or the payment gateway in response to verifying the authentication code; and transmitting the authorization request message to the transaction processing system by the merchant banking system or the payment gateway.

[0034] Clause 20. A method for encrypting an authentication code, comprising: generating a public key and a private key associated with the point-of-sale system; receiving at the point-of-sale system a merchant bank public key corresponding to a merchant bank private key, the merchant bank public key and the merchant bank private key being associated with the merchant bank system; generating at least one re-encryption key by the point-of-sale system based on the private key associated with the point-of-sale system; transmitting the at least one re-encryption key from the point-of-sale system to a payment gateway; generating encrypted transaction data of a transaction by the point-of-sale system, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key including the session key encrypted with the public key associated with the point-of-sale system; and transmitting the encrypted transaction data from the point-of-sale system to the payment gateway.

[0035] Clause 21. The method described in Clause 20, wherein the point-of-sale system comprises at least one of the following: a point-of-sale terminal, a server computer associated with a merchant or merchant banking system, a server computer associated with a point-of-sale service provider, or any combination thereof.

[0036] Clause 22. The method according to Clause 20 or 21, wherein the at least one re-encryption key comprises a plurality of re-encryption keys, and wherein each of the plurality of re-encryption keys corresponds to a public key among a plurality of merchant bank public keys, the plurality of merchant bank public keys comprising the merchant bank public key.

[0037] Clause 23. A method for encrypting an authentication code, comprising: generating a public key and a private key associated with the merchant banking system by a merchant banking system; transmitting the public key associated with the merchant banking system to a payment gateway by the merchant banking system; receiving encrypted transaction data from the payment gateway by the merchant banking system, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) a re-encrypted encrypted session key including an encrypted session key encrypted with a re-encryption key, the encrypted session key including the session key encrypted with a public key associated with the point-of-sale system; and decrypting the re-encrypted encrypted session key by the merchant banking system based on the private key associated with the merchant banking system.

[0038] Clause 24. The method according to Clause 23 further includes: the merchant banking system generating an authorization request message in response to verifying the authentication code; and the merchant banking system transmitting the authorization request message to the transaction processing system.

[0039] Clause 25. A method for encrypting an authentication code, comprising: receiving or generating an issuer key pair including an issuer public key and a corresponding issuer private key, the issuer key pair being associated with an issuer system; receiving or generating a merchant bank key pair including a merchant bank public key and a corresponding merchant bank private key, the merchant bank key pair being associated with a merchant bank system; generating at least one re-encryption key by the transaction processing system based at least in part on the issuer key pair and the merchant bank key pair; receiving encrypted transaction data of a transaction from the merchant bank system, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key including a session key encrypted with the merchant bank public key; re-encrypting the encrypted session key with the at least one re-encryption key; and transmitting the re-encrypted encrypted session key and the encrypted code to the issuer system.

[0040] Clause 26. The method according to Clause 25 further comprises: receiving the re-encrypted encrypted session key from the transaction processing system by the issuing system; decrypting the re-encrypted encrypted session key by the issuing system at least in part based on the issuing private key; and decrypting the encrypted code by the issuing system at least in part based on the session key.

[0041] Clause 27. A system for encrypting authentication codes, comprising a payment gateway, the payment gateway including at least one processor, the at least one processor being programmed or configured to: receive a merchant bank public key corresponding to a merchant bank private key, the merchant bank public key and the merchant bank private key being associated with a merchant bank system; transmit the merchant bank public key to a point-of-sale system; receive from the point-of-sale system at least one re-encryption key, the at least one re-encryption key being based on a private key associated with the point-of-sale system and the merchant bank public key; receive from the point-of-sale system encrypted transaction data of a transaction, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key, the encrypted session key including the session key encrypted with a public key associated with the point-of-sale system and corresponding to the private key associated with the point-of-sale system; determine a re-encryption key among the at least one re-encryption key based on the encrypted transaction data; re-encrypt the encrypted session key with the re-encryption key; and transmit the re-encrypted encrypted session key to the merchant bank system.

[0042] Clause 28. The system described in Clause 27, wherein the point-of-sale system includes at least one of the following: a point-of-sale terminal, a server computer associated with a merchant or merchant banking system, a server computer associated with a point-of-sale service provider, or any combination thereof.

[0043] Clause 29. The system according to Clause 27 or 28, wherein the at least one re-encryption key comprises a plurality of re-encryption keys, and wherein each of the plurality of re-encryption keys corresponds to a public key among a plurality of merchant bank public keys, the plurality of merchant bank public keys comprising the merchant bank public key.

[0044] Clause 30. The system pursuant to any one of Clauses 27 to 29, wherein the at least one re-encryption key is generated by the point-of-sale system.

[0045] Clause 31. The system according to any one of Clauses 27 to 30, wherein the private key associated with the point-of-sale system corresponds to a public key, and wherein the private key and public key associated with the point-of-sale system are generated by the point-of-sale system.

[0046] Clause 32. The system according to any one of Clauses 27 to 31 further includes a transaction processing system, the transaction processing system including at least one processor, the at least one processor being programmed or configured to: receive or generate an issuer public key corresponding to an issuer private key, the issuer public key and the issuer private key being associated with an issuer system; generate at least one second re-encryption key based on the issuer private key and the merchant bank private key or a second merchant bank private key; re-encrypt the encrypted session key with the at least one second re-encryption key; and transmit the re-encrypted encrypted session key to the issuer system.

[0047] Clause 33. The system according to any one of Clauses 27 to 32, wherein at least one processor of the payment gateway or at least one processor of the merchant banking system is programmed or configured to: generate an authorization request message in response to verifying the authentication code; and transmit the authorization request message to the transaction processing system.

[0048] Clause 34. A system for encrypting authentication codes, comprising a point-of-sale system, the point-of-sale system including at least one processor, the at least one processor being programmed or configured to: generate a public key and a private key associated with the point-of-sale system; receive a merchant bank public key corresponding to a merchant bank private key, the merchant bank public key and the merchant bank private key being associated with a merchant bank system; generate at least one re-encryption key based on the private key associated with the point-of-sale system; transmit the at least one re-encryption key to a payment gateway; generate encrypted transaction data of a transaction, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key including the session key encrypted with the public key associated with the point-of-sale system; and transmit the encrypted transaction data to the payment gateway.

[0049] Clause 35. The system described in Clause 34, wherein the point-of-sale system includes at least one of the following: a point-of-sale terminal, a server computer associated with a merchant or merchant banking system, a server computer associated with a point-of-sale service provider, or any combination thereof.

[0050] Clause 36. The system according to Clause 34 or 35, wherein the at least one re-encryption key comprises a plurality of re-encryption keys, and wherein each of the plurality of re-encryption keys corresponds to a public key among a plurality of merchant bank public keys, the plurality of merchant bank public keys comprising the merchant bank public key.

[0051] Clause 37. A system for encrypting authentication codes, comprising a merchant banking system, the merchant banking system including at least one processor programmed or configured to: generate a public key and a private key associated with the merchant banking system; transmit the public key associated with the merchant banking system to a payment gateway; receive encrypted transaction data from the payment gateway, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) a re-encrypted encrypted session key including an encrypted session key encrypted with a re-encryption key, the encrypted session key including the session key encrypted with a public key associated with the point-of-sale system; and decrypt the re-encrypted encrypted session key based on the private key associated with the merchant banking system.

[0052] Clause 38. The system according to Clause 37, wherein the at least one processor is further programmed or configured to: generate an authorization request message in response to verifying the authentication code; and transmit the authorization request message to the transaction processing system.

[0053] Clause 39. A system for encrypting authentication codes, comprising a transaction processing system including at least one processor, the at least one processor being programmed or configured to: receive or generate an issuer key pair including an issuer public key and a corresponding issuer private key, the issuer key pair being associated with an issuer system; receive or generate a merchant bank key pair including a merchant bank public key and a corresponding merchant bank private key, the merchant bank key pair being associated with a merchant bank system; generate at least one re-encryption key based at least in part on the issuer key pair and the merchant bank key pair; receive encrypted transaction data of a transaction from the merchant bank system, the encrypted transaction data including: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key including a session key encrypted with the merchant bank public key; re-encrypt the encrypted session key with the at least one re-encryption key; and transmit the re-encrypted encrypted session key and the encrypted code to the issuer system.

[0054] Clause 40. The system according to Clause 39 further includes the issuer system, the issuer system including at least one processor, the at least one processor being programmed or configured to: receive the re-encrypted encrypted session key from the transaction processing system; decrypt the re-encrypted encrypted session key at least in part based on the issuer private key; and decrypt the encrypted code at least in part based on the session key.

[0055] Clause 41. A computer program product comprising at least one non-transitory computer-readable medium, said at least one non-transitory computer-readable medium comprising program instructions, said program instructions, when executed by at least one processor, causing said at least one processor to: receive at a payment gateway a merchant bank public key corresponding to a merchant bank private key, said merchant bank public key and said merchant bank private key being associated with a merchant bank system; transmit said merchant bank public key from said payment gateway to a point-of-sale system; and receive from said point-of-sale system at least one re-encryption key, said at least one re-encryption key being based on the private key associated with said point-of-sale system and said merchant bank... The payment gateway receives encrypted transaction data from the point-of-sale system, the encrypted transaction data including: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key, the encrypted session key including the session key encrypted with a public key associated with the point-of-sale system and corresponding to the private key associated with the point-of-sale system; the payment gateway determines a re-encryption key from the at least one re-encryption key based on the encrypted transaction data; the encrypted session key is re-encrypted with the re-encryption key; and the re-encrypted encrypted session key is transmitted to the merchant bank system.

[0056] Clause 42. The computer program product pursuant to Clause 41, wherein the point-of-sale system comprises at least one of the following: a point-of-sale terminal, a server computer associated with a merchant or merchant banking system, a server computer associated with a point-of-sale service provider, or any combination thereof.

[0057] Clause 43. The computer program product according to Clause 41 or 42, wherein the at least one re-encryption key comprises a plurality of re-encryption keys, and wherein each of the plurality of re-encryption keys corresponds to a public key among a plurality of merchant bank public keys, the plurality of merchant bank public keys comprising the merchant bank public key.

[0058] Clause 44. A computer program product pursuant to any one of Clauses 41 to 43, wherein the at least one re-encryption key is generated by the point-of-sale system.

[0059] Clause 45. A computer program product according to any one of Clauses 41 to 44, wherein the private key associated with the point-of-sale system corresponds to a public key, and wherein the private key and public key associated with the point-of-sale system are generated by the point-of-sale system.

[0060] Clause 46. The computer program product according to any one of Clauses 41 to 45, wherein the one or more processors are further programmed and / or configured to: receive or generate at a transaction processing system an issuer public key corresponding to an issuer private key, the issuer public key and the issuer private key being associated with an issuer system; generate by the transaction processing system at least one second re-encryption key based on the issuer private key and the merchant bank private key or a second merchant bank private key; re-encrypt the encrypted session key with the at least one second re-encryption key; and transmit the re-encrypted encrypted session key to the issuer system.

[0061] Clause 47. The computer program product according to any one of Clauses 41 to 46, wherein the one or more processors are further programmed and / or configured to: generate an authorization request message by the merchant banking system or the payment gateway in response to verifying the authentication code; and transmit the authorization request message to the transaction processing system by the merchant banking system or the payment gateway.

[0062] Clause 48. A computer program product comprising at least one non-transient computer-readable medium, the at least one non-transient computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: generate a public key and a private key associated with the point-of-sale system; receive at the point-of-sale system a merchant bank public key corresponding to a merchant bank private key, the merchant bank public key and the merchant bank private key being associated with the merchant bank system; generate at least one re-encryption key by the point-of-sale system based on the private key associated with the point-of-sale system; transmit the at least one re-encryption key from the point-of-sale system to a payment gateway; generate encrypted transaction data of a transaction by the point-of-sale system, the encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) an encrypted session key including the session key encrypted with the public key associated with the point-of-sale system; and transmit the encrypted transaction data from the point-of-sale system to the payment gateway.

[0063] Clause 49. The computer program product pursuant to Clause 48, wherein the point-of-sale system comprises at least one of the following: a point-of-sale terminal, a server computer associated with a merchant or merchant banking system, a server computer associated with a point-of-sale service provider, or any combination thereof.

[0064] Clause 50. The computer program product according to Clause 48 or 49, wherein the at least one re-encryption key comprises a plurality of re-encryption keys, and wherein each of the plurality of re-encryption keys corresponds to a public key among a plurality of merchant bank public keys, the plurality of merchant bank public keys comprising the merchant bank public key.

[0065] Clause 51. A computer program product comprising at least one non-transitory computer-readable medium, said at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause said at least one processor to: generate a public key and a private key associated with said merchant banking system by said merchant banking system; transmit said public key associated with said merchant banking system to a payment gateway by said merchant banking system; receive encrypted transaction data from said payment gateway by said merchant banking system, said encrypted transaction data comprising: (i) an encrypted code including an authentication code encrypted with a session key, and (ii) a re-encrypted encrypted session key including an encrypted session key encrypted with a re-encryption key, said encrypted session key including said session key encrypted with a public key associated with said point-of-sale system; and decrypt said re-encrypted encrypted session key by said merchant banking system based on said private key associated with said merchant banking system.

[0066] Clause 52. The computer program product according to Clause 51, wherein the one or more processors are further programmed and / or configured to: generate an authorization request message by the merchant banking system in response to verifying the authentication code; and transmit the authorization request message to the transaction processing system by the merchant banking system.

[0067] Clause 53. A computer program product comprising at least one non-transient computer-readable medium, said at least one non-transient computer-readable medium comprising program instructions that, when executed by at least one processor, cause said at least one processor to: receive or generate, by a transaction processing system, an issuer key pair comprising an issuer public key and a corresponding issuer private key, said issuer key pair being associated with an issuer system; receive or generate, by said transaction processing system, a merchant bank key pair comprising a merchant bank public key and a corresponding merchant bank private key, said merchant bank key pair being associated with a merchant bank system; generate, by said transaction processing system, at least one re-encryption key based at least in part on said issuer key pair and said merchant bank key pair; receive, from said merchant bank system, encrypted transaction data of a transaction, said encrypted transaction data comprising: (i) an encrypted code comprising an authentication code encrypted with a session key, and (ii) an encrypted session key comprising a session key encrypted with said merchant bank public key; re-encrypt said encrypted session key with said at least one re-encryption key; and transmit the re-encrypted encrypted session key and said encrypted code to said issuer system.

[0068] Clause 54. The computer program product according to Clause 53, wherein the instructions further cause the at least one processor to: receive the re-encrypted encrypted session key from the transaction processing system by the issuing system; decrypt the re-encrypted encrypted session key by the issuing system at least in part based on the issuing private key; and decrypt the encrypted code by the issuing system at least in part based on the session key.

[0069] Clause 55. A computer-implemented method comprising: generating a first value (a) and a second value (g) by a payment network. a ), the second value (g) a The generator is generated based on the first value (a) and the generator value (g); multiple random merchant numbers (m) of the corresponding multiple merchant banks are generated by the payment network. i The payment network is based on the multiple random merchant numbers (m) of the corresponding multiple merchant banks. i The merchant product (M) is determined by the product of the second value (g) and the payment network based on the second value (g). a The merchant product (M) and the random merchant number (m) i Generate public key (pk) i And based on the merchant product (M) and the random merchant number (m) of each corresponding merchant bank among the plurality of merchant banks. i Generate random key (rk) i ); and the public key (pk) is transferred by the payment network. i ) and the random key (rk)i The data is transmitted to at least one corresponding merchant bank.

[0070] Clause 56. The computer-implemented method according to Clause 55 further includes: the merchant bank generating multiple random payment gateway numbers (P) corresponding to the multiple payment gateways. i ); and the merchant bank based on the second value (g) a The merchant product (M) and the random payment gateway number (P) i Generate a payment gateway public key and based on the random payment gateway number (P) of each of the plurality of payment gateways. i Generate a random key for the payment gateway.

[0071] Clause 57. The computer-implemented method according to Clause 55 or 56 further includes: the merchant bank generating multiple terminal numbers (t) for the corresponding multiple point-of-sale (POS) terminals. i ); and the merchant bank based on the second value (g) a The merchant product (M), the random payment gateway number (p) i ) and the terminal number (t) i Generate a terminal public key and based on the random payment gateway number (p) i ) and the terminal number (t) of each of the plurality of POS terminals. i Generate a terminal random key.

[0072] Clause 58. The computer-implemented method according to any one of Clauses 55 to 57 further comprises: transmitting the terminal public key and the terminal random key to at least one payment gateway by the merchant bank; and transmitting the terminal public key to at least one POS terminal by the at least one payment gateway.

[0073] Clause 59. The computer-implemented method according to any one of Clauses 55 to 58 further comprises: generating a random number (r) for a transaction message (m) associated with a transaction by the at least one POS terminal; generating a first ciphertext associated with the transaction by the at least one POS terminal, the first ciphertext comprising: (i) a first ciphertext value associated with the transaction message (m), the first ciphertext value being encrypted based on the random number (r), a generator value (g), and the transaction message (m); and ii) a second ciphertext value associated with the random number (r), the second ciphertext value being encrypted based on the random number (r) and the terminal public key; and transmitting the first ciphertext to the at least one payment gateway by the POS terminal.

[0074] Clause 60. The computer-implemented method according to any one of Clauses 55 to 59 further comprises: re-encrypting the second ciphertext value by the at least one payment gateway based on the terminal random key to convert the second ciphertext value into a form based on the second value (g) a The re-encrypted second ciphertext value of the merchant product (M) and the random number (r); and the re-encrypted second ciphertext value and the first ciphertext value are transmitted to the at least one merchant bank by the at least one payment gateway.

[0075] Clause 61. The computer-implemented method according to any one of Clauses 55 to 60 further includes: the at least one merchant bank using the random key (rk) i The re-encrypted second ciphertext value is re-encrypted to transform the re-encrypted second ciphertext value into a form based on the second value (g). a The merchant product (M), the merchant random number (m) i The second re-encrypted ciphertext value of the random number (r) and the first ciphertext value are transmitted to the payment network by the at least one merchant bank.

[0076] Clause 62. The computer-implemented method according to any one of Clauses 55 to 61 further comprises: the payment network based on the second re-encrypted second ciphertext value, the merchant product (M), and the merchant random number (m). i The first ciphertext value is decrypted using the first ciphertext value.

[0077] Clause 63. A system comprising: a payment network including one or more processors, wherein the payment network is programmed and / or configured to: generate a first value (a) and a second value (g) a ), the second value (g) a Generate multiple random merchant IDs (m) based on the first value (a) and the generator value (g); generate multiple random merchant IDs (m) for the corresponding multiple merchant banks. i Based on the multiple random merchant numbers (m) of the corresponding multiple merchant banks. i The merchant product (M) is determined by multiplying the product of the two values ​​(g, g, and g); based on the second value (g, g ... a The merchant product (M) and the random merchant number (m) i Generate public key (pk) i And based on the merchant product (M) and the random merchant number (m) of each corresponding merchant bank among the plurality of merchant banks. i Generate random key (rk) i ); and the public key (pk) i ) and the random key (rk)i The data is transmitted to at least one corresponding merchant bank.

[0078] Clause 64. The system according to Clause 63, wherein the merchant bank includes one or more processors, and wherein the merchant bank is programmed and / or configured to: generate multiple random payment gateway numbers (P) corresponding to multiple payment gateways. i ); and based on the second value (g) a The merchant product (M) and the random payment gateway number (P) i Generate a payment gateway public key and based on the random payment gateway number (P) of each of the plurality of payment gateways. i Generate a random key for the payment gateway.

[0079] Clause 65. The system according to Clause 63 or 64, wherein the merchant bank is further programmed and / or configured to: generate multiple terminal numbers (t) for corresponding multiple point-of-sale (POS) terminals. i ); and based on the second value (g) a The merchant product (M), the random payment gateway number (p) i ) and the terminal number (t) i Generate a terminal public key and based on the random payment gateway number (p) i ) and the terminal number (t) of each of the plurality of POS terminals. i Generate a terminal random key.

[0080] Clause 66. The system according to any one of Clauses 63 to 65, wherein the merchant bank is further programmed and / or configured to transmit the terminal public key and the terminal random key to at least one payment gateway, wherein the at least one payment gateway includes one or more processors, and wherein the at least one payment gateway is programmed and / or configured to transmit the terminal public key to at least one POS terminal.

[0081] Clause 67. The system according to any one of Clauses 63 to 66, wherein the at least one POS terminal includes one or more processors, and wherein the at least one POS terminal is programmed and / or configured to: generate a random number (r) for a transaction message (m) associated with a transaction; generate a first ciphertext associated with the transaction, the first ciphertext comprising: (i) a first ciphertext value associated with the transaction message (m), the first ciphertext value being encrypted based on the random number (r), a generator value (g), and the transaction message (m); and ii) a second ciphertext value associated with the random number (r), the second ciphertext value being encrypted based on the random number (r) and the terminal public key; and transmit the first ciphertext to the at least one payment gateway.

[0082] Clause 68. The system according to any one of Clauses 63 to 67, wherein the at least one payment gateway is further programmed and / or configured to: re-encrypt the second ciphertext value based on the terminal random key to transform the second ciphertext value into a form based on the second value (g) a The process involves re-encrypting the merchant product (M) and the random number (r) into a second ciphertext value; and transmitting the re-encrypted second ciphertext value and the first ciphertext value to the at least one merchant bank.

[0083] Clause 69. The system according to any one of Clauses 63 to 68, wherein the at least one merchant bank is further programmed and / or configured to: base its system on the random key (rk) i The re-encrypted second ciphertext value is re-encrypted to transform the re-encrypted second ciphertext value into a form based on the second value (g). a The merchant product (M), the merchant random number (m) i The second re-encrypted second ciphertext value of the random number (r) and the first ciphertext value; and the second re-encrypted second ciphertext value and the first ciphertext value are transmitted to the payment network.

[0084] Clause 70. The system according to any one of Clauses 63 to 69, wherein the payment network is further programmed and / or configured to: based on the second re-encrypted second ciphertext value, the merchant product (M), and the merchant random number (m) i The first ciphertext value is decrypted using the first ciphertext value.

[0085] Clause 71. A computer program product comprising at least one non-transient computer-readable medium, said at least one non-transient computer-readable medium comprising program instructions that, when executed by at least one processor, cause said at least one processor to: generate a first value (a) and a second value (g) from a payment network. a ), the second value (g) a The generator is generated based on the first value (a) and the generator value (g); multiple random merchant numbers (m) of the corresponding multiple merchant banks are generated by the payment network. i The payment network is based on the multiple random merchant numbers (m) of the corresponding multiple merchant banks. i The merchant product (M) is determined by the product of the second value (g) and the payment network based on the second value (g). a The merchant product (M) and the random merchant number (m) i Generate public key (pk) i And based on the merchant product (M) and the random merchant number (m) of each corresponding merchant bank among the plurality of merchant banks.i Generate random key (rk) i ); and the public key (pk) is transferred by the payment network. i ) and the random key (rk) i The data is transmitted to at least one corresponding merchant bank.

[0086] Clause 72. The computer program product according to Clause 71, wherein the instructions further cause the at least one processor to: generate, by the merchant bank, a plurality of random payment gateway numbers (P) corresponding to a plurality of payment gateways. i ); and the merchant bank based on the second value (g) a The merchant product (M) and the random payment gateway number (P) i Generate a payment gateway public key and based on the random payment gateway number (P) of each of the plurality of payment gateways. i Generate a random key for the payment gateway.

[0087] Clause 73. The computer program product according to Clause 71 or 72, wherein the instructions further cause the at least one processor to: generate multiple terminal numbers (t) for the corresponding multiple point-of-sale (POS) terminals by the merchant bank. i ); and the merchant bank based on the second value (g) a The merchant product (M), the random payment gateway number (p) i ) and the terminal number (t) i Generate a terminal public key and based on the random payment gateway number (p) i ) and the terminal number (t) of each of the plurality of POS terminals. i Generate a terminal random key.

[0088] Clause 74. A computer program product according to any one of Clauses 71 to 73, wherein the instructions further cause the at least one processor to: transmit the terminal public key and the terminal random key to at least one payment gateway by the merchant bank; and transmit the terminal public key to at least one POS terminal by the at least one payment gateway.

[0089] Clause 75. A computer program product according to any one of Clauses 71 to 74, wherein the instructions further cause the at least one processor to: generate a random number (r) for a transaction message (m) associated with a transaction by the at least one POS terminal; generate a first ciphertext associated with the transaction by the at least one POS terminal, the first ciphertext comprising: (i) a first ciphertext value associated with the transaction message (m), the first ciphertext value being encrypted based on the random number (r), a generator value (g), and the transaction message (m); and ii) a second ciphertext value associated with the random number (r), the second ciphertext value being encrypted based on the random number (r) and the terminal public key; and transmit the first ciphertext to the at least one payment gateway by the POS terminal.

[0090] Clause 76. A computer program product pursuant to any one of Clauses 71 to 75, wherein the instructions further cause the at least one processor to: re-encrypt the second ciphertext value by the at least one payment gateway based on the terminal random key, to transform the second ciphertext value into a form based on the second value (g) a The re-encrypted second ciphertext value of the merchant product (M) and the random number (r); and the re-encrypted second ciphertext value and the first ciphertext value are transmitted to the at least one merchant bank by the at least one payment gateway.

[0091] Clause 77. A computer program product pursuant to any one of Clauses 71 to 76, wherein the instructions further cause the at least one processor: by the at least one merchant bank based on the random key (rk) i The re-encrypted second ciphertext value is re-encrypted to transform the re-encrypted second ciphertext value into a form based on the second value (g). a The merchant product (M), the merchant random number (m) i The second re-encrypted ciphertext value of the random number (r) and the first ciphertext value are transmitted to the payment network by the at least one merchant bank.

[0092] Clause 78. A computer program product pursuant to any one of Clauses 71 to 77, wherein the instructions further cause the at least one processor: by the payment network based on the second re-encrypted second ciphertext value, the merchant product (M), and the merchant random number (m) i The first ciphertext value is decrypted using the first ciphertext value.

[0093] These and other features and characteristics of the subject matter, as well as the operational methods and functions of the associated structural elements and combinations of parts, and the economics of manufacture, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form part of this specification, wherein like 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 “described” as used in this specification and claims include plural indicators. Attached Figure Description

[0094] Additional advantages and details of the disclosed subject matter are explained in more detail below with reference to exemplary embodiments illustrated in the accompanying drawings, in which:

[0095] Figure 1 The figures are diagrams of non-limiting embodiments of environments in which the systems, methods, and / or computer program products described herein can be implemented based on the principles of the subject matter of this disclosure;

[0096] Figure 2 yes Figure 1 A diagram of a non-limiting embodiment of components of one or more devices;

[0097] Figure 3 A diagram is a non-limiting embodiment or aspect of a system for PIN verification;

[0098] Figure 4 This is a diagram of an example ISO PIN block encoding scheme;

[0099] Figure 5 This is a diagram of an example PIN block encryption scheme;

[0100] Figure 6 This is a diagram of an example proxy re-encryption (PRE) honest re-encryption attack - chosen ciphertext attack (HRA-CCA) game against an Oracle database;

[0101] Figure 7 This is a diagram of an example Private Agent Authentication (PPA) - HRCCA game using an Oracle database;

[0102] Figure 8 This is an example construction diagram of the PPA scheme based on the PRE scheme;

[0103] Figure 9 This is an example construction diagram of the hybrid PRE scheme;

[0104] Figure 10 A flowchart of a non-limiting embodiment or aspect of a process for securely transmitting PINs and other sensitive data;

[0105] Figure 11A-11C A flowchart of a non-limiting embodiment or aspect of a process for securely transmitting PINs and other sensitive data;

[0106] Figure 12A and 12B This is a diagram of an example Oracle database;

[0107] Figure 13 This is a signal flow diagram of a non-limiting embodiment or aspect of the process disclosed herein;

[0108] Figure 14 This is a signal flow diagram of a non-limiting embodiment or aspect of the process disclosed herein;

[0109] Figure 15 This is a signal flow diagram of a non-limiting embodiment or aspect of the process disclosed herein;

[0110] Figure 16 This is a signal flow diagram of a non-limiting embodiment or aspect of the process disclosed herein;

[0111] Figure 17 This is a signal flow diagram illustrating a non-limiting embodiment or aspect of the process disclosed herein; and

[0112] Figure 18 This is a signal flow diagram of a non-limiting embodiment or aspect of the process disclosed herein. Detailed Implementation

[0113] For descriptive purposes, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and their derivatives are intended to refer 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 apparatus and processes shown in the drawings and described in the following specification 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.

[0114] The aspects, components, elements, structures, actions, steps, functions, instructions, etc., used herein should not be construed as critical or essential unless explicitly stated otherwise. Furthermore, as used herein, the article “a” is intended to include one or more items and is 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, combinations of related and unrelated items, etc.) and is interchangeable with “one or more” or “at least one.” Where only one item is desired, the term “a” or similar language is used. Furthermore, as used herein, the terms “having” and similar expressions 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.”

[0115] 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, or a combination thereof) 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, etc.). Furthermore, although the transmitted information may be modified, processed, relayed, and / or routed between the first and second units, the two units can also communicate with each other. 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 (e.g., a data packet, etc.) that includes data. It should be understood that many other arrangements are possible.

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

[0117] As used herein, the term "account identifier" may include one or more types of identifiers (e.g., PAN, card number, payment card number, token, etc.) associated with a user account. In some non-limiting embodiments or aspects, an issuing authority may provide a user with an account identifier (e.g., PAN, 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 an issuing authority, such that the account identifier may be a token mapped to a PAN or other type of account identifier. Account identifiers can be any combination of alphanumeric characters, symbols, and / or symbols. The issuing entity can be associated with a Bank Identification Number (BIN) that uniquely identifies the issuing entity.

[0118] 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 recoverable 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 a payment token to identify it as a payment token and to recognize the entity issuing the token.

[0119] As used herein, the term “providing” can refer to a process that enables a device to use resources or services. For example, providing may involve enabling a device to use an account to perform a transaction. Alternatively or additionally, providing may include adding provisioning data associated with account data (e.g., a payment token representing an account) to the device.

[0120] As used herein, the term "token requester" may refer to an entity attempting to implement tokenization according to embodiments or aspects of the subject matter of this disclosure. For example, a token requester may initiate a request to tokenize a PAN by submitting a token request message to a token service provider. Alternatively or concurrently, once the requester has received a payment token in response to the token request message, the token requester may no longer need to store the PAN associated with the token. In some non-limiting embodiments or aspects, the requester may be an application, apparatus, process, or system configured to perform actions associated with the token. For example, the requester may request registration with a network token system, request token generation, token activation, token deactivation, token exchange, other token lifecycle management related processes, and / or any other token-related processes. In some non-limiting embodiments or aspects, the requester may connect to the network token system via any suitable communication network and / or protocol (e.g., using HTTPS, SOAP, and / or XML interfaces, etc.). For example, token requesters may include card-on-file merchants, acquirers, acquirer processors, payment gateways operating on behalf of merchants, payment enablers (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, issuers, third-party wallet providers, payment processing networks, etc. In some non-limiting embodiments or aspects, a token requester may request tokens for multiple domains and / or channels. Alternatively, a token service provider within the tokenization ecosystem may uniquely register and identify a token requester. For example, during token requester registration, the token service provider may formally process the token requester's application to participate in the token service system. In some non-limiting embodiments or aspects, the token service provider may collect information about the nature of the requester and the associated use of the token to verify and formally approve the token requester and establish appropriate domain restriction controls. Alternatively, a token requester identifier may be assigned to a successfully registered token requester, and this token requester identifier may also be entered and maintained within a token vault. In some non-limiting embodiments or aspects, a token requester identifier may be revoked, and / or a new token requester identifier may be assigned to a token requester. In some non-limiting embodiments or aspects, this information may be reported and audited by the token service provider.

[0121] As used herein, the term "token service provider" may refer to an entity comprising one or more server computers in a token service system that generates, processes, and maintains payment tokens. For example, a token service provider may include or communicate with a token vault storing generated tokens. Alternatively, the token vault may maintain a one-to-one mapping between tokens and PANs represented by the tokens. In some non-limiting embodiments or aspects, a token service provider is able to reserve an authorized BIN as a token BIN to issue tokens that can be submitted to the token service provider for PANs. In some non-limiting embodiments or aspects, various entities in the tokenization ecosystem may assume the role of a token service provider. For example, payment networks and issuers or their agents may become token service providers by implementing token services according to non-limiting embodiments or aspects of the subject matter of this disclosure. Alternatively, a token service provider may provide reports or data outputs to reporting tools regarding approved, pending, or rejected token requests, including any assigned token requester IDs. A token service provider may provide data outputs associated with token-based transactions to reporting tools and applications, and may present tokens and / or PANs in the report outputs as needed. In some non-limiting embodiments or aspects, the EMVCo standards organization may publish specifications defining how a tokenization system can operate. For example, such specifications may be informational, but they are not intended to limit any currently disclosed subject matter.

[0122] As used herein, the term "token vault" may refer to a repository that maintains established token-to-PAN mappings. For example, a token vault may also maintain other attributes of token requesters, which may be determined at registration and / or used by the token service provider to apply domain restrictions or other controls during transaction processing. In some non-limiting embodiments or aspects, the token vault may be part of a token service system. For example, the token vault may be provided as part of a token service provider. Alternatively, the token vault may be a remote repository accessible to the token service provider. In some non-limiting embodiments or aspects, the token vault may be protected by strong underlying physical and logical security due to the sensitive nature of the data mappings stored and managed therein. Alternatively, the token vault may be operated by any suitable entity, including payment networks, issuers, clearinghouses, other financial institutions, transaction service providers, etc.

[0123] 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, "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.

[0124] As used herein, “point-of-sale (POS) device” can refer to one or more devices that a merchant can use to initiate a transaction (e.g., a payment transaction), participate in a transaction, and / or process a transaction. For example, a POS device may include one or more computers, peripheral devices, card readers, near-field communication (NFC) receivers, radio frequency identification (RFID) receivers and / or other contactless transceivers or receivers, contact-based receivers, payment terminals, computers, servers, input devices, etc.

[0125] As used herein, a “point-of-sale (POS) system” can refer to one or more computers and / or peripheral devices used by a merchant to conduct transactions. For example, a POS system may include one or more POS devices, and / or other similar devices that can be used to conduct payment transactions. A POS system (e.g., a merchant POS system) may also include one or more server computers programmed or configured to process online payment transactions via web pages, mobile applications, etc.

[0126] 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, the transaction service provider may include credit card companies, debit card companies, etc. As used herein, the term "transaction service provider system" may 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.

[0127] As used herein, the term "acquiring party" can refer to an entity licensed and approved by a transaction service provider to initiate transactions (e.g., payment transactions) using a portable financial device 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 by the acquiring party can include payment transactions (e.g., purchases, Original Credit Transactions (OCT), Account Funds Transactions (AFT), etc.). In some non-limiting embodiments 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 device. The acquiring party may contract with payment service providers to enable them to sponsor merchants. The acquiring party may monitor the compliance of payment service providers in accordance with transaction service provider regulations. The acquiring party may conduct due diligence on payment service providers and ensure appropriate due diligence is performed before contracting with sponsored merchants. The acquiring party may be responsible for all transaction service provider programs operated or sponsored by the acquiring party. The acquiring party may be responsible for the actions of its payment service provider, merchants sponsored by the payment service provider, etc. In some non-limiting embodiments or aspects, the acquiring party may be a financial institution, such as a bank.

[0128] As used herein, the terms “e-wallet,” “e-wallet mobile application,” and “digital wallet” can refer to one or more electronic devices and / or one or more software applications configured to initiate and / or conduct transactions (e.g., payment transactions, electronic payment transactions, etc.). For example, an e-wallet may include an application and server-side software and / or database executed by a user device (e.g., a mobile device) for maintaining and providing transaction data to the user device. As used herein, the term “e-wallet provider” can include an entity that provides and / or maintains e-wallets and / or e-wallet mobile applications for users (e.g., customers). Examples of e-wallet providers include, but are not limited to, Google. Android Apple and Samsung In some non-limiting examples, a financial institution (e.g., an issuing institution) may be an e-wallet provider. As used herein, the term "e-wallet provider system" may refer to one or more computer systems, computer devices, servers, server groups, etc., operated by or on behalf of an e-wallet provider.

[0129] As used herein, the term "portable financial device" can refer to payment cards (e.g., credit or debit cards), gift cards, smart cards, smart media, payroll cards, healthcare cards, wristbands, machine-readable media containing account information, keychain devices or pendants, RFID transponders, retailer discount or membership cards, cellular phones, e-wallet mobile applications, personal digital assistants (PDAs), pagers, security cards, computers, access cards, wireless terminals, transponders, etc. In some non-limiting embodiments or aspects, a portable financial device may include volatile or non-volatile memory to store information (e.g., account identifiers, account holder's name, etc.).

[0130] As used herein, the term "payment gateway" can refer to an entity and / or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, payment service provider, payment servicer, payment servicer contracted with an acquirer, payment aggregator, etc.) that provides payment services (e.g., transaction service provider payment services, payment processing services, etc.) to one or more merchants. Payment services may be associated with the use of portable financial devices managed by a transaction service provider. As used herein, the term "payment gateway system" can refer to one or more computer systems, computer devices, servers, server clusters, etc., operated by or on behalf of a payment gateway, and / or the payment gateway itself. The term "payment gateway mobile application" can refer to one or more electronic devices and / or one or more software applications configured to provide payment services for transactions (e.g., payment transactions, electronic payment transactions, etc.).

[0131] As used herein, the terms "client" and "client device" can refer to one or more client-side devices or systems (e.g., at a remote location of a 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, 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 a transaction with a transaction service provider).

[0132] As used herein, the term "server" may refer to one or more computing devices (e.g., processors, storage devices, similar computer components, etc.) that communicate with client devices and / or other computing devices via a network (e.g., a public network, the Internet, a private network, etc.) and, in some examples, facilitate communication between other servers and / or client devices. It should be understood that various other arrangements are possible. As used herein, the term "system" may refer to one or more computing devices or a combination of computing devices (e.g., processors, servers, client devices, software applications, components of these computing devices, etc.). References to "device," "server," "processor," etc., as used herein may refer to a previously stated device, server, or processor, a different server or processor, and / or a combination of servers and / or processors, stated to perform a prior step or function. For example, as used in the specification and claims, a first server or first processor stated to perform a first step or a first function may refer to the same or different server or the same or different processor stated to perform a second step or a second function.

[0133] For illustrative purposes, while the subject matter of this disclosure relates to methods, systems, and computer program products for securely transmitting sensitive data (e.g., PIN authentication), those skilled in the art will recognize that the disclosed subject matter is not limited to the illustrative embodiments. For example, the methods, systems, and computer program products described herein can be used with a variety of settings, such as in any suitable setup, to securely transmit sensitive data (e.g., Social Security numbers, personally identifiable information, contact information, healthcare information, tax information, confidential information, privileged information, trade secret information, payment transaction information, account identifiers, etc.).

[0134] Non-limiting embodiments or aspects provide improved methods for PIN authentication based on proxy re-encryption, which avoid the use of the HSM by intermediaries during transaction processing. The reasons why simpler mechanisms based on public-key encryption (direct from the terminal to the consumer bank) cannot be used for this setup will be discussed in detail in the section titled "Strawman Solution." Instead of using the HMS during transaction processing, it is used only for the main ceremony during the initial setup phase. The HSM is not used during transaction processing, but only for the key ceremony during the initial setup phase. After the key ceremony, the initial public key and subsequent re-encryption keys can be used without requiring trusted hardware. Since PIN conversion is the only operation requiring the use of the HSM at the payment gateway and merchant bank, the infrastructure and compliance costs associated with using and relying on the HSM are reduced (although payment networks and consumer banks may use the HSM for other functions such as PIN / CVV verification).

[0135] Deployment and upgrades are both time-consuming and expensive. For example, it took nearly a decade to deploy an EMV system in the United States. Due to the large number of participants in the payments ecosystem, there is a vast space for designing potential solutions, and several straw man solutions may be identified but abandoned due to limitations such as deployment challenges or significant costs (e.g., reissuing cards to consumers). Non-limiting embodiments or aspects can be deployed according to existing EMV standards as described in EMVco's "EMV Integrated Circuit Card Specification for Payment Systems, Book 2 – Security and Key Management Version 4.3" (August 2011) [online]. Available at https: / / www.emvco.com / wpontent / uploads / 2017 / 05 / EMV_v4.3_Book_2_Security_and_Key_Management_20120607061923900.pdf, the contents of which are incorporated herein by reference in their entirety, without requiring the issuance of new cards to customers or significant changes to intermediaries. The key management process, including key ceremonies between intermediaries, is backward compatible with existing PCI-compatible processes. Furthermore, while threat models are well-known within the payments industry, they have not yet been formally simulated mathematically. Therefore, this paper provides a formal description of the participants, threat models, and security objectives of PIN authentication within a framework of provably secure security.

[0136] Because PINs play a crucial role in authenticating payment transactions, they are an explicit target for attackers. Several attacks have been proposed on the PIN processing API, allowing attackers (within consumer banks or intermediaries with access to the HSM) to obtain customer PINs. Others have proposed using a fix known as "salted PIN" to prevent these attacks, but this requires significant changes to the payment infrastructure. Other existing approaches focus on how to perform formal analysis of the HSM API for PIN verification and conversion to check for vulnerabilities.

[0137] Several solutions exist that avoid the need for PIN conversion and help reduce reliance on intermediaries. However, these solutions, very similar to the Scarecrow solution described in more detail here, require significant changes to the payment card or payment terminal.

[0138] Since its introduction, a significant body of work has formally defined the various security properties of proxy re-encryption (PRE) and the corresponding constructs for implementing these properties. The initial concept of PRE security considered only chosen-plaintext attack (CPA) attacks. Later, the concept of chosen-ciphertext attack (CCA) was considered in both one-way and two-way settings. The shortcomings of the CPA-based model have been pointed out, and a PRE security concept based on honest re-encryption attack (HRA) has been proposed.

[0139] Non-limiting embodiments or aspects of this disclosure provide (i) a Private Agent Authentication (PPA) scheme and security definition that accurately captures the participants, threat models, and security objectives of PIN-based payments; (ii) a PPA scheme that can be generally constructed according to any PRE scheme; (iii) a modified key management scheme that uses the same key ceremony to ensure backward compatibility (secure key management is crucial for managing payment compliance, and currently, in the payment ecosystem, keys are provided between neighboring parties using key ceremonies); (iv) a new PRE construct that follows a hybrid encryption paradigm of key encapsulation mechanism—a proxy key re-encapsulation mechanism (KEM-DEM), where the data encapsulation mechanism (DEM) is backward compatible with existing PIN block encryption processes, ensuring minimal deployment friction; and (v) latency roughly equivalent to an HSM, while throughput is more than 5 times that of a single HSM.

[0140] Non-limiting embodiments or aspects provide an improved method for transmitting messages (e.g., PIN authentication, etc.) based on re-encryption, the method using a combination of a public key and a random key used by intermediaries in the network. Therefore, computational resources can be conserved (e.g., the use of such computational resources can be reduced, etc.) because it is not necessary to generate one or more secret keys for each intermediary. Furthermore, since each intermediary does not need to protect its own secret key, the amount of risky secret keys exposed to attackers is reduced, thus improving security. Moreover, since each intermediary's public key and random key may be at least partially based on the public key and / or random key of at least one other intermediary and / or entity in the network, the re-encryption of ciphertext can be achieved based on known operations (e.g., mathematical operations, etc.) without decryption of the ciphertext.

[0141] Now for reference Figure 1 , Figure 1 This is a diagram of a non-limiting embodiment of an environment 100 where the systems, products, and / or methods described herein can be implemented. Figure 1 As shown, environment 100 includes transaction service provider system 102, issuer system 104, customer device 106, merchant system 108, acquirer system 110, and network 112.

[0142] Transaction service provider system 102 may include one or more devices capable of receiving and / or transmitting information to issuer system 104, client device 106, merchant system 108, and / or acquirer system 110 via network 112. For example, transaction service provider system 102 may include computing devices, such as servers (e.g., transaction processing servers), server clusters, and / or other similar devices. In some non-limiting embodiments or aspects, transaction service provider system 102 may be associated with the transaction service provider described herein. In some non-limiting embodiments or aspects, transaction service provider system 102 may communicate with a data storage device, which may be local or remote to transaction service provider system 102. In some non-limiting embodiments or aspects, transaction service provider system 102 is capable of receiving information from the data storage device, storing information in the data storage device, transmitting information to the data storage device, or searching for information stored in the data storage device.

[0143] Issuer system 104 may include one or more devices capable of receiving and / or transmitting information to transaction service provider system 102, customer device 106, merchant system 108, and / or acquiring system 110 via network 112. For example, issuer system 104 may include computing devices, such as servers, server clusters, and / or other similar devices. In some non-limiting embodiments or aspects, issuer system 104 may be associated with the issuer institution described herein. For example, issuer system 104 may be associated with an issuer institution that issues credit accounts, debit accounts, credit cards, debit cards, etc., to users associated with customer device 106.

[0144] Client device 106 may include one or more devices capable of receiving and / or transmitting information to transaction service provider system 102, issuer system 104, merchant system 108, and / or acquirer system 110 via network 112. Alternatively, each client device 106 may include devices capable of receiving and / or transmitting information to other client devices 106 via network 112, another network (e.g., temporary network, local network, private network, virtual private network, etc.), and / or any other suitable communication technology. For example, client device 106 may include client devices, etc. In some non-limiting embodiments or aspects, client device 106 may or may not be able to receive information via short-range wireless communication connections (e.g., NFC communication connections, RFID communication connections, etc.). Communication connection Receive information via communication connections (e.g., from merchant system 108 or from another client device 106), and / or transmit information via short-range wireless communication connections (e.g., to merchant system 108).

[0145] Merchant system 108 may include one or more devices capable of receiving and / or transmitting information to transaction service provider system 102, issuer system 104, customer device 106, and / or acquirer system 110 via network 112. Merchant system 108 may also include communication connections with customer device 106 via network 112 (e.g., NFC communication connection, RFID communication connection, etc.). Communication connection The merchant system 108 may include devices that receive information from the client device 106 via a network, communication connection, etc., and / or transmit information to the client device 106 via a network, communication connection, etc. In some non-limiting embodiments or aspects, the merchant system 108 may include computing devices, such as servers, server groups, client devices, client device groups, and / or other similar devices. In some non-limiting embodiments or aspects, the merchant system 108 may be associated with the merchant described herein. In some non-limiting embodiments or aspects, the merchant system 108 may include one or more client devices. For example, the merchant system 108 may include client devices that allow the merchant to transmit information to the transaction service provider system 102. In some non-limiting embodiments or aspects, the merchant system 108 may include one or more devices, such as computers, computer systems, and / or peripheral devices, that the merchant can use to conduct payment transactions with users. For example, the merchant system 108 may include POS devices and / or POS systems.

[0146] Acquiring system 110 may include one or more devices capable of receiving and / or transmitting information to transaction service provider system 102, issuer system 104, client device 106, and / or merchant system 108 via network 112. For example, acquiring system 110 may include computing devices, servers, server clusters, etc. In some non-limiting embodiments or aspects, acquiring system 110 may be associated with the acquiring party described herein.

[0147] Network 112 may include one or more wired and / or wireless networks. For example, network 112 may include cellular networks (e.g., Long Term Evolution (LTE) networks, third-generation (3G) networks, fourth-generation (4G) 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)), Private Networks (e.g., Private Networks Associated with Transaction Service Providers), Temporary Networks, Intranets, the Internet, Fiber-based Networks, Cloud Computing Networks, etc., and / or combinations of these or other types of networks.

[0148] Provided as an example Figure 1The number and arrangement of systems, devices, and / or networks are shown. Additional systems, devices, and / or networks, fewer systems, devices, and / or networks, different systems, devices, and / or networks may exist, and / or may be combined with... Figure 1 The systems, devices, and / or networks shown are arranged in different ways. Furthermore, implementation can be carried out within a single system and / or device. Figure 1 Two or more systems or devices shown in the document, or Figure 1 The single system or device shown may be implemented as multiple distributed systems or devices. 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 devices of environment 100.

[0149] Now for reference Figure 2 , Figure 2 This is a diagram illustrating example components of device 200. Device 200 may correspond to one or more devices of transaction service provider system 102, one or more devices of issuer system 104, customer device 106, one or more devices of merchant system 108, and / or one or more devices of acquirer system 110. In some non-limiting embodiments or aspects, transaction service provider system 102, issuer system 104, customer device 106, merchant system 108, and / or acquirer system 110 may include at least one device 200 and / or at least one component of device 200. Figure 2 As shown, device 200 may include bus 202, processor 204, memory 206, storage component 208, input component 210, output component 212, and communication interface 214.

[0150] Bus 202 may include components that enable communication between components of device 200. In some non-limiting embodiments or aspects, processor 204 may be implemented in hardware, software, or a combination of hardware and software. 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 component 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.

[0151] Storage component 208 may store information and / or software associated with 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.

[0152] Input component 210 may include components that allow device 200 to receive information, such as via user input (e.g., touchscreen display, keyboard, keypad, mouse, button, switch, microphone, camera, etc.). Alternatively, input component 210 may include sensors for sensing information (e.g., Global Positioning System (GPS) component, accelerometer, gyroscope, actuator, etc.). Output component 212 may include components that provide output information from device 200 (e.g., display, speaker, one or more light-emitting diodes (LEDs), etc.).

[0153] 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, etc. interface, interface, Interfaces, cellular network interfaces, etc.

[0154] Apparatus 200 can perform one or more processes described herein. Apparatus 200 can perform these processes based on software instructions stored in a computer-readable medium, such as memory 206 and / or storage component 208, executed by processor 204. Computer-readable medium (e.g., non-transient computer-readable medium) is defined herein as a non-transient memory device. A non-transient memory device includes memory space located within a single physical storage device or memory space distributed across multiple physical storage devices.

[0155] Software instructions may be read from another computer-readable medium or from another device into memory 206 and / or storage component 208 via communication interface 214. When executed, the software instructions stored in memory 206 and / or storage component 208 may cause processor 204 to perform one or more processes described herein. Alternatively or additionally, hard-wired circuitry may 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.

[0156] Provided as an example Figure 2 The number and arrangement of components are shown. In some non-limiting embodiments or aspects, with Figure 2 Compared to those shown, device 200 may include additional components, fewer components, different components, or components arranged in a different manner. Alternatively, a set of components of device 200 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 200.

[0157] Overview of PIN-based payments

[0158] Traditionally, PIN-based verification was reserved for use at ATMs, but with the adoption of EMV (also known as chip and PIN), PIN-based verification is now widely used for authentication of ATM and point-of-sale (POS) transactions. When a consumer enters a PIN on a POS device, PIN verification is performed in one of two ways: offline or online. If PIN verification occurs offline, the only parties involved are the POS device and the chip card. The PIN entered by the consumer is sent directly from the PIN pad to the chip card, where it is authenticated. In contrast, online PIN verification involves sending the PIN back to the consumer's bank that issued the card for verification. In countries with mature payment infrastructure (such as the United States), almost all PIN verifications are conducted online. Offline PIN verification has not yet been adopted in the United States due to the additional complexity involved in synchronizing the offline PIN held on the chip with the back-end PIN used for online verification.

[0159] Now for reference Figure 3 , Figure 3 This is a diagram of a non-limiting embodiment of a system 300 for PIN verification. (See diagram for reference.) Figure 3As shown, system 300 includes a POS device 302, a POS terminal / partner 304, a payment gateway 306, a merchant bank 308 (e.g., an acquiring system), a payment network 310 (e.g., a transaction service provider system), and a consumer bank 312 (e.g., an issuer system). In online verification, after a PIN is entered on the POS device 302, the PIN passes through multiple intermediaries before reaching the appropriate consumer bank 312 (e.g., the POS terminal / partner 304, payment gateway 306, merchant bank 308, and payment network 310). Merchants use POS partners and payment gateways to accept payments from cardholders worldwide. POS partner 304 enables merchants to manage heterogeneous POS terminals manufactured by numerous vendors. Payment gateway 306 enables merchants to accept payments from cardholders by contacting merchant bank 308. Merchant bank 308 enables merchants to accept various card types by contacting the appropriate payment network 310 (e.g., Visa). Payment network 310 performs authorization by contacting consumer banks 312, which perform the final verification of the transaction.

[0160] Because PINs are sensitive, confidentiality must be ensured when they reach consumer bank 312 through these intermediaries. Unsurprisingly, PCI regulations stipulate that PINs should never be disclosed to any intermediary. It could be assumed that POS terminal 304 encrypts the PIN using a key shared with consumer bank 312. However, since POS partner 304 has no direct relationship with consumer bank 312, it is impossible to establish such a key. Therefore, each adjacent participant must establish a shared key separately (e.g., POS partner 304 shares a key with payment gateway 306, which in turn shares a different key with merchant bank 308, which in turn shares a different key with payment network 310, which in turn shares a different key with consumer bank 312).

[0161] Another requirement of the PCI is that the PIN can only be explicitly present within the secure hardware. This means that each intermediary needs to deploy an HSM (Hardware Management System) to handle the PIN as it traverses the network. The key is generated internally within the HSM and shared with neighboring parties during a key ceremony, as described in more detail in the section titled "Key Management in Practice," ensuring dual control and split knowledge. However, such ceremonies are generally time-consuming and require a rigorous process. Subsequently, as the encrypted PIN passes through the intermediary, it is sent to the intermediary's HSM for decryption and re-encryption based on the shared key for the next hop. For example, in the first hop (POS device 302 to POS partner 304), the PCI requires the use of a unique key for each transaction (e.g., using the DUKPT (Derived Unique Key Per Transaction) method). After this first hop, most subsequent hops use static keys.

[0162] An encrypted PIN block (EPB) is constructed by first encoding the PIN and then encrypting the encoded block. PIN block encoding can be performed in several ways as defined in the ISO 9654-1 standard. For example, the ISO 9654-1 standard defines five different formats, referred to as ISO formats 0, 1, 2, 3, and 4. Non-limiting embodiments or aspects are described primarily with respect to formats 0 and 3, but are not limited thereto, and any ISO format can be used. ISO format 4 is more recently defined but has not yet been widely deployed. Formats 0 and 3 take the PIN and card number (PAN) as input and output an encoded block. The main difference between these two formats is that format 0 uses fixed padding, while format 3 uses random padding. Figure 4 A more detailed description of ISO PIN block encoding scheme 400 is shown.

[0163] After encoding, the PIN block is encrypted using a block cipher to obtain, as shown below. Figure 5 The final EPB 500 is shown. Formats 0 and 3 both output 64-bit blocks, which can be encrypted using 3DES. 3DES is the primary block cipher used in the financial industry to overcome the difficulties of migrating large amounts of legacy hardware to the new method. ISO Format 4 defines 128-bit encoded blocks, which can alternatively be encrypted using AES. As mentioned earlier, this has not yet been widely deployed.

[0164] Scarecrow Solution

[0165] Traditional scarecrow-based public-key cryptography solutions fail to achieve seamless deployment. For the sake of brevity, this article discusses only a few prominent scarecrow solutions to highlight the significant deployment overhead they incur.

[0166] In practice, one way to achieve PIN confidentiality is to encrypt the PIN against the public key of the consumer bank 312. All parties involved in a PIN-based transaction simply forward the encrypted PIN to the consumer bank 312. The consumer bank 312 decrypts the PIN using the associated secret key and verifies the PIN to perform authorization. To implement this paradigm, the POS device 302 must have reliable access to a database of PANs and the corresponding consumer bank public keys. Storing this database in the POS device 302 is not optimal because it incurs significant deployment overhead. For example, there are currently 46 million merchants accepting Visa cards. However, the POS device 302 queries a remotely hosted database server managed by the payment network to obtain the consumer bank's public key and encrypts the PIN against it. This additional remote call increases transaction latency and requires various intermediaries to deploy new changes. For example, POS partner 304, payment gateway 306, merchant bank 308, and payment network 310 all need to deploy new changes. Furthermore, the mapping of PAN numbers to corresponding consumer bank public keys is commercially sensitive for payment network 310, which could become an obstacle to successful deployment.

[0167] An alternative to POS device 302 is to read the consumer bank's public key from the chip card during the transaction. Consumer bank 312 now provides the chip card with a public key and a public / private key pair to support offline data authentication and offline PIN verification. Offline PIN verification is discouraged, and consumer banks no longer support this mode in the United States. Offline data authentication is currently deployed to support transit payments, improving latency by performing offline authorization. In this mode, the card proves its authenticity by signing a challenge randomly selected by POS device 302 during the transaction. The card returns a digital signature, a certificate containing the card's public key, and a certificate containing the consumer bank's public key to POS device 302. POS device 302 verifies the certificate chain and the digital signature to proceed with the payment. To ensure PIN privacy, POS device 302 can encrypt the PIN against the consumer bank's public key obtained during the card authentication process. However, this method is not backward compatible and incurs significant deployment overhead. Since all chip cards used do not have a consumer bank's public key due to the optional nature of offline data authentication, cards need to be reissued. Furthermore, it increases the cost of providing chip cards. This approach is not backward compatible because not all U.S. merchants support chip cards. For example, gas stations in the U.S. do not yet support chip cards. Reissuing magnetic stripe cards is not an option because magnetic stripe cards are not designed to store additional public key material.

[0168] Another alternative is to encrypt the PIN against the payment network's public key. This seemingly simple solution is not deployable for several reasons. First, it merely eliminates the burden of dependence on the HSM for all intermediaries outside the payment network. Second, merchants lose the routing flexibility of PIN-based transactions. Today, merchants dynamically route PIN-based transactions via their preferred network to minimize processing costs. Therefore, this seemingly natural straw man solution has brought about significant changes to the payments ecosystem.

[0169] Proxy re-encryption

[0170] The Proxy Re-encryption (PRE) scheme is a public-key encryption (PKE) scheme enhanced through re-encryption operations. PRE allows parties holding the re-encryption key to convert ciphertext encrypted with user A's public key into ciphertext encrypted with a different user B's public key. The bidirectional PRE scheme allows re-encryption of the key rk. A→BFor re-encryption in either direction (e.g., from A to B, or from B to A), as described in the following literature: M. Blaze, G. Bleumer, and M. Strauss, “Divertible protocols and atomic proxy cryptography”, presented at “Advances in Cryptography – EUROCRYPT’98”, Proceedings of the International Conference on Cryptography Theory and Applications, Espoo, Finland, May 31–June 4, 1998, Computer Science Lecture Series, edited by K. Nyberg, Vol. 1403, Springer, 1998, pp. 127–144. [Online]. Available at https: / / doi.org / 10.1007 / BFb0054122 (hereinafter referred to as Blaze et al.), the entire contents of which are incorporated herein by reference in full. In contrast, the re-encryption key generated by a one-way PRE scheme can only be used for re-encryption in one direction (e.g., from A to B but not from B to A), as described in the following literature: G. Ateniese, K. Fu, M. Green, and S. Hohenberger, “Improved proxy re-encryption schemes with applications to secure distributed storage,” ACM Trans, Information Systems Security, Vol. 9, No. 1, pp. 1-30, 2006. [Online]. Available at https: / / doi.org / 10.1145 / 1127345.1127346 (hereinafter referred to as Ateniese et al.), the entire contents of which are incorporated herein by reference in full.

[0171] Some PRE schemes limit the number of re-encryption operations allowed. Schemes that allow only one re-encryption are called single-hop schemes, such as the one proposed by Ateniese et al. Multi-hop PRE schemes are described, for example, in Blaze et al., “Chosen-ciphertext secure proxy re-encryption,” presented in the proceedings of the 2007 ACM Conference on Computer and Communications Security, CCS2007, Alexandria, VA, October 28–31, 2007, edited by P. Ning, SDCdi Vimercati, and PFSyverson, ACM, 2007, pp. 185–194. [Online]. Available at https: / / doi.org / 10.1145 / 1315245.1315269 (hereinafter referred to as Canetti et al.), the contents of which are incorporated herein by reference in full, without limiting the number of re-encryption operations.

[0172] Public-key cryptography schemes include a set of algorithms (Settings, KG, E, D) with the following interfaces:

[0173] Settings (1) λ →pp: Settings related to the input security parameter λ and the output common parameter PP.

[0174] KG(pp)→(pk,sk): Key generation, returns the public key and secret key pair (pk,sk).

[0175] E(pk,m)→c: Encryption, taking the public key and message as input, and outputting the ciphertext.

[0176] D(sk,c)→m or: Decryption, taking the input secret key and ciphertext as input, and outputting a plaintext message or error symbol.

[0177] A PRE scheme can be defined as a public-key encryption scheme type. A PRE scheme satisfies the correctness properties of both PRE schemes and re-encryption. A PRE scheme is a public-key encryption scheme with Update Key Generation (RKG) and Re-encryption (RE) functionality. Re-encryption has the following interface:

[0178] RE(rk i→j ,c)→c′ or: Regarding the input re-encryption key rk i→j The ciphertext c is converted to ciphertext c′ or an error symbol by the RE output.

[0179] In addition, the bidirectional PRE scheme exposes the following update key generation interface:

[0180] RKG(ski ,pk i ,sk j ,pk j )→rk i→j Regarding the input source key pair (sk) i ,pk i ) and target key pair (sk j ,pk j RKG outputs the re-encryption key rk i→j .

[0181] In the one-way scheme, RKG no longer transmits the target secret key sk. j As input.

[0182] Since the PRE scheme is an extension of the PKE scheme, it is as correct as the PKE scheme. The correctness of PKE can be defined as follows:

[0183] For all possible (pk, sk) generated by KG(pp), for all m, where the probability is one, the following must hold:

[0184] c = E(pk,m)

[0185] m = D(sk,c).

[0186] If the PRE scheme is as correct as the PKE scheme, then the PRE scheme is l-hop correct, and for all possible (pk) i ,sk i ), where 1≤i≤l+1, for all rk i→i+1 For all m, where 1≤i≤l, and the probability is one, the following holds:

[0187] c1 = E(pk1,m)

[0188] c i+1 =RE(rk) i→i+1 ,c i ), where 1≤i≤l

[0189] m=D(sk l+1 ,c l+1 ).

[0190] If a PRE scheme is l-hop correct, where all l ≥ 1, then a PRE scheme is multi-hop correct.

[0191] The security game has two phases: setup and attack. The setup phase generates key pairs for all participants and divides them into honest and fraudulent groups. The attack phase allows adversaries to access the PRE scheme and challenge the Oracle database.

[0192] Before giving a security definition, this paper introduces the concept of deduced ciphertext, which is used to avoid gaining negligible victories in security experiments. The definition of deduced ciphertext according to a non-limiting embodiment or aspect differs from that of Canetti et al. in that it is explicitly for the case where re-encrypting an Oracle database is deterministic.

[0193] The derivation of the ciphertext can be defined as follows:

[0194] Let O RE (i,j,c) and O RKG (i,j) represents the Oracle database generated by re-encrypting and updating the keys exposed to the adversary in the PRE scheme. The ciphertext tuple (i,c) is another ciphertext tuple (i...j) if one of the following is true. * ,c * The derivative of )

[0195] 1)(i,c)=(i * ,c * (Self-derived or reflection-derived)

[0196] 2) If (i,c) is the derivative of (i′,c′), where (i′,c′) is the derivative of (i′,c′), then (i′,c′) is the derivative of (i′,c′). * ,c * The derivative of ) (transitive derivation)

[0197] 3) If c = 0 RE (i*,i,c*) (Oracle database derivation), or

[0198] 4) If the opponent queries O RKG (i * ,i) to obtain from i * The re-encryption key to i, rk i*→i And c = RE(rk) i*→i ,c * (External derivation).

[0199] Two update key generation methods can be defined for the Oracle database: one for a one-way scheme and the other for a two-way scheme. In a one-way scheme, the Oracle database will not allow update key generation if an adversary attempts to generate a key from the honest party to the fraudulent party. However, in a two-way scheme (rk),... i→j equals rk j→i Therefore, for these schemes, inquiries are only allowed if both parties are honest or both parties are fraudulent.

[0200] The PRE HRA-CCA security definition is as follows:

[0201] Let λ be a security parameter, A be the adversary, and PRE = (Settings, KG, E, D, RKG, RE) be the PRE scheme. The honest re-encryption attack security game is conducted in two phases:

[0202] Setup: Run PRE.Setup and provide the generated public parameters to A. Let n represent the total number of keys determined by A. Generate n key pairs (pk i ,sk i PRE.KG is used to partition the key pair indices into sets H and C, representing honest users and fraudulent users respectively. For all i∈H, the opponent pk is derived. i And for all i∈C, the opponent (pk) is obtained. i ,sk i ).

[0203] Attack: For all i (j≤n, i≠j), use PRE.RKG to compute the re-encryption key rk. i→j Let D* represent the query from Oracle database O. Chall The output derivation of the ciphertext set; obtained before challenging the Oracle database. Similarly, let D denote the set of ciphertexts derived from the output of any encrypted Oracle database. For example... Figure 6 As shown, opponent A has access to Oracle database 600. At the end of the attack phase, the opponent outputs a guess b′, and if b′ = b, they win.

[0204] The scheme PRE is (t,∈)-safe, provided that for all adversaries A running at time t, |P[b′=b]–1 / 2|≤∈ holds.

[0205] Private Proxy Authentication

[0206] The Private Agent Authentication (PPA) scheme is used to securely transmit authentication data from the sender to the receiver via a set of agents. In the case of payments, the authentication data is the cardholder's PIN and related information. The sender is the cardholder / POS terminal 304, which transmits the encrypted data to a series of intermediaries (e.g., agents) across the payment network (e.g., payment gateway 304, merchant bank 308, etc.), and the final receiver is the cardholder's consumer bank 312.

[0207] The PPA scheme comprises six algorithms (Setup, KG, Send, Verify [A; ak], Register, Relay). The Setup function initializes the scheme's parameters. Key management is performed through the KG and Register functions. The KG function is run by each participant to generate key pairs. Register is used to generate update keys from one party to another.

[0208] Each agent maintains a set of updated keys shared by the agent and each of its neighbors. Key management is described in more detail in the section titled "General PPA Construction". The sender and agent run send and relay functions, respectively, to generate ciphertext for the next hop in the routed payment transaction. The receiver uses a verification function to check if the packet (a, c) is authentic. This function performs this check using a basic plaintext authentication prediction A. The prediction takes the associated data a, the plaintext message m, and the secret authentication key ak as input and outputs 0 or 1 depending on whether authentication is successful. In the payment, setting A defines the basic PIN verification method (e.g., IBM 3624). The formal definition of the PPA scheme and its related correctness are shown below.

[0209] The PPA scheme for the message space M, associated data space D, and basic authentication prediction A is a tuple of algorithm PPA[A] = (set, KG, send, verify [A; ak], register, relay), and can be defined as follows:

[0210] Settings (1) λ →pp: Settings related to the input security parameter λ and the output common parameter PP.

[0211] KG(pp)→(pk,sk): Key generation, returns the public key and secret key pair (pk,sk).

[0212] Send (pk,a,m)→c: Sends the input public key pk, associated data a, and message m, and outputs ciphertext c.

[0213] Verify [A; ak](sk, a, c) → 0 / 1 OR: Verify with respect to the input secret key sk, associated data a, and ciphertext c, outputting a bit of 0 or 1, or an error symbol.

[0214] Register ((pk) i ,sk i ),pk j )→rk i→j One-way registration, transferring the source key (pk) i ;sk i ) and target public key pk i As input, and output update key rk i→j .

[0215] Register ((pk) i ,sk i ),(pk j ,sk j ))→rk i→j Two-way registration, transferring the source key (pk) i ,sk i ) and target public key (pk j ,skj The input is the update key rk, and the output is the update key rk. i→j .

[0216] Relay (R,a,c)→c′: Relay takes associated data a, ciphertext c, and update key set R as input, and outputs the transformed ciphertext c′ or error symbol.

[0217] If the following properties are true, then the PPA is a correct prediction of the 1-hop for the message space M, the associated data space D, and the underlying plaintext authentication:

[0218] 1) Authentication correctness: For all (pk,sk) generated by PPA.KG and for all ak, a,m, where A(ak,a,m)=b, then the following holds:

[0219] PPA.Verify[A;ak](sk,PPA.Send(pk,a,m))=b;

[0220] 2) Correctness of the relay's l-hop point: For all possible (pk) i ,sk i ), where 1≤i≤l+1, for all R i For all ak, a, m, where 1 ≤ i ≤ l, and A(ak, a, m) = b, then the following holds:

[0221] c1 = PPA.Send(pk1, a, m)

[0222] c i+1 =PPA.Relay(a,c i ,R i ), where 1≤i≤l

[0223] b = PPA.Verify[A; ak](sk l+1 ,a,c l+1 ).

[0224] If a PPA scheme is l-hop correct, where all l ≥ 1, then the PPA scheme is multi-hop correct.

[0225] The primary objective of the PPA scheme is to perform authentication based on a confidential prediction A. In practice, attacks against the PPA scheme are either carried out by directly injecting plaintext (e.g., through a payment terminal) or by injecting encrypted messages into the network. In the case of authentication, due to the limited message space of the PIN (10... 4An attacker's optimal strategy is simple and brute force: sequentially entering each PIN at POS device 302. A mitigation measure for this situation is to limit the number of allowed retries. Non-limiting embodiments or aspects are intended to determine whether a PPA scheme can maintain confidentiality in the presence of a powerful attacker.

[0226] The concept of confidentiality can be defined as follows. In the security experiment, all public keys are provided to the adversary, not just those associated with the initial sender (e.g., POS terminal / partner 304). Now any participant can potentially become the sender. This makes the model more general than a standard payment setup, where only the initial sender's (e.g., POS terminal 304) public key is used for encryption, and all other key pairs are only related to generating the update key. This choice results in a more robust security model, and therefore better security guarantees. The security definition also relies on the concept of deduced ciphertext, which can be easily extended from the concept defined for the PRE setup of deduced ciphertext described in this paper.

[0227] Now for reference Figure 7 The diagram illustrates a PPA-HRCCA game on an Oracle database 700. For PPA security against selected ciphertext attacks, let λ be a security parameter, A be the adversary, and PPA[A] = (Setup, KG, Send, Verify [A; ak], Register, Relay) be a PPA scheme with a base authentication prediction A. The security game is conducted in two phases, as shown below:

[0228] Setup: Run PPA.Setup(1) λ The generated public parameters are then provided to A. n represents the total number of keys determined by the adversary. n new key pairs (pk) are generated. i ,sk i ←PPA.KG, partitions the key pair exponents between sets H and C (honesty and fraud, respectively), and for i∈H, derives the opponent's pk. i And for all i∈C, the opponent (pk) is obtained. i ,sk i ).

[0229] Attack: For all i, where j≤n, i≠j, use PPA.Enroll to compute the update key rk. i→j And for each participant R i ={rk i→j :j} populates and updates the key set. Allows A to access the following Oracle databases:

[0230] register:

[0231]

[0232]

[0233] Inquiry (one-time), O Chall (pk i Given a, m0, m1), if i ∈ H, output the corresponding position; otherwise, randomly assign positions. Sampling, returning encrypted consultation text c* = PPA.Send(pk i ,a,m b ).

[0234] Relay, ORelay(pk) i If i∈H, a specifies j∈C and (pk) j If (a, c) is the derivative of the query, then return; otherwise, return PPA.Relay(R). i ,a,c)

[0235] Verification, OVerify(pk) j If (pk) j If (a, c) is the derivative of the query, then return; otherwise, return PPA.Verify[A, ak](sk). j ,a,c)

[0236] At the end of the questioning phase, opponent A outputs a guess b′, and if b′ = b, then they win.

[0237] The scheme PPA is (t, ∈)-safe, provided that for all adversaries A running at time t, |P[b′=b]–1 / 2|≤∈ holds.

[0238] General PPA Construction

[0239] PPA Solution PPA A =(Setup, KG, Register, Send, Authenticate, Relay) can be constructed from any multi-hop PRE scheme. Besides the PRE=(Setup, KG, RKG, E, D, RE) scheme, there are two other building blocks. Plaintext authentication prediction A (e.g., PIN verification, such as IBM 3624) takes the authentication key ak, some associated data a, and the message m as input and outputs bits b indicating whether authentication was successful or not. The lookup function L takes some associated data a and a set of re-encryption keys R. i As input, and output a single re-encryption key rk (set R) i This is defined as the set of all re-encryption keys output by PPA.Enroll from source i. Note that in payment practice, each intermediary transitions between multiple different parties, therefore the associated data 'a' is used to determine the route to the next hop (and the corresponding re-encryption key).

[0240] Figure 8 The diagram illustrates the formal PPA construction 800 based on PRE, which describes in more detail how it adapts to the payment context based on two phases: a setup phase, which generates keys for all parties; and an online phase, which uses these keys to protect the PIN in the process from the POS terminal to the consumer bank.

[0241] By initializing the PRE scheme (PRE.Setup) and authentication prediction A 3 The key ak is used to perform the initial setup of the PPA scheme. Once the system is initialized, the first phase is to perform key setup. Any entity that calls PPA.KG runs PRE.KG. Similarly, PRE.Enroll runs directly when generating a re-encryption key. The differences in key management processes between traditional methods, one-way PPAs, and two-way PPAs will be further described in the section titled "General PPA Construction" below.

[0242] The online phase includes running the functions PPA.Send, PPA.Relay, and PPA.Verify. PPA.Send is run by the initial payment terminal 304 that captures the PIN; PPA.Relay is run by each intermediary as the encrypted PIN block is sent over the network; and PPA.Verify is run by the consumer bank 312 that performs the final verification. PPA.Send is constructed by simply calling the PRE encryption function PRE.E. The relay call is constructed by first calling the lookup function L to determine the correct re-encryption key to use, and then making an appropriate call to PRE.RE. Finally, PPA.Verify calls the PRE decryption function PRE.D and provides the output of PRE.D to the authentication prediction A to determine the final output bit b.

[0243] An efficient PRE construct for directly instantiating PPAs is described in more detail in the section titled "Efficient PPA Constructs" of this paper. This construct uses a hybrid approach that makes the encrypted PIN blocks backward compatible with existing infrastructure.

[0244] The security analysis of the PPA scheme can be configured based on the following theorems and proofs:

[0245] Theorem. Given a (t,∈)-safe PRE scheme, Figure 8 The constructor defined in is (t,∈′)-secure PPA scheme, where ∈′≤∈.

[0246] Proof. Suppose adversary A is attacking PPA's PPA-CCA security. Using A, construct a new adversary B that is attacking PRE's PRE-CCA security. B uses its Oracle database to simulate A's Oracle database.

[0247] The security game begins with the setup phase. The setup procedure is run to perform B's PRE-CCA experiment, returning the received honest public key and fraudulent key pair to A. Additionally, a plaintext authentication prediction key ak for A is generated. The next step is to run the attack / challenge phase. Whenever A causes an Oracle database call O... Enroll Or O Chall At that time, by calling B's Oracle database O respectively RKG Or O Chall To simulate these. When A performs O Relay (pk i When calling ,a,c), first check a to determine pk. j Then call O RE (pk i ,pk j (a, c). When A causes Oracle database to call O Verify When using B's O D The Oracle database is decrypted, and then the result of the authentication prediction A is calculated using ak and returned.

[0248] When A terminates and outputs its guess b, B terminates and outputs the same bit b. It is easy to see that if A wins, then B also wins, therefore ∈′≤∈.

[0249] In a typical key management process for PIN conversion keys, each pair of adjacent parties establishes a shared symmetric key. For example, when payment network 310 receives an encrypted PIN from merchant bank 308, payment network 310 decrypts the encrypted PIN using a key shared with merchant bank 308 and encrypts the PIN using a key shared with consumer bank 312 to which the encrypted PIN is sent. Since all keys are stored in the HSM, a strict key ceremony procedure is followed to establish these shared keys. It should be noted that there is no direct online connection between the HSMs of adjacent parties that facilitates online key exchange. Instead, each party designates multiple employees as key custodians. The parties wishing to establish shared keys do so in the following manner. For the purposes of this specification, each party may have two custodians. First, one of the parties (Party A) generates a key encryption key (KEK) in its HSM. Party A's two custodians perform an export operation on the HSM, so each custodian receives an XOR share of the key (k = k1⊕k2). The first custodian seals its XOR share in a tamper-proof envelope and sends it to the corresponding custodian of Party B via courier. Similarly, the second custodian sends the XOR share to the corresponding custodian of Party B via a different courier. Party B's custodian performs the import operation on its HSM. It should be noted that neither party knows the complete plaintext key at any given time. This concept is called split knowledge. When both parties load the same KEK into their HSMs, all subsequent keys can be shared and encrypted based on this key (key generation and encryption based on the KEK are performed within the HSM). This is a rigorously audited process and strictly adheres to the requirements specified by PCI. Specifically, the above process strictly follows Control Object 3 and Requirement 8 of the PCI PIN Security Requirements.

[0250] When considering the practicalities of key management processes when using bidirectional or unidirectional schemes (note that for either scheme type, an HSM is used during the key setup phase because the secret key should not be exposed in plaintext), once the key is set, only the end party performing the verification can use the HSM. This significantly reduces the number of HSMs required by intermediaries, who no longer need to consider the large number of HSM calls previously performed during transactions for PIN conversion. A key part of PPA key management is how the re-encryption key is generated. Because bidirectional schemes use two secret keys to compute the re-encryption key, they employ a strictly controlled process. In contrast, unidirectional schemes use only the source secret key and the target public key. Sharing the target public key with the source can be done in a more relaxed (but still rigorously audited) manner.

[0251] For a two-way PPA, consider the final three hops in the basic payments ecosystem: Merchant Bank 308, Payment Network 310, and Consumer Bank 312. In a standard setup, Payment Network 310 generates all keys and distributes them to Merchant Bank 308 and Consumer Bank 312 using the process described earlier in this document. In a two-way PPA, when a new bank (whether Merchant Bank 308 or Consumer Bank 312) registers, the Trusted Payment Network Key Manager (HSM-based) generates a new key pair. The secret key is shared with the key manager of the registering bank. It should be noted that Consumer Bank 312 uses the secret key to perform the final decryption, and Merchant Bank 308 uses the secret key to compute the earlier re-encryption key (due to the fact that the scheme is two-way). These secret keys can be securely shared between the parties using traditional KEK-based methods. In addition to generating and sharing new key pairs upon registration, the key manager also computes the re-encryption key. If the new key pair applies to merchant bank 308, the key manager generates a re-encryption key for each previously registered consumer bank 312 (for consumer bank 312 registered from a previously registered merchant bank 308, and vice versa). The re-encryption key is provided to the "untrusted" payment network application (note that the application maintains mn re-encryption keys, where m is the number of merchant banks and n is the number of consumer banks).

[0252] In contrast, the one-way PPA scenario is much simpler. Here, when a new participant registers, their trusted key manager generates their own key pair. The key manager shares the new public key with their previous neighbors and requests a public key from each of their subsequent neighbors. Each participant's key manager can generate a re-encryption key based on their own secret key and the public keys of their subsequent neighbors. These re-encryption keys are used by their own application during the transaction. The application holds a re-encryption key associated with each of its subsequent neighbors. In this setup, because participants only share public keys, no KEK or split knowledge is required during key transfers, making the key management process much simpler.

[0253] High-efficiency PPA construction

[0254] Elgamal encryption, as described in the following document: TEGamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,” Proceedings of the “Advances in Cryptography – CRYPTO '84 Conference,” Santa Barbara, California, August 19–22, 1984, Computer Science Lecture Series, eds. G.R. Blakley and D. Chaum, Vol. 196, Springer, 1984, pp. 10–18. [Online]. Available at https: / / doi.org / 10.1007 / 3-540-39568-7_2, the contents of which are incorporated herein by full reference. This encryption forms the basis of many PRE schemes. It also supports many well-known hybrid encryption schemes, such as those described in the following literature: For example, R. Cramer and V. Shoup, “A practical public key cryptosystem provably secure against adaptive chosen ciphertext attack,” Proceedings of the 18th International Conference on Cryptography, Santa Barbara, California, August 23-27, 1998, Computer Science Lecture Series, edited by H. Krawczyk, Vol. 1462, Springer, 1998, pp. 13–25. [Online]. Available at https: / / doi.org / 10.1007 / BFb0055717, the contents of which are incorporated herein by reference in full. Hybrid encryption schemes are constructs that combine public-key encryption and symmetric-key encryption. It consists of a Key Encapsulation Mechanism (KEM) and a Data Encapsulation Mechanism (DEM). The KEM is used to share a randomly selected key, and the DEM is used to encrypt data based on this random key. The PRE configuration according to non-limiting embodiments or aspects may include a hybrid encryption scheme. The DEM is used to encrypt the PIN based on the random key protected by the KEM. When re-encryption is performed, the KEM can be modified, but the DEM can remain unchanged.

[0255] S. Myers and A. Shull, “Efficient hybrid proxy re-encryption for practical revocation and keyrotation,” IACR Cryptography Research Preprint, Vol. 2017, p. 833, 2017. [Online]. Available at http: / / eprint.iacr.org / 2017 / 833, the contents of which are incorporated herein by reference in full. The aforementioned literature describes the construction of hybrid proxy re-encryption, focusing on use cases related to key rotation for cloud outsourced data storage and access control. In this context, key breaking attacks become a significant problem. Here, an adversary who previously had access to files or had the ability to download large amounts of KEMs in a short period can decrypt the KEMs to retrieve the random key used by the DEM. After key rotation and re-encryption, it is assumed that the adversary no longer has access to the plaintext. However, in conventional methods, only the KEM is re-encrypted, and even after re-encryption, the DEM remains unchanged. This means that an adversary who previously obtained the random key from the KEM can always decrypt the data. In non-limiting embodiments or aspects, the KEM can be re-encrypted, but key-breaking attacks are no longer critical for two reasons. First, the DEM only encrypts very short plaintext (PIN blocks are only 64 bits), so an adversary capable of breaking the KEM can also easily break the DEM simultaneously. In contrast, DEMs in outsourced data setups are typically several megabytes or gigabytes in size. Second, in payment setups, ciphertext does not need to be stored long-term because it is only relevant to a single transaction cycle.

[0256] Now for reference Figure 9 It illustrates a hybrid PRE construct 900, which, according to a non-limiting embodiment or aspect, can use a generator g to examine a set of prime order q, and employs a symmetric encryption scheme SE = (SE.E, SE.D). Key generation is from... Randomly select a secret key sk and calculate the public key pk = g. sk The construction can include a bidirectional PRE scheme, therefore the re-encryption key generation PRE.RKG uses the source secret key and the target secret key (sk i and SK j The re-encryption key is sk. i / sk j It should be noted that since the basic symmetric encryption scheme uses associated data 'a' as input, the syntax of PRE is applicable to inputs including this. The encryption algorithm PRE.E uses associated data 'a' and message 'm' as input. First, KEM is calculated, which selects a random exponent r and calculates c1 = g. r The symmetric key K is calculated as hash pk.r =g sk·r This is actually a ephemeral, static Diffie-Hellman key. Next, SE.E is run on inputs a and m with key K to compute the DEM, yielding c2. The final output of PRE.E is (c1, c2). Decryption follows the reverse procedure. First, the decapsulation of c1 is performed to obtain the symmetric key K. Here, the hash c1 is taken. sk =g r·sk And using K, call SE.D on a and c2 to retrieve m. As mentioned before, the re-encryption function PRE.RE only runs on KEM c1. By raising it to the re-encryption key c1 rki→j To perform re-encryption. For example... Figure 9 As shown, DEM is simply labeled as a symmetric encryption scheme SE. A practical implementation of DEM can be based on standard PIN block encryption, as described in the section titled "Overview of PIN-Based Payments" and as... Figure 4 and 5 As shown, it encodes the PIN based on ISO 9564-1 and encrypts the PIN block using 3DES with a random key protected by KEM, which means that DEM ensures best backward compatibility with existing PIN verification calls.

[0257] Now for reference Figure 10 , Figure 10 This is a flowchart of a non-limiting embodiment or aspect of a process 1000 for securely sending PINs and other sensitive data. In some non-limiting embodiments or aspects, one or more steps of process 1000 (e.g., wholly, partially, etc.) are performed by payment network 310 (e.g., one or more devices of payment network 310, etc.). In some non-limiting embodiments or aspects, one or more steps of process 1000 (e.g., wholly, partially, etc.) are performed by another device or group of devices separate from or including payment network 310, such as POS partner 304 (e.g., one or more devices of POS partner 304, etc.), payment gateway 306 (e.g., one or more devices of payment gateway 306, etc.), merchant bank 308 (e.g., one or more devices of merchant bank 308, etc.) and / or consumer bank 312 (e.g., one or more devices of consumer bank 312, etc.).

[0258] like Figure 10As shown, in step 1002, process 1000 includes generating a first ciphertext including a first ciphertext value and a second ciphertext value. For example, POS terminal / partner 304 may generate a first ciphertext including a first ciphertext value and a second ciphertext value associated with a transaction. As an example, POS terminal / partner 304 may generate a first ciphertext associated with a transaction. In such an example, the first ciphertext may include: (i) a first ciphertext value associated with a randomly selected key (r), the first ciphertext value being encrypted based on the randomly selected key (r) and a generator value (g); and (ii) a second ciphertext value associated with the first public key (pk1) of a first pair of keys including a first public key (pk1) and a first secret key (sk1), the first public key (pk1) being generated based on the first secret key (sk1) and the generator value (g), the second ciphertext value being encrypted based on transaction data associated with the transaction, and a symmetric key (K) being generated based on the first public key (pk1) and the randomly selected key (r).

[0259] In some non-limiting embodiments or aspects, the intermediary server transfers data between multiple different parties by decrypting the second ciphertext value and using a portion of the transaction data to determine the path selection and corresponding re-encryption key for subsequent transmissions.

[0260] In some non-limiting embodiments or aspects, the transaction data includes at least one of a mobile personal identification number (PIN), a card verification number, or a card number associated with it.

[0261] In some non-limiting embodiments or aspects, the second ciphertext value is used to encrypt a personal identification number (PIN) based on a randomly selected key (r) protected by the first ciphertext value, and re-encryption generates a new ciphertext value without changing the second ciphertext value.

[0262] like Figure 10 As shown, in step 1004, process 1000 includes transmitting a first ciphertext. For example, POS terminal / partner 304 may transmit the first ciphertext to payment gateway 306. As an example, POS terminal / partner 304 may transmit the first ciphertext to at least one payment gateway 306.

[0263] like Figure 10 As shown, in step 1006, process 1000 includes re-encrypting the first ciphertext value. For example, payment gateway 306 may re-encrypt the first ciphertext value. As an example, payment gateway 306 may re-encrypt the first ciphertext value using a first re-encryption key to transform the first ciphertext value encrypted according to a first public key (pk1) into a re-encrypted first ciphertext value encrypted according to a second public key (pk2) associated with at least one payment gateway 306;

[0264] like Figure 10As shown, in step 1008, process 1000 includes transmitting a first ciphertext value and a second ciphertext value that have been re-encrypted. For example, payment gateway 306 can transmit the re-encrypted first ciphertext value and the second ciphertext value to merchant bank 308. As an example, payment gateway 306 can transmit the re-encrypted first ciphertext value and the second ciphertext value to at least one merchant bank 308.

[0265] like Figure 10 As shown, in step 1010, process 1000 includes re-encrypting the re-encrypted first ciphertext value into a second re-encrypted first ciphertext value. For example, merchant bank 308 can re-encrypt the re-encrypted first ciphertext value into a second re-encrypted first ciphertext value. As an example, merchant bank 308 can re-encrypt the re-encrypted first ciphertext value encrypted with a second re-encryption key to transform the re-encrypted first ciphertext value encrypted according to a second public key (pk2) of at least one payment gateway 306 into a second re-encrypted first ciphertext value according to a third public key (pk3) of at least one merchant bank 308.

[0266] like Figure 10 As shown, in step 1012, process 1000 includes transmitting a second re-encrypted first ciphertext value and a second ciphertext. For example, merchant bank 308 can transmit the second re-encrypted first ciphertext value and the second ciphertext to payment network 310. As an example, merchant bank 308 can transmit the second re-encrypted first ciphertext value and the second ciphertext value to payment network 310.

[0267] like Figure 10 As shown, in step 1014, process 1000 includes re-encrypting the second re-encrypted first ciphertext value into a third re-encrypted first ciphertext value. For example, payment network 310 can re-encrypt the second re-encrypted first ciphertext value into a third re-encrypted first ciphertext value. As an example, payment network 310 can re-encrypt the second re-encrypted first ciphertext value encrypted with a third re-encryption key to transform the second re-encrypted first ciphertext value encrypted according to a third public key (pk3) of at least one merchant bank into a third re-encrypted first ciphertext value according to a fourth public key (pk4) of payment network 310.

[0268] like Figure 10 As shown, in step 1016, process 1000 includes transmitting a third re-encrypted first ciphertext value. For example, payment network 310 may transmit the third re-encrypted first ciphertext value to consumer bank 312. As an example, payment network 310 may transmit the third re-encrypted first ciphertext value and a second ciphertext value to at least one consumer bank 312.

[0269] like Figure 10As shown, in step 1018, process 1000 includes determining a symmetric key based on the third re-encrypted first ciphertext value and the secret key. For example, consumer bank 312 can determine the symmetric key based on the third re-encrypted first ciphertext value and the secret key. As an example, consumer bank 312 can determine the symmetric key (K) based on the third re-encrypted first ciphertext value and the secret key of consumer bank 312.

[0270] like Figure 10 As shown, in step 1020, process 1000 includes decrypting the second ciphertext value based on a symmetric key. For example, consumer bank 312 can decrypt the second ciphertext value based on a symmetric key. As an example, consumer bank 312 can decrypt the second ciphertext value based on a symmetric key (K) to obtain transaction data.

[0271] Now for reference Figure 11A-11C , Figure 11A-11C This is a flowchart of a non-limiting embodiment or aspect of a process 1100 for securely sending PINs and other sensitive data. In some non-limiting embodiments or aspects, one or more steps of process 1100 (e.g., wholly, partially, etc.) are performed by payment network 310 (e.g., one or more devices of payment network 310, etc.). In some non-limiting embodiments or aspects, one or more steps of process 1100 (e.g., wholly, partially, etc.) are performed by another device or group of devices separate from or including payment network 310, such as POS partner 304 (e.g., one or more devices of POS partner 304, etc.), payment gateway 306 (e.g., one or more devices of payment gateway 306, etc.), merchant bank 308 (e.g., one or more devices of merchant bank 308, etc.) and / or consumer bank 312 (e.g., one or more devices of consumer bank 312, etc.).

[0272] like Figure 11A As shown, in step 1102, process 1100 includes generating a first value (a) and a second value (g). a For example, payment network 310 can generate a first value (a) and a second value (g). a As an example, payment network 310 can generate a first value (a) and a second value (g). a In such examples, the second value (g) a It can be generated based on the first value (a) and the generator value (g).

[0273] In some non-limiting embodiments or aspects, the second value can be generated as a generator value (g) raised to the power of the first value (a). For example, the second value can be generated as follows:

[0274] Second value = g a

[0275] like Figure 11A As shown, in step 1104, process 1100 includes generating a random merchant ID (m i For example, payment network 310 can generate random merchant IDs (m). i As an example, payment network 310 can generate a random merchant number (m) for each of multiple merchant banks 308. i For example, payment network 310 can generate multiple random merchant numbers (m1, ..., mk ∈ G) for the corresponding multiple merchant banks 308 (e.g., i = 1, ..., k, where k is the number of merchant banks 1308).

[0276] like Figure 11A As shown, in step 1106, process 1100 includes determining the merchant product (M). For example, payment network 310 can determine the merchant product (M). As an example, payment network 310 can determine the merchant product (M) based on multiple random merchant numbers (m) of corresponding multiple merchant banks 308. i The product of ) determines the merchant product (M).

[0277] In some non-limiting embodiments or aspects, the merchant product (M) can be determined as follows:

[0278]

[0279] like Figure 11A As shown, in step 1108, process 1100 includes generating a public key (pk). i ) and random key (rk) i For example, Payment Network 310 can generate public keys (pk). i ) and random key (rk) i As an example, payment network 310 can be based on the second value (g). a Merchant product (M) and random merchant number (m) i Generate public key((pk) i ), and based on the merchant product (M) and the random merchant number (m) of each corresponding merchant bank in the multiple merchant banks 308. i Generate random key (rk) i ).

[0280] In some non-limiting embodiments or aspects, the public key (pk) i The following can be generated:

[0281]

[0282] In some non-limiting embodiments or aspects, the random key (rk) i The following can be generated:

[0283]

[0284] like Figure 11A As shown, in step 1110, process 1100 includes transmitting the public key (pk). i ) and random key (rk) i For example, payment network 310 can transmit public key (pk) i ) and random key (rk) i The public key (pk) is transmitted to the merchant bank 308. As an example, the payment network 310 can transmit the public key (pk) to the merchant bank 308. i ) and random key (rk) i The data is transmitted to at least one corresponding merchant bank 308.

[0285] like Figure 11A As shown, in step 1112, process 1100 includes generating a random payment gateway number (p i For example, Merchant Bank 308 can generate a random payment gateway number (p). i As an example, merchant bank 308 can generate a random payment gateway number (p) for each of multiple payment gateways 306. i (For example, i = 1, ..., k, where k is the number of payment gateways 1706).

[0286] like Figure 11A As shown, in step 1114, process 1100 includes generating a payment gateway public key and a payment gateway random key. For example, merchant bank 308 can generate a payment gateway public key and a payment gateway random key. As an example, merchant bank 308 can generate a payment gateway public key and a payment gateway random key based on a second value (g). a Merchant product (M) and random payment gateway number (p) i Generate a public key for the payment gateway, and based on the random payment gateway number (p) of each corresponding payment gateway in the multiple payment gateways 306. i Generate a random key for the payment gateway.

[0287] In some non-limiting embodiments or aspects, the payment gateway public key for each payment gateway 306 can be generated as follows:

[0288]

[0289] In some non-limiting embodiments or aspects, the payment gateway random key for each payment gateway 306 can be generated as follows:

[0290]

[0291] like Figure 11A As shown, in step 1116, process 1100 includes generating a terminal number (t iFor example, Merchant Bank 308 can generate a terminal number (t). i As an example, Merchant Bank 308 can generate multiple terminal numbers (t) for multiple corresponding point-of-sale (POS) terminals / partners 304. i ).

[0292] like Figure 11A As shown, in step 1118, process 1100 includes generating a terminal public key and a terminal random key. For example, merchant bank 308 can generate a terminal public key and a terminal random key. As an example, merchant bank 308 can generate a terminal public key and a terminal random key based on a second value (g). a Merchant product (M), random payment gateway number (p) i ) and terminal number (t) i Generate a terminal public key, and based on the random payment gateway number (p) i ) and the terminal number (t) of each corresponding POS terminal in multiple POS terminals / partners 304 i Generate a terminal random key.

[0293] In some non-limiting embodiments or aspects, the terminal public key for each POS terminal / partner 304 can be generated as follows:

[0294]

[0295] In some non-limiting embodiments or aspects, the terminal random key for each POS terminal / partner 304 can be generated as follows:

[0296]

[0297] like Figure 11B As shown, in step 1120, process 1100 includes transmitting the terminal public key and the terminal random key. For example, merchant bank 308 can transmit the terminal public key and the terminal random key. As an example, merchant bank 308 can transmit the terminal public key and the terminal random key to at least one payment gateway 306.

[0298] like Figure 11B As shown, in step 1122, process 1100 includes transmitting the terminal public key. For example, payment gateway 306 can transmit the terminal public key. As an example, payment gateway 306 can transmit the terminal public key to at least one POS terminal / partner 304.

[0299] like Figure 11B As shown, in step 1124, process 1100 includes generating a random number (r) for the transaction message (m) associated with the transaction. For example, the POS terminal / partner 304 can generate a random number (r) for the transaction message (m) associated with the transaction.

[0300] like Figure 11B As shown, in step 1126, process 1100 includes generating a first ciphertext that includes a first ciphertext value and a second ciphertext value. For example, POS terminal / partner 304 may generate a first ciphertext that includes a first ciphertext value and a second ciphertext value. As an example, POS terminal / partner 304 may generate a first ciphertext associated with a transaction. In such an example, the first ciphertext may include (i) a first ciphertext value associated with a transaction message (m), which is encrypted based on a random number (r), a generator value (g), and the transaction message (m); and ii) a second ciphertext value associated with a random number (r), which is encrypted based on the random number (r) and the terminal public key.

[0301] In some non-limiting embodiments or aspects, the first ciphertext value may be generated as follows:

[0302] First ciphertext value = m·g r

[0303] In some non-limiting embodiments or aspects, the second ciphertext value may be generated as follows:

[0304]

[0305] like Figure 11B As shown, in step 1128, process 1100 includes transmitting a first ciphertext. For example, a POS terminal / partner 304 may transmit the first ciphertext. As an example, the POS terminal / partner 304 may transmit the first ciphertext to at least one payment gateway 306.

[0306] like Figure 11B As shown, in step 1130, process 1100 includes re-encrypting the second ciphertext value. For example, payment gateway 306 can re-encrypt the second ciphertext value. As an example, payment gateway 306 can re-encrypt the second ciphertext value based on a terminal random key to transform the second ciphertext value into a value based on the second value (g). a The second ciphertext value is re-encrypted from the merchant product (M) and the random number (r).

[0307] In some non-limiting embodiments or aspects, the second ciphertext value may be re-encrypted as follows:

[0308]

[0309] like Figure 11B As shown, in step 1132, process 1100 includes transmitting a re-encrypted second ciphertext value and a first ciphertext value. For example, payment gateway 306 can transmit the re-encrypted second ciphertext value and the first ciphertext value. As an example, payment gateway 306 can transmit the re-encrypted second ciphertext value and the first ciphertext value to at least one merchant bank 308.

[0310] like Figure 11B As shown, in step 1134, process 1100 includes re-encrypting the re-encrypted second ciphertext value into a second re-encrypted second ciphertext value. For example, merchant bank 308 can re-encrypt the re-encrypted second ciphertext value into a second re-encrypted second ciphertext value. As an example, merchant bank 308 can use a random key (rk) i The re-encrypted second ciphertext value is re-encrypted to transform the re-encrypted second ciphertext value into a value based on the second value (g). a Merchant product (M), Merchant random number (m) i The second ciphertext value is re-encrypted using the second ciphertext value and the second random number (r).

[0311] In some non-limiting embodiments or aspects, the re-encrypted second ciphertext value may be re-encrypted as follows:

[0312]

[0313] like Figure 11C As shown, in step 1136, process 1100 includes transmitting a second re-encrypted second ciphertext value and a first ciphertext value. For example, merchant bank 308 can transmit the second re-encrypted second ciphertext value and the first ciphertext value. As an example, merchant bank 308 can transmit the second re-encrypted second ciphertext value and the first ciphertext value to payment network 310.

[0314] like Figure 11C As shown, in step 1138, process 1100 includes based on the second re-encrypted second ciphertext value, the merchant product (M), and the merchant random number (m). i The first ciphertext value is decrypted. For example, payment network 310 can decrypt the second ciphertext value based on the second re-encrypted ciphertext value, the merchant product (M), and the merchant random number (m). i The first ciphertext value is decrypted. As an example, payment network 310 can decrypt the second ciphertext value (which has been re-encrypted), the merchant product (M), and the merchant random number (m). i The first ciphertext value is decrypted using the first ciphertext value.

[0315] In some non-limiting embodiments or aspects, the payment network 310 may transform the second re-encrypted second ciphertext value as follows:

[0316]

[0317] In some non-limiting embodiments or aspects, the payment network 310 may decrypt the first ciphertext value to form the message (m) as follows:

[0318]

[0319] Security analysis of hybrid PRE schemes based on non-limiting embodiments or aspects can be configured according to the following definitions, theorems, and proofs. The input domain of all algorithms is not explicitly defined. It is assumed that the inputs, when entered into the algorithm, will be in the correct domain. f(a,b,c,...) and f a (b,c...) can be written interchangeably. Additionally, for opponent A, it is defined as...

[0320] Δ

[0321] A(f1,f2,...;g1,g2...)=

[0322] |P[A f1,f2,... =1]–P[A g1,g2... ]|.

[0323] The Key Encapsulation Mechanism (KEM) consists of an algorithm (KG, Encaps, Decaps) tuple, defined as follows:

[0324] KG→(pk,sk): Key generation, returns the public key and secret key pair (pk,sk).

[0325] Encaps(pk)→c: Encryption, takes the input public key, and outputs the ciphertext and key k.

[0326] Decaps(sk,c)→m or □: Decrypts the key and ciphertext as input, and outputs the key k or an error symbol.

[0327] KEM correctness can be defined as follows:

[0328] For all (pk, sk) output by KG, where the probability is one, the following holds true.

[0329] (c,k) = Encaps(pk)

[0330] k = Decaps(sk,c).

[0331] Bidirectional KREMs can be defined, and the definition can be easily modified to capture unidirectional KREMs.

[0332] The Proxy Key Resealing Mechanism (KREM) is a KEM with the following added features:

[0333] RKG(sk i ,pk i ,sk j ,pk j )→rk i→j ReKeyGen will transfer the source key pair (sk i ,pk i ) and target key pair (sk j,pk j ) as input and output repackaged key rk i →j.

[0334] ReEncaps(rk i→j c)→c′ or: Re-encapsulation will re-encapsulate the key rk i→j Take the ciphertext c as input and output the converted ciphertext c′ or error symbol.

[0335] If the KREM scheme is as correct as the KEM scheme, then the KREM scheme is l-hop correct, and for all possible (pk) i ,sk i ), where i≤i≤l+1, for all rk i→i+1 If 1 ≤ i ≤ l, and the probability is one, then the following holds true:

[0336] (c1,k) = Encaps(pk1)

[0337] c i+1 =ReEncaps(rk) i→i+1 c1), where 1≤i≤l

[0338] k = Decaps(sk) l+1 ,c l+1 ).

[0339] If a KREM scheme is l-hop correct, where all l ≥ 1, then the KREM scheme is multi-hop correct.

[0340] If for all k output by KG and all messages m, the following holds with a probability of one, then DEM is correct:

[0341] D(k,E(k,m))=m.

[0342] The advantages of KEM CCA can be defined as follows:

[0343] Considering KEM(KG, Encaps, Decaps), then opponent A's CCA advantage is

[0344] Δ

[0345] Adv(A): = A(pk,c,k,Decaps) sk ;pk,c,k′,Decaps sk ),

[0346] Where (pk,sk)←KG, (c,k)←Encaps(pk), k′ is uniformly selected from all strings of length |k|, and A cannot input c into its Decaps. skOracle database.

[0347] The Data Encapsulation Mechanism (DEM) includes algorithm (KG, E, D) tuples, defined as follows:

[0348] KG(pp)→k: Key generation returns the secret key k.

[0349] E(k,m)→c: Encryption, taking the input key and message as input, and outputting ciphertext.

[0350] D(k,c)→m OR: Decryption, with input secret key and ciphertext, output message or error symbol.

[0351] The DEM CCA advantage can be defined by considering DEM(KG,E,D). Then, opponent A's CCA advantage is...

[0352] Δ

[0353]

[0354] Where k←KG, $(x) returns a uniform string of length |x|, always returns, and A can only query its left Oracle database once, and cannot use the output of its left Oracle database as the input of its right Oracle database.

[0355] The advantage of KREM CCA can be defined by considering the key recapping mechanism KREM:=(KG,Encaps,Decaps,RKG,ReEncaps). Let A be the adversary, and let A... Gi Let b be the value of i, and let i be the value of i. Then the KREM CCA advantage of A is defined as follows:

[0356] Δ

[0357] Adv KREM (A):=A(G0;G1).

[0358] KREM CCA Safe Games G i It will be carried out in the following two stages:

[0359] Setup: Run the KREM setup and provide the generated public parameters to the adversary. The adversary returns n, H, and C, representing the total number of each party, the set of honest parties, and the set of cheating parties, respectively. Generate n key pairs (pk) using KG. i ,sk i And partition the index between sets H and C. For all i∈H, provide pk for the opponent. i And for all i∈C, provide the opponent with (pk i ,sk i ).

[0360] Attack: For all i (j≤n, i≠j), use RKG to compute the re-encryption key rk. i→j Let D* denote the set of ciphertexts derived from the challenge ciphertext (see below); this is the set of ciphertexts obtained before challenging the Oracle database. Similarly, let D denote the set of ciphertexts derived from the output of any encapsulated Oracle database. For example... Figure 12A As shown in the KREM CCA game Oracle database 1200, opponent A is granted access to the Oracle database, where A can query at most once, and b = i.

[0361] The following theorems follow a simple mixed argument:

[0362] Theorem. Combining CCA KREM with CCA DEM results in the CCA PRE scheme, which allows the construction of opponents B and C such that...

[0363] Adv PRE (A)≤Adv KREM (B)+Adv DEM (C).

[0364] Randomized Oracle databases rely on the Oracle Database Diffie-Hellman (ODH) hypothesis.

[0365] The advantage that opponent A has when playing the ODH-RO game is...

[0366] Δ

[0367] A(F(·),g u ,g v ,F(g uv ),F v (·);F(·),g u ,g v ,W,F v (·)),

[0368] Where F is a random Oracle database, u, v, and W are randomly and uniformly selected, and F v (X):=F(X v ).

[0369] Theorem. Suppose A is an adversary. Figure 9 The KREM CCA opponent presented in the hybrid PRE construction then constructs the ODH-RO opponent B such that

[0370] Adv KREM (A)≤Adv ODH-RO (B)

[0371] Proof. Construct ODH-RO opponent B as follows.

[0372] 1) Provide g for B u g v W, F v , where W is F(g uv (or randomly selected)

[0373] 2) B runs A, and the KREM CCA game setup procedure is as follows. A gives B two separate subsets {1,...,n}, namely H and C, representing honest users and cheating users respectively. For i∈C, B uses KREM.KG to generate an independent key (pk i ,sk i For i∈H, B generates a uniform random value r. i Opponent B provides A with PK (player kill) opportunities. i =g vri , where i∈H, and (pk i ,sk i ), where i∈C.

[0374] 3) B initiates the attack phase on A, and uses, for example... Figure 12B The example shown is an Oracle database query response A specified in simulated Oracle database 1250.

[0375] It can be seen that the standard PIN block encryption scheme is a secure DEM. These constructions are highly relevant to the code-then-encipher paradigm normalized by M. Bellare and P. Rogaway in the following literature: “Encode-then-encipher encryption: How to exploit nonces or redundancy in plaintexts for efficient cryptography,” “Advances in Cryptography - ASIACRYPT 2000,” Proceedings of the 6th International Conference on Cryptography and Information Security Theory and Applications, Kyoto, Japan, December 3-7, 2000, Computer Science Lecture Series, edited by T. Okamoto, Vol. 1976, Springer, 2000, pp. 317–330. [Online]. Available at https: / / doi.org / 10.1007 / 3-540-44448-3_24 (hereinafter referred to as Bellare et al.), the contents of which are incorporated herein by reference in full. The two main differences are: 1) additional associated data is considered; 2) due to the use of hybrid encryption, only one-time use of the key / cipher needs to be considered. The final point is that the anti-collision properties of the encoding scheme no longer need to be considered, as each DEM key has only one encryption call. Figure 5 The SE of the EPB defined in the standard is a secure DEM, which can be demonstrated by extending the results of Bellare et al.

[0376] PPA schemes can be implemented using Java. For example, the NIST P-256 curve (aka secp256r1) can be used, which has the parameters recommended by the standard. This curve provides approximately 128 bits of security. The Bouncy Castle Crypto API can be used for its elliptic curve implementation. In this example, all parties involved in a PIN-based transaction can transact in the following order: the POS application calls the PPA.Send method and sends the encrypted PIN to the payment gateway; the payment gateway then calls the PPA.Relay method and sends the re-encrypted PIN to the merchant bank; the merchant bank forwards the message to the payment network; the payment network calls the PPA.Relay method and sends the re-encrypted PIN to the consumer bank for authorization; finally, the consumer bank calls the PPA.Verify method to authorize the transaction. Each intermediary deploys the PPA.Relay method in its own environment and interacts with the consumer bank using ISO 8583 messages.

[0377] Both the intermediary and consumer banking applications can run on a single machine. The prototype payment gateway service can be implemented as a web application accessed via HTTPS. All requests from the POS application are first processed by this web application, invoking the merchant banking web application running on a different port on the same machine. The merchant banking web application then forwards the request to the consumer banking web application via the payment network web application. Dropwizard can be used to implement all prototype web applications. Except for the consumer banking web application, all web applications may require efficient management of re-encryption keys to invoke the PPA.Relay method. LevelDB can be used to store all re-encryption keys and load them into memory during web application startup.

[0378] Example Key Settings

[0379] Now for reference Figure 13 , Figure 13 This is a non-limiting embodiment or aspect overview diagram of implementation 1300 related to a process for securely sending PINs and other sensitive data. (See diagram for example.) Figure 13 As shown, implementation 1300 includes a POS partner / terminal 1304, a payment gateway 1306, a merchant bank 1308, a payment network 1310, and a consumer bank 1312. In some non-limiting embodiments or aspects, the POS partner / terminal 1304 may be the same as or similar to the POS partner / terminal 304. In some non-limiting embodiments or aspects, the payment gateway 1306 may be the same as or similar to the payment gateway 306. In some non-limiting embodiments or aspects, the merchant bank 1308 may be the same as or similar to the merchant bank 308. In some non-limiting embodiments or aspects, the payment network 1310 may be the same as or similar to the payment network 310. In some non-limiting embodiments or aspects, the consumer bank 1312 may be the same as or similar to the consumer bank 312.

[0380] like Figure 13 As shown by reference numeral 1320 in the attached figure, the POS partner / terminal 1304 can use the key generation function PRE.KG(pp) to generate a key including the POS partner public key (pk). pos ) and POS Partner Secret Key (sk pos POS partner key pair (pk) pos ,sk pos ), POS Partner Key Pair (pk pos ,sk posThis is associated with POS partner 1304. In some non-limiting embodiments or aspects, POS partner / terminal 1304 includes at least one of the following: a point-of-sale terminal, a server computer associated with a merchant or acquiring system, a server computer associated with a point-of-sale service provider, or any combination thereof.

[0381] like Figure 13 As shown by reference numeral 1322 in the attached figure, Merchant Bank 1308 uses the key generation function PRE.KG(pp) to generate a key including the Merchant Bank's public key (pk). mb ) and merchant bank secret key (sk mb Merchant bank key pair (pk) mb ,sk mb Merchant bank key pair (pk) mb ,sk mb It is associated with Merchant Bank 1308.

[0382] like Figure 13 As shown by reference numeral 1324 in the attached diagram, the payment gateway 1306 receives the merchant bank's public key (pk) from the merchant bank 1308. mb For example, Merchant Bank 1308 will store the Merchant Bank's public key (pk). mb The data is transmitted to payment gateway 1306.

[0383] like Figure 13 As shown by reference numeral 1326 in the attached diagram, payment gateway 1306 stores the merchant bank public key (PK) from merchant bank 1308. mb 1 ..., pk mb n ).

[0384] like Figure 13 As shown by reference numeral 1328 in the attached diagram, the POS partner / terminal 1304 receives the merchant's bank public key (pk). mb For example, POS partner / terminal 1304 retrieves the merchant's bank public key (PK) from payment gateway 1306. mb 1 ..., pk mb n As an example, payment gateway 1306 will store the merchant's bank public key (pk). mb 1 ..., pk mb n Transmitted to POS partner / terminal 1304.

[0385] like Figure 13 As shown by reference numeral 1330 in the attached figure, the POS partner / terminal 1304 uses the update key generation function PRE.RKG((pkpos ,sk pos ),(pk mb Based on POS partner secret key (sk pos Generate re-encryption key (rk) pos->mb For example, POS partner / terminal 1304 uses the POS partner secret key (sk pos Generate and store bank public key (pk) mb 1 ..., pk mb n The corresponding re-encryption key (rk) pos->mb 1 , ..., rk pos->mb n It should be noted that for one-way PRE schemes, PRE.RKG will not transmit the target secret key (e.g., the merchant bank's secret key sk). mb ) is used as input, but for the bidirectional PRE scheme, PRE.RKG uses the target secret key as input.

[0386] like Figure 13 As indicated by reference numeral 1332 in the attached diagram, the POS partner / terminal 1304 will re-encrypt the key (rk). pos->mb The key is transmitted to payment gateway 1306. For example, POS partner / terminal 1304 will re-encrypt the key (rk). pos->mb 1 , ..., rk pos->mb n The payment gateway 1306 publishes the re-encryption key (rk) to the payment gateway 1306. As an example, the payment gateway 1306 receives the re-encryption key (rk) from the POS partner / terminal 1304. pos->mb 1 , ..., rk pos->mb n ).

[0387] like Figure 13 As shown by reference numeral 1334 in the attached figure, the payment gateway 1306 stores the re-encryption key (rk). pos->mb 1 , ..., rk pos->mb n ).

[0388] like Figure 13 As shown by reference numeral 1336 in the attached figure, the consumer bank 1312 uses the key generation function PRE.KG(pp) to generate a key including the consumer bank's public key (pk). cb ) and consumer banking secret key (sk cb Consumer bank key pair (pk) cb ,sk cbConsumer bank key pair (pk) cb ,sk cb It is associated with Consumer Bank 1312.

[0389] like Figure 13 As shown by reference numeral 1338 in the attached diagram, payment network 1310 receives the consumer bank's public key (pk) from consumer bank 1312. cb For example, Consumer Bank 1312 will use the Consumer Bank's public key (pk) cb The data is transmitted to payment network 1310.

[0390] like Figure 13 As shown by reference numeral 1340 in the attached diagram, payment network 1310 stores the consumer bank public key (pk) from consumer bank 1312. cb 1 ..., pk cb n ).

[0391] like Figure 13 As shown by reference numeral 1342 in the attached diagram, the merchant bank 1308 receives the consumer bank's public key (pk). cb For example, merchant bank 1308 retrieves the consumer bank's public key (pk) from payment network 1310. cb 1 ..., pk cb n As an example, payment network 1310 will store the consumer's bank public key (pk). cb 1 ..., pk cb n The data was transmitted to the merchant's bank, number 1308.

[0392] like Figure 13 As shown by reference numeral 1344 in the attached diagram, Merchant Bank 1308 uses the update key generation function PRE.RKG((pk mb ,sk mb ),(pk cb Based on the merchant bank's secret key (sk mb Generate re-encryption key (rk) mb->cb For example, Merchant Bank 1308 uses the Merchant Bank Secret Key (sk) mb Generate and consumer bank public key (pk) cb 1 ..., pk cb n The corresponding re-encryption key (rk) mb->cb 1 , ..., rk mb->cb nIt should be noted that for one-way PRE schemes, PRE.RKG will not transmit the target secret key (e.g., the consumer banking secret key sk). cb ) is used as input, but for the bidirectional PRE scheme, PRE.RKG uses the target secret key as input.

[0393] like Figure 13 As indicated by reference numeral 1346 in the attached diagram, Merchant Bank 1308 will re-encrypt the key (rk). mb->cb The key is transmitted to payment network 1310. For example, merchant bank 1308 will re-encrypt the key (rk). mb->cb 1 , ..., rk mb->cb n The payment network 1310 receives a re-encryption key (rk) from the merchant bank 1308. mb->cb 1 , ..., rk mb->cb n ).

[0394] like Figure 13 As indicated by reference numeral 1348 in the attached figure, the payment network 1310 stores the re-encryption key (rk). mb->cb 1 , ..., rk mb->cb n ).

[0395] Example Key Settings

[0396] Now for reference Figure 14 , Figure 14 This is a non-limiting embodiment or aspect overview diagram of an implementation scheme 1400 related to a process for securely sending PINs and other sensitive data. (See diagram for example.) Figure 14 As shown, implementation 1400 includes a POS partner / terminal 1404, a payment gateway 1406, a merchant bank 1408, a payment network 1410, and a consumer bank 1412. In some non-limiting embodiments or aspects, the POS partner / terminal 1404 may be the same as or similar to POS partner / terminal 304. In some non-limiting embodiments or aspects, the payment gateway 1406 may be the same as or similar to payment gateway 306. In some non-limiting embodiments or aspects, the merchant bank 1408 may be the same as or similar to merchant bank 308. In some non-limiting embodiments or aspects, the payment network 1410 may be the same as or similar to payment network 310. In some non-limiting embodiments or aspects, the consumer bank 1412 may be the same as or similar to consumer bank 312.

[0397] like Figure 14As shown by reference numeral 1420 in the attached figure, the payment network 1410 uses the key generation function PRE.KG(pp) to generate a key including the merchant bank's public key (pk). mb ) and merchant bank secret key (sk mb Merchant bank key pair (pk) mb ,sk mb Merchant bank key pair (pk) mb ,sk mb It is associated with Merchant Bank 1308.

[0398] like Figure 14 As shown by reference numeral 1422 in the attached figure, payment network 1410 uses the key generation function PRE.KG(pp) to generate a key including the consumer bank's public key (pk). cb ) and consumer banking secret key (sk cb Consumer bank key pair (pk) cb ,sk cb Consumer bank key pair (pk) cb ,sk cb It is associated with Consumer Bank 1312.

[0399] like Figure 14 As shown by reference numeral 1424 in the attached figure, payment network 1410 uses the update key generation function PRE.RKG((pk mb ,sk mb ),(pk cb ,sk cb Based on the merchant bank's secret key (sk mb ) and consumer banking secret key (sk cb Generate re-encryption key (rk) mb->cb For example, payment network 1410 uses the merchant bank's secret key (sk). mb ) and consumer banking secret key (sk cb Generate and consumer bank public key (pk) cb 1 ..., pk cb n The corresponding re-encryption key (rk) mb->cb 1 , ..., rk mb->cb n It should be noted that for a two-way PRE scheme, PRE.RKG will target the secret key (e.g., the consumer banking secret key sk). cb ) is used as input, but in a one-way PRE scheme, PRE.RKG will not use the target secret key as input.

[0400] like Figure 14As indicated by reference numeral 1426 in the attached figure, the payment network 1410 stores the re-encryption key (rk). mb->cb 1 , ..., rk mb->cb n ).

[0401] like Figure 14 As shown by reference numeral 1428 in the attached diagram, merchant bank 1408 receives a merchant bank key pair (pk) from payment network 1410. mb ,sk mb For example, payment network 1410 will transfer the merchant's bank key pair (pk) to the bank. mb ,sk mb The data was transmitted to the merchant's bank, 1408.

[0402] like Figure 14 As shown by reference numeral 1430 in the attached figure, the consumer bank 1412 receives the consumer bank key pair (pk) from the payment network 1410. cb ,sk cb For example, payment network 1410 will transfer the consumer's bank key pair (pk) to the consumer's bank key pair. cb ,sk cb () Transmitted to Consumer Bank 1412.

[0403] like Figure 14 As shown by reference numeral 1432 in the attached diagram, Merchant Bank 1408 uses the key generation function PRE.KG(pp) to generate a key including the POS partner's public key (pk). pos ) and POS Partner Secret Key (sk pos POS partner key pair (pk) pos ,sk pos ), POS Partner Key Pair (pk pos ,sk pos It is associated with POS partner 1404.

[0404] like Figure 14 As shown by reference numeral 1434 in the attached figure, Merchant Bank 1408 uses the update key generation function PRE.RKG((pk pos ,sk pos ),(pk mb ,sk mb Based on POS partner secret key (sk pos ) and merchant bank secret key (sk mb Generate re-encryption key (rk) pos->mb For example, Merchant Bank 1408 uses the POS Partner Secret Key (SK). pos ) and merchant bank secret key (sk mb Generate and store bank public key (pk)mb 1 ..., pk mb n The corresponding re-encryption key (rk) pos->mb 1 , ..., rk pos->mb n It should be noted that for a two-way PRE scheme, PRE.RKG will contain the target secret key (e.g., the merchant bank's secret key sk). mb ) is used as input, but in a one-way PRE scheme, PRE.RKG will not use the target secret key as input.

[0405] like Figure 14 As shown by reference numeral 1436 in the attached figure, the payment gateway 1406 receives the re-encryption key (rk). pos->mb 1 , ..., rk pos->mb n For example, Merchant Bank 1408 will re-encrypt each key (rk) pos->mb 1 , ..., rk pos->mb n The data is transmitted to payment gateway 1406.

[0406] like Figure 14 As shown by reference numeral 1438 in the attached diagram, the POS partner / terminal 1404 receives the POS partner's public key (pk). pos For example, Merchant Bank 1408 will use the POS partner's public key (pk) pos Transmitted to POS partner / terminal 1404.

[0407] Example PIN conversion

[0408] Now for reference Figure 15 , Figure 15 This is a non-limiting embodiment or aspect overview diagram of an implementation scheme 1500 related to a process for securely sending PINs and other sensitive data. (See diagram for example.) Figure 15As shown, implementation 1500 includes a POS partner / terminal 1504, a payment gateway 1506, a merchant bank 1508, a payment network 1510, and a consumer bank 1512. In some non-limiting embodiments or aspects, the POS partner / terminal 1504 may be the same as or similar to POS partner / terminal 304. In some non-limiting embodiments or aspects, the payment gateway 1506 may be the same as or similar to payment gateway 306. In some non-limiting embodiments or aspects, the merchant bank 1508 may be the same as or similar to merchant bank 308. In some non-limiting embodiments or aspects, the payment network 1510 may be the same as or similar to payment network 310. In some non-limiting embodiments or aspects, the consumer bank 1512 may be the same as or similar to consumer bank 312.

[0409] like Figure 15 As shown by reference numeral 1520 in the attached figure, the POS partner / terminal 1504 uses the DUKPT method (e.g., DUKPT = KDF(MSK, random number), where KDF is the key derivation function and MSK is the master session key) to generate a session key (DUKPT) (e.g., session secret key ss). k wait).

[0410] like Figure 15 As shown by reference numeral 1522 in the attached figure, the POS partner / terminal 1504 uses the 3DES algorithm TDES and the session key (DUKPT) to encrypt the authentication code of the transaction (e.g., PIN, etc.) to generate a PIN block (EPB) (e.g., EPB = TDES(PIN, DUKPT) etc.).

[0411] like Figure 15 As shown by reference numeral 1524 in the attached figure, the POS partner / terminal 1504 uses the function PRE.E(DUKPT, pk pos Based on POS partner public key (pk) pos Encrypt the session key (DUKPT) (e.g., using the POS partner public key (pk)). pos Packaging session secret key ss k To generate DUKPT'). For example, POS partner / terminal 1504 generates encrypted transaction data for a transaction (e.g., Authorization Request Password (ARQC), EPB, DUKPT'), said encrypted transaction data including: (i) an encrypted code (EPB), including an authentication code (PIN) encrypted with a session key (DUKPT), and (ii) an encrypted session key (DUKPT'), including a POS partner public key (pk) associated with POS partner / terminal 1504. pos Encrypted session key (DUKPT).

[0412] like Figure 15 As indicated by reference numeral 1526 in the attached figure, the POS partner / terminal 1504 transmits encrypted transaction data (e.g., ARQC, EPB, DUKPT') to the payment gateway 1506. For example, the payment gateway 1506 receives the encrypted transaction data (ARQC, EPB, DUKPT') from the POS partner / terminal 1504. The encrypted transaction data includes: (i) an encrypted code (EPB), comprising an authentication code (PIN) encrypted with a session key (DUKPT), and (ii) an encrypted session key (DUKPT'), comprising a POS partner public key (pk) associated with the POS partner / terminal 1504. pos Encrypted session key (DUKPT).

[0413] like Figure 15 As shown by reference numeral 1528 in the attached diagram, the payment gateway 1506 determines the re-encryption key (rk) based on the encrypted transaction data. pos->mb 1 , ..., rk pos->mb n The re-encryption key (rk) in ) pos->mb For example, payment gateway 1506 determines the re-encryption key (rk). pos->mb 1 , ..., rk pos->mb n In the merchant's bank public key (pk) mb 1 ..., pk mb n The merchant's bank public key (pk) in ) mb The corresponding re-encryption key (rk) pos->mb ).

[0414] like Figure 15 As shown by reference numeral 1530 in the attached figure, the payment gateway 1506 uses the re-encryption function PRE.RE (e.g., DUKPT" = PRE.RE(DUKPT',rk)). pos->mb )) Use the re-encryption key (rk) pos->mb The encrypted session key (DUKPT') is re-encrypted to generate a re-encrypted encrypted session key DUKPT".

[0415] like Figure 15As shown by reference numeral 1532 in the attached figure, payment gateway 1506 transmits the re-encrypted encrypted session key (DUKPT) to merchant bank 1508. For example, merchant bank 1508 can receive encrypted transaction data (e.g., ARQC, EPB, DUKPT) from payment gateway 1506, the encrypted transaction data including: (i) an encrypted code (EPB), including an authentication code (PIN) encrypted with the session key (DUKPT), and (ii) the re-encrypted encrypted session key (DUKPT), including a re-encrypted key (rk). pos->mb The encrypted session key (DUKPT') includes the POS partner public key (pk) associated with the POS partner / terminal 1504. pos Encrypted session key (DUKPT).

[0416] like Figure 15 As shown by reference numeral 1534 in the attached diagram, Merchant Bank 1508 can use the function PRE.D based on the Merchant Bank's secret key (sk mb The re-encrypted encrypted session key (DUKPT) is decrypted. In some non-limiting embodiments or aspects, the merchant bank 1508 generates an authorization request message in response to a verification authentication code (PIN) and transmits the authorization request message to the payment network 1510.

[0417] like Figure 15 As shown by reference numeral 1536 in the attached figure, merchant bank 1508 can generate encrypted transaction data (e.g., ARQC, EPB, DUKPT') and forward it to payment network 1510. The encrypted transaction data includes (i) an encrypted code (EPB) comprising an authentication code (PIN) encrypted with a session key (DUKPT), and (ii) an encrypted session key (DUKPT') comprising a merchant bank public key (pk) associated with merchant bank 1508. mb The encrypted session key (DUKPT). For example, payment network 1510 can receive encrypted transaction data (e.g., ARQC, EPB, DUKPT') including (i) an encrypted code (EPB) including an authentication code (PIN) encrypted with the session key (DUKPT), and (ii) an encrypted session key (DUKPT') including a merchant bank public key (pk) associated with merchant bank 1508. mb Encrypted session key (DUKPT).

[0418] like Figure 15 As shown by reference numeral 1538 in the attached diagram, payment network 1510 can determine a re-encryption key (rk) based on the encrypted transaction data.mb->cb 1 , ..., rk mb->cb n The re-encryption key (rk) in ) mb->cb For example, payment network 1510 determines the re-encryption key (rk). mb->cb 1 , ..., rk mb->cb n In the context of consumer bank public keys (pk) cb 1 ..., pk cb n Consumer bank public key (pk) in ) cb The corresponding re-encryption key (rk) mb->cb ).

[0419] like Figure 15 As shown by reference numeral 1540 in the attached figure, payment network 1510 uses the re-encryption function PRE.RE (e.g., DUKPT" = PRE.RE(DUKPT',rk)). mb->cb )) Use the re-encryption key (rk) mb->cb Re-encrypt the encrypted session key (DUKPT').

[0420] like Figure 15 As indicated by reference numeral 1542 in the attached figure, payment network 1510 transmits the re-encrypted encrypted session key (DUKPT) to consumer bank 1512. For example, consumer bank 1512 can receive encrypted transaction data (e.g., ARQC, EPB, DUKPT) from payment network 1510, the encrypted transaction data including: (i) an encrypted code (EPB), including an authentication code (PIN) encrypted with the session key (DUKPT), and (ii) the re-encrypted encrypted session key (DUKPT), including an authentication code (PIN) encrypted with the re-encrypted key (rk). mb->cb The encrypted session key (DUKPT') includes a merchant bank public key (e.g., pk) associated with merchant bank 1508. mb Encrypted session key (DUKPT).

[0421] like Figure 15 As shown by reference numeral 1544 in the attached figure, consumer bank 1512 can use the function PRE.D(e.g., DUKPT = PRE.D(DUKPT", sk cb Based on consumer bank secret key (sk cbThe re-encrypted encrypted session key (DUKPT) is decrypted to obtain the session key (DUKPT), and the session key (DUKPT) is used to decrypt the encrypted code (EPB) (e.g., PIN = TDES(DUKPT, EPB)) to obtain the authentication code (PIN).

[0422] like Figure 15 As shown by reference numeral 1546 in the attached diagram, Consumer Bank 1512 can authorize (or reject) transactions based on an authentication code (PIN).

[0423] Example offline consumer bank

[0424] Now for reference Figure 16 , Figure 16 This is a non-limiting embodiment or aspect overview diagram of an implementation scheme 1600 related to a process for securely sending PINs and other sensitive data. (See diagram for example.) Figure 16 As shown, implementation 1600 includes a payment network 1610, a consumer bank 1612, and trusted hardware 1614. In some non-limiting embodiments or aspects, the payment network 1610 may be the same as or similar to the payment network 310. In some non-limiting embodiments or aspects, the consumer bank 1612 may be the same as or similar to the consumer bank 312.

[0425] like Figure 16 As shown by reference numeral 1620 in the attached diagram, the consumer bank 1612 can authorize the payment network 1610 to transfer the consumer bank's secret key (sk). cb This provides access to trusted hardware 1614 (such as an Intel SGX-managed extended access point, etc.).

[0426] like Figure 16 As shown by reference numeral 1622 in the attached figure, payment network 1610 uses the re-encryption function PRE.RE (e.g., DUKPT" = PRE.RE(DUKPT',rk) mb->cb )) Use the re-encryption key (rk) mb->cb The encrypted session key (DUKPT') of the transaction is re-encrypted.

[0427] like Figure 16 As shown by reference numeral 1624 in the attached figure, the payment network 1610 attempts to send the encrypted transaction data to the consumer bank 1612 and detects that the consumer bank 1612 is offline.

[0428] like Figure 16As shown by reference numeral 1626 in the accompanying drawings, payment network 1610 requests trusted hardware 1614 to authorize a transaction. For example, in response to determining that consumer bank 1612 is offline, payment network 1610 requests trusted hardware 1614 to authorize a transaction by providing encrypted transaction data (e.g., ARQC, EPB, DUKPT) to trusted hardware 1614.

[0429] like Figure 16 As shown by reference numeral 1628 in the attached figure, trusted hardware 1614 can use the function PRE.D(e.g., DUKPT = PRE.D(DUKPT", sk cb Based on consumer bank secret key (sk cb The re-encrypted encrypted session key (DUKPT) is decrypted to obtain the session key (DUKPT), and the session key (DUKPT) is used to decrypt the encrypted code (EPB) (e.g., PIN = TDES(DUKPT, EPB)) to obtain the authentication code (PIN).

[0430] like Figure 16 As shown by reference numeral 1630 in the attached figure, the trusted hardware 1614 can authorize (or reject) transactions based on an authentication code (PIN).

[0431] Example Key Settings

[0432] Now for reference Figure 17 , Figure 17 This is a non-limiting embodiment or aspect overview diagram of implementation 1700 related to a process for securely sending PINs and other sensitive data. (See diagram for example.) Figure 17 As shown, implementation 1700 includes a POS partner / terminal 1704, a payment gateway 1706, a merchant bank 1708, a payment network 1710, and a consumer bank 1712. In some non-limiting embodiments or aspects, the POS partner / terminal 1704 may be the same as or similar to POS partner / terminal 304. In some non-limiting embodiments or aspects, the payment gateway 1706 may be the same as or similar to payment gateway 306. In some non-limiting embodiments or aspects, the merchant bank 1708 may be the same as or similar to merchant bank 308. In some non-limiting embodiments or aspects, the payment network 1710 may be the same as or similar to payment network 310. In some non-limiting embodiments or aspects, the consumer bank 1712 may be the same as or similar to consumer bank 312.

[0433] like Figure 17 As shown by reference numeral 1720 in the attached figure, the payment network 1710 can generate a first value (a) and a second value (g). a For example, the second value (g) aIt can be generated based on the first value (a) and the generator value (g).

[0434] In some non-limiting embodiments or aspects, the second value can be generated as a generator value (g) raised to the power of the first value (a). For example, the second value can be generated as follows:

[0435] Second value = g a

[0436] like Figure 17 As shown by reference numeral 1722 in the attached diagram, payment network 1710 can generate a random merchant ID (m i As an example, payment network 1710 can generate a random merchant number (m) for each of multiple merchant banks 1708. i For example, payment network 1710 can generate multiple random merchant IDs (m1, ..., m) for multiple merchant banks 1708. k ∈ G (For example, i = 1, ..., k, where k is the number of merchant banks).

[0437] like Figure 17 As shown by reference numeral 1724 in the attached diagram, payment network 1710 can determine the merchant product (M). For example, payment network 1710 can determine the merchant product (M) based on multiple random merchant numbers (m) of corresponding multiple merchant banks 308. i The product of ) determines the merchant product (M).

[0438] In some non-limiting embodiments or aspects, the merchant product (M) can be determined as follows:

[0439]

[0440] Where k is the number of merchant banks.

[0441] like Figure 17 As shown by reference numeral 1726 in the attached diagram, payment network 1710 can generate a public key (pk). i ) and random key (rk) i As an example, payment network 1710 can be based on a second value (g). a Merchant product (M) and random merchant number (m) i Generate public key((pk) i ), and based on the merchant product (M) and the random merchant number (m) of each corresponding merchant bank in the multiple merchant banks 308. i Generate random key (rk) i ).

[0442] In some non-limiting embodiments or aspects, each merchant bank's public key (pk) iThe following can be generated:

[0443]

[0444] In some non-limiting embodiments or aspects, the random key (rk) i The following can be generated:

[0445]

[0446] like Figure 17 As shown by reference numeral 1728 in the attached diagram, payment network 1710 can transmit public key (pk) i ) and random key (rk) i The public key (pk) is transmitted to the merchant bank 1708. As an example, the payment network 1710 can transmit the public key (pk) to the merchant bank 1708. i ) and random key (rk) i The data is transmitted to at least one corresponding merchant bank 308.

[0447] like Figure 17 As shown by reference numeral 1730 in the attached diagram, merchant bank 1708 can generate a random payment gateway number (p i As an example, merchant bank 1708 can generate a random payment gateway number (p) for each of multiple payment gateways 1706. i (For example, i = 1, ..., k, where k is the number of payment gateways 1706).

[0448] like Figure 17 As shown by reference numeral 1732 in the attached diagram, merchant bank 1708 can generate a payment gateway public key and a payment gateway random key. As an example, merchant bank 1708 can generate a second value (g) based on... a Merchant product (M) and random payment gateway number (p) i Generate a public key for the payment gateway, and based on the random payment gateway number (p) of each corresponding payment gateway in the multiple payment gateways 306. i Generate a random key for the payment gateway.

[0449] In some non-limiting embodiments or aspects, the payment gateway public key for each payment gateway 1706 can be generated as follows:

[0450]

[0451] In some non-limiting embodiments or aspects, the payment gateway random key for each payment gateway 1706 can be generated as follows:

[0452]

[0453] like Figure 17As shown by reference numeral 1734 in the attached diagram, merchant bank 1708 can generate a terminal number (t). i As an example, Merchant Bank 1708 can generate a terminal number (t) for each of multiple point-of-sale (POS) terminals / partners 1704. i ).

[0454] like Figure 17 As shown by reference numeral 1736 in the attached diagram, merchant bank 1708 can generate a terminal public key and a terminal random key. As an example, merchant bank 308 can generate a second value (g) based on... a Merchant product (M), random payment gateway number (p) i ) and terminal number (t) i Generate a terminal public key, and based on the random payment gateway number (p) i ) and the terminal number (t) of each corresponding POS terminal in multiple POS terminals / partners 304 i Generate a terminal random key.

[0455] In some non-limiting embodiments or aspects, the terminal public key for each POS terminal / partner 1704 can be generated as follows:

[0456]

[0457] In some non-limiting embodiments or aspects, the terminal random key for each POS terminal / partner 1704 can be generated as follows:

[0458]

[0459] like Figure 17 As shown by reference numeral 1738 in the attached diagram, merchant bank 1708 can transmit terminal public key and / or terminal random key. As an example, merchant bank 1708 can transmit terminal public key and terminal random key to at least one payment gateway 1706.

[0460] like Figure 17 As shown by reference numeral 1740 in the attached figure, payment gateway 1706 can transmit terminal public keys. As an example, payment gateway 1706 can transmit terminal public keys to at least one POS terminal / partner 1704.

[0461] Example PIN conversion

[0462] Now for reference Figure 18 , Figure 18 This is a non-limiting embodiment or aspect overview diagram of an implementation scheme 1800 related to a process for securely sending PINs and other sensitive data. (See diagram for example.) Figure 18As shown, implementation 1800 includes a POS partner / terminal 1804, a payment gateway 1806, a merchant bank 1808, a payment network 1810, and a consumer bank 1812. In some non-limiting embodiments or aspects, the POS partner / terminal 1804 may be the same as or similar to POS partner / terminal 304 and / or POS partner / terminal 1704. In some non-limiting embodiments or aspects, the payment gateway 1806 may be the same as or similar to payment gateway 306 and / or payment gateway 1706. In some non-limiting embodiments or aspects, the merchant bank 1808 may be the same as or similar to merchant bank 308 and / or merchant bank 1708. In some non-limiting embodiments or aspects, the payment network 1810 may be the same as or similar to payment network 310 and / or payment network 1710. In some non-limiting embodiments or aspects, the consumer bank 1812 may be the same as or similar to consumer bank 312 and / or consumer bank 1712.

[0463] like Figure 18 As indicated by reference numeral 1820 in the attached figure, the POS terminal / partner 1804 can generate a random number (r) for the transaction message (m) associated with the transaction.

[0464] like Figure 18 As shown by reference numeral 1822 in the attached figure, the POS terminal / partner 1804 can generate a first ciphertext including a first ciphertext value and a second ciphertext value. As an example, the POS terminal / partner 1804 can generate a first ciphertext associated with a transaction. In such an example, the first ciphertext value can be associated with a transaction message (m), and the first ciphertext value is encrypted based on a random number (r), a generator value (g), and the transaction message (m). Alternatively, the second ciphertext value can be associated with a random number (r), and the second ciphertext value is encrypted based on the random number (r) and the terminal's public key.

[0465] In some non-limiting embodiments or aspects, the first ciphertext value may be generated as follows:

[0466] First ciphertext value = m·g r

[0467] In some non-limiting embodiments or aspects, the second ciphertext value may be generated as follows:

[0468]

[0469] like Figure 18 As indicated by reference numeral 1824 in the attached diagram, the POS terminal / partner 1804 can transmit the first ciphertext. As an example, the POS terminal / partner 1804 can transmit the first ciphertext to at least one payment gateway 1806.

[0470] like Figure 18 As shown by reference numeral 1826 in the attached figure, payment gateway 1806 can re-encrypt the second ciphertext value. As an example, payment gateway 1806 can re-encrypt the second ciphertext value based on a terminal random key to transform the second ciphertext value into a value based on the second value (g). a The second ciphertext value is re-encrypted from the merchant product (M) and the random number (r).

[0471] In some non-limiting embodiments or aspects, the second ciphertext value may be re-encrypted as follows:

[0472]

[0473] like Figure 18 As shown by reference numeral 1828 in the attached figure, payment gateway 1806 can transmit a second ciphertext value and a first ciphertext value that have been re-encrypted. As an example, payment gateway 1806 can transmit the re-encrypted second ciphertext value and the first ciphertext value to at least one merchant bank 1808.

[0474] like Figure 18 As shown by reference numeral 1830 in the attached diagram, Merchant Bank 1808 can re-encrypt the re-encrypted second ciphertext value into a second re-encrypted second ciphertext value. As an example, Merchant Bank 1808 can use a random key (rk) i The re-encrypted second ciphertext value is re-encrypted to transform the re-encrypted second ciphertext value into a value based on the second value (g). a Merchant product (M), Merchant random number (m) i The second ciphertext value is re-encrypted using the second ciphertext value and the second random number (r).

[0475] In some non-limiting embodiments or aspects, the re-encrypted second ciphertext value may be re-encrypted as follows:

[0476]

[0477] like Figure 18 As shown by reference numeral 1832 in the attached diagram, merchant bank 1808 can transmit a second re-encrypted second ciphertext value and a first ciphertext value. As an example, merchant bank 1808 can transmit the second re-encrypted second ciphertext value and the first ciphertext value to payment network 1810.

[0478] like Figure 18 As shown by reference numeral 1834 in the attached figure, the payment network 1810 can be based on the second re-encrypted second ciphertext value, the merchant product (M), and the merchant random number (m). i The first ciphertext value is decrypted. As an example, payment network 1810 can decrypt the second ciphertext value based on the second, re-encrypted ciphertext value, the merchant product (M), and the merchant random number (m). iThe first ciphertext value is decrypted using the first ciphertext value.

[0479] In some non-limiting embodiments or aspects, the payment network 1810 may transform the second re-encrypted second ciphertext value as follows:

[0480]

[0481] In some non-limiting embodiments or aspects, the payment network 1810 may decrypt the first ciphertext value to form the message (m) as follows:

[0482]

[0483] like Figure 18 As indicated by reference numeral 1836 in the accompanying drawings, payment network 1810 can transmit message (m) to consumer bank 1812. In some non-limiting embodiments or aspects, payment network 1810 may encrypt and / or re-encrypt message (m) using any suitable encryption and / or re-encryption techniques before and / or during communication with consumer bank 1812. For example, payment network 1810 may use any encryption and / or re-encryption techniques disclosed herein to encrypt and / or re-encrypt message (m).

[0484] Although the disclosed subject matter has been described in detail for illustrative purposes based on embodiments or aspects currently considered to be most practical and preferred, it should be understood that such details are for the purposes described 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 is intended to contemplate, as far as possible, that one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

1. A computer-implemented method for network binding proxy re-encryption and PIN translation, comprising: generating, by at least one point of sale terminal, a random number r of a transaction message m associated with a transaction; generating, by the at least one point of sale terminal, a first ciphertext associated with the transaction, the first ciphertext comprising: (i) a first ciphertext value associated with the transaction message m, the first ciphertext value encrypted based on the random number r, a generator value g, and the transaction message m; and ii) a second ciphertext value associated with the random number r, the second ciphertext value encrypted based on the random number r and a terminal public key; and communicating, by the point of sale terminal, the first ciphertext to at least one payment gateway; re-encrypting, by the at least one payment gateway, the second ciphertext value based on a terminal random key to transform the second ciphertext value into a re-encrypted second ciphertext value based on a second value g a a merchant product M, and the random number r; and communicating, by the at least one payment gateway, the re-encrypted second ciphertext value and the first ciphertext value to at least one merchant bank, wherein the computer-implemented method further comprises: generating, by a payment network, a first value a and the second value g a , the second value g a based on the first value a and the generator value g generating, by the payment network, a plurality of random merchant numbers m for a corresponding plurality of merchant banks i ; and by the payment network based on the plurality of random merchant numbers m i and determining the merchant product M.

2. The computer-implemented method of claim 1, further comprising: by the payment network based on the second value g a , the merchant product M and the random merchant number m i generating a public key pk i and based on the merchant product M and the random merchant number m i generating a random key rk i ; and transmitting the public key pk i and the random key rk i to at least one respective merchant bank by the payment network.

3. The computer-implemented method of claim 2, further comprising: generating, by the merchant bank, a plurality of random payment gateway numbers p for a corresponding plurality of payment gateways i ; and generating, by the merchant bank, a merchant public key based on the second value g a , the merchant product M, and the random payment gateway number p i generating a payment gateway public key and based on the random payment gateway number p for each respective payment gateway of the plurality of payment gateways i generating a payment gateway random key.

4. The computer-implemented method of claim 3, further comprising: generating, by the merchant bank, a plurality of terminal numbers t for a corresponding plurality of point of sale terminals i ; and Based on the second value g, the merchant bank a The merchant product M, the random payment gateway number p i and the terminal number t i Generate the terminal public key and based on the random payment gateway number p i and the terminal number t of each of the plurality of point-of-sale terminals. i Generate the terminal random key.

5. The computer-implemented method of claim 4, further comprising: communicating, by the merchant bank, the terminal public key and the terminal random key to the at least one payment gateway; and communicating, by the at least one payment gateway, the terminal public key to the at least one point of sale terminal.

6. The computer-implemented method of claim 1, further comprising: re-encrypting the second ciphertext value based on the random key rk i re-encrypting the re-encrypted second ciphertext value to transform the re-encrypted second ciphertext value into a second ciphertext value based on the second value g a , the merchant product M, a random merchant number m i and the random number r; and communicating, by the at least one merchant bank, the second re-encrypted second ciphertext value and the first ciphertext value to a payment network.

7. The computer-implemented method of claim 6, further comprising: decrypting, by the payment network, the first ciphertext value based on the second re-encrypted second ciphertext value, the merchant product M, the random merchant number m i and the first ciphertext value.

8. A system for network binding proxy re-encryption and PIN translation, comprising: at least one point of sale terminal comprising one or more processors, wherein the at least one point of sale terminal is programmed and / or configured to: generate a random number r of a transaction message m associated with a transaction; generate a first ciphertext associated with the transaction, the first ciphertext comprising: (i) a first ciphertext value associated with the transaction message m, the first ciphertext value encrypted based on the random number r, a generator value g, and the transaction message m; and ii) a second ciphertext value associated with the random number r, the second ciphertext value encrypted based on the random number r and a terminal public key; and communicate the first ciphertext to at least one payment gateway; and the at least one payment gateway comprising one or more processors, wherein the at least one payment gateway is further programmed and / or configured to: re-encrypting the second ciphertext value based on a terminal random key to transform the second ciphertext value into a second value g a a re-encrypted second ciphertext value based on a merchant product M and the random number r; and communicate the re-encrypted second ciphertext value and the first ciphertext value to at least one merchant bank, wherein the system further comprises: a payment network comprising one or more processors, wherein the payment network is programmed and / or configured to: generating a first value a and the second value g a , the second value g a based on the first value a and the generator value g generating a plurality of random merchant numbers m for a corresponding plurality of merchant banks i ; and based on the plurality of random merchant numbers m of the respective plurality of merchant banks i and determining the merchant product M.

9. The system of claim 8, wherein the payment network is further programmed and / or configured to: based on the second value g a , the merchant product M and the random merchant number m i generating a public key pk i and based on the merchant product M and the random merchant number m of each respective merchant bank of the plurality of merchant banks i generating a random key rk i ; and transmitting the public key pk i and the random key rk i to at least one respective merchant bank.

10. The system of claim 9, wherein the merchant bank comprises one or more processors, and wherein the merchant bank is programmed and / or configured to: generating a plurality of random payment gateway numbers p for a corresponding plurality of payment gateways i ; and based on the second value g a , the merchant product M and the random payment gateway number p i generating a payment gateway public key and based on the random payment gateway number p for each respective payment gateway of the plurality of payment gateways i generating a payment gateway random key.

11. The system of claim 10, wherein the merchant bank is further programmed and / or configured to: generating a plurality of terminal numbers t of a corresponding plurality of point-of-sale terminals i ; and based on the second value g a , the merchant product M, the random payment gateway number p i and the terminal number t i generating the terminal public key and based on the random payment gateway number p i and the terminal number t of each respective point of sale terminal of the plurality of point of sale terminals i generating the terminal random key.

12. The system of claim 11, wherein the merchant bank is further programmed and / or configured to: communicate the terminal public key and the terminal random key to the at least one payment gateway, and wherein the at least one payment gateway is programmed and / or configured to: communicate the terminal public key to the at least one point of sale terminal.

13. The system of claim 8, wherein the at least one merchant bank is further programmed and / or configured to: based on a random key rk i re-encrypting the re-encrypted second ciphertext value to transform the re-encrypted second ciphertext value into a second ciphertext value based on the second value g a , the merchant product M, a random merchant number m i and the random number r; and communicate the second re-encrypted second ciphertext value and the first ciphertext value to a payment network.

14. The system of claim 13, wherein the payment network comprises one or more processors, and wherein the payment network is programmed and / or configured to: based on the second re-encrypted second ciphertext value, the merchant product M, the random merchant number m i and the first ciphertext value decrypts the first ciphertext value.

15. A computer program product comprising at least one non-transitory computer- readable medium including program instructions, the program instructions, when executed by at least one processor, cause the at least one processor to: generate, by at least one point of sale terminal, a random number r for a transaction message m associated with a transaction; generate, by the at least one point of sale terminal, a first ciphertext associated with the transaction, the first ciphertext comprising: (i) a first ciphertext value associated with the transaction message m, the first ciphertext value encrypted based on the random number r, a generator value g, and the transaction message m; and (ii) a second ciphertext value associated with the random number r, the second ciphertext value encrypted based on the random number r and a terminal public key; and communicate, by the point of sale terminal, the first ciphertext to at least one payment gateway; re-encrypting, by the at least one payment gateway, the second ciphertext value based on a terminal random key to transform the second ciphertext value into a re-encrypted second ciphertext value based on a second value g a , a merchant product M, and the random number r; and communicate, by the at least one payment gateway, the re-encrypted second ciphertext value and the first ciphertext value to at least one merchant bank, wherein the instructions further cause the at least one processor to: generating, by the payment network, a first value a and the second value g a , the second value g a based on the first value a and the generator value g generating, by the payment network, a plurality of random merchant numbers m for a corresponding plurality of merchant banks i ; and by the payment network based on the plurality of random merchant numbers m i and determining the merchant product M.

16. The computer program product of claim 15, wherein the instructions further cause the at least one processor to: by the payment network based on the second value g a , the merchant product M and the random merchant number m i generating a public key pk i and based on the merchant product M and the random merchant number m of each respective merchant bank of the plurality of merchant banks i generating a random key rk i ; and transmitting the public key pk i and the random key rk i to at least one respective merchant bank by the payment network.

17. The computer program product of claim 16, wherein the instructions further cause the at least one processor to: generating, by the merchant bank, a plurality of random payment gateway numbers p for the corresponding plurality of payment gateways i ; and generating, by the merchant bank, a merchant public key based on the second value g a , the merchant product M, and the random payment gateway number p i generating a payment gateway public key and based on the random payment gateway number p for each respective payment gateway of the plurality of payment gateways i generating a payment gateway random key.

18. The computer program product of claim 17, wherein the instructions further cause the at least one processor to: generating, by the merchant bank, a plurality of terminal numbers t for a corresponding plurality of point of sale terminals i ; and generating, by the merchant bank, the terminal public key based on the second value g a , the merchant product M, the random payment gateway number p i , and the terminal number t i generating the terminal public key based on the random payment gateway number p i , and the terminal number t i of each respective point of sale terminal of the plurality of point of sale terminals.

19. The computer program product of claim 18, wherein the instructions further cause the at least one processor to: communicate, by the merchant bank, the terminal public key and the terminal random key to the at least one payment gateway; and communicate, by the at least one payment gateway, the terminal public key to the at least one point of sale terminal.

20. The computer program product of claim 15, wherein the instructions further cause the at least one processor to: re-encrypting the re-encrypted second ciphertext value based on a random key rk i re-encrypting the re-encrypted second ciphertext value to transform the re-encrypted second ciphertext value based on the second value g a , the merchant product M, a random merchant number m i and the random number r; and communicate, by the at least one merchant bank, the second re-encrypted second ciphertext value and the first ciphertext value to a payment network.

21. The computer program product of claim 20, wherein the instructions further cause the at least one processor to: decrypting, by the payment network, the first ciphertext value based on the second re-encrypted second ciphertext value, the merchant product M, the random merchant number m i and the first ciphertext value.

Images