CN113874876A - 用于分布式计算系统的安全模型 - Google Patents

Abstract

一种用于计算节点响应于服务请求而提供密码密钥的方法，该方法包括：建立密钥列表，其中该密钥列表包括多个密钥的密钥标识符；接收服务请求并且响应于服务请求而识别出需要密钥；以及使用根据与服务请求相关联的数据的确定性过程来分配密钥标识符中的一个密钥标识符，并且因此将与密钥标识符中的所述一个密钥标识符相关联的密钥分配给服务请求。还描述了适当配置的计算节点。

Description

用于分布式计算系统的安全模型

相关申请的交叉引用

本申请基于并要求于2019年6月5日提交的序列号为19178579.9的欧洲专利申请和2019年6月5日提交的序列号为19178583.1的欧洲专利申请的权益和优先权，其内容出于所有目的在此全文并入本文。

技术领域

本公开涉及凭证的管理和用于在分布式计算系统中使用的安全模型。本公开具体地涉及具有需要与系统的使用相关联的凭证的非常大量客户端的分布式系统。

背景技术

存在需要中央化(centralized)系统为非常大量的客户端提供服务的许多技术挑战，尤其是当这些客户端在地理上广泛分布时。考虑分布系统使得相关服务能够由一组地理上分布的服务器提供，而不是由一个中央服务器或数据中心提供是合乎逻辑的。

在实践中，这种去中央化可能会使用云体系架构，该云体系架构将通常使用多个地理上分布的服务器——或数据中心——来向客户端递送服务。云体系架构可以被认为包括多个节点——当使用云体系架构时，节点可以是多个计算机的聚合，并且可以在给定节点内以“实时”连接和数据共享来覆盖多于一个的数据中心。

去中央化本身可能是有问题的，特别是在有必要以这种方式来提供服务的情况下，服务的供给会产生超出提供服务的服务器和接收服务的客户端的后果。例如，如果其它客户端(或其它系统节点)需要回溯到服务提供节点以检查否已提供服务或如何提供服务，或者中央系统是否有必要知道已经如何提供服务或分布式服务器节点的性能，那么新的瓶颈可能会取代以前的瓶颈出现在中央服务器上，系统中的消息传递总量可能增加，并且网络延迟可能成为严重的问题。

当服务与安全相关(因此必须确信它已经在整个系统中安全地执行)时并且当它涉及在短时间段内供给服务时，这尤其严重。这两个问题都适用于交易系统——交易必须在短时间段内获得授权，并且必须确保它们已经被合法地执行——但也适用于其它技术情境。

发明内容

在第一方面，本公开提供了一种用于计算节点响应于服务请求而提供密码密钥的方法，该方法包括：建立密钥列表，其中该密钥列表包括多个密钥的密钥标识符；接收服务请求并且响应于服务请求而识别出需要密钥；以及使用根据与服务请求相关联的数据的确定性过程来分配密钥标识符中的一个密钥标识符，并且因此将与密钥标识符中的所述一个密钥标识符相关联的密钥分配给服务请求。

这种方法提供了非常高效和可扩展的方法，用于将密钥分配给密码过程。以这种方式使用确定性过程使得可以轻松确定在特定情况下使用了哪个密钥。

计算节点可以是分布式计算系统的多个节点中的一个，并且服务请求可以是从分布式计算系统内的客户端接收的。该客户端可以是与计算节点相关联的分布式计算系统的客户端的子集中的一个客户端。

服务请求可以与凭证的管理相关——它可以与凭证的生成或验证相关。凭证可以与由提供服务请求的客户端执行的交易相关。与服务请求相关联的数据可以包括交易标识符，该交易标识符可以基于本地交易计数器。

密钥列表包括唯一标识符。可以在密钥列表中识别确定性过程。密钥列表可以用密钥列表密封锁以密码方式密封。

密钥列表可以具有有效期。当有效期到期时，可以用另一个密钥列表替换该密钥列表。该另一个密钥列表可以由远离计算节点的中央服务提供、或者可以在本地生成或由对等节点提供。在凭证的情况下，有效期可以与凭证的生成相关，但与生成的凭证的验证无关。

可以在密钥列表中识别用于使用密钥的密码方法——一种可能性将是HMAC。来自密钥列表的信息用作密码过程的输入，作为将过程的输出绑定到密钥列表的一种方式。在实施例中，密码过程递送计算节点上的密码证明、来自服务请求的信息、交易标识和来自密钥列表的信息。

在第二方面，本公开提供了一种计算节点，其适于根据第一方面的方法响应于服务请求而提供密码密钥。该计算节点可以包括其中存储密码密钥的一个或多个硬件安全模块。

附图说明

现在参考附图以举例的方式描述本公开的具体实施例，其中：

图1示出了与中央服务器交互的多个客户端；

图2示出了提供与图1中的中央服务器相同的服务的分布式计算体系架构交互的多个客户端；

图3示意性地示出了使用四方(four party)模型的分布式交易体系架构；

图4图示了适于实现图3的交易体系架构的复杂分布式系统的元素；

图5示意性地示出了用于在图3和图4的交易体系架构中实现数字交易的示例性系统；

图6示意性地图示了用于交易的数字化实现(enablement)的分布式系统的布置；

图7更详细地图示了图6的布置的计算节点；

图8图示了图7的计算节点内的元素；

图9指示与图7的节点执行的操作相关的交易流程；

图10指示在图7到图9的布置的实施例中使用令牌化(tokenisation)；

图11指示在本公开的实施例中使用的密钥管理的方法；

图12图示了交易识别的示例性方法；

图13图示了在本公开的实施例中用于数字化交易的一组示例性密码机制；

图14图示了具有如图11中所示管理的各个模式的密钥管理的全局模型；

图15图示了与图11和图14的密钥管理模型相关联的全局监控模型；

