用于网络绑定代理重新加密和PIN转换的方法、系统和计算机程序产品

相关申请交叉引用

本申请与2019年1月9日申请的第62/790,163号和2019年11月1日申请的第62/929,344号美国临时专利申请有关，所述临时专利申请的公开内容以全文引用的方式并入本文中。

技术领域

本文公开的主题一般涉及用于传送PIN和其它敏感数据的方法、系统和产品，且在一些具体实施例或方面，涉及用于安全发送PIN和其它敏感数据的方法、系统和计算机程序产品。

背景技术

信用卡和借记卡支付交易由大量各方处理，包括销售点(POS)终端、支付网关、商家银行、支付网络和消费者银行。为减少欺诈性交易，支付生态系统通常部署基于个人标识号(PIN)的认证，其中消费者将PIN输入到终端，所述PIN将以被加密形式随同例如个人账号(PAN)等其它敏感数据一起通过整个网络发送到消费者的银行，所述银行在授权交易之前验证PIN。不足为奇，支付卡行业(PCI)法规规定PIN绝不会向任何一方公开。目前的部署通过在将PIN转发到下一方之前在每个中介机构使用硬件安全模块(HSM)对PIN进行解密然后加密来实现合规性。

因此，从支付网关开始，HSM在所有中介机构中大量存在。这将产生巨大的成本，部分原因是购买和维护这些HSM，且部分原因是观察和管理PCI合规性的负担。此外，HSM成为性能瓶颈，因为任何一方的支付交易的最大吞吐量取决于该方可用HSM的数量，这在偶尔的流量高峰期间(例如节假日期间)会产生更多问题。例如，一些支付网络平均每秒处理5,000个交易，且被设计成每秒最高处理60,000个交易；因此，必须部署大量的HSM以确保足够的硬件并行性来处理这种吞吐量。

发明内容

因此，本公开主题的一个目的是提供用于安全发送个人标识号(PIN)和其它敏感数据的方法、系统和计算机程序产品。