图16图示了使用具有图7和图8的节点的传统用例的交易的示例性修改令牌化过程；

图17图示了使用传统用例的系统的密钥轮换过程；

图18图示了用于使用传统用例的数字化交易的一组示例性密码机制；

图19图示了使用适合与图7和图8的节点一起使用的传统用例来传送(carry)本地交易计数器的方法；

图20图示了在使用与图7和图8的节点一起使用的卡核实码(CVC)来递送本地交易计数器时使用图19的方法；

图21图示了使用适合与图7和图8的节点一起使用的UCAF(通用持卡人认证字段)格式来传送交易凭证信息作为交易的一部分的方法；

图22图示了用于使用UCAF格式的数字化交易的一组示例性密码机制；以及

图23图示了使用用于与图7和图8的节点一起使用的DPD(数字支付数据)来传送交易凭证信息的方法。

具体实施方式

一般而言，本公开解决的问题在图1和图2中图示。图1示出了响应于来自非常大量的地理上分布的实体的请求而执行功能的中央系统。这对中央系统在处理能力、存储和消息传递方面提出了强烈需求，并且通常会由于瓶颈和消息传递要求而导致整个系统出现显著延迟。

图2示出了替代布置，其中中央系统的角色被分解，使得由一组分布式节点执行相同的功能，每个节点都具有执行中央系统所提供的一些或全部功能的能力。各个节点都应看到比中央系统低得多的需求，并且由于实体应该能够与比中央系统更本地的节点进行交互，因此可以潜在地减少延迟。但是，如上面一般性讨论的，以及下面与交易处理系统具体相关的，在实现这种好处方面存在重大的技术挑战。

这个问题与交易处理系统特别相关，特别是与用于处理数字交易的系统相关。数字交易的数量增长极快，并且需要它们可靠且快速地执行。这些交易的支持可以使用为使用支付卡的基于设备的支付而开发的交易处理系统，并使用此类支付系统的协议，但实际上此类交易与基于设备的交易具有不同的特点。这将在下面讨论，首先参考交易处理系统的一般元素，然后更详细地讨论用于支持数字交易的基础设施。

图3是典型的四方模型或四方支付交易方案的框图。该图图示了模型中存在的实体以及在卡方案中操作的实体之间发生的交互。

通常，卡方案——与支付卡相关的支付网络——基于以下两个模型中的一个：三方模型或四方模型(由本申请人采用)。出于本文档的目的，下面更详细地描述四方模型。

四方模型可以用作交易网络的基础。对于每个交易，该模型包括四个实体类型：持卡人110、商家120、发行方130和收单方140。在该模型中，持卡人110从商家120购买商品或服务。发行方130是向持卡人110发行卡的银行或任何其它金融机构。收单方140向商家120提供用于卡处理的服务。

该模型还包括中央交换机150——发行方130和收单方140之间的交互经由交换机150进行路由。交换机150使与一个特定银行收单方140相关联的商家120能够接受来自与不同银行发行方130相关联的持卡人110的支付交易。

四方模型中实体之间的典型交易可以被划分为两个主要阶段：授权和结算。持卡人110使用他们的卡发起从商家120购买商品或服务。卡和交易的详细信息经由收单方140和交换机150发送到发行方130以授权交易。持卡人110可能已经在交易中提供了核实信息，并且在一些情况下可能需要经历附加的核实过程来核实他们的身份(诸如，在在线交易情况下的3-D安全)。一旦附加的核实过程完成，交易就被授权。

在持卡人110与商家120之间的交易完成后，商家120将交易详细信息提交给收单方140以进行结算。

交易详细信息然后由收单方140经由交换机150路由到相关发行方130。在接收到这些交易详细信息后，发行方130将结算资金提供给交换机150，交换机150进而经由收单方140将这些资金转发给商家120。

单独地，发行方130和持卡人110在他们之间结算支付金额。作为回报，商家120针对每个交易向收单方140支付服务费，并且收单方140向发行方130支付交换(interchange)费以换取资金结算。

在四方系统模型的实际实施方式中，特定方的角色可能涉及共同作用的多个元素。在已经发展超越客户卡和商家终端之间基于接触的交互的实施方式到在诸如智能电话之类的用户计算设备上使用代理或虚拟卡的数字实施方式中，通常是这种情况。

图4示出了根据本公开的实施例的适合于持卡人和商家之间的交互的体系架构。该图示出了通用体系架构以供参考，但特别示出了当持卡人与商家服务器进行在线交易时使用的体系架构的特定元素。

对于常规的交易，持卡人将使用他们的支付卡6——或诸如适于用作非接触式支付设备的智能电话11之类的移动计算设备——与商家2的POS终端7进行交易。但是，在与本发明相关的实施例中，持卡人将使用他或她的计算设备——其可以是蜂窝电话手机、平板电脑、膝上型电脑、静态个人计算机或任何其它合适的计算设备中的任何或全部计算设备(这里示出了移动电话手机或智能电话11)——并且也可以使用其它计算设备(诸如智能手表或其它可穿戴设备)——用以充当物理支付卡6的代理或充当仅在数字域中操作的虚拟支付卡。如下所述，智能电话11可以通过移动支付应用和数字钱包来实现这一点。智能电话11可以使用它来使用NFC或其它非接触式技术与商家POS终端7进行交易，或者如下面所讨论的与其钱包服务相关联地进行支付。但是，本公开的实施例特别关注的是与商家的在线交易，而不是与商家POS终端7的接触式或非接触式交易。为了进行在线交易，智能电话11还能够通过任何适当的网络连接(诸如公共互联网)与表示商家2的商家服务器12交互——与商家的连接可以由计算设备上的app或应用提供。

交易方案基础设施(交易基础设施)5在此不仅提供操作卡方案所需的计算基础设施以及向诸如收单方3和发行方4的各方提供交易路由和其它消息传递，而且还提供支持持卡人计算设备上的数字钱包的钱包服务17，并且提供互联网网关18以接受基于互联网的交易以供交易基础设施处理。在其它实施例中，钱包服务17可以由与交易方案提供商具有适当信任关系的第三方类似地提供。为了支持令牌化，存在令牌服务提供商19(同样，这被示为交易基础设施5的一部分，但可以由具有适当信任关系的第三方提供)，并且交易方案基础设施提供数字实现服务16以支持令牌化数字交易的执行，以及与系统的其它元素交互以使得交易被正确执行——这种数字实现服务可以包括其它元素，诸如令牌服务供给。

对于令牌化交易，通过将持卡人令牌映射到他们的卡PAN、检查令牌状态(以确保它处于有效期或以其它方式是有效的)以及使用的任何客户核实方法，在交易方案中对交易进行验证。这允许发行方以普通方式对交易进行授权。

图5更详细地示出了支持从移动设备进行数字化支付的交易基础设施的元素。该图示出了作为具体示例的申请人的基于万事达卡云的支付(Mastercard Cloud BasedPayment,MCBP)体系架构——这是示例性的而非特定于本发明的，并且图示了该体系架构如何用于支持移动设备(诸如智能电话11)上的移动支付应用215—这里移动支付应用215被显示为包含在钱包应用或数字钱包41内。这样的数字钱包41可以与钱包服务器17通信以允许管理移动支付应用，并且它还可以用于请求由移动设备11使用的支付卡6的数字化。

万事达卡数字实现服务(MDES)42执行各种功能以支持移动支付和数字化交易。如上所述，MDES 42仅是示例性的——例如，其它实施例可以使用与其它交易处理基础设施相关联的数字化、令牌化和供给服务。钱包服务器17不是MDES 42的一部分——并且在例如移动支付应用215没有嵌入在数字钱包41内的情况下不需要存在——而是充当移动设备11和MDES 42之间的接口。MDES 42还对令牌化交易进行调解，使得它们可以像常规卡交易一样通过交易方案进行处理。MDES 42内显示以下功能元素：账户实现系统(AES)43、凭证管理系统(CMS)44、令牌库45和交易管理系统(TMS)46。这些将在下面简要描述。

账户实现系统(AES)43用于卡数字化和用户建立。它将与移动支付应用(这里通过钱包服务器17)交互以进行卡数字化请求，并将在令牌化时填充令牌库45，并将与CMS 44交互以建立具有相关联的密钥的卡简档，用于卡的数字化使用。

凭证管理系统(CMS)44支持持卡人凭证的管理，并且是MDES 42内的密钥系统。核心系统441通过与TMS 46的交互来管理与整个交易系统的同步，并管理到AES 43的通道。专用系统442以使用所需的形式向移动支付应用提供必要元素(诸如数字化卡和凭证和密钥)的递送。该系统还可以与钱包服务器17交互以管理移动支付应用。

令牌库45——这里显示为在MDES 42内，但它可以是单独控制下的单独元素——是用于令牌信息的储存库，包括令牌和相关联的卡之间的对应关系。在处理令牌化交易时，MDES 42将参考令牌库45，并且卡的令牌化将导致在令牌库45中创建新的条目。

交易管理系统(TMS)46在处理令牌化交易时使用。如果交易方案将交易识别为被令牌化，那么交易被路由到TMS 46，TMS 46通过使用令牌库45对交易进行去令牌化。去令牌化的交易然后被路由到发行方(这里由金融授权系统47表示)以常规方式进行授权。TMS 46还与CMS 44交互以确保与持卡人账户和凭证相关的同步。

本公开的实施例针对实现用于执行如图5中所示的数字化交易的系统的各方面——特别是凭证的管理——能够被去中央化。这是通过用一组去中央化的节点替换中央节点来完成的，每个去中央化节点能够进行凭证管理，如图6到图8中所示。

图6示出了计算节点Nx的去中央化的系统，每个节点都能够生成G和验证V凭证。这些凭证可以在整个系统中有效(除非由于土壤(on-soil)监管等而仅限于一些节点)，并且在这种情况下与一组用户(客户端)的交易相关联，这些用户(客户端)的交易通常通过地理接近度被路由到该节点。节点向客户端提供凭证生成G和凭证验证V作为服务，并且需要能够安全地生成凭证并至少在它们有效时安全地验证它们。在所示的体系架构中，凭证没有被存储——它们是根据请求生成的，并即时进行验证。如图6和图7中所示，除了凭证生成和验证之外，密钥管理K和监控M可以被视为在节点本地和跨系统两者的服务，并且通常需要访问控制AC来允许访问服务。下面将更详细地描述这些方面。

合适的计算节点的元素如图8中所示。节点80包括至少一个网络连接81以允许与客户端90和其它节点91以及(在该示例中)中央节点91a的通信。这里将通信显示为通过单独的网络到每一组其它方——通过用于连接到客户端的第一网络云92和用于连接到分布式系统内的其它节点的第二网络云92a。这反映了这些网络可以在物理上不同，或者可以有不同的安全要求和协议。

节点80包含多个常规服务器83(它们将包含它们自己的处理器和存储器——未示出——以及通常在服务器中发现的其它组件)和包含中央数据库的存储器84。节点80内还包括多个硬件安全模块85(HSM)，其适于保存密码材料并安全地执行密码函数。这里节点80内的元素被示出借助于总线86进行通信。虽然在这种情况下节点80被表示为单个数据中心，但这不是必需的——“总线”可以例如包括一组相关数据中心之间的专用网络连接，其允许它们提供实时响应，使得它们对于与节点通信的其它实体看起来是集成整体的一部分。