根据一些非限制性实施例或方面，提供一种方法、系统和计算机程序产品，其：由销售点(POS)终端生成与交易相关联的第一密文，所述第一密文包括：(i)与随机选择密钥(r)相关联的第一密文值，所述第一密文值基于所述随机选择密钥(r)和生成器值(g)加密；以及(ii)与包括第一公钥(pk

根据一些非限制性实施例或方面，提供一种方法、系统和计算机程序产品，其：在支付网关处接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；将所述商家银行公钥从所述支付网关传送到销售点系统；从所述销售点系统接收至少一个重新加密密钥，所述至少一个重新加密密钥基于与所述销售点系统相关联的私钥以及所述商家银行公钥；从所述销售点系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥且对应于与所述销售点系统相关联的所述私钥；由所述支付网关基于所述被加密交易数据确定所述至少一个重新加密密钥中的重新加密密钥；由所述支付网关用所述重新加密密钥对所述被加密会话密钥重新加密；以及由所述支付网关将被重新加密的被加密会话密钥传送到商家银行系统。

根据一些非限制性实施例或方面，提供一种方法、系统和计算机程序产品，其：由销售点系统生成与所述销售点系统相关联的公钥和私钥；在所述销售点系统处接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；由销售点系统基于与所述销售点系统相关联的所述私钥生成至少一个重新加密密钥；将所述至少一个重新加密密钥从所述销售点系统传送到支付网关；由所述销售点系统生成交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用与所述销售点系统相关联的所述公钥加密的所述会话密钥的被加密会话密钥；以及将所述被加密交易数据从所述销售点系统传送到所述支付网关。

根据一些非限制性实施例或方面，提供一种方法、系统和计算机程序产品，其：由商家银行系统生成与所述商家银行系统相关联的公钥和私钥；由所述商家银行系统将与所述商家银行系统相关联的所述公钥传送到支付网关；由所述商家银行系统从所述支付网关接收被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用重新加密密钥加密的被加密会话密钥的被重新加密的被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥；以及由所述商家银行系统基于与所述商家银行系统相关联的所述私钥对所述被重新加密的被加密会话密钥解密。

根据一些非限制性实施例或方面，提供一种方法、系统和计算机程序产品，其：由交易处理系统接收或生成包括发行方公钥和对应发行方私钥的发行方密钥对，所述发行方密钥对与发行方系统相关联；由所述交易处理系统接收或生成包括商家银行公钥和对应商家银行私钥的商家银行密钥对，所述商家银行密钥对与商家银行系统相关联；由所述交易处理系统至少部分地基于所述发行方密钥对和所述商家银行密钥对生成至少一个重新加密密钥；从所述商家银行系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用所述商家银行公钥加密的会话密钥的被加密会话密钥；用所述至少一个重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥和所述被加密代码传送到所述发行方系统。

根据一些非限制性实施例或方面，提供一种方法、系统和计算机程序产品，其：由支付网络生成第一值(a)和第二值(g

在以下编号条款中阐述其它非限制性实施例或方面：

条款1.一种计算机实现的方法，其包括：由销售点(POS)终端生成与交易相关联的第一密文，所述第一密文包括：(i)与随机选择密钥(r)相关联的第一密文值，所述第一密文值基于所述随机选择密钥(r)和生成器值(g)加密；以及(ii)与包括第一公钥(pk

条款2.根据条款1所述的计算机实现的方法，其中中介机构服务器通过对所述第二密文值解密并使用所述交易数据的一部分确定用于后续传送的路径选择和对应重新加密密钥来在多个不同方之间转换。

条款3.根据条款1和2中任一项所述的计算机实现的方法，其中所述交易数据包括移动个人标识号(PIN)、卡验证号或与其相关联的卡号中的至少一个。

条款4.根据条款1至3中任一项所述的计算机实现的方法，其中所述第二密文值用于根据受所述第一密文值保护的所述随机选择密钥(r)对个人标识号(PIN)加密，并且其中重新加密会在所述第二密文值不变的情况下生成新密文值。

条款5.一种系统，其包括：包括一个或多个处理器的销售点(POS)终端，其中所述POS终端被编程和/或配置成：生成与交易相关联的第一密文，所述第一密文包括：(i)与随机选择密钥(r)相关联的第一密文值，所述第一密文值基于所述随机选择密钥(r)和生成器值(g)加密；以及(ii)与包括第一公钥(pk

条款6.根据条款5所述的系统，还包括中介机构服务器，其被编程和/或配置成通过对所述第二密文值解密并使用所述交易数据的一部分确定用于后续传送的路径选择和对应重新加密密钥来在多个不同方之间转换。

条款7.根据条款5和6中任一项所述的系统，其中所述交易数据包括移动个人标识号(PIN)、卡验证号或与其相关联的卡号中的至少一个。

条款8.根据条款5至7中任一项所述的系统，其中所述第二密文值用于根据受所述第一密文值保护的所述随机选择密钥(r)对个人标识号(PIN)加密，并且其中重新加密会在所述第二密文值不变的情况下生成新密文值。

条款9.一种包括至少一个非瞬态计算机可读介质的计算机程序产品，所述至少一个非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：由销售点(POS)终端生成与交易相关联的第一密文，所述第一密文包括：(i)与随机选择密钥(r)相关联的第一密文值，所述第一密文值基于所述随机选择密钥(r)和生成器值(g)加密；以及(ii)与包括第一公钥(pk

条款10.根据条款9所述的计算机程序产品，其中中介机构服务器通过对所述第二密文值解密并使用所述交易数据的一部分确定用于后续传送的路径选择和对应重新加密密钥来在多个不同方之间转换。

条款11.根据条款9和10中任一项所述的计算机程序产品，其中所述交易数据包括移动个人标识号(PIN)、卡验证号或与其相关联的卡号中的至少一个。

条款12.根据条款9至11中任一项所述的计算机程序产品，其中所述第二密文值用于根据受所述第一密文值保护的所述随机选择密钥(r)对个人标识号(PIN)加密，并且其中重新加密会在所述第二密文值不变的情况下生成新密文值。

条款13.一种对认证码加密的方法，包括：在支付网关处接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；将所述商家银行公钥从所述支付网关传送到销售点系统；从所述销售点系统接收至少一个重新加密密钥，所述至少一个重新加密密钥基于与所述销售点系统相关联的私钥以及所述商家银行公钥；从所述销售点系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥且对应于与所述销售点系统相关联的所述私钥；由所述支付网关基于所述被加密交易数据确定所述至少一个重新加密密钥中的重新加密密钥；由所述支付网关用所述重新加密密钥对所述被加密会话密钥重新加密；以及由所述支付网关将被重新加密的被加密会话密钥传送到商家银行系统。

条款14.根据条款13所述的方法，其中所述销售点系统包括以下至少一种：销售点终端、与商家或商家银行系统相关联的服务器计算机、与销售点服务提供商相关联的服务器计算机，或其任何组合。

条款15.根据条款13和14中任一项所述的方法，其中所述至少一个重新加密密钥包括多个重新加密密钥，并且其中所述多个重新加密密钥中的每个重新加密密钥对应于多个商家银行公钥中的公钥，所述多个商家银行公钥包括所述商家银行公钥。

条款16.根据条款13至15中任一项所述的方法，其中所述至少一个重新加密密钥由所述销售点系统生成。

条款17.根据条款13至16中任一项所述的方法，其中与所述销售点系统相关联的所述私钥对应于公钥，并且其中与所述销售点系统相关联的所述私钥和公钥由所述销售点系统生成。

条款18.根据条款13至17中任一项所述的方法，还包括：在交易处理系统处接收或生成对应于发行方私钥的发行方公钥，所述发行方公钥和所述发行方私钥与发行方系统相关联；由所述交易处理系统基于所述发行方私钥和所述商家银行私钥或第二商家银行私钥生成至少一个第二重新加密密钥；用所述至少一个第二重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥传送到所述发行方系统。

条款19.根据条款13至18中任一项所述的方法，还包括：由所述商家银行系统或所述支付网关响应于验证所述认证码而生成授权请求消息；以及由所述商家银行系统或所述支付网关将所述授权请求消息传送到交易处理系统。

条款20.一种对认证码加密的方法，包括：由销售点系统生成与所述销售点系统相关联的公钥和私钥；在所述销售点系统处接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；由销售点系统基于与所述销售点系统相关联的所述私钥生成至少一个重新加密密钥；将所述至少一个重新加密密钥从所述销售点系统传送到支付网关；由所述销售点系统生成交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用与所述销售点系统相关联的所述公钥加密的所述会话密钥的被加密会话密钥；以及将所述被加密交易数据从所述销售点系统传送到所述支付网关。

条款21.根据条款20所述的方法，其中所述销售点系统包括以下至少一种：销售点终端、与商家或商家银行系统相关联的服务器计算机、与销售点服务提供商相关联的服务器计算机，或其任何组合。

条款22.根据条款20和21中任一项所述的方法，其中所述至少一个重新加密密钥包括多个重新加密密钥，并且其中所述多个重新加密密钥中的每个重新加密密钥对应于多个商家银行公钥中的公钥，所述多个商家银行公钥包括所述商家银行公钥。

条款23.一种对认证码加密的方法，包括：由商家银行系统生成与所述商家银行系统相关联的公钥和私钥；由所述商家银行系统将与所述商家银行系统相关联的所述公钥传送到支付网关；由所述商家银行系统从所述支付网关接收被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用重新加密密钥加密的被加密会话密钥的被重新加密的被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥；以及由所述商家银行系统基于与所述商家银行系统相关联的所述私钥对所述被重新加密的被加密会话密钥解密。

条款24.根据条款23所述的方法，还包括：由所述商家银行系统响应于验证所述认证码而生成授权请求消息；以及由所述商家银行系统将所述授权请求消息传送到交易处理系统。

条款25.一种对认证码加密的方法，包括：由交易处理系统接收或生成包括发行方公钥和对应发行方私钥的发行方密钥对，所述发行方密钥对与发行方系统相关联；由所述交易处理系统接收或生成包括商家银行公钥和对应商家银行私钥的商家银行密钥对，所述商家银行密钥对与商家银行系统相关联；由所述交易处理系统至少部分地基于所述发行方密钥对和所述商家银行密钥对生成至少一个重新加密密钥；从所述商家银行系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用所述商家银行公钥加密的会话密钥的被加密会话密钥；用所述至少一个重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥和所述被加密代码传送到所述发行方系统。

条款26.根据条款25所述的方法，还包括：由所述发行方系统从所述交易处理系统接收所述被重新加密的被加密会话密钥；由所述发行方系统至少部分地基于所述发行方私钥对所述被重新加密的被加密会话密钥解密；以及由所述发行方系统至少部分地基于所述会话密钥对所述被加密代码解密。

条款27.一种用于对认证码加密的系统，包括支付网关，所述支付网关包括至少一个处理器，所述至少一个处理器被编程或配置成：接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；将所述商家银行公钥传送到销售点系统；从所述销售点系统接收至少一个重新加密密钥，所述至少一个重新加密密钥基于与所述销售点系统相关联的私钥以及所述商家银行公钥；从所述销售点系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥且对应于与所述销售点系统相关联的所述私钥；基于所述被加密交易数据确定所述至少一个重新加密密钥中的重新加密密钥；用所述重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥传送到商家银行系统。

条款28.根据条款27所述的系统，其中所述销售点系统包括以下至少一种：销售点终端、与商家或商家银行系统相关联的服务器计算机、与销售点服务提供商相关联的服务器计算机，或其任何组合。

条款29.根据条款27和28中任一项所述的系统，其中所述至少一个重新加密密钥包括多个重新加密密钥，并且其中所述多个重新加密密钥中的每个重新加密密钥对应于多个商家银行公钥中的公钥，所述多个商家银行公钥包括所述商家银行公钥。

条款30.根据条款27至29中任一项所述的系统，其中所述至少一个重新加密密钥由所述销售点系统生成。

条款31.根据条款27至30中任一项所述的系统，其中与所述销售点系统相关联的所述私钥对应于公钥，并且其中与所述销售点系统相关联的所述私钥和公钥由所述销售点系统生成。

条款32.根据条款27至31中任一项所述的系统，还包括交易处理系统，所述交易处理系统包括至少一个处理器，所述至少一个处理器被编程或配置成：接收或生成对应于发行方私钥的发行方公钥，所述发行方公钥和所述发行方私钥与发行方系统相关联；基于所述发行方私钥和所述商家银行私钥或第二商家银行私钥生成至少一个第二重新加密密钥；用所述至少一个第二重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥传送到所述发行方系统。

条款33.根据条款27至32中任一项所述的系统，其中所述支付网关的所述至少一个处理器或所述商家银行系统的至少一个处理器被编程或配置成：响应于验证所述认证码而生成授权请求消息；以及将所述授权请求消息传送到交易处理系统。

条款34.一种用于对认证码加密的系统，包括销售点系统，所述销售点系统包括至少一个处理器，所述至少一个处理器被编程或配置成：生成与所述销售点系统相关联的公钥和私钥；接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；基于与所述销售点系统相关联的所述私钥生成至少一个重新加密密钥；将所述至少一个重新加密密钥传送到支付网关；生成交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用与所述销售点系统相关联的所述公钥加密的所述会话密钥的被加密会话密钥；以及将所述被加密交易数据传送到所述支付网关。

条款35.根据条款34所述的系统，其中所述销售点系统包括以下至少一种：销售点终端、与商家或商家银行系统相关联的服务器计算机、与销售点服务提供商相关联的服务器计算机，或其任何组合。

条款36.根据条款34和35中任一项所述的系统，其中所述至少一个重新加密密钥包括多个重新加密密钥，并且其中所述多个重新加密密钥中的每个重新加密密钥对应于多个商家银行公钥中的公钥，所述多个商家银行公钥包括所述商家银行公钥。

条款37.一种用于对认证码加密的系统，包括商家银行系统，所述商家银行系统包括至少一个处理器，所述至少一个处理器被编程或配置成：生成与所述商家银行系统相关联的公钥和私钥；将与所述商家银行系统相关联的所述公钥传送到支付网关；从所述支付网关接收被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用重新加密密钥加密的被加密会话密钥的被重新加密的被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥；以及基于与所述商家银行系统相关联的所述私钥对所述被重新加密的被加密会话密钥解密。

条款38.根据条款37所述的系统，其中所述至少一个处理器还被编程或配置成：响应于验证所述认证码而生成授权请求消息；以及将所述授权请求消息传送到交易处理系统。

条款39.一种用于对认证码加密的系统，包括交易处理系统，所述交易处理系统包括至少一个处理器，所述至少一个处理器被编程或配置成：接收或生成包括发行方公钥和对应发行方私钥的发行方密钥对，所述发行方密钥对与发行方系统相关联；接收或生成包括商家银行公钥和对应商家银行私钥的商家银行密钥对，所述商家银行密钥对与商家银行系统相关联；至少部分地基于所述发行方密钥对和所述商家银行密钥对生成至少一个重新加密密钥；从所述商家银行系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用所述商家银行公钥加密的会话密钥的被加密会话密钥；用所述至少一个重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥和所述被加密代码传送到所述发行方系统。

条款40.根据条款39所述的系统，还包括所述发行方系统，所述发行方系统包括至少一个处理器，所述至少一个处理器被编程或配置成：从所述交易处理系统接收所述被重新加密的被加密会话密钥；至少部分地基于所述发行方私钥对所述被重新加密的被加密会话密钥解密；以及至少部分地基于所述会话密钥对所述被加密代码解密。

条款41.一种包括至少一个非瞬态计算机可读介质的计算机程序产品，所述至少一个非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：在支付网关处接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；将所述商家银行公钥从所述支付网关传送到销售点系统；从所述销售点系统接收至少一个重新加密密钥，所述至少一个重新加密密钥基于与所述销售点系统相关联的私钥以及所述商家银行公钥；从所述销售点系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥且对应于与所述销售点系统相关联的所述私钥；由所述支付网关基于所述被加密交易数据确定所述至少一个重新加密密钥中的重新加密密钥；用所述重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥传送到商家银行系统。

条款42.根据条款41所述的计算机程序产品，其中所述销售点系统包括以下至少一种：销售点终端、与商家或商家银行系统相关联的服务器计算机、与销售点服务提供商相关联的服务器计算机，或其任何组合。

条款43.根据条款41和42中任一项所述的计算机程序产品，其中所述至少一个重新加密密钥包括多个重新加密密钥，并且其中所述多个重新加密密钥中的每个重新加密密钥对应于多个商家银行公钥中的公钥，所述多个商家银行公钥包括所述商家银行公钥。

条款44.根据条款41至43中任一项所述的计算机程序产品，其中所述至少一个重新加密密钥由所述销售点系统生成。

条款45.根据条款41至44中任一项所述的计算机程序产品，其中与所述销售点系统相关联的所述私钥对应于公钥，并且其中与所述销售点系统相关联的所述私钥和公钥由所述销售点系统生成。

条款46.根据条款41至45中任一项所述的计算机程序产品，其中所述一个或多个处理器还被编程和/或配置成：在交易处理系统处接收或生成对应于发行方私钥的发行方公钥，所述发行方公钥和所述发行方私钥与发行方系统相关联；由所述交易处理系统基于所述发行方私钥和所述商家银行私钥或第二商家银行私钥生成至少一个第二重新加密密钥；用所述至少一个第二重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥传送到所述发行方系统。

条款47.根据条款41至46中任一项所述的计算机程序产品，其中所述一个或多个处理器还被编程和/或配置成：由所述商家银行系统或所述支付网关响应于验证所述认证码而生成授权请求消息；以及由所述商家银行系统或所述支付网关将所述授权请求消息传送到交易处理系统。

条款48.一种包括至少一个非瞬态计算机可读介质的计算机程序产品，所述至少一个非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：由销售点系统生成与所述销售点系统相关联的公钥和私钥；在所述销售点系统处接收对应于商家银行私钥的商家银行公钥，所述商家银行公钥和所述商家银行私钥与商家银行系统相关联；由销售点系统基于与所述销售点系统相关联的所述私钥生成至少一个重新加密密钥；将所述至少一个重新加密密钥从所述销售点系统传送到支付网关；由所述销售点系统生成交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用与所述销售点系统相关联的所述公钥加密的所述会话密钥的被加密会话密钥；以及将所述被加密交易数据从所述销售点系统传送到所述支付网关。

条款49.根据条款48所述的计算机程序产品，其中所述销售点系统包括以下至少一种：销售点终端、与商家或商家银行系统相关联的服务器计算机、与销售点服务提供商相关联的服务器计算机，或其任何组合。

条款50.根据条款48和49中任一项所述的计算机程序产品，其中所述至少一个重新加密密钥包括多个重新加密密钥，并且其中所述多个重新加密密钥中的每个重新加密密钥对应于多个商家银行公钥中的公钥，所述多个商家银行公钥包括所述商家银行公钥。

条款51.一种包括至少一个非瞬态计算机可读介质的计算机程序产品，所述至少一个非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：由商家银行系统生成与所述商家银行系统相关联的公钥和私钥；由所述商家银行系统将与所述商家银行系统相关联的所述公钥传送到支付网关；由所述商家银行系统从所述支付网关接收被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用重新加密密钥加密的被加密会话密钥的被重新加密的被加密会话密钥，所述被加密会话密钥包括用与所述销售点系统相关联的公钥加密的所述会话密钥；以及由所述商家银行系统基于与所述商家银行系统相关联的所述私钥对所述被重新加密的被加密会话密钥解密。

条款52.根据条款51所述的计算机程序产品，其中所述一个或多个处理器还被编程和/或配置成：由所述商家银行系统响应于验证所述认证码而生成授权请求消息；以及由所述商家银行系统将所述授权请求消息传送到交易处理系统。

条款53.一种包括至少一个非瞬态计算机可读介质的计算机程序产品，所述至少一个非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：由交易处理系统接收或生成包括发行方公钥和对应发行方私钥的发行方密钥对，所述发行方密钥对与发行方系统相关联；由所述交易处理系统接收或生成包括商家银行公钥和对应商家银行私钥的商家银行密钥对，所述商家银行密钥对与商家银行系统相关联；由所述交易处理系统至少部分地基于所述发行方密钥对和所述商家银行密钥对生成至少一个重新加密密钥；从所述商家银行系统接收交易的被加密交易数据，所述被加密交易数据包括：(i)包括用会话密钥加密的认证码的被加密代码，以及(ii)包括用所述商家银行公钥加密的会话密钥的被加密会话密钥；用所述至少一个重新加密密钥对所述被加密会话密钥重新加密；以及将被重新加密的被加密会话密钥和所述被加密代码传送到所述发行方系统。

条款54.根据条款53所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述发行方系统从所述交易处理系统接收所述被重新加密的被加密会话密钥；由所述发行方系统至少部分地基于所述发行方私钥对所述被重新加密的被加密会话密钥解密；以及由所述发行方系统至少部分地基于所述会话密钥对所述被加密代码解密。

条款55.一种计算机实现的方法，包括：由支付网络生成第一值(a)和第二值(g

条款56.根据条款55所述的计算机实现的方法，还包括：由所述商家银行生成相应多个支付网关的多个随机支付网关号(P

条款57.根据条款55和56中任一项所述的计算机实现的方法，还包括：由所述商家银行生成相应多个销售点(POS)终端的多个终端号(t

条款58.根据条款55至57中任一项所述的计算机实现的方法，还包括：由所述商家银行将所述终端公钥和所述终端随机密钥传送到至少一个支付网关；以及由所述到至少一个支付网关将所述终端公钥传送到至少一个POS终端。

条款59.根据条款55至58中任一项所述的计算机实现的方法，还包括：由所述至少一个POS终端生成与交易相关联的交易消息(m)的随机数(r)；由所述至少一个POS终端生成与交易相关联的第一密文，所述第一密文包括：(i)与所述交易消息(m)相关联的第一密文值，所述第一密文值基于所述随机数(r)、生成器值(g)和所述交易消息(m)加密；以及ii)与所述随机数(r)相关联的第二密文值，所述第二密文值基于所述随机数(r)和所述终端公钥加密；以及由所述POS终端将所述第一密文传送到所述至少一个支付网关。

条款60.根据条款55至59中任一项所述的计算机实现的方法，还包括：由所述至少一个支付网关基于所述终端随机密钥对所述第二密文值重新加密，以将所述第二密文值转化为基于所述第二值(g

条款61.根据条款55至60中任一项所述的计算机实现的方法，还包括：由所述至少一个商家银行基于所述随机密钥(rk

条款62.根据条款55至61中任一项所述的计算机实现的方法，还包括：由所述支付网络基于所述第二被重新加密第二密文值、所述商家乘积(M)、所述商家随机数(m

条款63.一种系统，包括：包括一个或多个处理器的支付网络，其中所述支付网络被编程和/或配置成：生成第一值(a)和第二值(g

条款64.根据条款63所述的系统，其中所述商家银行包括一个或多个处理器，并且其中所述商家银行被编程和/或配置成：生成相应多个支付网关的多个随机支付网关号(P

条款65.根据条款63和64中任一项所述的系统，其中所述商家银行还被编程和/或配置成：生成相应多个销售点(POS)终端的多个终端号(t

条款66.根据条款63至65中任一项所述的系统，其中所述商家银行还被编程和/或配置成：将所述终端公钥和所述终端随机密钥传送到至少一个支付网关，其中所述至少一个支付网关包括一个或多个处理器，并且其中所述至少一个支付网关被编程和/或配置成：将所述终端公钥传送到至少一个POS终端。

条款67.根据条款63至66中任一项所述的系统，其中所述至少一个POS终端包括一个或多个处理器，并且其中所述至少一个POS终端被编程和/或配置成：生成与交易相关联的交易消息(m)的随机数(r)；生成与交易相关联的第一密文，所述第一密文包括：(i)与所述交易消息(m)相关联的第一密文值，所述第一密文值基于所述随机数(r)、生成器值(g)和所述交易消息(m)加密；以及ii)与所述随机数(r)相关联的第二密文值，所述第二密文值基于所述随机数(r)和所述终端公钥加密；以及将所述第一密文传送到所述至少一个支付网关。

条款68.根据条款63至67中任一项所述的系统，其中所述至少一个支付网关还被编程和/或配置成：基于所述终端随机密钥对所述第二密文值重新加密，以将所述第二密文值转化为基于所述第二值(g

条款69.根据条款63至68中任一项所述的系统，其中所述至少一个商家银行还被编程和/或配置成：基于所述随机密钥(rk

条款70.根据条款63至69中任一项所述的系统，其中所述支付网络还被编程和/或配置成：基于所述第二被重新加密第二密文值、所述商家乘积(M)、所述商家随机数(mi)和所述第一密文值对所述第一密文值解密。

条款71.一种包括至少一个非瞬态计算机可读介质的计算机程序产品，所述至少一个非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：由支付网络生成第一值(a)和第二值(g

条款72.根据条款71所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述商家银行生成相应多个支付网关的多个随机支付网关号(P

条款73.根据条款71和72中任一项所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述商家银行生成相应多个销售点(POS)终端的多个终端号(t

条款74.根据条款71至73中任一项所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述商家银行将所述终端公钥和所述终端随机密钥传送到至少一个支付网关；以及由所述到至少一个支付网关将所述终端公钥传送到至少一个POS终端。

条款75.根据条款71至74中任一项所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述至少一个POS终端生成与交易相关联的交易消息(m)的随机数(r)；由所述至少一个POS终端生成与交易相关联的第一密文，所述第一密文包括：(i)与所述交易消息(m)相关联的第一密文值，所述第一密文值基于所述随机数(r)、生成器值(g)和所述交易消息(m)加密；以及ii)与所述随机数(r)相关联的第二密文值，所述第二密文值基于所述随机数(r)和所述终端公钥加密；以及由所述POS终端将所述第一密文传送到所述至少一个支付网关。

条款76.根据条款71至75中任一项所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述至少一个支付网关基于所述终端随机密钥对所述第二密文值重新加密，以将所述第二密文值转化为基于所述第二值(g

条款77.根据条款71至76中任一项所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述至少一个商家银行基于所述随机密钥(rk

条款78.根据条款71至77中任一项所述的计算机程序产品，其中所述指令还使所述至少一个处理器：由所述支付网络基于所述第二被重新加密第二密文值、所述商家乘积(M)、所述商家随机数(m

在参考附图考虑以下描述和所附权利要求书之后，当前公开的主题的这些和其它特征和特性，以及相关结构元件和各部分组合的操作方法和功能以及制造经济性将变得更加显而易见，所有附图形成本说明书的部分，其中相同的附图标记表示各图中的对应部分。然而，应明确地理解，图式仅出于说明和描述目的，并非旨在作为所公开主题的限制的定义。除非上下文另外明确规定，否则在本说明书和权利要求书中所用时，单数形式“一”及“所述”包括多个指示物。

附图说明

下文参考附图中示出的示例性实施例更详细地解释所公开主题的额外优点和细节，在附图中：

图1是可以根据本公开主题的原理实施本文描述的系统、方法和/或计算机程序产品的环境的非限制性实施例的图；

图2是图1的一个或多个装置的组件的非限制性实施例的图；

图3是用于PIN验证的系统的非限制性实施例或方面的图；

图4是示例ISO PIN块编码方案的图；

图5是示例PIN块加密方案的图；

图6是示例代理重新加密(PRE)诚实重新加密攻击-选择密文攻击(HRA-CCA)游戏Oracle数据库的图；

图7是示例私有代理认证(PPA)-HRCCA游戏Oracle数据库的图；

图8是根据PRE方案的PPA方案的示例构造图；

图9是混合PRE方案的示例构造图；

图10是用于安全发送PIN和其它敏感数据的过程的非限制性实施例或方面的流程图；

图11A-11C是用于安全发送PIN和其它敏感数据的过程的非限制性实施例或方面的流程图；

图12A和12B是示例Oracle数据库的图；

图13是本文公开的过程的非限制性实施例或方面的实施方案的信号流程图；

图14是本文公开的过程的非限制性实施例或方面的实施方案的信号流程图；

图15是本文公开的过程的非限制性实施例或方面的实施方案的信号流程图；

图16是本文公开的过程的非限制性实施例或方面的实施方案的信号流程图；

图17是本文公开的过程的非限制性实施例或方面的实施方案的信号流程图；以及

图18是本文公开的过程的非限制性实施例或方面的实施方案的信号流程图。

具体实施方式

下文出于描述的目的，术语“端”、“上”、“下”、“右”、“左”、“竖直”、“水平”、“顶部”、“底部”、“横向”、“纵向”以及其衍生词应涉及所公开主题如其在附图中的定向。然而，应理解，除了明确指定相反情况之外，所公开主题可以采用各种替代变化和步骤序列。还应理解，附图中示出的以及在以下说明书中描述的特定装置和过程仅仅是所公开主题的示例性实施例或方面。因此，除非另有指示，否则与本文公开的实施例或方面相关联的特定维度和其它物理特性不应被视为限制。

本文所使用的方面、组件、元件、结构、动作、步骤、功能、指令等都不应当被理解为关键的或必要的，除非明确地如此描述。并且，如本文中所使用，冠词“一”希望包括一个或多个项目，且可与“一个或多个”和“至少一个”互换使用。此外，如本文中所使用，术语“集合”希望包括一个或多个项目(例如，相关项目、不相关项目、相关项目与不相关项目的组合等)，并且可与“一个或多个”或“至少一个”互换使用。在希望仅有一个项目的情况下，使用术语“一个”或类似语言。且，如本文中所使用，术语“具有”等希望是开放式术语。另外，除非另外明确陈述，否则短语“基于”希望意味着“至少部分地基于”。

如本文中所使用，术语“通信”和“传送”可指信息(例如，数据、信号、消息、指令、命令等)的接收、接受、发送、传送、提供等。一个单元(例如，装置、系统、装置或系统的组件、其组合等)与另一单元通信意味着所述一个单元能够直接或间接地从所述另一单元接收信息和/或向所述另一单元发送信息。这可指在本质上有线和/或无线的直接或间接连接(例如，直接通信连接、间接通信连接等)。另外，尽管所发送的信息可以在第一单元与第二单元之间被修改、处理、中继和/或路由，但这两个单元也可以彼此通信。例如，即使第一单元被动地接收信息且不会主动地将信息发送到第二单元，第一单元也可以与第二单元通信。作为另一示例，如果至少一个中间单元(例如，位于第一单元与第二单元之间的第三单元)处理从第一单元接收的信息且将处理后的信息传送到第二单元，则第一单元可以与第二单元通信。在一些非限制性实施例或方面中，消息可以指代包括数据的网络包(例如，数据包等)。应了解，可能有许多其它布置。

如本文中所使用，术语“发行方机构”、“便携式金融装置发行方”、“发行方”或“发行方银行”可指代向客户提供账户用于进行交易(例如，支付交易)(例如发起信用和/或借记支付)的一个或多个实体。例如，发行方机构可向客户提供唯一地标识与所述客户相关联的一个或多个账户的账户标识符，例如主账号(PAN)。账户标识符可以在例如实体金融工具(例如，支付卡)等便携式金融装置上实施，和/或可以是电子的且用于电子支付。术语“发行方机构”和“发行方机构系统”也可指代由发行方机构或代表发行方机构操作的一个或多个计算机系统，例如执行一个或多个软件应用程序的服务器计算机。例如，发行方机构系统可以包括用于授权交易的一个或多个授权服务器。

如本文中所使用，术语“账户标识符”可包括与用户账户相关联的一种或多种类型的标识符(例如，PAN、卡号、支付卡号、令牌等)。在一些非限制性实施例或方面中，发行方机构可向用户提供账户标识符(例如，PAN、令牌等)，所述账户标识符唯一地标识与所述用户相关联的一个或多个账户。账户标识符可在物理金融工具(例如，便携式金融工具、支付卡、信用卡、借记卡等)上体现，和/或可为传送到用户使得用户可用于电子支付的电子信息。在一些非限制性实施例或方面中，账户标识符可以是原始账户标识符，其中在创建与账户标识符相关联的账户时，将原始账户标识符提供给用户。在一些非限制性实施例或方面中，账户标识符可以是在将原始账户标识符提供给用户之后提供给用户的账户标识符(例如，补充账户标识符)。例如，如果原始账户标识符被遗忘、被盗等，则补充账户标识符可提供给用户。在一些非限制性实施例或方面中，账户标识符可直接或间接地与发行方机构相关联，使得账户标识符可以是映射到PAN或其它类型账户标识符的令牌。账户标识符可以是文数字、字符和/或符号的任何组合等。发行方机构可以与唯一地标识发行方机构的银行标识号(BIN)相关联。

如本文中所使用，术语“支付令牌”或“令牌”可指代用作例如PAN的账户标识符的替代或替换标识符的标识符。令牌可与一种或多种数据结构(例如，一个或多个数据库等)中的PAN或其它账户标识符相关联，使得所述令牌可用于进行交易(例如，支付交易)而无需直接使用账户标识符，例如PAN。在一些示例中，例如PAN的账户标识符可以与用于不同个人、不同用途和/或不同目的的多个令牌相关联。例如，支付令牌可包括可以用作原始账户标识符的替代的一连串数字和/或字母数字字符。例如，支付令牌“4900 0000 0000 0001”可代替PAN“4147 0900 0000 1234”使用。在一些非限制性实施例或方面中，支付令牌可以是“保留格式的”，并且可以具有与现有支付处理网络中使用的账户标识符一致的数字格式(例如，ISO 8583金融交易消息格式)。在一些非限制性实施例或方面中，支付令牌可代替PAN用来发起、授权、结算或解决支付交易，或在通常会提供原始凭证的其它系统中表示原始凭证。在一些非限制性实施例或方面中，可以生成令牌值，使得可能无法以计算方式从令牌值得到原始PAN或其它账户标识符的恢复(例如，使用单向散列或其它密码函数)。此外，在一些非限制性实施例或方面中，令牌格式可被配置成允许接收支付令牌的实体将其标识为支付令牌，并辨识发行所述令牌的实体。

如本文中所使用,术语“提供”可指代使得装置能够使用资源或服务的过程。例如，提供可能涉及使得装置能够使用账户来执行交易。另外或替代地，提供可包括将与账户数据(例如，表示账号的支付令牌)相关联的提供数据添加到装置。

如本文中所使用，术语“令牌请求者”可指力图根据本公开主题的实施例或方面实施令牌化的实体。例如，令牌请求者可以通过向令牌服务提供商提交令牌请求消息来发起使PAN令牌化的请求。另外或替代地，一旦请求者已响应于令牌请求消息而接收支付令牌，令牌请求者就可能不再需要存储与令牌关联的PAN。在一些非限制性实施例或方面中，请求者可以是被配置成执行与令牌相关联的动作的应用程序、装置、过程或系统。例如，请求者可以请求注册网络令牌系统、请求令牌生成、令牌激活、令牌去激活、令牌交换、其它令牌生命周期管理相关过程和/或任何其它令牌相关过程。在一些非限制性实施例或方面中，请求者可以通过任何合适的通信网络和/或协议(例如，使用HTTPS、SOAP和/或XML接口等)与网络令牌系统连接。例如，令牌请求者可包括卡存档(card-on-file)商家、收单方、收单方处理器、代表商家操作的支付网关、支付使能者(enabler)(例如，原始设备制造商、移动网络运营商等)、数字钱包提供商、发行方、第三方钱包提供商、支付处理网络等。在一些非限制性实施例或方面中，令牌请求者可以针对多个域和/或信道请求令牌。另外或替代地，令牌化生态系统内的令牌服务提供商可以唯一地注册和标识令牌请求者。例如，在令牌请求者注册期间，令牌服务提供商可以正式处理令牌请求者的应用程序以参与令牌服务系统。在一些非限制性实施例或方面中，令牌服务提供商可以收集关于请求者的性质和令牌的相关使用的信息，以验证并正式批准令牌请求者并建立适当的域限制控制。另外或替代地，可以向成功注册的令牌请求者分配令牌请求者标识符，所述令牌请求者标识符也可以被输入并在令牌库内维护。在一些非限制性实施例或方面中，可以吊销令牌请求者标识符，和/或可以向令牌请求者分配新的令牌请求者标识符。在一些非限制性实施例或方面中，此信息可由令牌服务提供商进行报告和审计。

如本文中所使用，术语“令牌服务提供商”可指代包括令牌服务系统中的一个或多个服务器计算机的实体，所述实体生成、处理并维护支付令牌。例如，令牌服务提供商可以包括存储所生成令牌的令牌库或与所述令牌库通信。另外或替代地，令牌库可维护令牌与由令牌表示的PAN之间的一对一映射。在一些非限制性实施例或方面中，令牌服务提供商能够预留授权的BIN作为令牌BIN以发行可以提交给令牌服务提供商的PAN的令牌。在一些非限制性实施例或方面中，令牌化生态系统的各种实体可以承担令牌服务提供商的角色。例如，支付网络和发行方或其代理方可以通过实施根据本公开主题的非限制性实施例或方面的令牌服务而成为令牌服务提供商。另外或替代地，令牌服务提供商可以将报告或数据输出提供给有关被批准、待决或被拒绝的令牌请求的报告工具，包括任何分配的令牌请求者ID。令牌服务提供商可将与基于令牌的交易相关联的数据输出提供给报告工具和应用程序，并且按需要在报告输出中呈现令牌和/或PAN。在一些非限制性实施例或方面中，EMVCo标准组织可以发布限定令牌化系统可如何操作的规范。例如，此类规范可以是信息性的，但它们并不意图限制任何当前公开的主题。

如本文中所使用，术语“令牌库”可指代维护已建立的令牌到PAN映射的存储库。例如，令牌库还可以维护令牌请求者的其它属性，这些属性可以在注册时确定，和/或可以由令牌服务提供商使用以在交易处理期间应用域限制或其它控制。在一些非限制性实施例或方面中，令牌库可以是令牌服务系统的一部分。例如，令牌库可被提供为令牌服务提供商的一部分。另外或替代地，令牌库可以是令牌服务提供商可访问的远程存储库。在一些非限制性实施例或方面中，令牌库因其中存储和管理的数据映射的敏感性质而可受到强大的基础物理和逻辑安全性的保护。另外或替代地，令牌库可以由任何合适的实体操作，所述实体包括支付网络、发行方、清算所、其它金融机构、交易服务提供商等。

如本文中所使用，术语“商家”可指代一个或多个实体(例如，基于交易(例如，支付交易)向用户(例如，客户、消费者、商家的客户等)提供商品和/或服务和/或对商品和/或服务的访问的零售企业的运营者)。如本文中所使用，“商家系统”可以指代由商家或代表商家操作的一个或多个计算机系统，例如执行一个或多个软件应用程序的服务器计算机。如本文中所使用，术语“产品”可以指商家提供的一种或多种商品和/或服务。

如本文中所使用，“销售点(POS)装置”可指代可由商家使用以发起交易(例如，支付交易)、参与交易和/或处理交易的一个或多个装置。例如，POS装置可以包括一个或多个计算机、外围装置、读卡器、近场通信(NFC)接收器、射频标识(RFID)接收器和/或其它非接触式收发器或接收器、基于接触的接收器、支付终端、计算机、服务器、输入装置等。

如本文中所使用，“销售点(POS)系统”可以指商家用来进行交易的一个或多个计算机和/或外围装置。例如，POS系统可包括一个或多个POS装置，和/或可用于进行支付交易的其它类似装置。POS系统(例如，商家POS系统)还可以包括被编程或配置成通过网页、移动应用程序等等处理在线支付交易的一个或多个服务器计算机。

如本文中所使用，术语“交易服务提供商”可以指代接收来自商家或其它实体的交易授权请求且在一些情况下通过交易服务提供商与发行方机构之间的协议来提供支付保证的实体。在一些非限制性实施例或方面中，交易服务提供商可包括信用卡公司、借记卡公司等。如本文中所使用，术语“交易服务提供商系统”还可指代由交易服务提供商或代表交易服务提供商操作的一个或多个计算机系统，例如执行一个或多个软件应用的交易处理服务器。交易处理服务器可以包括一个或多个处理器，并且在一些非限制性实施例或方面中，可以由交易服务提供商或代表交易服务提供商操作。

如本文中所使用，术语“收单方”可以指由交易服务提供商许可且由交易服务提供商批准可以使用与交易服务提供商相关联的便携式金融装置发起交易(例如，支付交易)的实体。如本文中所使用，术语“收单方系统”也可以指由收单方或代表收单方操作的一个或多个计算机系统、计算机装置等等。收单方的交易可以包括支付交易(例如，购买、原始信用交易(OCT)、账户资金交易(AFT)等)。在一些非限制性实施例或方面中，收单方可以由交易服务提供商授权以与商家或服务提供商签约，来使用交易服务提供商的便携式金融装置发起交易。收单方可以与支付服务商签合约，以使支付服务商能够向商家提供赞助。收单方可以根据交易服务提供商规章监视支付服务商的合规性。收单方可以对支付服务商进行尽职调查，并确保在与受赞助的商家签约之前进行适当的尽职调查。收单方可能对收单方操作或赞助的所有交易服务提供商计划负责任。收单方可以负责收单方支付服务商、由收单方支付服务商赞助的商家等的行为。在一些非限制性实施例或方面中，收单方可以是金融机构，例如银行。

如本文中所使用，术语“电子钱包”、“电子钱包移动应用程序”和“数字钱包”可指代被配置成发起和/或进行交易(例如，支付交易、电子支付交易等)的一个或多个电子装置和/或一个或多个软件应用程序。例如，电子钱包可包括用户装置(例如，移动装置)执行用于维护和向用户装置提供交易数据的应用程序和服务器侧软件和/或数据库。如本文中所使用，术语“电子钱包提供商”可包括为用户(例如，客户)提供和/或维护电子钱包和/或电子钱包移动应用程序的实体。电子钱包提供商的示例包括但不限于Google

如本文中所使用，术语“便携式金融装置”可以指代支付卡(例如，信用卡或借记卡)、礼品卡、智能卡、智能介质、工资卡、医疗保健卡、腕带、含有账户信息的机器可读介质、钥匙链装置或吊坠、RFID应答器、零售商折扣或会员卡、蜂窝式电话、电子钱包移动应用程序、个人数字助理(PDA)、寻呼机、安全卡、计算机、访问卡、无线终端、应答器等。在一些非限制性实施例或方面中，便携式金融装置可以包括易失性或非易失性存储器以存储信息(例如，账户标识符、账户持有人的姓名等)。

如本文中所使用，术语“支付网关”可指实体和/或由此类实体或代表此类实体操作的支付处理系统，所述实体(例如商家服务提供商、支付服务提供商、支付服务商、与收单方有合约的支付服务商、支付集合人(payment aggregator)等)将支付服务(例如交易服务提供商支付服务、支付处理服务等)提供到一个或多个商家。支付服务可与由交易服务提供商管理的便携式金融装置的使用相关联。如本文中所使用，术语“支付网关系统”可指代由支付网关或代表支付网关操作的一个或多个计算机系统、计算机装置、服务器、服务器群组等，和/或支付网关本身。术语“支付网关移动应用”可指代被配置成提供交易(例如，支付交易、电子支付交易等)的支付服务的一个或多个电子装置和/或一个或多个软件应用。

如本文中所使用，术语“客户端”和“客户端装置”可指代用于发起或促进交易(例如，支付交易)的一个或多个客户端侧装置或系统(例如，在交易服务提供商的远程处)。作为示例，“客户端装置”可指代由商家使用的一个或多个POS装置、由收单方使用的一个或多个收单方主机计算机、由用户使用的一个或多个移动装置等。在一些非限制性实施例或方面中，客户端装置可以是被配置成与一个或多个网络通信并发起或促进交易的电子装置。例如，客户端装置可包括一个或多个计算机、便携式计算机、膝上型计算机、平板计算机、移动装置、蜂窝式电话、可穿戴装置(例如，手表、眼镜、镜片、衣物等)、PDA等。此外，“客户端”还可指代拥有、利用和/或操作客户端装置用于发起交易(例如，用于发起与交易服务提供商的交易)的实体(例如，商家、收单方等)。

如本文中所使用，术语“服务器”可指代经由网络(例如，公用网络、因特网、专用网络等)与客户端装置和/或其它计算装置通信且在一些示例中促进其它服务器和/或客户端装置之间的通信的一个或多个计算装置(例如，处理器、存储装置、类似的计算机组件等)。应了解，可能有各种其它布置。如本文中所使用，术语“系统”可指代一个或多个计算装置或计算装置的组合(例如，处理器、服务器、客户端装置、软件应用程序、这些计算装置的组件等)。如本文中所使用对“装置”、“服务器”、“处理器”等的提及可指代陈述为执行先前步骤或功能的先前陈述的装置、服务器或处理器、不同的服务器或处理器，和/或服务器和/或处理器的组合。例如，如说明书和权利要求书所使用，陈述为执行第一步骤或第一功能的第一服务器或第一处理器可指代陈述为执行第二步骤或第二功能的相同或不同服务器或相同或不同处理器。

出于说明的目的，在以下描述中，虽然本公开主题是关于用于安全传送敏感数据(例如，PIN认证)的方法、系统和计算机程序产品而描述的，但本领域的技术人员将认识到，所公开的主题不限于说明性实施例。例如，本文描述的方法、系统和计算机程序产品可以与各种设置一起使用，例如在任何合适的设置中安全传送敏感数据(例如，社会保障号、个人标识信息、联系信息、医疗保健信息、税务信息、机密信息、特权信息、商业秘密信息、支付交易信息、账户标识符等)。

非限制性实施例或方面提供基于代理重新加密的PIN认证的改进方法，这些方法避免在交易处理期间HSM在中介机构使用的情况。基于公钥加密的更简单机制(从终端直接到消费者的银行)不能用于此设置的原因将在本文标题为“稻草人(Strawman)解决方案”的章节详细讨论。HMS不是在交易处理期间使用HSMS，而是在初始设置阶段仅用于主要仪式。在交易处理过程中不使用HSM，而是只在初始设置阶段针对密钥仪式使用HSM。在密钥仪式之后，可以使用初始公钥和后续重新加密密钥，而不需要可信硬件。由于PIN转换是唯一需要在支付网关和商家银行使用HSM的操作，因此降低了与使用HSM和依赖HSM相关联的基础设施和合规性成本(但是支付网络和消费者银行可能会将HSM用于其它功能(例如PIN/CVV验证))。

部署升级既耗时又昂贵。例如，在美国部署EMV系统花了将近十年的时间。由于支付生态系统中有大量参与方，潜在解决方案的设计空间很大，并且可能会确定若干稻草人方案，但由于部署挑战或重大成本(例如，向消费者重新发行卡)等限制而被放弃。非限制性实施例或方面可以按照EMVco于2011年8月的“支付系统的EMV集成电路卡规范，第2册——安全性和密钥管理版本4.3”描述的现有EMV标准部署。[在线]。可从https://www.emvco.com/wpontent/uploads/2017/05/EMV_v4.3_Book_2_Security_and_Key_Management_20120607061923900.pdf获得，其内容在此以全文引用的方式并入，无需向客户发行新卡或在中介机构发生重大变化。密钥管理过程，包括中介机构之间的密钥仪式，可与现有的PCI兼容过程向后兼容。此外，虽然威胁模型是支付行业内人们所熟知的，但它尚未从数学角度进行正式模拟。因此，本文在可证明安全的框架内提供了PIN认证的参与者、威胁模型和安全目标的形式描述。

由于PIN在认证支付交易中发挥着重要作用，因此PIN是攻击者的明确目标。有人提议对PIN处理API进行几次攻击，允许攻击者(在消费者银行或中介机构访问HSM)获取客户PIN，也有人提议使用被称为“加盐PIN”的修复来防止这些攻击，但这种修复要求对支付基础设施进行重大更改。其它现有方法关注如何执行正式分析HSM API以进行PIN验证和PIN转换以检查漏洞。

还存在避免对PIN转换的需求且有助于减少对中介机构的信任的几个解决方案。然而，与本文更详细描述的稻草人解决方案非常相似，这些解决方案需要对支付卡或支付终端进行重大更改。

自从引入以来，已经有大量的工作正式定义了代理重新加密(PRE)的不同安全属性以及实现这些属性的对应构造。PRE安全性的最初概念只考虑选择明文攻击(CPA)攻击。后来在单向和双向设置中考虑选择密文攻击(CCA)概念。已指出基于CPA模型的缺陷，且提出根据诚实重新加密攻击(HRA)的PRE安全性概念。

本公开的非限制性实施例或方面提供了(i)私有代理认证(PPA)方案和安全性定义，其准确地捕获基于PIN的支付的参与者、威胁模型和安全目标，(ii)PPA方案，其可根据任何PRE方案一般构造，(iii)被修改密钥管理方案，其使用相同密钥仪式从而确保向后兼容性(安全密钥管理对于管理支付合规性至关重要，目前，在支付生态系统中，密钥是使用密钥仪式在相邻方之间提供的)，(iv)新的PRE构造，其遵循密钥封装机制——代理密钥重新封装机制(KEM-DEM)混合加密范式，其中数据封装机制(DEM)与现有的PIN块加密过程向后兼容，确保部署摩擦最小，以及(v)大致相当于HSM的时延，而吞吐量是单个HSM的5倍以上。

非限制性实施例或方面提供了基于重新加密的用于传送消息(例如，PIN认证等)的改进方法，所述方法使用用于网络中的中介机构的公钥和随机密钥的组合。因此，可以保留计算资源(例如，可以减少此类计算资源的使用等)，因为不需要为每个中介机构生成一个或多个秘密密钥。此外，由于每个中介机构不需要保护各自的秘密密钥，从而减少了暴露于攻击者的风险秘密密钥量，因此可以改进安全性。此外，每个中介机构的公钥和随机密钥可至少部分地基于网络中的至少一个其它中介机构和/或实体的公钥和/或随机密钥，因此可以基于已知的运算(例如，数学运算等)来实现密文的重新加密而无需对密文解密。

现在参考图1，图1是可实施如本文描述的系统、产品和/或方法的环境100的非限制性实施例的图。如图1所示，环境100包括交易服务提供商系统102、发行方系统104、客户装置106、商家系统108、收单方系统110和网络112。

交易服务提供商系统102可以包括能够经由网络112从发行方系统104、客户装置106、商家系统108和/或收单方系统110接收信息和/或将信息传送到它们的一个或多个装置。例如，交易服务提供商系统102可以包括计算装置，例如服务器(例如，交易处理服务器)、服务器群组和/或其它类似装置。在一些非限制性实施例或方面中，交易服务提供商系统102可以与本文描述的交易服务提供商相关联。在一些非限制性实施例或方面中，交易服务提供商系统102可以与数据存储装置通信，所述数据存储装置对于交易服务提供商系统102可以是本地或远程的。在一些非限制性实施例或方面中，交易服务提供商系统102能够从数据存储装置接收信息，将信息存储在数据存储装置中，将信息传送到数据存储装置，或搜索存储在数据存储装置中的信息。

发行方系统104可以包括能够经由网络112从交易服务提供商系统102、客户装置106、商家系统108和/或收单方系统110接收信息和/或将信息传送到它们的一个或多个装置。例如，发行方系统104可以包括计算装置，例如服务器、服务器群组和/或其它类似装置。在一些非限制性实施例或方面中，发行方系统104可与本文描述的发行方机构相关联。例如，发行方系统104可以与向与客户装置106相关联的用户发行信用账户、借记账户、信用卡、借记卡等的发行方机构相关联。

客户装置106可以包括能够经由网络112从交易服务提供商系统102、发行方系统104、商家系统108和/或收单方系统110接收信息和/或将信息传送到它们的一个或多个装置。另外或替代地，每个客户装置106可以包括能够经由网络112、另一网络(例如，临时网络、本地网络、专用网络、虚拟专用网络等)和/或任何其它合适的通信技术从其它客户装置106接收信息和/或将信息传送到所述其它客户装置的装置。例如，客户装置106可以包括客户端装置等。在一些非限制性实施例或方面中，客户装置106能够或不能够经由短程无线通信连接(例如，NFC通信连接、RFID通信连接、

商家系统108可以包括能够经由网络112从交易服务提供商系统102、发行方系统104、客户装置106和/或收单方系统110接收信息和/或将信息传送到它们的一个或多个装置。商家系统108还可以包括能够经由网络112、与客户装置106的通信连接(例如，NFC通信连接、RFID通信连接、

收单方系统110可以包括能够经由网络112从交易服务提供商系统102、发行方系统104、客户装置106和/或商家系统108接收信息和/或将信息传送到它们的一个或多个装置。例如，收单方系统110可包括计算装置、服务器、服务器群组等。在一些非限制性实施例或方面中，收单方系统110可与本文描述的收单方相关联。

网络112可以包括一个或多个有线和/或无线网络。例如，网络112可包括蜂窝网络(例如，长期演进(LTE)网络、第三代(3G)网络、第四代(4G)网络、码分多址(CDMA)网络等)、公共陆地移动网络(PLMN)、局域网(LAN)、广域网(WAN)、城域网(MAN)、电话网络(例如，公共交换电话网络(PSTN))、专用网络(例如，与交易服务提供商相关联的专用网络)、临时网络、内联网、因特网、基于光纤的网络、云计算网络等，和/或这些或其它类型的网络的组合。

作为示例提供图1所示的系统、装置和/或网络的数目和布置。可存在额外系统、装置和/或网络、更少系统、装置和/或网络、不同的系统、装置和/或网络，和/或以与图1所示的那些不同的方式布置的系统、装置和/或网络。此外，可在单个系统和/或装置内实施图1中展示的两个或更多个系统或装置，或图1中展示的单个系统或装置可实施为多个分布式系统或装置。另外或替代地，环境100的一组系统(例如，一个或多个系统)和/或一组装置(例如，一个或多个装置)可执行被描述为由环境100的另一组系统或另一组装置执行的一个或多个功能。

现在参考图2，图2是装置200的示例组件的图。装置200可以对应于交易服务提供商系统102的一个或多个装置、发行方系统104的一个或多个装置、客户装置106、商家系统108的一个或多个装置，和/或收单方系统110的一个或多个装置。在一些非限制性实施例或方面中，交易服务提供商系统102、发行方系统104、客户装置106、商家系统108和/或收单方系统110可以包括至少一个装置200和/或装置200的至少一个组件。如图2所示，装置200可包括总线202、处理器204、存储器206、存储组件208、输入组件210、输出组件212，和通信接口214。

总线202可包括准许装置200的组件之间的通信的组件。在一些非限制性实施例或方面中，处理器204可以硬件、软件，或硬件和软件的组合实施。例如，处理器204可以包括处理器(例如，中央处理单元(CPU)、图形处理单元(GPU)、加速处理单元(APU)等)、微处理器、数字信号处理器(DSP)，和/或可被编程为执行某一功能的任何处理组件(例如，现场可编程门阵列(FPGA)、专用集成电路(ASIC)等)等。存储器206可以包括随机存取存储器(RAM)、只读存储器(ROM)，和/或存储供处理器204使用的信息和/或指令的另一类型的动态或静态存储装置(例如，闪存存储器、磁存储器、光学存储器等)。

存储组件208可以存储与装置200的操作和使用相关联的信息和/或软件。例如，存储组件208可以包括硬盘(例如，磁盘、光盘、磁光盘、固态磁盘等)、压缩光盘(CD)、数字多功能光盘(DVD)、软盘、盒带、磁带和/或另一类型的计算机可读介质，以及对应的驱动器。

输入组件210可以包括准许装置200例如经由用户输入(例如，触摸屏显示器、键盘、小键盘、鼠标、按钮、开关、麦克风、摄像头等)接收信息的组件。另外或替代地，输入组件210可以包括用于感测信息的传感器(例如，全球定位系统(GPS)组件、加速度计、陀螺仪、致动器等)。输出组件212可包括从装置200提供输出信息的组件(例如显示器、扬声器、一个或多个发光二极管(LED)等)。

通信接口214可包括收发器式组件(例如，收发器、单独的接收器和发送器等)，其使装置200能够例如经由有线连接、无线连接或有线和无线连接的组合与其它装置通信。通信接口214可以准许装置200接收来自另一装置的信息和/或向另一装置提供信息。例如，通信接口214可以包括以太网接口、光学接口、同轴接口、红外接口、射频(RF)接口、通用串行总线(USB)接口、

装置200可以执行本文描述的一个或多个过程。装置200可以基于处理器204执行由例如存储器206和/或存储组件208的计算机可读介质存储的软件指令来执行这些过程。计算机可读介质(例如，非瞬态计算机可读介质)在本文中定义为非瞬态存储器装置。非瞬态存储器装置包括位于单个物理存储装置内部的存储器空间或散布于多个物理存储装置上的存储器空间。

软件指令可以经由通信接口214从另一计算机可读介质或从另一装置读取到存储器206和/或存储组件208中。在被执行时，存储在存储器206和/或存储组件208中的软件指令可以使处理器204执行本文描述的一个或多个过程。另外或替代地，硬接线电路系统可以替代或结合软件指令使用以执行本文中所描述的一个或多个过程。因此，本文描述的实施例或方面不限于硬件电路系统和软件的任何特定组合。

作为示例提供图2所示的组件的数目和布置。在一些非限制性实施例或方面中，与图2中所示的那些相比，装置200可以包括额外组件、更少组件、不同组件或以不同方式布置的组件。另外或替代地，装置200的一组组件(例如一个或多个组件)可以执行被描述为由装置200的另一组组件执行的一个或多个功能。

传统上，基于PIN的验证保留在ATM上使用，但随着EMV(又名芯片和PIN)的采用，基于PIN的验证现在广泛用于ATM和销售点终端(POS)交易的认证。当消费者在POS装置上输入PIN时，PIN验证以两种方式之一进行：离线验证或在线验证。如果PIN验证离线发生，则涉及的各方仅是POS装置和芯片卡。消费者输入的PIN直接从PIN键盘发送到芯片卡，在芯片卡上认证PIN。相比之下，在线PIN验证涉及将PIN发送回发行所述卡的消费者银行进行验证。在支付基础设施成熟的国家(例如美国)，几乎所有PIN验证都是在线进行的。由于将芯片上保持的离线PIN与用于在线验证的后端PIN同步所涉及的额外复杂性，因此美国尚未采用离线PIN验证。

现在参考图3，图3是用于PIN验证的系统300的非限制性实施例的图。如图3所示，系统300包括POS装置302、POS终端/合作伙伴304、支付网关306、商家银行308(例如，收单方系统等)、支付网络310(例如，交易服务提供商系统等)以及消费者银行312(例如，发行方系统等)。在线验证中，在POS装置302上输入PIN之后，在PIN到达适当的消费者银行312(例如，POS终端/合作伙伴304、支付网关306、商家银行308和支付网络310)之前，PIN通过多个中介机构。商家采用POS合作伙伴和支付网关接受全球持卡人的支付。POS合作伙伴304使得商家能够管理由众多供应商制造的异源POS终端。支付网关306使得商家能够通过联系商家银行308来接受来自持卡人的支付。商家银行308使得商家能够通过联系适当的支付网络310(例如，Visa等)来接受各种卡类型。支付网络310通过联系消费者银行312来执行授权，这些消费者银行执行交易的最终验证。

由于PIN是敏感的，因此应确保PIN通过这些中介机构到达消费者银行312时的机密性。不足为奇，PCI法规规定PIN绝不应向任何中介机构公开。当然，可以假设POS终端304根据与消费者银行312共享的密钥对PIN加密。但是，由于POS合作伙伴304与消费者银行312没有直接关系，因此不可能建立这样的密钥。因此，每个相邻参与者必须分别建立共享密钥(例如，POS合作伙伴304与支付网关306共享密钥，所述支付网关又与商家银行308共享不同密钥，所述商家银行又与支付网络310共享不同密钥，所述支付网络又与消费者银行312共享不同密钥)。

PCI提出的另一个要求是，PIN只能明确出现在安全硬件的内部。这意味着，每个中介机构都需要部署HSM以便在PIN穿越网络时处理PIN。密钥在HSM内部生成，并在密钥仪式过程中与相邻方共享，如本文标题为“实践中的密钥管理”章节更详细描述的，从而确保双重控制和分割知识。然而，此类仪式一般都很耗时且需要遵循严格的过程。随后，当被加密PIN通过中介机构时，被加密PIN被发送到中介机构的HSM，以根据下一跃点的共享密钥进行解密和重新加密。例如，在第一跃点(POS装置302到POS合作伙伴304)中，PCI要求为每个交易使用唯一密钥(例如，使用每交易推导唯一密钥(DUKPT)方法)。在此第一跃点之后，大多数后续跃点都使用静态密钥。

被加密PIN块(EPB)是通过首先对PIN编码然后对被编码块加密来构造的。PIN块编码可以按照ISO 9654-1标准中定义的多种方式执行。例如，ISO 9654-1标准定义了五种不同的格式，称为ISO格式0、1、2、3和4。非限制性实施例或方面主要针对格式0和3进行描述，但不限于此，并且可以使用任何ISO格式。ISO格式4是最近定义的，但尚未得到广泛部署。格式0和3是将PIN和卡号(PAN)作为输入且输出被编码块。这两种格式之间的主要区别在于，格式0使用固定填充，而格式3使用随机填充。图4示出ISO PIN块编码方案400的更详细描述。

编码后，使用分组密码对PIN块加密，得到如图5所示的最终EPB 500。格式0和3均输出64位块，这些块可使用3DES加密。3DES是金融行业为克服将大量传统硬件迁移到新方法所带来的困难而使用的主要分组密码。ISO格式4定义了128位被编码块，其可替代地由AES加密。如前所述，这尚未得到广泛部署。

传统的基于公钥密码的稻草人解决方案未能实现无缝部署。为了简洁起见，本文中仅讨论几个突出的稻草人解决方案，以强调稻草人解决方案会带来显著的部署开销。

实际上，实现PIN机密性的一种方法是对照消费者银行312的公钥对PIN加密。所有参与基于PIN的交易的各方只需将被加密PIN转发到消费者银行312。消费者银行312使用相关联的秘密密钥对PIN解密并且验证PIN以执行授权。为了实现这种范式，POS装置302必须具有对PAN的数据库和对应消费者银行公钥的可靠访问。在POS装置302中存储所述数据库并不是最佳的，因为它会导致大量部署开销。例如，目前有4600万家商家接受Visa卡。然而，POS装置302会查询由支付网络管理的远程托管数据库服务器以获取消费者银行公钥并对照所述公钥对PIN加密。此额外的远程调用会增加交易时延，并要求各个中介机构部署新的变更。例如POS合作伙伴304、支付网关306、商家银行308和支付网络310的各方需要部署新的变更。此外，PAN号与对应消费者银行公钥的映射对于支付网络310是商业敏感的，这可能成为对成功部署的障碍。

POS装置302的替代方案是在交易期间从芯片卡读取消费者银行公钥。消费者银行312现在为芯片卡提供公钥和公钥/私钥对，以支持离线数据认证和离线PIN验证。不鼓励离线PIN验证，并且在美国，消费者银行不再支持这种模式。离线数据认证目前部署用于支持过境支付，其通过执行离线授权来改进时延。在此模式下，卡通过在交易期间对由POS装置302随机选择的质询进行签名来证明其真实性。卡将数字签名、包含卡公钥的证书以及包含消费者银行公钥的证书返回给POS装置302。POS装置302验证证书链并验证数字签名以继续支付。为确保PIN隐私，POS装置302可以对照认证卡的过程中获得的消费者银行公钥进行加密。但是，这种方法不向后兼容并且会产生大量的部署开销。由于使用的所有芯片卡因离线数据认证是可选的而不具备消费者银行公钥，因此需要重新发行卡。此外，它还增加了提供芯片卡的成本。这种方法不是向后兼容的，因为并非所有美国商家都支持芯片卡。例如，美国的加油站尚不支持芯片卡。不能选择重新发行磁条卡，因为磁条卡的设计目的不是存储额外的公钥材料。

另一种替代方案是对照支付网络的公钥对PIN加密。由于以下原因，这种看似简单的解决方案不可部署。首先，它仅消除了支付网络以外的所有中介机构对HSM的依赖负担。其次，商家失去了基于PIN的交易的路由灵活性。如今，商家经由其首选网络动态路由基于PIN的交易，以最大程度地减少处理费用。为此，上述看似天然的稻草人解决方案对支付生态系统带来了显著的变化。

代理重新加密(PRE)方案是通过重新加密操作增强的公钥加密(PKE)方案。PRE使得持有重新加密密钥的各方能够将根据用户A的公钥加密的密文转化为根据不同用户B的公钥的密文。双向PRE方案允许重新加密密钥rk

一些PRE方案限制可执行多少次重新加密。只允许一次重新加密的方案被称为单跃点，例如Ateniese等人提出的方案。多跃点PRE方案，例如以下文献所描述：Blaze等人，以及R.Canetti和S.Hohenberger在2007ACM计算机和通信安全会议的会议记录中发表的“选择密文安全代理重新加密(Chosen-ciphertext secure proxy re-encryption)”,CCS2007，美国弗吉尼亚州亚历山大市，2007年10月28日至31日，P.Ning、S.D.C.di Vimercati和P.F.Syverson编辑，ACM，2007年，第185-194页。[在线]。可从https://doi.org/10.1145/1315245.1315269获得(以下简称Canetti等人)，其内容在此以全文引用的方式并入，不限制重新加密的次数。

公钥加密方案包括一组具有以下接口的算法(设置、KG、E、D)：

设置(1

KG(pp)→(pk,sk)：密钥生成，返回公钥和秘密密钥对(pk,sk)。

E(pk,m)→c：加密，有关输入公钥和消息，输出密文。

D(sk,c)→m或⊥：解密，有关输入秘密密钥和密文，输出明文消息或错误符号。

PRE方案可以定义为公钥加密方案类型。PRE方案满足PRE方案和重新加密两者的正确性属性。PRE方案是具有更新密钥生成(RKG)和重新加密(RE)功能的公钥加密方案。重新加密具有以下接口：

RE(rk

此外，双向PRE方案暴露以下更新密钥生成接口：

RKG(sk

在单向方案中，RKG不再将目标秘密密钥sk

由于PRE方案是PKE方案的扩展，因此PRE方案与PKE方案一样正确。PKE正确性可定义如下：

对于由KG(pp)生成的所有可能的(pk、sk)，对于所有m，其中概率为一，则以下必须成立：

c＝E(pk,m)

m＝D(sk,c)。

如果PRE方案与PKE方案一样正确，则PRE方案为

c

c

如果PRE方案是

安全游戏有两个阶段：设置和攻击。设置阶段为所有参与者生成密钥对，并将密钥对分成诚实参与者组和舞弊参与者组。攻击阶段允许对手访问PRE方案和质询Oracle数据库。

在给出安全性定义之前，本文介绍了推导密文的概念，所述密文用于避免在安全性实验中获得微不足道的胜利。根据非限制性实施例或方面的推导密文的定义与Canetti等人的定义的不同之处在于明确针对重新加密Oracle数据库是确定的情况。

推导密文可定义如下：

设O

1)(i,c)＝(i

2)如果(i,c)是(i′,c′)的导数，其中(i′,c′)是(i

3)如果c＝O

4)如果对手查询O

可以定义两个更新密钥生成Oracle数据库，一个用于单向方案且另一个用于双向方案。如果对手试图从诚实的一方到舞弊的一方生成密钥，则单向Oracle数据库不允许更新密钥生成。但是，对于双向方案rk

PRE HRA-CCA安全性定义如下：

设λ是安全性参数，A是对手且PRE＝(设置,KG,E,D,RKG,RE)是PRE方案。诚实重新加密攻击安全游戏分两个阶段进行：

设置：运行PRE.Setup并将生成的公共参数提供给A。设n表示由A决定的密钥总数。生成n密钥对(pk

攻击：对于所有i(j≤n，i≠j)，使用PRE.RKG计算重新加密密钥rk

方案PRE为(t,∈)-安全的，条件是对于在时间t运行的所有对手A，|P[b′＝b]–1/2|≤∈成立。

私有代理认证(PPA)方案用于通过一组代理将认证数据从发送方安全地发送到接收方。在支付的情况下，认证数据是持卡人的PIN和相关数据。发送方是持卡人/POS终端304，其将被加密数据传递到跨越支付网络(例如，支付网关304、商家银行308等)的一系列中介机构(例如，代理)上，且最终接收方是持卡人的消费者银行312。

PPA方案包括六个算法(设置、KG、发送、验证[A；ak]、注册、中继)。设置功能初始化方案的参数。密钥管理是通过函数KG和注册进行的。KG函数由每个参与者运行以生成密钥对。注册用于生成从一方到另一方的更新密钥。

每个代理维护所述代理与其每个相邻者共享的更新密钥集合。本文标题为“通用PPA构造”的章节中更详细描述密钥管理。发送方和代理分别运行发送和中继函数，为被路由支付交易中的下一跃点生成密文。接收方使用验证函数来检查数据包(a,c)是否是真实的。此函数利用基础明文认证预测A来执行此检查。预测将关联数据a、明文消息m和秘密认证密钥ak作为输入，并根据认证成功与否来输出0或1。在支付中，设置A定义了基础PIN验证方法(例如IBM3624等)。PPA方案的正式定义及其相关正确性如下所示。

用于消息空间M、相关联数据空间D和基础认证预测A的PPA方案是算法PPA[A]＝(设置、KG、发送、验证[A；ak]、注册、中继)的元组，且可定义如下：

设置(1

KG(pp)→(pk,sk)：密钥生成，返回公钥和秘密密钥对(pk,sk)。

发送(pk,a,m)→c：发送，有关输入公钥pk、相关联数据a和消息m，输出密文c。

验证[A；ak](sk,a,c)→0/1或⊥：验证，有关输入秘密密钥sk、相关联数据a和密文c，输出位0或1，或错误符号⊥。

注册((pk

注册((pk

中继(R,a,c)→c′：中继，将相关联数据a、密文c和更新密钥集合R作为输入，且输出转化的密文c′或错误符号。

如果以下属性成立，则PPA就消息空间M、相关联数据空间D和基础明文认证预测A是

1)认证的正确性：对于由PPA.KG生成的所有(pk,sk)且对于所有ak、a、m，其中A(ak,a,m)＝b，则以下成立：

PPA.Verify[A；ak](sk,PPA.Send(pk,a,m))＝b；

2)中继的

c

c

如果PPA方案是

PPA方案的主要目的是以保密的方式基于基础预测A进行认证。在实践中，针对PPA方案的攻击或者通过直接注入明文(例如，通过支付终端)或者通过将被加密消息注入网络来进行。在认证的情况下，由于PIN的消息空间有限(10

机密性概念可定义如下。在安全性实验中，向对手提供所有公钥，而不仅仅是那些与初始发送方(例如，POS终端/合作伙伴304)相关联的公钥。现在任何参与者都有可能成为发送方。这使得模型比标准支付设置更为普遍，其中只有初始发送方(例如POS终端304)的公钥被用于加密，并且所有其它密钥对仅与生成更新密钥相关。这种选择产生了更强大的安全性模型，因此更好的安全性保障。安全性定义还依赖于被推导密文的概念，其可以容易地从为本文描述的被推导密文的PRE设置而定义的概念扩展。

现在参考图7，示出PPA-HRCCA游戏Oracle数据库700，对于针对选择密文攻击的PPA安全性，设λ是安全性参数，A是对手，并且PPA[A]＝(设置、KG、发送、验证[A；ak]、注册、中继)是具有基础认证预测A的PPA方案。安全游戏分两个阶段进行，如下所示：

设置：运行PPA.Setup(1

攻击：对于所有i，其中j≤n，i≠j，使用PPA.Enroll计算更新密钥rk

注册：

质询(一次性)，O

中继，ORelay(pk

验证，OVerify(pk

质询阶段结束时，对手A输出猜测b′，且如果b′＝b，则获胜。

方案PPA为(t,∈)-安全的，条件是对于在时间t运行的所有对手A，|P[b′＝b]–1/2|≤∈成立。

PPA方案PPA

图8示出根据PRE的正式PPA构造800，其中更详细地描述了它如何基于两个阶段适应支付上下文：设置阶段，其为所有各方生成密钥；以及在线阶段，其在从POS终端到消费者银行的过程中使用这些密钥来保护PIN。

通过初始化PRE方案(PRE.Setup)和认证预测A

在线阶段包括运行函数PPA.Send、PPA.Relay和PPA.Verify。PPA.Send由捕获PIN的初始支付终端304运行，PPA.Relay在被加密PIN块通过网络发送时由每个中介机构运行，并且PPA.Verify由执行最终验证的消费者银行312运行。PPA.Send是通过简单调用PRE加密函数PRE.E来构造的。中继调用是通过首先调用查找函数L以确定要使用的正确重新加密密钥然后对PRE.RE进行适当调用来构造的。最后，PPA.Verify调用PRE解密函数PRE.D并将PRE解密函数PRE.D的输出提供到认证预测A以确定最终输出位b。

用于直接实例化PPA的高效PRE构造在本文标题为“高效PPA构造”的章节中更详细地描述。这种构造使用混合方法，其使被加密PIN块与现有的基础设施向后兼容。

PPA方案的安全性分析可以根据以下定理和证明进行配置：

定理。给定(t,∈)-安全PRE方案，图8中定义的构造是(t,∈′)-安全PPA方案，其中∈′≤∈。

证明。假设有对手A正在攻击PPA的PPA-CCA安全性。使用A构造正在攻击PRE的PRE-CCA安全性的新的对手B。B使用其Oracle数据库来提供A的Oracle数据库的模拟。

安全游戏由设置阶段开始。运行设置程序以进行B的PRE-CCA实验，将接收到的诚实公钥和舞弊密钥对返回到A。另外，生成明文认证预测A的密钥ak。下一步运行攻击/质询阶段。每当A使Oracle数据库调用O

当A终止并输出其猜测b时，B终止并输出相同的位b。很容易看出，如果A获胜，则B也获胜，因此∈′≤∈。

在PIN转换密钥的典型密钥管理过程中，每对相邻方建立共享对称密钥。例如，当支付网络310从商家银行308接收被加密PIN时，支付网络310使用与商家银行308共享的密钥对被加密PIN解密，并且使用与被加密PIN被发送到的消费者银行312共享的密钥对PIN加密。由于所有密钥都保存在HSM中，因此遵循严格的密钥仪式流程来建立这些共享密钥。应注意，相邻方的HSM之间没有能促进在线密钥交换的直接在线连接。相反，每一方指定多名员工为密钥保管人。希望建立共享密钥的双方以以下方式进行这种操作。出于本说明书的目的，每一方可能有两个保管人。首先，各方中的一方(甲方)在其HSM中生成密钥加密密钥(KEK)。甲方的两个保管人在HSM上执行导出操作，因此每个保管人都会收到密钥的XOR份额(k＝k

当考虑采用双向或单向方案时密钥管理过程的实际情况(应注意，对于任何一种方案类型，在密钥设置阶段都使用HSM，因为不应以明文形式暴露秘密密钥)，一旦密钥设置，只有执行验证的最终方才能使用HSM。这大大减少了中介机构的HSM数量，而这些中介机构现在不再需要考虑以前在交易期间执行的大量HSM调用以进行PIN转换。PPA密钥管理的一个关键部分是如何生成重新加密密钥。由于双向方案使用两个秘密密钥来计算重新加密密钥，因此双向方案使用严格控制的过程。相比之下，单向方案仅使用源秘密密钥和目标公钥。与源共享目标公钥可以以更放松(但仍然严格审核)的方式执行。

对于双向PPA情况，可以考虑基本支付生态系统中的最后三个跃点：商家银行308、支付网络310以及消费者银行312。在标准设置中，支付网络310生成所有密钥，并使用本文先前描述的过程将这些密钥分配给商家银行308和消费者银行312。在双向PPA的情况下，当新银行(无论其是商家银行308还是消费者银行312)注册时，可信支付网络密钥管理器(基于HSM)都会生成新密钥对。与注册银行的密钥管理器共享秘密密钥。应注意，消费者银行312使用秘密密钥来执行最终解密，并且商家银行308使用秘密密钥来计算早期重新加密密钥(由于方案是双向的事实)。可以使用基于KEK的传统方法在各方之间安全地共享这些秘密密钥。除了在注册时生成和共享新密钥对之外，密钥管理器还计算重新加密密钥。如果新密钥对适用于商家银行308，则密钥管理器针对每个先前注册的消费者银行312生成重新加密密钥(对于从先前注册的商家银行308注册消费者银行312，反之亦然)。重新加密密钥提供给“不受信任”的支付网络应用程序(应注意，应用程序维护mn个重新加密密钥，其中m是商家银行的数量且n是消费者银行的数量)。

相比之下，单向PPA的情况要简单得多。此处，当新的参与者注册时，他们的可信密钥管理器生成其自身的密钥对。密钥管理器与它们之前的相邻者共享新的公钥，并从它们的后续相邻者中的每一个另外请求公钥。每个参与者的密钥管理器可以基于其自身的秘密密钥和其后续相邻者的公钥生成重新加密密钥。这些重新加密密钥在交易期间由其自身的应用程序使用。应用程序持有与其每个后续相邻者相关联的重新加密密钥。在此设置中，由于参与者之间只共享公钥，因此在密钥转移期间不需要使用KEK或分割知识，从而使密钥管理过程要简单得多。

Elgamal加密，如以下文献所描述：T.E.Gamal在“密码学进展-CRYPTO'84会议记录”中发表的“公钥密码系统和基于离散对数的签名方案(A public key cryptosystemand a signature scheme based on discrete logarithms)”，美国加利福尼亚州圣巴巴拉，1984年8月19日至22日会议记录，计算机科学系列讲义，G.R.Blakley和D.Chaum主编，第196卷，斯普林格出版社(Springer)，1984年，第10–18页。[在线]。可从https://doi.org/10.1007/3-540-39568-7_2获得，其内容在此以全文引用的方式并入，所述加密构成许多PRE方案的基础。它还支持许多众所周知的混合加密方案，例如以下文献所描述：例如R.Cramer和V.Shoup在“密码学进展-CRYPTO'98”中发表的“证明能安全抵御自适应选择密文攻击的实用公钥密码系统(A practical public key cryptosystem provably secureagainst adaptive chosen ciphertext attack)”，第18届国际密码学年会，美国加利福尼亚州圣巴巴拉，1998年8月23日至27日会议记录，计算机科学系列讲义，H.Krawczyk主编，第1462卷，斯普林格出版社(Springer)，1998年，第13–25页。[在线]。可从https://doi.org/10.1007/BFb0055717获得，其内容在此以全文引用的方式并入。混合加密方案是结合公钥加密和对称密钥加密的构造。它由密钥封装机制(KEM)和数据封装机制(DEM)组成，KEM用于共享随机选择的密钥，DEM用于根据此随机密钥对数据加密。根据非限制性实施例或方面的PRE构造可以包括混合加密方案。DEM用于根据受KEM保护的随机密钥对PIN加密。执行重新加密时，可以对KEM进行更改，但DEM可保持不变。

S.Myers和A.Shull的“用于实际撤销和密钥轮换的高效混合代理重新加密(Efficient hybrid proxy re-encryption for practical revocation and keyrotation)”，IACR密码研究预印本，第2017卷，第833页，2017年。[在线]。可从http://eprint.iacr.org/2017/833获得，其内容在此以全文引用的方式并入，前述文献描述混合代理重新加密的构造，重点关注与用于云外包数据存储和访问控制的密钥轮换相关的用例。在这种情况下，密钥破碎攻击成为重要的问题。这里，先前有权访问文件或短时间内有权下载大量KEM的对手可以对KEM解密以检取DEM使用的随机密钥。在密钥轮换和重新加密之后，假设对手不再有权访问明文。然而，在传统方法中，仅对KEM执行重新加密，即使在重新加密之后，DEM也保持不变。这意味着先前从KEM获得随机密钥的对手总是能够对数据解密。在非限制性实施例或方面中，可以对KEM执行重新加密，但是出于两个原因，密钥破碎攻击不再关键。首先，DEM只对很短的明文(PIN块只有64位)加密，因此能够破坏KEM的对手也能同时轻松地破坏DEM。相比之下，外包数据设置中的DEM通常为数兆字节或千兆字节。其次，在支付设置中，密文不需要长期存储，因为它们只与单个交易周期相关。

现在参考图9，其示出混合PRE构造900，根据非限制性实施例或方面的方案可以用生成器g检查一组素数阶q，并且使用对称加密方案SE＝(SE.E,SE.D)。密钥生成从

现在参考图10，图10是用于安全发送PIN和其它敏感数据的过程1000的非限制性实施例或方面的流程图。在一些非限制性实施例或方面中，过程1000的一个或多个步骤(例如，完全、部分地等)由支付网络310(例如，支付网络310的一个或多个装置等)执行。在一些非限制性实施例或方面中，过程1000的一个或多个步骤(例如，完全、部分地等)由与支付网络310分离或包括所述支付网络的另一装置或一组装置执行，例如POS合作伙伴304(例如，POS合作伙伴304的一个或多个装置等)、支付网关306(例如，支付网关306的一个或多个装置等)、商家银行308(例如，商家银行308的一个或多个装置等)和/或消费者银行312(例如，消费者银行312的一个或多个装置等)。

如图10所示，在步骤1002，过程1000包括生成包括第一密文值和第二密文值的第一密文。例如，POS终端/合作伙伴304可以生成包括第一密文值和与交易相关联的第二密文值的第一密文。作为示例，POS终端/合作伙伴304可以生成与交易相关联的第一密文。在此类示例中，第一密文可以包括：(i)与随机选择密钥(r)相关联的第一密文值，所述第一密文值基于随机选择密钥(r)和生成器值(g)加密；以及(ii)与包括第一公钥(pk

在一些非限制性实施例或方面中，中介机构服务器通过对第二密文值解密并使用交易数据的一部分确定用于后续传送的路径选择和对应重新加密密钥来在多个不同方之间转换。

在一些非限制性实施例或方面中，交易数据包括移动个人标识号(PIN)、卡验证号或与其相关联的卡号中的至少一个。

在一些非限制性实施例或方面中，第二密文值用于根据受第一密文值保护的随机选择密钥(r)对个人标识号(PIN)加密，并且重新加密会在第二密文值不变的情况下生成新密文值。

如图10所示，在步骤1004，过程1000包括传送第一密文。例如，POS终端/合作伙伴304可以将第一密文传送到支付网关306。作为示例，POS终端/合作伙伴304可以将第一密文传送到至少一个支付网关306。

如图10所示，在步骤1006，过程1000包括对第一密文值重新加密。例如，支付网关306可以对第一密文值重新加密。作为示例，支付网关306可以利用第一重新加密密钥对第一密文值重新加密，以将根据第一公钥(pk

如图10所示，在步骤1008，过程1000包括传送被重新加密第一密文值和第二密文值。例如，支付网关306可以将被重新加密第一密文值和第二密文值传送到商家银行308。作为示例，支付网关306可以将被重新加密第一密文值和第二密文传送到至少一个商家银行308。

如图10所示，在步骤1010，过程1000包括将被重新加密第一密文值重新加密为第二被重新加密第一密文值。例如，商家银行308可以将被重新加密第一密文值重新加密为第二被重新加密第一密文值。作为示例，商家银行308可以对用第二重新加密密钥加密的被重新加密第一密文值重新加密，以将根据至少一个支付网关306的第二公钥(pk

如图10所示，在步骤1012，过程1000包括传送第二被重新加密第一密文值和第二密文。例如，商家银行308可以将第二被重新加密第一密文值和第二密文传送到支付网络310。作为示例，商家银行308可以将第二被重新加密第一密文值和第二密文值传送到支付网络310。

如图10所示，在步骤1014，过程1000包括将第二被重新加密第一密文值重新加密为第三被重新加密第一密文值。例如，支付网络310可以将第二被重新加密第一密文值重新加密为第三被重新加密第一密文值。作为示例，支付网络310可以对用第三重新加密密钥加密的第二被重新加密第一密文值重新加密，以将根据至少一个商家银行的第三公钥(pk

如图10所示，在步骤1016，过程1000包括传送第三被重新加密第一密文值。例如，支付网络310可以将第三被重新加密第一密文值传送到消费者银行312。作为示例，支付网络310可以将第三被重新加密第一密文值和第二密文值传送到至少一个消费者银行312。

如图10所示，在步骤1018，过程1000包括基于第三被重新加密第一密文值和秘密密钥确定对称密钥。例如，消费者银行312可以基于第三被重新加密第一密文值和秘密密钥确定对称密钥。作为示例，消费者银行312可以基于第三被重新加密第一密文值和消费者银行312的秘密密钥确定对称密钥(K)。

如图10所示，在步骤1020，过程1000包括基于对称密钥对第二密文值解密。例如，消费者银行312可以基于对称密钥对第二密文值解密。作为示例，消费者银行312可以基于对称密钥(K)对第二密文值解密以获得交易数据。

现在参考图11A-11C，图11A-11C是用于安全发送PIN和其它敏感数据的过程1100的非限制性实施例或方面的流程图。在一些非限制性实施例或方面中，过程1100的一个或多个步骤(例如，完全、部分地等)由支付网络310(例如，支付网络310的一个或多个装置等)执行。在一些非限制性实施例或方面中，过程1100的一个或多个步骤(例如，完全、部分地等)由与支付网络310分离或包括所述支付网络的另一装置或一组装置执行，例如POS合作伙伴304(例如，POS合作伙伴304的一个或多个装置等)、支付网关306(例如，支付网关306的一个或多个装置等)、商家银行308(例如，商家银行308的一个或多个装置等)和/或消费者银行312(例如，消费者银行312的一个或多个装置等)。

如图11A所示，在步骤1102，过程1100包括生成第一值(a)和第二值(g

在一些非限制性实施例或方面中，第二值可以作为提高到第一值(a)的幂的生成器值(g)而生成。例如，可以如下生成第二值：

第二值＝g

如图11A所示，在步骤1104，过程1100包括生成随机商家号(m

如图11A所示，在步骤1106，过程1100包括确定商家乘积(M)。例如，支付网络310可以确定商家乘积(M)。作为示例，支付网络310可以基于相应多个商家银行308的多个随机商家号(m

在一些非限制性实施例或方面中，商家乘积(M)可以确定如下：

如图11A所示，在步骤1108，过程1100包括生成公钥(pk

在一些非限制性实施例或方面中，公钥(pk

在一些非限制性实施例或方面中，随机密钥(rk

如图11A所示，在步骤1110，过程1100包括传送公钥(pk

如图11A所示，在步骤1112，过程1100包括生成随机支付网关号(p

如图11A所示，在步骤1114，过程1100包括生成支付网关公钥和支付网关随机密钥。例如，商家银行308可以生成支付网关公钥和支付网关随机密钥。作为示例，商家银行308可以基于第二值(g

在一些非限制性实施例或方面中，每个支付网关306的支付网关公钥可生成如下：

在一些非限制性实施例或方面中，每个支付网关306的支付网关随机密钥可生成如下：

如图11A所示，在步骤1116，过程1100包括生成终端号(t

如图11A所示，在步骤1118，过程1100包括生成终端公钥和终端随机密钥。例如，商家银行308可以生成终端公钥和终端随机密钥。作为示例，商家银行308可以基于第二值(g

在一些非限制性实施例或方面中，每个POS终端/合作伙伴304的终端公钥可生成如下：

在一些非限制性实施例或方面中，每个POS终端/合作伙伴304的终端随机密钥可生成如下：

如图11B所示，在步骤1120，过程1100包括传送终端公钥和终端随机密钥。例如，商家银行308可以传送终端公钥和终端随机密钥。作为示例，商家银行308可以将终端公钥和终端随机密钥传送到至少一个支付网关306。

如图11B所示，在步骤1122，过程1100包括传送终端公钥。例如，支付网关306可以传送终端公钥。作为示例，支付网关306可以将终端公钥传送到至少一个POS终端/合作伙伴304。

如图11B所示，在步骤1124，过程1100包括为与交易相关联的交易消息(m)生成随机数(r)。例如，POS终端/合作伙伴304可以为与交易相关联的交易消息(m)生成随机数(r)。

如图11B所示，在步骤1126，过程1100包括生成包括第一密文值和第二密文值的第一密文。例如，POS终端/合作伙伴304可以生成包括第一密文值和第二密文值的第一密文。作为示例，POS终端/合作伙伴304可以生成与交易相关联的第一密文。在此类示例中，第一密文可以包括(i)与交易消息(m)相关联的第一密文值，所述第一密文值基于随机数(r)、生成器值(g)和交易消息(m)加密；以及ii)与随机数(r)相关联的第二密文值，所述第二密文值基于随机数(r)和终端公钥加密。

在一些非限制性实施例或方面中，第一密文值可生成如下：

第一密文值＝m·g

在一些非限制性实施例或方面中，第二密文值可生成如下：

如图11B所示，在步骤1128，过程1100包括传送第一密文。例如，POS终端/合作伙伴304可以传送第一密文。作为示例，POS终端/合作伙伴304可以将第一密文传送到至少一个支付网关306。

如图11B所示，在步骤1130，过程1100包括对第二密文值重新加密。例如，支付网关306可以对第二密文值重新加密。作为示例，支付网关306可以基于终端随机密钥对第二密文值重新加密，以将第二密文值转化为基于第二值(g

在一些非限制性实施例或方面中，第二密文值可如下被重新加密：

如图11B所示，在步骤1132，过程1100包括传送被重新加密第二密文值和第一密文值。例如，支付网关306可以传送被重新加密第二密文值和第一密文值。作为示例，支付网关306可以将被重新加密第二密文值和第一密文值传送到至少一个商家银行308。

如图11B所示，在步骤1134，过程1100包括将被重新加密第二密文值重新加密为第二被重新加密第二密文值。例如，商家银行308可以将被重新加密第二密文值重新加密为第二被重新加密第二密文值。作为示例，商家银行308可以基于随机密钥(rk

在一些非限制性实施例或方面中，被重新加密第二密文值可如下被重新加密：

如图11C所示，在步骤1136，过程1100包括传送第二被重新加密第二密文值和第一密文值。例如，商家银行308可以传送第二被重新加密第二密文值和第一密文值。作为示例，商家银行308可以将第二被重新加密第二密文值和第一密文值传送到支付网络310。

如图11C所示，在步骤1138，过程1100包括基于第二被重新加密第二密文值、商家乘积(M)和商家随机数(m

在一些非限制性实施例或方面中，支付网络310可以如下转化第二被重新加密第二密文值：

在一些非限制性实施例或方面中，支付网络310可以如下对第一密文值解密以形成消息(m)：

可以根据以下定义、定理和证明来配置根据非限制性实施例或方面的混合PRE方案的安全性分析。所有算法的输入域都不是明确的。假设输入被输入算法时，则会在正确的域中。f(a,b,c,...)和f

Δ

A(f

|P[A

密钥封装机制(KEM)包括算法(KG、Encaps、Decaps)元组，定义如下：

KG→(pk,sk)：密钥生成，返回公钥和秘密密钥对(pk,sk)

Encaps(pk)→c：加密，有关输入公钥，输出密文和密钥k

Decaps(sk,c)→m或⊥：解密，有关输入秘密密钥和密文，输出密钥k或错误符号。

KEM正确性可定义如下：

对于KG输出的所有(pk,sk)，其中概率为一，以下成立

(c,k)＝Encaps(pk)

k＝Decaps(sk,c)。

可以定义双向KREM，也可以容易修改定义以捕获单向KREM。

代理密钥重新封装机制(KREM)是添加了以下功能的KEM：

RKG(sk

ReEncaps(rk

如果KREM方案与KEM方案一样正确，则KREM方案为

(c

c

如果KREM方案是

如果对于KG输出的所有k以及所有消息m，在概率为一的情况下以下成立，则DEM是正确的：

D(k,E(k,m))＝m。

KEM CCA优势可定义如下：

考虑KEM(KG,Encaps,Decaps)，则对手A的CCA优势是

Δ

Adv(A):＝A(pk,c,k,Decaps

其中(pk,sk)←KG,(c,k)←Encaps(pk)，k′是从所有长度|k|的字符串均匀选择的，且A不能将c输入到其Decaps

数据封装机制(DEM)包括算法(KG、E、D)元组，定义如下：

KG(pp)→k：密钥生成返回秘密密钥k。

E(k,m)→c：加密，有关输入密钥和消息，输出密文。

D(k,c)→m或⊥：解密，有关输入秘密密钥和密文，输出消息或错误符号。

可以通过考虑DEM(KG,E,D)来定义DEM CCA优势，则对手A的CCA优势是

Δ

其中k←KG,$(x)返回长度|x|的统一字符串，⊥始终返回⊥，并且A只能查询其左侧Oracle数据库一次，并且不能将其左侧Oracle数据库的输出用作其右侧Oracle数据库的输入。

可以通过考虑密钥重新封装机制KREM:＝(KG,Encaps,Decaps,RKG,ReEncaps)来定义KREM CCA优势。设A为对手，且设A

Δ

Adv

KREM CCA安全游戏G

设置：运行KREM设置并向对手提供生成的公共参数。对手返回n、H和C，分别代表各方的总数、诚实方集合和舞弊方集合。用KG生成n个密钥对(pk

攻击：对于所有i(j≤n，i≠j)，使用RKG计算重新加密密钥rk

以下定理遵循简单的混合论证：

定理。将CCA KREM与CCA DEM结合使用会形成CCA PRE方案，即可以构造对手B和C使得

Adv

随机Oracle数据库依赖于Oracle数据库Diffie-Hellman(ODH)假设。

作为对手A在玩ODH-RO游戏时的优势的ODH-RO优势是

Δ

A(F(·),g

其中F是随机Oracle数据库，u、v、W是随机统一选择的，并且F

定理。假设A是对抗图9中呈现的混合PRE构造的KREM CCA对手，则构造ODH-RO对手B使得

Adv

证明。如下构造ODH-RO对手B。

1)为B提供g

2)B运行A，并且KREM CCA游戏的设置程序如下。A给予B{1,...,n}的两个分离子集，即H和C，分别代表诚实用户和舞弊用户。对于i∈C，B使用KREM.KG生成独立密钥(pk

3)B发起A的攻击阶段，并用如图12B所示的模拟Oracle数据库1250中指定的Oracle数据库查询响应A。

可以看出，标准PIN块加密方案是安全的DEM。这些构造与M.Bellare和P.Rogaway在以下文献中规范化的先编码后加密范式非常相关：“先编码后加密的加密：如何利用明文中的随机数或冗余来实现高效密码学(Encode-then-encipher encryption:How toexploit nonces or redundancy in plaintexts for efficient cryptography)”，“密码学进展-ASIACRYPT 2000”，第6届国际密码和信息安全理论和应用会议，日本京都，2000年12月3日至7日会议记录，计算机科学系列讲义，T.Okamoto主编，第1976卷，斯普林格出版社(Springer)，2000年，第317–330页。[在线]。可从https://doi.org/10.1007/3-540-44448-3_24获得(以下简称Bellare等人)，其内容在此以全文引用的方式并入。两个主要区别在于：1)考虑了额外的相关联数据；2)由于使用了混合加密，因此只需要考虑一次性使用密钥/密码。最后一点的影响是，不再需要考虑编码方案的抗冲突性，因为每个DEM密钥只有一个加密调用。如图5中定义的EPB的SE是安全的DEM，可以通过扩展Bellare等人的结果来证明。

PPA方案可以使用Java实施。例如，可以使用NIST P-256曲线(又名secp256r1)，所述曲线具有标准建议的参数。此曲线提供约128位的安全性。针对其椭圆曲线实施方案可以使用Bouncy Castle Crypto API。在这种示例中，参与基于PIN的交易的所有各方可以按以下顺序进行交易：POS应用程序调用PPA.Send方法并将被加密PIN发送到支付网关，然后支付网关调用PPA.Relay方法并将被重新加密PIN发送到商家银行，商家银行将消息转发到支付网络，支付网络调用PPA.Relay方法并将被重新加密PIN发送到消费者银行以获得授权。最后，消费者银行调用PPA.Verify方法以授权交易。每个中介机构在自己的环境中部署PPA.Relay方法，并使用ISO 8583消息与消费者银行进行交互。

中介机构和消费者银行应用程序均可在单个机器上运行。原型支付网关服务可以实施为通过HTTPS访问的Web应用程序。来自POS应用程序的所有请求都首先由此Web应用程序处理，并调用在同一机器的不同端口上运行的商家银行Web应用程序。商家银行Web应用程序通过支付网络Web应用程序将请求发送到消费者银行Web应用程序。可以使用Dropwizard来实施所有原型Web应用程序。除了消费者银行Web应用程序之外，所有Web应用程序可能都需要有效管理重新加密密钥以调用PPA.Relay方法。可以使用LevelDb来存储所有重新加密密钥，并在Web应用程序启动期间将存储的重新加密密钥加载到存储器中。

现在参考图13，图13是与用于安全发送PIN和其它敏感数据的过程有关的实施方案1300的非限制性实施例或方面的概述图。如图13所示，实施方案1300包括POS合作伙伴/终端1304、支付网关1306、商家银行1308、支付网络1310和消费者银行1312。在一些非限制性实施例或方面中，POS合作伙伴/终端1304可以与POS合作伙伴/终端304相同或类似。在一些非限制性实施例或方面中，支付网关1306可以与支付网关306相同或类似。在一些非限制性实施例或方面中，商家银行1308可以与商家银行308相同或类似。在一些非限制性实施例或方面中，支付网络1310可以与支付网络310相同或类似。在一些非限制性实施例或方面中，消费者银行1312可以与消费者银行312相同或类似。

如图13中的附图标记1320所示，POS合作伙伴/终端1304可以使用密钥生成函数PRE.KG(pp)生成包括POS合作伙伴公钥(pk

如图13中的附图标记1322所示，商家银行1308使用密钥生成函数PRE.KG(pp)生成包括商家银行公钥(pk

如图13中的附图标记1324所示，支付网关1306从商家银行1308接收商家银行公钥(pk

如图13中的附图标记1326所示，支付网关1306存储来自商家银行1308的商家银行公钥(pk

如图13中的附图标记1328所示，POS合作伙伴/终端1304接收商家银行公钥(pk

如图13中的附图标记1330所示，POS合作伙伴/终端1304使用更新密钥生成函数PRE.RKG((pk

如图13中的附图标记1332所示，POS合作伙伴/终端1304将重新加密密钥(rk

如图13中的附图标记1334所示，支付网关1306存储重新加密密钥(rk

如图13中的附图标记1336所示，消费者银行1312使用密钥生成函数PRE.KG(pp)生成包括消费者银行公钥(pk

如图13中的附图标记1338所示，支付网络1310从消费者银行1312接收消费者银行公钥(pk

如图13中的附图标记1340所示，支付网络1310存储来自消费者银行1312的消费者银行公钥(pk

如图13中的附图标记1342所示，商家银行1308接收消费者银行公钥(pk

如图13中的附图标记1344所示，商家银行1308使用更新密钥生成函数PRE.RKG((pk

如图13中的附图标记1346所示，商家银行1308将重新加密密钥(rk

如图13中的附图标记1348所示，支付网络1310存储重新加密密钥(rk

现在参考图14，图14是与用于安全发送PIN和其它敏感数据的过程有关的实施方案1400的非限制性实施例或方面的概述图。如图14所示，实施方案1400包括POS合作伙伴/终端1404、支付网关1406、商家银行1408、支付网络1410和消费者银行1412。在一些非限制性实施例或方面中，POS合作伙伴/终端1404可以与POS合作伙伴/终端304相同或类似。在一些非限制性实施例或方面中，支付网关1406可以与支付网关306相同或类似。在一些非限制性实施例或方面中，商家银行1408可以与商家银行308相同或类似。在一些非限制性实施例或方面中，支付网络1410可以与支付网络310相同或类似。在一些非限制性实施例或方面中，消费者银行1412可以与消费者银行312相同或类似。

如图14中的附图标记1420所示，支付网络1410使用密钥生成函数PRE.KG(pp)生成包括商家银行公钥(pk

如图14中的附图标记1422所示，支付网络1410使用密钥生成函数PRE.KG(pp)生成包括消费者银行公钥(pk

如图14中的附图标记1424所示，支付网络1410使用更新密钥生成函数PRE.RKG((pk

如图14中的附图标记1426所示，支付网络1410存储重新加密密钥(rk

如图14中的附图标记1428所示，商家银行1408从支付网络1410接收商家银行密钥对(pk

如图14中的附图标记1430所示，消费者银行1412从支付网络1410接收消费者银行密钥对(pk

如图14中的附图标记1432所示，商家银行1408使用密钥生成函数PRE.KG(pp)生成包括POS合作伙伴公钥(pk

如图14中的附图标记1434所示，商家银行1408使用更新密钥生成函数PRE.RKG((pk

如图14中的附图标记1436所示，支付网关1406接收重新加密密钥(rk

如图14中的附图标记1438所示，POS合作伙伴/终端1404接收POS合作伙伴公钥(pk

现在参考图15，图15是与用于安全发送PIN和其它敏感数据的过程有关的实施方案1500的非限制性实施例或方面的概述图。如图15所示，实施方案1500包括POS合作伙伴/终端1504、支付网关1506、商家银行1508、支付网络1510和消费者银行1512。在一些非限制性实施例或方面中，POS合作伙伴/终端1504可以与POS合作伙伴/终端304相同或类似。在一些非限制性实施例或方面中，支付网关1506可以与支付网关306相同或类似。在一些非限制性实施例或方面中，商家银行1508可以与商家银行308相同或类似。在一些非限制性实施例或方面中，支付网络1510可以与支付网络310相同或类似。在一些非限制性实施例或方面中，消费者银行1512可以与消费者银行312相同或类似。

如图15中的附图标记1520所示，POS合作伙伴/终端1504使用DUKPT方法(例如DUKPT＝KDF(MSK，随机数)等，其中KDF为密钥推导函数且MSK为主会话密钥)生成会话密钥(DUKPT)(例如，会话秘密密钥ss

如图15中的附图标记1522所示，POS合作伙伴/终端1504使用三DES算法TDES和会话密钥(DUKPT)对交易的认证码(例如，PIN等)加密以生成PIN块(EPB)(例如，EPB＝TDES(PIN,DUKPT)等)。

如图15中的附图标记1524所示，POS合作伙伴/终端1504使用函数PRE.E(DUKPT,pk

如图15中的附图标记1526所示，POS合作伙伴/终端1504将被加密交易数据(例如，ARQC、EPB、DUKPT')传送到支付网关1506。例如，支付网关1506从POS合作伙伴/终端1504接收交易的被加密交易数据(ARQC，EPB，DUKPT')，所述被加密交易数据包括：(i)被加密代码(EPB)，包括用会话密钥(DUKPT)加密的认证码(PIN)，以及(ii)被加密会话密钥(DUKPT')，包括用与POS合作伙伴/终端1504相关联的POS合作伙伴公钥(pk

如图15中的附图标记1528所示，支付网关1506基于被加密交易数据确定重新加密密钥(rk

如图15中的附图标记1530所示，支付网关1506使用重新加密函数PRE.RE(例如，DUKPT"＝PRE.RE(DUKPT',rk

如图15中的附图标记1532所示，支付网关1506将被重新加密的被加密会话密钥(DUKPT")传送到商家银行1508。例如，商家银行1508可以从支付网关1506接收被加密交易数据(例如，ARQC，EPB，DUKPT")，所述被加密交易数据包括：(i)被加密代码(EPB)，包括用会话密钥(DUKPT)加密的认证码(PIN)，以及(ii)被重新加密的被加密会话密钥(DUKPT")，包括用重新加密密钥(rk

如图15中的附图标记1534所示，商家银行1508可以使用函数PRE.D基于商家银行秘密密钥(sk

如图15中的附图标记1536所示，商家银行1508可以生成交易的被加密交易数据(例如，ARQC、EPB、DUKPT')并将其转发到支付网络1510，所述被加密交易数据包括(i)被加密代码(EPB)，包括用会话密钥(DUKPT)加密的认证码(PIN)，以及(ii)被加密会话密钥(DUKPT')，包括用与商家银行1508相关联的商家银行公钥(pk

如图15中的附图标记1538所示，支付网络1510可以基于被加密交易数据确定重新加密密钥(rk

如图15中的附图标记1540所示，支付网络1510使用重新加密函数PRE.RE(例如，DUKPT"＝PRE.RE(DUKPT',rk

如图15中的附图标记1542所示，支付网络1510将被重新加密的被加密会话密钥(DUKPT")传送到消费者银行1512。例如，消费者银行1512可以从支付网络1510接收被加密交易数据(例如，ARQC，EPB，DUKPT")，所述被加密交易数据包括：(i)被加密代码(EPB)，包括用会话密钥(DUKPT)加密的认证码(PIN)，以及(ii)被重新加密的被加密会话密钥(DUKPT")，包括用重新加密密钥(rk

如图15中的附图标记1544所示，消费者银行1512可以使用函数PRE.D(例如，DUKPT＝PRE.D(DUKPT",sk

如图15中的附图标记1546所示，消费者银行1512可以基于认证码(PIN)授权(或拒绝)交易。

现在参考图16，图16是与用于安全发送PIN和其它敏感数据的过程有关的实施方案1600的非限制性实施例或方面的概述图。如图16所示，实施方案1600包括支付网络1610、消费者银行1612和可信硬件1614。在一些非限制性实施例或方面中，支付网络1610可以与支付网络310相同或类似。在一些非限制性实施例或方面中，消费者银行1612可以与消费者银行312相同或类似。

如图16中的附图标记1620所示，消费者银行1612可以授权支付网络1610将消费者银行秘密密钥(sk

如图16中的附图标记1622所示，支付网络1610使用重新加密函数PRE.RE(例如，DUKPT"＝PRE.RE(DUKPT',rk

如图16中的附图标记1624所示，支付网络1610尝试将交易的被加密交易数据发送到消费者银行1612并检测到消费者银行1612离线。

如图16中的附图标记1626所示，支付网络1610请求可信硬件1614对交易进行授权。例如，响应于确定消费者银行1612处于离线状态，支付网络1610通过将被加密交易数据(例如，ARQC、EPB、DUKPT")提供到可信硬件1614来请求可信硬件1614对交易进行授权。

如图16中的附图标记1628所示，可信硬件1614可以使用函数PRE.D(例如，DUKPT＝PRE.D(DUKPT",sk

如图16中的附图标记1630所示，可信硬件1614可以基于认证码(PIN)授权(或拒绝)交易。

现在参考图17，图17是与用于安全发送PIN和其它敏感数据的过程有关的实施方案1700的非限制性实施例或方面的概述图。如图17所示，实施方案1700包括POS合作伙伴/终端1704、支付网关1706、商家银行1708、支付网络1710和消费者银行1712。在一些非限制性实施例或方面中，POS合作伙伴/终端1704可以与POS合作伙伴/终端304相同或类似。在一些非限制性实施例或方面中，支付网关1706可以与支付网关306相同或类似。在一些非限制性实施例或方面中，商家银行1708可以与商家银行308相同或类似。在一些非限制性实施例或方面中，支付网络1710可以与支付网络310相同或类似。在一些非限制性实施例或方面中，消费者银行1712可以与消费者银行312相同或类似。

如图17中的附图标记1720所示，支付网络1710可以生成第一值(a)和第二值(g

在一些非限制性实施例或方面中，第二值可以作为提高到第一值(a)的幂的生成器值(g)而生成。例如，可以如下生成第二值：

第二值＝g

如图17中的附图标记1722所示，支付网络1710可以生成随机商家号(m

如图17中的附图标记1724所示，支付网络1710可以确定商家乘积(M)。例如，支付网络1710可以基于相应多个商家银行308的多个随机商家号(m

在一些非限制性实施例或方面中，商家乘积(M)可以确定如下：

其中k是商家银行的数量。

如图17中的附图标记1726所示，支付网络1710可以生成公钥(pk

在一些非限制性实施例或方面中，每个商家银行1708的公钥(pk

在一些非限制性实施例或方面中，随机密钥(rk

如图17中的附图标记1728所示，支付网络1710可以将公钥(pk

如图17中的附图标记1730所示，商家银行1708可以生成随机支付网关号(p

如图17中的附图标记1732所示，商家银行1708可以生成支付网关公钥和支付网关随机密钥。作为示例，商家银行1708可以基于第二值(g

在一些非限制性实施例或方面中，每个支付网关1706的支付网关公钥可生成如下：

在一些非限制性实施例或方面中，每个支付网关1706的支付网关随机密钥可生成如下：

如图17中的附图标记1734所示，商家银行1708可以生成终端号(t

如图17中的附图标记1736所示，商家银行1708可以生成终端公钥和终端随机密钥。作为示例，商家银行308可以基于第二值(g

在一些非限制性实施例或方面中，每个POS终端/合作伙伴1704的终端公钥可生成如下：

在一些非限制性实施例或方面中，每个POS终端/合作伙伴1704的终端随机密钥可生成如下：

如图17中的附图标记1738所示，商家银行1708可以传送终端公钥和/或终端随机密钥。作为示例，商家银行1708可以将终端公钥和终端随机密钥传送到至少一个支付网关1706。

如图17中的附图标记1740所示，支付网关1706可以传送终端公钥。作为示例，支付网关1706可以将终端公钥传送到至少一个POS终端/合作伙伴1704。

现在参考图18，图18是与用于安全发送PIN和其它敏感数据的过程有关的实施方案1800的非限制性实施例或方面的概述图。如图18所示，实施方案1800包括POS合作伙伴/终端1804、支付网关1806、商家银行1808、支付网络1810和消费者银行1812。在一些非限制性实施例或方面中，POS合作伙伴/终端1804可以与POS合作伙伴/终端304和/或POS合作伙伴/终端1704相同或类似。在一些非限制性实施例或方面中，支付网关1806可以与支付网关306和/或支付网关1706相同或类似。在一些非限制性实施例或方面中，商家银行1808可以与商家银行308和/或商家银行1708相同或类似。在一些非限制性实施例或方面中，支付网络1810可以与支付网络310和/或支付网络1710相同或类似。在一些非限制性实施例或方面中，消费者银行1812可以与消费者银行312和/或消费者银行1712相同或类似。

如图18中的附图标记1820所示，POS终端/合作伙伴1804可以为与交易相关联的交易消息(m)生成随机数(r)。

如图18中的附图标记1822所示，POS终端/合作伙伴1804可以生成包括第一密文值和第二密文值的第一密文。作为示例，POS终端/合作伙伴1804可以生成与交易相关联的第一密文。在此类示例中，第一密文值可以与交易消息(m)相关联，第一密文值基于随机数(r)、生成器值(g)和交易消息(m)加密。另外或替代地，第二密文值可以与随机数(r)相关联，第二密文值基于随机数(r)和终端公钥加密。

在一些非限制性实施例或方面中，第一密文值可生成如下：

第一密文值＝m·g

在一些非限制性实施例或方面中，第二密文值可生成如下：

如图18中的附图标记1824所示，POS终端/合作伙伴1804可以传送第一密文。作为示例，POS终端/合作伙伴1804可以将第一密文传送到至少一个支付网关1806。

如图18中的附图标记1826所示，支付网关1806可以对第二密文值重新加密。作为示例，支付网关1806可以基于终端随机密钥对第二密文值重新加密，以将第二密文值转化为基于第二值(g

在一些非限制性实施例或方面中，第二密文值可如下被重新加密：

如图18中的附图标记1828所示，支付网关1806可以传送被重新加密第二密文值和第一密文值。作为示例，支付网关1806可以将被重新加密第二密文值和第一密文值传送到至少一个商家银行1808。

如图18中的附图标记1830所示，商家银行1808可以将被重新加密第二密文值重新加密为第二被重新加密第二密文值。作为示例，商家银行1808可以基于随机密钥(rk

在一些非限制性实施例或方面中，被重新加密第二密文值可如下被重新加密：

如图18中的附图标记1832所示，商家银行1808可以传送第二被重新加密第二密文值和第一密文值。作为示例，商家银行1808可以将第二被重新加密第二密文值和第一密文值传送到支付网络1810。

如图18中的附图标记1834所示，支付网络1810可以基于第二被重新加密第二密文值、商家乘积(M)和商家随机数(m

在一些非限制性实施例或方面中，支付网络1810可以如下转化第二被重新加密第二密文值：

在一些非限制性实施例或方面中，支付网络1810可以如下对第一密文值解密以形成消息(m)：

如图18中的附图标记1836所示，支付网络1810可以将消息(m)传送到消费者银行1812。在一些非限制性实施例或方面中，支付网络1810可以在与消费者银行1812通信之前和/或期间使用任何合适的加密和/或重新加密技术对消息(m)加密和/或重新加密。例如，支付网络1810可以使用本文所公开的任何加密和/或重新加密技术对消息(m)加密和/或重新加密。

尽管已出于说明的目的而基于当前被认为是最实用和优选的实施例或方面详细描述了所公开主题，但应理解，此类细节仅用于所述目的，且所公开主题不限于所公开实施例或方面，而是相反，旨在涵盖在所附权利要求书的精神和范围内的修改和等效布置。例如，应理解，当前所公开主题尽可能地考虑任何实施例的一个或多个特征可以与任何其它实施例的一个或多个特征组合。