支付系统中现有的凭证管理过程是中央化的——创建或验证凭证的任何请求都会导致对中央化系统的查询。对于实现EMV标准的支付系统，凭证是使用根据分层过程导出的密钥生成的。发行方主密钥(IMK)与特定范围的令牌相关联，并且用于凭证的密钥是分层导出的(卡主密钥–CMK–来自IMK，然后是会话密钥–SK–来自CMK)。这种方法用于设备(诸如物理卡)，但也用于数字交易。与基于设备的交互相比，数字交易的数量增长非常迅速，其中增长与资源更加一致。

在数字生态系统中，虽然存在非常快速的需求增长，但通常也存在更安全的环境，因为交互通常是在商家系统(或支付服务提供商)和交易系统之间通过身份明确的参与者之间的安全途径进行的。因此，当将所有资产安全保持在包括密钥管理和密码操作的受限环境中时，当暴露访问服务的API时，当在服务器上下文中提供服务时，在可以被流线化的设备上下文中存在为了安全性可能要求多个密码操作的交互。

虽然通过使用一组分布式服务器来生成和验证凭证来扩展用于执行数字EMV交易的交易系统似乎是可取的，但发现这种方法无法扩展。密钥生成的整体水平不会改变，但系统内的消息传递量会大大增加，因为需要管理和复制非常大量的令牌。由于现有的EMV密钥生成方法需要定制的代替现成的硬件安全模块(HSM)，因此处理要求高且成本高昂，并且数据存储，特别是网络延迟将变得无法管理问题。

本公开的实施例通过将令牌的绑定替换为特定分层导出的密钥从而允许将来自密钥堆栈的第一可用密钥改为分配给令牌化交易来支持这种分布式方法。这种方法使用灵活和动态的密钥管理，允许可扩展的解决方案。可以以确保分布式体系架构安全的方式进行监控，而无需传输或复制大量敏感信息。这种方法也可以使用完全符合FIPS的流程在标准HSM中执行——例如，不需要使用DES和3DES。下面更详细地描述这种方法。

目前，设备安全模型也用于完全数字交易。这种安全模型涉及存储在交易系统HSM中并用于从相关IMK和卡PAN(主账号)导出卡主密钥(CMK)的发行方主密钥(IMK)。然后这些CMK被存储在设备(通常是安全元件或替代技术)中。当使用基于软件的解决方案使用移动设备生成交易凭证时，使用相关CMK和卡/设备的ATC(应用交易计数器)生成会话密钥(SK)——这目前由如图5中所示的凭证管理系统(CMS)生成。目前，所有的令牌，即使对于完全数字交易，都绑定到这种IMK/CMK/SK推导。这也适用于由服务器通过交易系统暴露的用于远程支付交易的API而生成的交易凭证。

这种方法需要非常繁重的密钥管理负载，这不适用于完全数字交易，如下面参考图9和图10所讨论的。SK的生成以及因此应用密码(AC—EMV交易中的标准机制)需要多个密码操作，并非所有这些操作都可以由常规的现成的HSM执行，因此需要定制的HSM。需要在整个系统中大量分发密钥，使得在发生交易的任何地方交易的执行都能得到支持，并且ATC管理是复杂的。期望使用标准HSM、避免大量密钥复制，同时让密钥直接可用，并且能够提供限制整体HSM数量的解决方案(因为它们通常仅支持几千个密钥)。

这种安全性的大部分是即使在系统端点(例如，在持卡人设备处)有可能受到威胁时也提供安全保证。除此之外，安全性的作用有限，如图9中所示。密码函数的主要目的是提供保证——这覆盖了数据的完整性和认证两者。受密码数据保护的交易相关数据包括交易的标识和相关联的令牌，以及所使用的任何密码过程的指示和任何相关的金融数据(以及需要保证的交易的任何其它方面)。这由交易凭证表示——这需要生成G并随后验证V，这些过程被监控M以确保整体系统完整性并由某种密钥管理系统K支持。

在完全数字交易的情况下，这些过程发生在受限环境中，其中端点安全性不像设备那样成为问题。如从图10中可以看出，在该域中，令牌不会到达常规交易管理系统的任一端点——持卡人或发行方。替代地，它跨商家系统或支付服务提供商(PSP)和交易方案提供商进行操作。

这种方法允许将凭证系统从复杂的中央服务器分散到提供服务的多个节点中。这些节点通常在地理上分布，但可能会扩展到多个数据中心(例如，通过使用云基础设施来实现节点内的数据共享)。这些节点提供与凭证、生成服务G和验证服务V相关的服务，并定义对服务的访问控制的规则。商家或PSP与生成服务G通信以获得凭证，然后在标准授权过程中使用这些凭证，在需要验证凭证时调用验证服务V。这些服务可以访问节点的计算基础设施(HSM、数据库)。还提供监控M和密钥管理K服务——这些服务可以集中组织或包括中央和本地功能的混合。下面将更详细地描述所有这些服务及其相互关系。

可以以基本上常规的方式提供对服务的访问控制。可以为节点定义一组通用控制，并可以进行本地修改——例如，以满足本地监管或其它特定安全要求。这种方法可以轻松实现特定于国家的策略，例如通过将特定国家的所有业务限制到一组特定节点。访问控制可以在多于一个的级别(例如，针对各个服务，但也针对节点)执行，并且可以存在针对特定服务类型的特定规则或检查。访问控制潜在地非常颗粒化，并且可以以多种方式提供特定的解决方案——例如，它可以用于允许给定商家在给定令牌的定义时间期间执行最大数量的交易凭证生成操作。

图11中所示的密钥管理机制图示了如何能够将有限数量的密钥分配给节点，同时提供确定性过程以选取用于生成凭证的密钥。验证实体可以使用相同的过程来确定生成器使用的密钥，使得它可以验证作为提交验证的凭证的一部分的任何密码材料。

对于每个节点，生成G和验证V服务都可以访问HSM池。HSM包含各自由一组密钥标识符(KeyId)唯一识别的密钥。KeyId可以是标签、值、明确的唯一值(诸如UUID)、或具有适当属性的任何其它内容。这些KeyId被存储在唯一识别(标识符)密钥列表中——这些密钥列表提供了标识符(Id)和存储的密钥(KeyId)之间的关系列表。标识符(Id)是由确定性过程确定的，以便建立要使用什么密钥，如将在下面进一步描述的。

每个密钥列表的完整性使用密封锁(Seal)来保证——如果密钥列表是从中央位置供给的，那么这可以由与该中央位置相关联的受信任方应用。可以使用例如作为本地功能而不是中央位置的受信任方来支持若干其它分布模型。节点通常有多个可用的密钥列表，但在给定时间仅有用于生成凭证(G)的一个活动密钥列表——但是，验证服务(V)通常需要能够访问可以与仍然有效的凭证相关联的任何密钥列表。这种方法中的密钥轮换非常简单——它可能只涉及用另一个密钥列表替换活动密钥列表。但是，判断需要哪个KeyId来验证凭证非常简单——这将完全由节点标识符和对密钥列表的引用来确定。该信息是凭证的一部分，并用作确定性过程的输入以从密钥列表中选取密钥。

图11图示了节点Ni的示例性布置，其具有能够生成与交易相关联的凭证的两个生成服务G。在任何给定的时间点，将需要这些服务G使用给定的密钥列表——比如第一实例中的密钥列表A。这使用黄色111和蓝色112密钥，因此这些密钥必须加载到生成服务G所使用的HSM中。在一段时间到期后，密钥轮换过程可能例如强制使用密钥列表B——这使用黄色111和蓝色112密钥，但也使用绿色113密钥，因此绿色113密钥必须加载到相关HSM中(如果尚未存在)。要使用的特定密钥是通过确定性过程从密钥列表中选择的，如下面将讨论的——这通常会在密钥轮换后给出不同的结果，但情况并非不可避免(例如，Id＝2或Id＝6将在轮换之前或之后给出蓝色112密钥)。虽然生成服务G在密钥轮换后不需要密钥列表A，但验证服务V仍然需要——它们需要访问与潜在有效凭证相关的任何密钥列表。验证服务V必须能够确切地确定生成服务G使用哪个密钥来生成凭证，以便验证凭证。

要密码保护的交易相关数据包括与交易相关联的令牌的标识，但也包括交易本身的标识。为此，需要某种交易标识符。在每个节点，凭证生成和验证服务都可以访问可以用于管理此类数据的本地数据库。为确保跨系统有效管理交易，给定令牌的任何交易凭证生成都应与每个交易的唯一交易标识符相关联。这可以是UUID或任何适当的标识符结构(诸如，n比特节点标识符、e比特纪元时间和c比特本地计数器的级联)。

但是，通过使用本地交易计数器，交易凭证中传送的数据大小可以减少到几个数字位(digit)。这可以简单地存储在节点的本地数据库中，并且当本地生成服务G生成新令牌时，本地(而不是全局)值会递增，如图12中的一般项所示的过程。

现在将参考图11描述用于识别用于交易的密钥的示例性过程。如上所述，在任何给定时间，生成服务G可以访问本地HSM中的一组密钥，并根据其当前活动密钥列表来使用密钥。该密钥列表本身是(通过Identifier(标识符))唯一识别出的，并包含条目列表，这些条目对应于标识符(Id)和存储的密钥(由KeyId表示)之间的关系。在密钥列表A的情况下，存在十个条目，并且每个Id是整数。

将有与密钥列表相关联的确定性过程来确定哪个密钥将与给定的交易相关联。对于每个密钥列表，不需要是相同的确定性过程，但需要一致地用于该密钥列表，使得生成和验证服务都将获得相同的结果。为了提供这种关联，确定性过程应该对识别交易的信息进行操作，诸如某种交易标识符——在这种情况下，本地交易计数器(LTC)是特别有效的选择，因为它可以方便地获得并且容易处理。

存在可用于函数的很多选择，但最简单的选择是MOD操作——例如，这里，Id＝LTCMOD 10将适合提供确定性结果，该结果可以指向任何可用的Id值。有权访问交易数据中的交易计数器值(或从该值导出的任何计数器)的任何验证服务V然后可以确定由生成服务G使用的逻辑密钥标识符，该生成服务G生成凭证并访问正确存储的密钥，而无需任何试错机制。以这种方式将确定性过程函数(以下称为keyList.GetIdFunction)与密钥列表的属性相关联允许可扩展的解决方案，该解决方案可以接受给定密钥列表的任意数量的逻辑密钥标识符。

HSM密码函数应该适用于通过凭证生成和验证来确保数据完整性和认证。密码函数使用密钥对所选择的交易数据进行操作，并提供不暴露密钥的输出。可以使用各种替代密码函数——HMAC是特别有效的选择，但CMAC、CBC MAC是其中可能的替代方案。使用的密码函数应在密钥列表中指定(如keyList.CryptoFunction)，并且还由用于生成和验证的HSM的能力驱动。土壤监管、密码材料出口或其它安全考虑可能导致选择特定的密码函数。

在交易数据内，应该有表示在交易过程期间生成的应用密码的信息。这可能是密码的简化形式——例如，在无法传送任何数字安全远程支付(DSRP)数据(使用EMV或UCAF字段)的传统环境(诸如磁条(Magnetic Stripe)或电子商务(eCommerce))中，这可以被提供为CVC2字段。这很重要，因为验证服务V必须能够访问生成服务G所使用的所有数据来生成密码——这将包括以下内容：

作为交易流程的一部分传送的动态信息；

来自以下之一的共享信息：

复制过程(诸如密钥列表的管理)；

特定用例的系统参数。

不同用例的标准方法——传统交易、UCAF和DPD字段交易——将在下面进一步讨论。当商家和/或PSP只能将PAN、到期日期和CVC2作为交易流程的一部分进行管理，并且无法访问最近的发展时，传统交易用例提供了解决方案。UCAF用例旨在利用最近引入的通用持卡人认证字段来传送更多数据作为交易流程的一部分。DPD用例涵盖数字支付数据的引入，这是能够传送作为交易流程一部分所需的所有数据的容器。

一组完整的密码机制如图13中所示。参考图14讨论密钥管理。该模型中的密钥管理有两个方面：密钥本身的管理，包括它们的生成和递送到与节点相关联的HSM，以及密钥列表的管理，包括它们的生成、分发、激活和停用。密钥列表是敏感资产，而密钥被视为秘密资产——密钥列表定义了用于密码的生成和验证的密钥。在将密钥加载到HSM中时，密钥需要端到端的安全性，其中使用包装/解包技术来安全传输密钥。它们的使用不应受到密钥列表的影响，以防攻击者想要改变密钥列表的内容以更改密钥选择过程。密钥列表的完整性由密封锁保证——通过生成方或相关联的可信方为密钥列表提供密封锁，将涉及合适的密码过程(诸如，具有适当专用密钥或使用例如使用非对称算法(诸如RSA、ECC、SM2...)生成的数字签名的HMAC)，并且其效果是系统的任何相关部分都可以确信密钥列表是由适当的一方生成的并且尚未被修改。此外，密钥列表密封锁可以用于密码的生成和验证以保护凭证。

不同的控制模型是可能的。可能存在中央控制，其中中央服务生成密钥和密钥列表，并将它们分发到不同的节点。但是，如果在特定节点处需要专用过程，也可能存在本地化控制。如果对于特定国家存在特定要求，那么这可能特别适用——例如，对密码材料出口的土壤监管或限制。如果HMS管理需要专有机制——例如，特定的云服务提供商，那么这也可能适用。这不需要受节点限制——它可以适用于区域内具有中央服务的区域控制(这可能特别适用于特定国家有特定安全模型以满足当地法律要求的情况)。也可以存在混合或复合模型，其中一些密钥和密钥列表供给是中央的，而一些是本地的——也可能存在分布式模型，其中分布式对等点一起承担中央服务的角色。

与图15相关讨论的监控可以具有本地和中央两个方面。虽然本地监控和中央化监控都是可能的，但混合方法可能特别有效，以便提供对任何问题的有效检测并产生有效应对以抵消与完全分布式体系架构相关联的风险。

要考虑的监控主要有三类：分布式系统的完整性；交易凭证的生成；以及交易凭证的验证。由于交易凭证可以在任何地方生成或验证，因此对整个分布式系统进行有效监控是重要的。要考虑的风险包括攻击者滥用节点中生成服务G所生成的真实交易凭证，特别是尝试在其它节点中的多个验证服务中进行验证——这是一个问题，因为验证服务V通常不会实时查看分布式系统的其它节点中验证服务V采取的动作。

虽然监控对于维护系统的完整性是重要的，但限制产生的消息传递量以确保系统可扩展并且不会因监控过程而过载也是重要的。可以进行多个选择来确保有效的监控过程。一个是针对由凭证生成服务G直接馈送的监控过程M。另一个是：由于任何验证服务V都可以验证交易凭证，在任何给定节点处为所有验证服务V提供共同存储。这允许监控服务M本地的相关联数据管理以提供初始防御层，特别是针对重放检测。

然后，本地监控服务可以能够经由中央监控服务(中心辐射(hub and spoke))或直接(对等(peer to peer))向其它节点报告，从而向作为第二层防御的其它验证服务V报告，以防止跨节点滥用交易凭证。

验证服务本身显然会检查交易凭证是否有效，并且可以级联检测任何问题(诸如验证失败、过度重试以及无效的交易数据或密钥列表引用)——这些可以用于跨节点暂停令牌。还可以执行附加控制，诸如对密钥列表密封锁的验证进行随机检查。另一个监控过程是不同服务类型之间的关联——这里是生成G和验证V——以检测交易凭证是否已经丢失(由于未提交、异常生成或其它原因)。可以跟踪密码材料的使用以跟踪它被适当地使用并且系统被适当地配置——例如，可以跟踪使用给定存储的密钥的密码操作的数量。

如上所述，有效监控要遵循的一个原则是提供有效的解决方案，而不会对分布式系统造成过多的负载。这可以通过支持不同级别的信息(例如，在适当的情况下进行本地监控，仅进一步传达本地监控活动的摘要)并通过数据复制和共享减少负载来完成。

监控可能因节点而异，或因地区而异，其中存在特定的要求。可以在给定节点或给定地区使用特定的监测过程来解决给定地理区域中的土壤或个人可识别信息(PII)要求。

所涉及的挑战是在交易中有效识别凭证是如何生成的，以便实现它们的后续验证——特别是识别哪个节点生成了凭证以及使用了哪个密钥列表来完成它，以及本地交易计数器的状态。这是具有挑战性的，因为交易数据受到高度限制，并且为了提供任何此类信息，有必要更改现有的电子交易协议(诸如ISO 8583)或重新利用现有字段。

对于传统的电子交易协议，原则上可以被重新利用的字段是主账号(PAN)，因为PAN内的一些数字位在此类交易的上下文中可能是隐含的，并且因此可以被重复使用，到期日期，其中一些信息可以以压缩格式以及CVC2传送。可以使用到期日期作为载体直接释放六比特，但这还不够——对于任何扩展系统，节点标识符通常至少需要四比特，并且一比特可能不足以用于密钥列表引用或交易计数器。

可以使用的一种方法是使用一组特定的银行信息号码(BIN)，其构成PAN中的前六个数字位，以支持上述实施方式——当检测到这些BIN中的一个时，可以采用特殊处理。这可能涉及将令牌与多个PAN值相关联。该模型如图16中所示。FPAN(资金主账号——对应于实体卡账户)——可以映射到一个或多个令牌，但特定的令牌与特定技术相关联。顶行示出了常规的令牌化过程——FPAN与单个令牌相关联。在使用上述方法的情况下，对于传统EMV用例(底线)，令牌可以与九个PAN值相关联，但是如下所述，对于某些新格式，仍然可以使用一对一映射。

因此，传统情况下交易字段的重用可以如下。对于PAN，可以使用14个数字位来完全识别令牌，其中1个数字位用于与给定数字的令牌相关联的计数器，并且1个数字位用于Luhn数字(其需要被保留为校验和以确保使用有效数字)。到期日期的6比特可以被重新利用，其中x比特用于识别节点，y比特用于引用该节点的相关密钥列表。CVC2提供可以用于密码的三个数字位。

为了安全，期望定期更改密钥列表，以确保系统安全免受攻击。能够在凭证创建后的一段时间内允许对其进行验证也是重要的——建议的方法是允许在创建后最多24小时内验证凭证。如果这与每24-36小时操作一次的密钥轮换过程相结合，这意味着虽然生成过程对于给定节点将仅有一个活动密钥列表，但验证过程将仅需要考虑两个密钥列表(一个当前活用于凭证生成，另一个紧接在它之前活动)。使用基于交易计数器建立的确定性过程从而建立要使用的密钥。这种类型的二进制信息(即，一个或另一个)通常可以使用一比特信息进行编码。密码在保护交易完整性方面起着关键作用——成功验证使用正确密钥对给定数据集计算的密码确认最初用于凭证生成的数据是真实的。验证过程中的任何失败都可能来自使用错误的密码材料和/或损坏的交易数据。

图17中示出了这种传统布置的示例性密钥轮换过程。首先，根据需要向HSM提供新密钥——这可能是通过从中央源分发，或通过另一个密钥生成过程，例如通过本地密钥生成进行的。然后生成新密钥列表——这可能涉及现有密钥和新密钥——这里，密钥列表中的大多数插槽(slot)涉及密钥列表中新位置中的现有密钥(但是密钥也可能保留在密钥列表中的相同位置——如这里针对密钥列表位置2和6所示)，但是在位置3、7和8中也使用了新密钥。同样，这可能是中央过程，一个由分布式网络中的对等点管理，或者一个本地管理。新的密钥列表被分发到有资格进行验证的任何验证服务以及使用它来生成的单个生成服务。新密钥列表然后在验证服务中被激活，并且然后在生成服务中被激活，这自动停用该生成服务中的先前活动密钥列表——此时密钥轮换过程完成。在24小时后，先前密钥列表然后针对验证服务被停用。这种方法适用于传统情况可用的有限空间——只需切换单个比特即可指示使用了哪个密钥列表。

一个潜在的问题是，为给定令牌执行的交易数量看起来受到可用于传送交易计数器的空间的限制。一种解决方案是增加交易计数器的可用空间，但这将对应地限制可用令牌的数量(因为这是附加比特可能来自的唯一地方)。另一种可能性将是如果验证最初未能恢复“完整计数器”值，其中该值大于原始可用空间并且仅作为模值存储，那么使用“重试”过程。可以组合这两种方法。还可以为不同的令牌范围引入不同的规则。

在每个节点中，每个生成(G)和验证(V)服务都可以访问本地数据库。给定令牌的任何交易凭证的生成都与每个交易的唯一交易标识符相关联。对于给定节点中的给定令牌，本地交易计数器(LTC)由“G”管理。同样的过程适用于由“V”验证时。该信息在PAN字段(数字位15，或数字位14和15)中传送，其中到期日期字段中有重试标志，如果LTC处于较高值，那么在必要时生成“完整计数器”。但是，重要的是要限制对于给定密钥列表对于给定节点对于给定令牌可以由G生成并且由V验证的密码数量，以确保有效的访问控制——该值“MaxTransactionCounter”可以被存储在密钥列表中并由密钥列表密封锁保护。

图18中示出了此传统情况的密码过程。在这种情况下，选择HMAC作为密码函数，因为这允许在递送有效功能的同时使用通用HSM。令牌的标识使用PAN值。交易的标识从到期日期(EMV字段DE14)获取信息——特别是节点标识符和引用，可能还带有重试标志——并且来自保持计数器的PAN字段。密钥的标识和密码方法由计数器(其确定从密钥列表中选择哪个密钥)以及由密钥管理系统在密钥列表中共享的信息一起提供。定义交易的各种字段可以用作用于生成密码的金融数据(如图18中所示)，所有这些字段都用于生成密码，该密码然后被十进制化并在CVC2字段中使用三位最低有效数字。

本领域技术人员将认识到，这些协议的一些变体可以优先考虑某些选择或优先级。例如，可以考虑期望找到更有效的方式来传送数据，诸如不需要使用重试过程的本地交易计数器——如从图19中可以看出，上面显示的过程允许交易计数器最多使用PAN的两个数字位(并且使用两个数字位限制了可以提供的令牌数量)，并在三个CVC数字位中保持了缩减的密码。一种不同的方法是仅使用密码中的CVC字段的两个数字位而不是三个数字位，其中另一个数字位用于保持本地交易计数器的最右边的数字位。这可以通过将三个数字位重新布置为不同的顺序以更动态的方式提供——这可以通过将CVC编码表添加到密钥列表中来完成，使得在使用密钥列表时，编码表——也受密封锁保护——确定为提供CVC2字段而选择的编码。可以通过G和V服务两者都已知的任何值来选择代码——例如，PAN的Luhn数。然后，新密钥列表可以使用完全不同的编码表，从而使该过程具有显著的动态性。

这种布置如图20中所示。PAN数字位识别令牌并且还提供Luhn数，并且Luhn数用于确定CVC字段的数字位顺序——在这种情况下，选择选项3，指示密码在前两个位置的最低有效数字位和次最低有效数字位，计数器的最低有效数字位在第三位置。这导致G和V服务两者都可以导出CVC输出。

如果使用较新版本的电子交易协议，那么可以使用其它字段来传送更多信息。例如，在通用持卡人认证字段(UCAF)可用的情况下，可以使用许多附加数字位，从而允许避免在传统情况中使用的妥协。这种方法可以释放另外21个字节的数据来传送数据作为交易流程的一部分。这足以允许传送完整的本地交易计数器值，从而避免需要任何重试机制。可以使用更多的密码材料——8字节的密码，而不是2个或3个数字位。可以使用更多的节点，而不会因为电子交易协议要求中定义的交易数据中的可用空间有限而导致节点识别成为问题。也可以比24小时更频繁地轮换密钥列表，因为存在空间来使用多于一个的比特用于验证服务的密钥列表标识。可以利用交易数据中的可用空间提供附加特征，例如通过支持商家锁定技术(在使用某种形式的商家标识将交易有效绑定到给定商家的情况下)、通过在密码过程中包含附加组件(诸如通过在生成器和验证器之间使用一些随机元素或种子)、或通过采取附加措施来提供符合任何监管要求的完全合规性。

如从图21中可以看出，使用UCAF内容的新布局(例如，格式7)有21个字节可用。可以在版本标识符和码本之间拆分一个字节以指定密码生成中使用的条件数据。完整的字节可以用于保持本地交易计数器——这意味着生成服务G将能够针对给定节点针对给定令牌每个密钥列表生成最多(up to)255个密码，这应该可以防止需要重试计数器并且在激活新密钥列表之前解决交易凭证的需求。另一个字节对于节点标识符数据和密钥列表引用是足够的，这为密码生成和/或验证中使用的条件数据留下完整的10个字节——每个用例都与码本中的值相关联——从而允许使用与授权消息中传送的数据不同的数据(传送的数据可以包括用于交易的不可预测的号码、商家数据，诸如商家类型和卡接受者或收单机构ID代码、金额相关信息…)。8个字节可以用于截断密码，从而显著提高安全性。图22指示密码过程如何与图18中所示的不同——PAN、LTC、节点标识符和引用都可以被轻松地包含在内，并且可以在加密数据中提供附加信息，诸如附加交易字段、码本和其它条件数据。

这种方法提供了各种进一步的可能性。为密钥列表引用供给附加比特允许两倍频繁的密钥列表轮换。虽然一些要求仍然存在——诸如需要限制服务G针对给定密钥列表针对给定节点的给定令牌生成的密码数量——但其它要求被免除(完整LTC的存在意味着不需要任何重试过程)。应该注意的是，密钥列表可能仅限于特定用例——传统、UCAF或DPD——并且这可以用于确定指定用例的交易计数器的特定限制。

不久将引入称为DPD(数字支付数据)的新格式——这甚至将提供更多的选项，如图23中所示。如上所述，DPD可以将UCAF传送到凭证。在第一个选项中，生成服务可以在交易创建时定义唯一标识符(诸如，UUID)，并将其添加到密码过程中使用的数据列表——这允许交易凭证独立于交易详细信息进行端到端跟踪，从而提供监控和欺诈预防优势。在第二个选项中，可以使用大得多的码本，以及节点的扩展标识、更多条件数据的存储和使用如在其它交易流程中使用的标准截断密码——以及用于第一个选项的UUID。

如本领域技术人员将认识到的，上述实施例是示例性的，并且本领域技术人员根据以上阐述的原理和示例进行工作可以开发落入本公开的精神和范围内的进一步实施例。

Claims (18)

1.一种用于计算节点响应于服务请求而提供密码密钥的方法，所述方法包括：

建立密钥列表，其中所述密钥列表包括多个密钥的密钥标识符；

接收服务请求并且响应于服务请求而识别出需要密钥；以及

使用根据与服务请求相关联的数据的确定性过程来分配密钥标识符中的一个密钥标识符，并且因此将与密钥标识符中的所述一个密钥标识符相关联的密钥分配给所述服务请求。

2.如权利要求1所述的方法，其中计算节点是分布式计算系统的多个节点中的一个节点。

3.如权利要求2所述的方法，其中服务请求是从分布式计算系统内的客户端接收的。

4.如权利要求3所述的方法，其中客户端是与计算节点相关联的分布式计算系统的客户端的子集中的一个客户端。

5.如权利要求4所述的方法，其中服务请求与凭证的生成或验证相关。

6.如权利要求5所述的方法，其中凭证与由提供服务请求的客户端执行的交易相关。

7.如权利要求6所述的方法，其中与服务请求相关联的数据包括交易标识符。

8.如权利要求7所述的方法，其中交易标识符基于本地交易计数器。

9.如前述权利要求中的任一项所述的方法，其中密钥列表包括唯一标识符。

10.如前述权利要求中的任一项所述的方法，其中在密钥列表中识别用于密钥和密码操作选择的确定性过程。

11.如前述权利要求中的任一项所述的方法，其中密钥列表用密钥列表密封锁以密码方式密封。

12.如前述权利要求中的任一项所述的方法，其中密钥列表具有有效期。

13.如权利要求12所述的方法，还包括当有效期到期时，用另一个密钥列表替换所述密钥列表。

14.如权利要求13所述的方法，其中另一个密钥列表由远离计算节点的中央服务提供、由对等节点提供或在本地生成。

15.如从属于权利要求5的权利要求13至14中的任一项所述的方法，其中所述有效期与凭证的生成相关，但与生成的凭证的验证无关。

16.如前述权利要求中的任一项所述的方法，其中在密钥列表中识别用于使用密钥的密码方法。

17.如权利要求16所述的方法，其中密码过程递送计算节点上的密码证明、来自服务请求的信息、交易标识和来自密钥列表的信息。

18.一种计算节点，适于根据权利要求1至17中的任一项所述的方法响应于服务请求而提供密码密钥。

Images