CN116250209A - 分布式计算系统中的数据管理和加密 - Google Patents

分布式计算系统中的数据管理和加密 Download PDF

Info

Publication number
CN116250209A
CN116250209A CN202180060004.7A CN202180060004A CN116250209A CN 116250209 A CN116250209 A CN 116250209A CN 202180060004 A CN202180060004 A CN 202180060004A CN 116250209 A CN116250209 A CN 116250209A
Authority
CN
China
Prior art keywords
transaction
service
key
credentials
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180060004.7A
Other languages
English (en)
Inventor
M·克林吉
A·约翰逊
O·拉齐马尼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard International Inc
Original Assignee
Mastercard International Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mastercard International Inc filed Critical Mastercard International Inc
Publication of CN116250209A publication Critical patent/CN116250209A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H04L9/0836—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key using tree structure or hierarchical structure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

描述了在计算节点处为计算节点外部的请求方提供安全服务的方法。以下步骤在计算节点处发生。从请求方接收服务请求，该服务请求包括生成凭证的请求。计算节点生成凭证，并获得服务相关信息。创建包括服务识别信息的明文消息部分。然后从服务识别信息的至少一部分和从服务相关信息和凭证的至少一部分创建校验和。然后对凭证、服务相关信息和校验和进行加密以形成加密的消息部分。然后向请求方发送包括明文消息部分和加密的消息部分的消息。还描述了用于提供安全服务以验证凭证和获得服务相关信息的方法，以及适于执行所有这些方法的计算装置。

Description

分布式计算系统中的数据管理和加密
相关申请的交叉引用
本申请要求于2021年5月28日提交的英国专利申请号2107661.7的权益，该临时申请的内容出于所有目的通过引用并入本文。
技术领域
本公开涉及分布式计算系统中的数据管理和加密，特别地，涉及执行一个或多个安全过程的分布式计算系统。
背景技术
存在需要中央化(centralized)系统为非常大量的客户端提供服务的多个技术挑战，尤其是当这些客户端在地理上广泛分布时。考虑分布系统使得相关服务能够由一组地理上分布的服务器提供，代替由一个中央服务器或数据中心提供是合乎逻辑的。
在实践中，这种去中央化可能会使用云体系架构，该云体系架构将通常使用多个地理上分布的服务器——或数据中心——来向客户端递送服务。云体系架构可以被认为包括多个节点——当使用云体系架构时，节点可以是多个计算机的聚合，并且可以在给定节点内以“实时”连接和数据共享来覆盖多于一个的数据中心。
去中央化本身可能是有问题的，特别是在有必要以这种方式来提供服务的情况下，服务的供给会产生超出提供服务的服务器和接收服务的客户端的后果。例如，如果其它客户端(或其它系统节点)需要回溯到服务提供节点以检查否已提供服务或如何提供服务，或者中央系统是否有必要知道已经如何提供服务或分布式服务器节点的预期操作，那么新的瓶颈可能会取代以前的瓶颈出现在中央服务器上，系统中的消息传递总量可能增加，并且网络延迟可能成为严重的问题。
当服务与安全性相关时(因此有必要确信它已在整个系统中安全地执行)以及当与在短时间帧内供给服务相关时，这尤其严重。这两个问题都适用于交易系统——交易需要在短时间段内获得授权，并且有必要确保交易已经被合法执行——但也适用于其它技术情境(context)。
诸如交易授权之类的服务可能需要在短时间帧内完成，但也可能需要将与服务实例相关的数据安全且可靠地保持到将来。如果存在异常多的服务实例，那么服务实例记录的安全存储将被证明是极其繁重的。解决这个问题所期望的方式是可以识别过去的服务实例，并使用与服务实例相关的数据来支持将来的服务活动，所有这些都是以维护数据安全性而不对系统资源有过多需求的方式。
发明内容
在第一方面，本公开提供了一种在计算节点处为计算节点外部的请求方提供安全服务的方法，所述方法包括在计算节点处：从请求方接收服务请求，其中该服务请求包括生成凭证的请求；生成凭证；获得服务相关信息；创建包括服务识别信息的明文消息部分；从服务识别信息的至少一部分和从服务相关信息和凭证的至少一部分创建校验和；使用加密过程来加密凭证、服务相关信息和校验和，以形成加密的消息部分；以及向请求方发送包括明文消息部分和加密的消息部分的消息。
使用这种方法，可以使凭证仅在相对短的时间段内可用于验证，同时使服务相关信息在长得多的时间段内可用，其中校验和提供对于未加密的和加密的消息部分之间的关系的完整性的保证。
在实施例中，加密过程包括块密码。
可以使用密码过程来生成凭证。可以使用共享机制用于为加密过程和密码过程提供密钥。在实施例中，用于加密过程的密钥的密钥有效期可以长于用于密码过程的密钥的密钥有效期——以这种方式，当凭证无法被验证时，服务相关信息在延长的时间段内仍然可用——这甚至可能先于凭证的验证。
在实施例中，密码过程可以特定于执行密码过程的节点，而加密过程可以不特定于执行加密过程的计算节点。如果加密过程没有以这种方式绑定到特定节点，那么可以通过维护允许访问加密密钥的节点列表来管理它，其中列表上的节点被允许执行加密和解密。
密码过程可以包括密钥散列算法。
在实施例中，安全服务包括为交易提供凭证以允许交易在验证所述凭证的情况下被授权。未加密的消息部分然后可以包括用以识别如何处理交易的信息，并且加密的消息部分可以包括交易数据以及凭证。该交易数据可以包括账户数据和交易详细信息，其中交易详细信息适于独立于凭证的验证来检查账户数据的有效性。
在第二方面，本公开提供了一种在计算节点处为计算节点外部的请求方提供安全服务的方法，所述方法包括在计算节点处：从请求方接收服务请求，其中该服务请求包括验证凭证的请求，其中该服务请求包括包含凭证的消息，其中该消息包括包含服务识别信息的明文消息部分以及包含凭证、服务相关信息和校验和的加密部分，该校验和是从服务识别信息的至少一部分以及服务相关信息和凭证的至少一部分生成的；使用服务识别信息执行解密过程以解密消息的加密部分；使用校验和来确定消息中的信息的完整性；以及进一步使用服务识别信息来验证所述凭证。
解密过程可以包括块密码，并且可以使用诸如密钥散列算法之类的密码过程来生成凭证。
安全服务可以包括验证交易的凭证以允许交易被授权。在这种情况下，未加密的消息部分可以包括用以识别如何处理交易的信息。
在第三方面，本公开提供了一种在计算节点处为计算节点外部的请求方提供安全服务的方法，所述方法包括在计算节点处：从请求方接收服务请求，其中该服务请求包括确认服务相关信息的完整性的请求，其中消息包括包含服务识别信息的明文消息部分以及包含服务相关信息和校验和的加密部分，该校验和是从服务识别信息的至少一部分和服务相关信息的至少一部分生成的；使用服务识别信息执行解密过程以解密消息的加密部分以提供服务相关信息；使用校验和来确定消息的完整性；以及进一步使用服务相关信息的第一部分来确认服务相关信息的第二部分的完整性，其中服务相关信息的第一部分是在服务请求中提供的。
解密过程这里可以包括块密码。
安全服务可以包括向有权接收交易相关数据的一方提供交易相关数据，在这种情况下，未加密的消息部分可以包括用以识别如何处理交易的信息——然后加密的消息部分可以包括交易数据。该交易数据可以包括账户数据和交易详细信息，其中交易详细信息适于检查账户数据的有效性。
在该方法中，计算节点可以确定其是否有权获得密钥以执行解密过程，并且如果是的话，则访问所述密钥。
在第四方面，本公开提供了包括处理器和存储器并且适于发送和接收消息的计算装置，其中所述处理器被编程以在存储器的帮助下执行如上所述的第一方面至第三方面中的任一方面的方法。
附图说明
现在参考附图以举例的方式描述本公开的具体实施例，其中：
图1示出了与中央服务器交互的多个客户端；
图2示出了提供与图1中的中央服务器相同的服务的分布式计算体系架构交互的多个客户端；
图3示出了诸如图2中所示的分布式系统的操作，其中分布式节点创建和验证证明；
图4示出了根据本公开的实施例的在图3的布置中提供附加加密层的方法；
图5示意性地示出了使用四方模型的分布式交易体系架构；
图6图示了适于实现图5的交易体系架构的复杂分布式系统的元素；
图7示意性地示出了用于在图5和图6的交易体系架构中实现数字交易的示例性系统；
图8示意性地图示了用于交易的数字化实现(enablement)的分布式系统的布置；
图9更详细地图示了图8的布置的计算节点；
图10图示了图9的计算节点内的元素；
图11指示与图9的节点执行的操作相关的交易流程；
图12指示在图9至图11的布置的实施例中使用令牌化(tokenization)；
图13指示在图8至图12的布置中使用的密钥管理的方法；
图14图示了交易识别的示例性方法；
图15图示了用于图8至图14的布置中的数字化交易的一组示例性密码机制；
图16图示了具有如图13中所示管理的各个模式的密钥管理的全局模型；
图17图示了与图13和图16的密钥管理模型相关联的全局监控模型；
图18示出了根据本公开的实施例的如图9中所示的节点中的第二加密层的管理；
图19示出了加密和解密的使用在图9的节点和图18的节点之间如何变化；
图20示出了本公开的实施例中交易数据与加密材料之间的关系；
图21示出了本公开的实施例中使用的加密和解密过程；
图22A和图22B分别图示了如在本公开的实施例中使用的节点简档和节点简档内的服务简档；
图23示出了密钥列表的元素，其图示了用于生成和验证凭证的密钥列表与用于图21的加密和解密过程的密钥列表之间的异同；
图24图示了用于图23中所示的密钥列表的密钥拓扑；
图25A和图25B图示了在图22的节点简档中使用的密钥列表简档的元素；
图26A和图26B分别比较了图21的过程中使用的交易密钥列表和加密密钥列表；
图27图示了使用适合与图9的节点一起使用的UCAF(通用持卡人认证字段)格式来传送交易凭证信息作为交易的一部分的方法；
图28图示了用于使用UCAF格式的数字化交易的一组示例性密码机制；
图29图示了特别适合与图28中所示的密码机制一起使用的修订后的UCAF格式；
图30示出了在图29中所示的修订后的UCAF格式中使用的校验和的生成中使用的信息；
图31图示了使用图19中所示的修改过程的初始交易的执行；
图32图示了使用图19中所示的修改过程进行验证之前访问映射信息；
图33图示了使用图19中所示的修改过程访问映射信息用于后续交易；以及
图34总结了使用图19的修改过程可以采取的不同类型的动作。
具体实施方式
一般而言，本公开的情境在图1至图3中图示。图1示出中央系统响应于来自非常多的地理分布的实体的请求而执行功能。这对中央系统提出了与处理能力、存储和消息传递相关的强烈需求，并且通常会由于瓶颈和消息传递要求而导致整个系统的大量负载。当请求来自与中央化系统通信的地理上遥远的请求者时，除了行进时间导致的网络时延问题之外，还有其它问题。
图2示出了替代布置，其中中央系统的角色被复制，使得相同的功能由一组分布式节点执行，每个节点都具有执行中央系统提供的部分或全部功能的能力。各个节点应该看到比中央系统低得多的需求，并且由于实体应该能够比中央系统与更多的本地节点进行交互，因此有可能减少网络时延。但是，如上面一般性讨论的以及下面与交易处理系统具体相关讨论的那样，实现这一益处存在重大的技术挑战——特别地，对于直接复制，需要将所有相同的信息分发给复制中央化系统的所有节点，从而通常使整体状况变得更糟而不是更好。
在需要系统的第二个用户确信系统的第一个用户采取的动作是合法的情况下，存在特定的困难。在图1的情况下，这相对简单——因为服务是集中执行的，并且中央系统拥有所有信息，那么如果用户信任中央系统，这通常不会有问题。在图2的情况下，第一用户可能一直在与一个节点交互，并且第二用户可能正在与另一个节点交互，在这种情况下，除非所有必要的信息在所有节点之间共同保持、适当地进行同步(这将在复制中央化系统时使分解点失败)，否则无法达到相同的置信度。如果第一用户执行的第一服务的产品是有价值的信息——诸如第一用户进行支付证明将被第二用户用于完成交易——那么由于例如多个第二用户在多个节点处使用证明来完成相关交易而导致的系统故障或妥协的风险需要被解决。
一般而言，这种情况如图3中所示。第一用户51请求执行第一服务53——在这种情况下，创建诸如来自特定账户的支付之类的事件的证明——并且第二用户52从第二服务54请求对该事件的证明进行验证，例如以确定有效地进行了支付。第一用户51已经在第一节点55处调用了第一服务53。第二用户通常无法选择在哪里调用第二服务54——这可能是地理或其它管理因素的问题——特别是可能无法在第一节点55处调用第二服务54(但是这可以是一种可能性)。实际上，然后将在具有足够信息来实现验证过程的另一个节点56a、56b、56c处调用第二服务54。通常，这将涉及访问一组公共密码密钥以及重新生成证明或以其它方式确定证明正确所需的最少信息集——如下面所讨论的，在实施例中，可以使用一组有限的密钥。此类证明或声称是此类证明的对象在一个或多个节点处呈现给一个或多个第二服务的情况需要被解决，以便此类系统可靠且安全地工作。
本公开教导了基于该方法的开发，如图4中所示。第一用户51像以前一样请求执行第一服务53，但是第一服务53的输出现在被提供给第三服务57以供进一步处理——在这种情况下，由第一服务53提供的事件证明的加密。在所示的情况下，第一服务53和第三服务57两者都被示为较大节点过程60的一部分。该节点过程60在这里也提供附加信息61连同来自第一服务53的事件证明，两者由第三服务53在公共信封中加密。第三服务57的加密输出再次被提供给第一用户51——如下面进一步讨论的，这可以是消息的一部分，其包含作为加密部分的加密输出以及节点过程60也提供的未加密部分。未加密部分可以用于识别服务实例，其中事件证明和其它敏感数据保持在加密部分中。这可以再次与第二用户52共享。还可能期望确保被解密的信息是有意义的，并且没有被破坏、篡改或人为构造——这可以例如通过包括使用来自加密部分和未加密部分两者的信息生成的校验和或其它确认来完成
第二用户52像以前一样获得证明的验证，其中的变化是在另一个节点56a、56b、56c处调用第二服务54之前，必须调用第四服务58以恢复证明以供第二服务54验证。
在实施例中，验证可能只有短的窗口——例如，24小时。加密和解密的时间帧可能长得多，因为关于服务事件的信息可能在验证后很久才需要，或者验证甚至仍然是可能的。在此期间，可能不再需要验证交易，但可能强烈期望恢复附加信息61。这可以通过识别相关交易来完成——例如，通过使用前面描述的消息的未加密部分——并使用该信息来获得解密。这里，第三用户59需要建立该附加信息——这可以在这里单独从第四服务58实现，而无需调用第二服务54，相关节点过程60返回附加信息。第四服务58甚至可以用于在验证发生之前(或者如果验证从未发生)建立该附加信息。
所有过程都可以使用相同的密钥识别过程，但是如所指示的，加密和解密可能会在长得多的时间跨度内操作，因此可以采用不同的密钥轮换策略。可能需要不同的算法用于生成/验证(可能涉及使用具有大量或可变量数据输入的散列)以及用于加密/解密(可能涉及块密码(block cipher))。
如上所述，这里的验证在很短的时间跨度内操作，而信息可能在长得多的时间跨度内需要。这段时间内安全环境可能变化，因此期望对加密能力和解密能力进行不同于验证能力的管理。这可以通过布置来解决，在这种布置中，虽然验证可能需要生成节点的知识，但如果加密过程不使用加密节点的标识，那么解密就不需要这种知识。以这种方式，只需通过使用确定哪些节点可以访问相关解密密钥的列表，就可以轻松管理解密能力。这提供了灵活的解决方案，该解决方案允许一组解密节点出于相关原因(诸如安全性)随时间而变化。
这个问题与交易处理系统尤其相关，特别是与用于处理数字交易的系统相关。数字交易的数量增长极快，并且需要它们可靠且快速地执行。对这些交易的支持可以使用为使用支付卡的基于设备的支付而开发的交易处理系统，并使用此类支付系统的协议，但实际上此类交易与基于设备的交易具有不同的特点。这将在下面讨论，首先参考交易处理系统的一般元素，然后更详细地讨论用于支持数字交易的基础设施。
图5是典型的四方模型或四方支付交易方案的框图。该图图示了模型中存在的实体以及在卡方案中操作的实体之间发生的交互。
通常，卡方案——与支付卡链接的支付网络——基于以下两个模型中的一个：三方模型或四方模型(由本申请人采用)。出于本文档的目的，下面更详细地描述四方模型。
四方模型可以用作交易网络的基础。对于每个交易，该模型包括四个实体类型：持卡人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)费以换取资金结算。
在四方系统模型的实际实施方式中，特定方的角色可能涉及共同作用的多个元素。在已经发展超越客户卡和商家终端之间基于接触的交互的实施方式到在诸如智能电话之类的用户计算设备上使用代理或虚拟卡的数字实施方式中，通常是这种情况。
图6示出了根据本公开的实施例的适合于持卡人和商家之间的交互的体系架构。该图示出了通用体系架构以供参考，但特别示出了当持卡人与商家服务器进行在线交易时使用的体系架构的特定元素。
对于常规的交易，持卡人将使用他们的支付卡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、检查令牌状态(以确保它处于有效期或以其它方式是有效的)以及使用的任何客户核实方法，在交易方案中对交易进行验证。这允许发行方以普通方式对交易进行授权。
图7更详细地示出了支持从移动设备进行数字化支付的交易基础设施的元素。该图示出了作为具体示例的申请人的基于万事达卡云的支付(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交互以确保与持卡人账户和凭证相关的同步。
在申请人的早期欧洲专利申请No.19178579.9中描述了实现用于执行如图7中所示的数字化交易的系统的各个方面的方法——特别是凭证的管理——能够去中心化，该申请的内容在适用法律允许的范围内通过引用并入。这是通过用一组去中央化的节点替换中央节点来完成的，每个去中央化节点能够进行凭证管理，如图8至图10中所示。
图8示出了计算节点Nx的去中央化的系统，每个节点都能够生成G和验证V凭证。这些凭证可以在整个系统中有效(除非由于本土(on-soil)监管等而仅限于一些节点)，并且在这种情况下与一组用户(客户端)的交易相关联，这些用户(客户端)的交易通常通过地理接近度被路由到该节点。节点向客户端提供凭证生成G和凭证验证V作为服务，并且它们需要能够安全地生成凭证并至少在它们有效时安全地验证它们。在所示的体系架构中，凭证没有被存储——它们是根据请求生成的，并即时进行验证。如图8和图9中所示，除了凭证生成和验证之外，密钥管理K和监控M可以被视为在节点本地和跨系统两者的服务，并且通常需要访问控制AC来允许访问服务。下面将更详细地描述这些方面。
合适的计算节点的元素如图10中所示。节点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)——这目前由如图7中所示的凭证管理系统(CMS)生成。目前，所有的令牌，即使对于完全数字交易，都绑定到这种IMK/CMK/SK导出。这也适用于由服务器通过交易系统暴露的用于远程支付交易的API而生成的交易凭证。
这种方法需要非常繁重的密钥管理负载，这不适用于完全数字交易，如下面参考图11和图12所讨论的。SK的生成以及因此应用密码(AC——EMV交易中的标准机制)需要多个密码操作，并非所有这些操作都可以由常规的现成的HSM执行，因此需要定制的HSM。需要在整个系统中大量分发密钥，使得在发生交易的任何地方都可以支持交易的执行，并且ATC管理是复杂的。期望使用标准HSM、避免大量密钥复制，同时让密钥直接可用，并且能够提供限制整体HSM数量的解决方案(因为它们通常仅支持几千个密钥)。
这种安全性的大部分是即使在系统端点(例如，在持卡人设备处)有可能受到威胁时也通过适当的预防机制提供保证。除此之外，安全性的作用有限，如图11中所示。密码函数的主要目的是提供保证——这覆盖了认证和数据的完整性两者。受密码数据保护的交易相关数据包括交易的标识和相关联的令牌，以及所使用的任何密码过程的指示和任何相关的金融数据(以及需要保证的交易的任何其它方面)。这由交易凭证表示——这需要生成G并随后验证V，这些过程被监控M以确保整体系统完整性并由某种密钥管理系统K支持。本公开涉及用以监控的方法，该方法通过适当的检测、消息传递和反应来有效地解决错误或恶意行为的后果——如将要描述的，这在很大程度上与交易的实际执行分开发生。
在完全数字交易的情况下，这些过程发生在受限环境中，其中端点安全性不像设备那样成为问题。如从图12中可以看出，在该域中，令牌不会到达常规交易管理系统的任一端点——持卡人或发行方。替代地，它跨商家系统或支付服务提供商(PSP)和交易方案提供商进行操作。
这种方法允许将凭证系统从复杂的中央服务器分散到提供服务的多个节点中。这些节点将通常在地理上分布，但可能会扩展到多个数据中心(例如，通过使用云基础设施来实现节点内的数据共享)。这些节点提供服务——与凭证、生成服务G和验证服务V相关——以及针对服务的访问控制的定义的规则。商家或PSP与生成服务G进行通信以获得凭证，然后在通过支付系统的支付网络执行的标准授权过程中使用这些凭证，在需要验证凭证时调用验证服务V。这些服务可以访问节点的计算基础设施(HSM、数据库)。还提供监控M和密钥管理K服务——这些服务可以集中组织或包括中央和本地功能的混合。
可以以基本上常规的方式提供对服务的访问控制。可以为节点定义一组通用控制，并可以进行本地修改——例如，以满足本地监管或其它特定安全要求。这种方法可以轻松实现本地化策略，例如通过将特定国家的所有业务限制到一组特定节点，或者通过采取其它特定于区域或市场的行动。访问控制可以在多于一个的级别(例如，针对各个服务，但也针对节点)执行，并且可以存在针对特定服务类型的特定规则或检查。访问控制潜在地非常颗粒化，并且可以以多种方式提供特定的解决方案——例如，它可以用于允许给定商家在给定令牌的定义时间期间执行最大数量的交易凭证生成操作。
图13中所示的密钥管理机制图示了如何能够将有限数量的密钥分配给节点，同时提供确定性过程以选取用于生成凭证的密钥。验证实体可以使用相同的过程来确定生成器使用的密钥，使得它可以验证作为提交验证的凭证的一部分的任何密码材料。
对于每个节点，生成G和验证V服务都可以访问HSM池。HSM包含各自由一组密钥标识符(KeyId)唯一识别的密钥。KeyId可以是标签、值、明确的唯一值(诸如UUID)、或具有适当属性的任何其它内容。这些KeyId值被存储在唯一识别(标识符)密钥列表中——这些密钥列表提供了标识符(Id)和存储的密钥(KeyId)之间的关系列表。标识符(Id)是由确定性过程确定的，以便建立要使用什么密钥，如将在下面进一步描述的。
每个密钥列表的完整性使用密封锁(Seal)来保证——如果密钥列表是从中央位置供给的，那么这可以由与该中央位置相关联的受信任方应用。可以使用例如作为本地功能而不是中央位置的受信任方来支持若干其它分布模型。节点通常有多个可用的密钥列表，但在给定时间仅有用于生成凭证(G)的一个活动密钥列表——但是，验证服务(V)通常需要能够访问可以与仍然有效的凭证相关联的任何密钥列表。这种方法中的密钥轮换非常简单——它可能只涉及用另一个密钥列表替换活动密钥列表。但是，判断需要哪个KeyId来验证凭证非常简单——这将完全由节点标识符和对密钥列表的引用来确定。该信息是凭证的一部分，并用作确定性过程的输入以从密钥列表中选取密钥。
图13图示了节点Ni的示例性布置，其具有能够生成与交易相关联的凭证的两个生成服务G。在任何给定的时间点，将需要这些服务G使用给定的密钥列表——比如第一实例中的密钥列表A。这使用黄色和蓝色密钥，因此这些密钥必须加载到生成服务G所使用的HSM中。在一段时间到期后，密钥轮换过程可能例如强制使用密钥列表B——这使用黄色和蓝色密钥，但也使用绿色密钥，因此绿色密钥必须加载到相关HSM中(如果尚未存在)。要使用的特定密钥是通过确定性过程从密钥列表中选择的，这通常会在密钥轮换后给出不同的结果，但情况并非不可避免(例如，Id＝3或Id＝6将在轮换之前或之后给出蓝色密钥)。虽然生成服务G在密钥轮换后不需要密钥列表A，但验证服务V仍然需要——它们需要访问与潜在有效凭证相关的任何密钥列表。验证服务V必须能够确切地确定生成服务G使用哪个密钥来生成凭证，以便验证凭证。
要密码保护的交易相关数据包括与交易相关联的令牌的标识，但也包括交易本身的标识。为此，需要某种交易标识符。在每个节点，凭证生成和验证服务都可以访问可以用于管理此类数据的本地数据库。为确保跨系统有效管理交易，给定令牌的任何交易凭证生成都应与每个交易的唯一交易标识符相关联。这可以是UUID或任何适当的标识符结构(诸如n比特节点标识符、e比特纪元时间和c比特本地计数器的级联)。
但是，通过使用本地交易计数器，可以将交易凭证中传送的数据大小减少到几个数字位(digit)。这可以简单地存储在节点的本地数据库中，并且当本地生成服务G为令牌生成新的交易凭证时，本地(而不是全局)值会递增，如图14中的一般项所示的过程。
现在将参考图13描述用于识别用于交易的密钥的示例性过程。如上所述，在任何给定时间，生成服务G可以访问本地HSM中的一组密钥，并根据其当前活动密钥列表来使用密钥。该密钥列表本身是(通过Identifier(标识符))唯一识别出的，并包含条目列表，这些条目对应于标识符(Id)和存储的密钥(由KeyId表示)之间的关系。在密钥列表A的情况下，存在十个条目，并且每个Id是整数。
将存在与密钥列表相关联的确定性过程来确定哪个密钥将与给定交易相关联。对于每个密钥列表，不需要是相同的确定性过程，但需要一致地用于该密钥列表，使得生成和验证服务两者都将实现相同的结果。为了提供这种关联，确定性过程应该对识别交易的信息进行操作，该信息诸如某种交易标识符——在这种情况下，本地交易计数器(LTC)是特别有效的选择，因为它可以方便地获得并且易于处理。
存在可用于函数的很多选择，但最简单的选择是MOD操作——例如，这里，Id＝LTCMOD 10将适合提供确定性结果，该确定性结果可以指向任何可用的Id值。有权访问交易数据中的交易计数器值(或从该值导出的任何计数器)的任何验证服务V然后可以确定由生成服务G使用的逻辑密钥标识符，该生成服务G生成凭证并访问正确存储的密钥，而无需任何试错机制。以这种方式将确定性过程函数(以下称为keyList.GetIdFunction，或GetId)与密钥列表的属性相关联允许可扩展的解决方案，该解决方案可以接受给定密钥列表的任何数量的逻辑密钥标识符。
HSM密码函数应该适用于通过凭证生成和验证来确保数据完整性和认证。密码函数使用密钥对所选择的交易数据进行操作，并提供不暴露密钥的输出。可以使用各种替代密码函数——HMAC是特别有效的选择，具有关于散列函数的若干选项，但CMAC、CBC MAC是其中甚至没有谈论使用非对称密码的解决方案的可能的替代方案。使用的密码函数应在密钥列表中指定(如keyList.CryptoFunction)，并且还由用于生成和验证的HSM的能力驱动。本土监管、密码材料出口或其它安全考虑可能导致选择特定的密码函数。
在交易数据内，应该有表示在交易过程期间生成的应用密码的信息。这可能是密码的简化形式——例如，在传统EMV交易中，这可以被提供为CVC2字段。这很重要，因为验证服务V必须能够访问生成服务G所使用的所有数据来生成密码——这将包括以下内容：
作为交易流程的一部分传送的动态信息；
来自以下中的一者的共享信息：
复制过程(诸如密钥列表的管理)；
特定用例的系统参数。
不同的方法可以用于不同的交易信息格式——传统交易、UCAF和DPD字段交易。当商家和/或PSP只能将PAN、到期日期和CVC2作为交易流程的一部分进行管理，并且无法访问最近的发展时，传统交易用例提供了解决方案。UCAF用例旨在利用通用持卡人认证字段来传送更多数据作为交易流程的一部分。DPD用例涵盖最近引入的数字支付数据，这是能够传送作为交易流程的一部分所需的所有数据的容器。如下所述，诸如UCAF之类的格式的附加能力可以支持本公开的实施例提供附加能力。
一组完整的密码机制如图15中所示。参考图16讨论密钥管理。该模型中的密钥管理有两个方面：密钥本身的管理，包括它们的生成和递送到与节点相关联的HSM，以及密钥列表的管理，包括它们的生成、分发、激活和停用。密钥列表是敏感资产，而密钥被视为秘密资产——密钥列表定义了用于密码的生成和验证的密钥。在将密钥加载到HSM中时，密钥需要端到端的安全性，其中使用包装/解包技术来安全传输密钥。它们的使用不应受到密钥列表的影响，以防攻击者想要改变密钥列表的内容以更改密钥选择过程。密钥列表的完整性由密封锁保证——通过生成方或相关联的可信方为密钥列表提供密封锁，将涉及合适的密码过程(诸如，具有适当专用密钥或使用例如使用非对称算法(诸如RSA、ECC、SM2...)生成的数字签名的HMAC)，并且其效果是系统的任何相关部分都可以确信密钥列表是由适当的一方生成的并且尚未被修改。此外，密钥列表密封锁可以用于密码的生成和验证以保护凭证。
不同的控制模型是可能的。可能存在中央控制，其中中央服务生成密钥和密钥列表，并将它们分发到不同的节点。但是，如果在特定节点处需要专用过程，也可能存在本地化控制。如果对于特定国家存在特定要求，那么这可能特别适用——例如，对密码材料出口的本土监管或限制。如果HSM管理需要专有机制——例如，特定的云服务提供商，那么这也可能适用。这不需要受节点限制——它可以适用于区域内具有中央服务的区域控制(这可能特别适用于特定国家有特定安全模型以满足当地法律要求的情况)。也可以存在混合或复合模型，其中一些密钥和密钥列表供给是中央的，而一些是本地的——也可能存在分布式模型，其中分布式对等点一起承担中央服务的角色。
图17以一般术语示出了监控。这里，监控是对直接在服务中采取的安全措施的补充，以防止欺诈或滥用(诸如服务的基本目的——使用密码生成凭证并进行后续验证)。这种监控旨在检测与交易相关联的安全异常——然后它可以触发适当的反应机制来包含任何安全风险并识别任何攻击者。原则上，这可能既有本地方面的，也有中央方面的。已经发现，混合方法特别有效，既可以提供对任何问题的有效检测，又可以产生有效的反应来应对与完全分布式体系架构相关联的风险。
在这样的系统中进行监控要解决三类问题：分布式系统的完整性；交易凭证的生成；以及交易凭证的验证。由于交易凭证可以在任何地方生成或验证，因此对整个分布式系统进行有效监控是重要的。示例性风险是攻击者滥用由节点中的生成服务G生成的真实交易凭证，特别是通过尝试在其它节点中的多个验证服务中进行验证——如果验证服务V对验证服务V在分布式系统的其它节点中采取的动作没有有效的可见性，那么这会成为问题。
虽然监控对于维护系统的完整性是重要的，但限制所产生的消息传递量以确保系统可扩展且不会因监控过程而超载也是重要的。因此，期望从节点发出的消息传递仅限于解决威胁真正必要的消息传递，并且期望节点在本地存储信息以允许有效使用监控结果。
在本公开的实施例中，通过添加附加的加密层来修改该方法以允许凭证在延长的时间段内受到保护——附加的交易相关信息也可以包括在与凭证一起的公共加密信封(envelope)中。这个延长的时间段可能比凭证生成后可以进行验证的时间段长得多。这个附加的加密层允许安全且高效地存储交易凭证，以便将来可以使用它们和其它交易相关信息，例如在新交易和先前交易之间建立联系(例如，在处理退款或预授权后的后续交易中)。当凭证在生成后提供时，它们可能在包含加密部分和未加密部分的消息中提供。加密部分可以包含凭证以及其它敏感交易数据。未加密部分可以包含允许识别交易并使系统的节点能够解密加密信封的信息。下面将进一步讨论用于提供这种消息的适当数据格式。
为此，除了向客户端提供凭证生成G和凭证验证V作为服务外，还提供了另外两个服务：加密服务E和解密服务D。该布置在图18中示出。其它特征与以前基本相同——密钥管理K和监控M再次可以被视为在节点本地和跨系统的服务，并且通常需要访问控制(未示出)以允许访问服务。加密和解密服务需要附加的密钥管理活动，但如下面所讨论的，由于所涉及的时间跨度不同，此策略将有所不同。
如前所述，节点80可以作为单个服务器或作为多个常规服务器(它们将包含它们自己的处理器和存储器——未示出——以及如通常在服务器中找到的其它组件)提供。节点80可以访问多个硬件安全模块85(HSM)，其适于以执行密码函数所需的密钥的形式保持密码材料并安全地执行密码函数，以及访问数据存储装置84。
加密服务E适于在凭证生成后对包括凭证的数据进行加密。如图19中所示，解密服务D用于解密此类加密数据，以允许凭证使得对其进行验证，并且还在以后的时间允许在必要时使用交易信息，通常是在进一步交易所需的情况下使用交易信息。虽然在执行交易时只需要一次凭证验证，但交易数据元素的识别和引用可能发生多次，因此加密和解密过程中使用的密钥需要长期保持可用。如下面将进一步描述的，加密和解密不依赖于验证过程并且解密可以在验证之后(甚至之前)执行许多次。如从图19中还可以看出，凭证生成G和验证V服务具有一组密钥，并且加密E和解密D服务具有另一组密钥。如下面将进一步描述的，这些可以使用类似的机制轮换，但在不同的时间帧内。
在生成凭证(在这种情况下为密码)时采用的密钥识别和使用的总体方法也可以用于加密，但使用变化慢得多的一组不同的密钥。用于生成的密钥选择方法在本说明书前面一般性地列出并在图20中进行了总结。建立交易相关数据，包括在节点处建立的本地交易计数器(LTC)值。LTC用作函数id的输入，其中函数id被用于选择标签。该标签与相关HSM中的密钥——keyid相关联。HSM使用此密钥生成对相关数据(这里为特定交易数据)进行操作的密码。
这种方法不仅可以用于选择用于生成凭证的密钥——交易密钥——还可以用于选择用于加密数据的密钥——加密密钥。可以使用相同的步骤——本地交易计数器可以再次用于计算encid函数(它甚至可以是与用于凭证生成相同的id函数——但是在其它实施例中也可以不同)，并且这用于选择密钥标签。这里的密钥标签是指来自不同密钥列表——加密密钥列表而非交易密钥列表的密钥。相关HSM中标签指示的密钥用于加密数据本身。
虽然每个级别的加密都重复使用相同的体系架构，但交易密钥列表和加密密钥列表的使用之间存在差异。交易密钥列表密钥引用具有有限的生命周期(例如，24小时)并且定期轮换。因此，密钥本身经常被更改。交易密钥列表由节点标识符和交易密钥列表引用的组合来识别。加密密钥列表密钥引用将被选择为具有长得多的生命周期(可能数月或数年)。鉴于如此长的生命周期，加密密钥可能被大量使用，但由于伪随机元素被包含作为使用该密钥加密的数据的一部分，因此减少了在多次使用相同加密密钥进行数据保护中的任何相关联的安全风险。加密密钥列表的标识是使用其加密密钥列表引用完成的，从而允许检索由其密钥列表标识符唯一识别的对应活动加密密钥列表。
如图22A和图22B中所示，节点本身可以具有节点简档。这允许节点被创建、配置和管理，允许密钥和密钥列表以及它们被节点处的服务的使用被定义和确定，允许请求被路由到适当节点以及允许节点被监控。节点简档的顶层如图22A中所示——这指示节点简档的唯一标识符、区域标识符和提供商标识符、节点提供的服务及其一般状态的指示。应注意的是，例如，如果不允许节点进行验证，那么它只能解密现有的服务输出而不能验证凭证，并且提供商信息可以用于限制对解密能力的访问(以便合作伙伴只能解密他们已经生成并加密的内容，而交易方案提供商有能力解密所有加密数据)。
图22B图示了节点简档内的服务的简档。节点简档为每个服务定义以下内容：服务类型；访问它的URL；该服务支持的密钥列表简档数组；服务状态；以及节点标识符。
不同的算法通常用于生成/验证和用于加密/解密。上述实施例中的生成和验证涉及从大量数据(并且可能具有不同的格式)生成输出——密钥散列函数在这里通常是合适的，并且验证涉及重新创建相同的散列并将其与供应值进行比较。对于加密/解密，原始输入需要通过解密过程从加密数据中恢复，因此块密码是合乎逻辑的选择。
因此，密钥列表密封锁在实施例中可以用于进一步的目的，如图21中所示。如果块密码用于加密——在所示的情况下，使用CBC模式中的块密码——那么初始化向量(IV)对于每次加密操作都需要。特别有效的选择是使用密钥列表密封锁来定义IV——在本实施例中这是16字节的值，其中16字节的数据也将被加密。密钥列表密封锁是给定密钥列表的静态值(用作伪随机元素)，并且如上文参考图20所述来确定密钥。对于解密过程反向进行。识别相关加密密钥列表，从而揭示密钥列表密封锁，并且用如前所述的相同的方法针对加密建立密钥。因此可以重新建立解密数据。
虽然这里通常使用块密码进行加密和解密，但不同的算法选择是可能的。一种可能性是使用广泛支持的密码，诸如AES，另一种选择是使用SM4块密码，这在特定地理区域可能是优选的，以满足关于密码原语选择的特定要求。在这里的实施例中，可以做出任一选择——这可以通过与交易相关联的信息中的适当引用来指示。例如，引用3可能与AES相关，在这种情况下，加密和解密过程可以被识别如下：
encryptCryptoXAes128Cbc()
decryptCryptoXAes128Cbc()
而引用13可能与SM4块密码相关，在这种情况下，加密和解密过程可以被识别如下：
encryptCryptoXSm4Cbc()
decryptCryptoXSm4Cbc()
以相同的方式，可以为凭证生成和验证做出匹配选择，这通常使用密钥散列函数执行，因为输出将是受约束的大小，远小于输出。引用3和13的函数现在可能分别是SHA-256密钥散列和SM3密钥散列——对于引用3，生成和验证过程被识别如下：
generateCryptoXHmacSha256()
validateCryptoXHmacSha256()
而对于引用13，生成和验证过程被识别如下：
generateCryptoXHmacSm3()
validateCryptoXHmacSm3()
加密密钥列表是长期存在的资产。它包含的元素如图23中所示——图23示出了交易密钥列表和加密密钥列表两者的元素，指示不同元素的功能重要性以及两种密钥列表类型之间的差异。两种密钥列表都包含密钥列表标识符，并且每种类型的密钥列表将具有各种属性，指示其来源(创建和激活和停用日期的时间戳、格式版本信息)及其用途(用于密码操作的函数的标识、指示是否多个节点可以用于解密的孤立标志)以及密钥标签本身和完整性维护密钥列表密封锁。密钥列表还可以包含与用于密钥管理的方法相关的信息(替代方案是例如当所有密钥管理操作都由正在使用的系统驱动时的驱动方法，以及其中部分密钥管理活动被委托给另一个密钥管理服务的委托方法)。在这种情况下，密钥拓扑的概念用于使用与密钥列表类似的原则(包括使用密钥拓扑密封锁唯一识别密钥拓扑并保证其完整性的方式)提供关于要使用的密钥的所需信息。图24图示了密钥拓扑，它具有与密钥列表类似的一般设计。它具有唯一标识符(UUID)和创建时间戳以提供唯一性，并且它包括类型(交易/加密/密封锁/包装)和密码模型。它包括密钥标签部分，这是有序的密钥标签数组——这个数组可以包含用于密钥列表密封锁的单个密钥或包装密钥。可以在密钥拓扑中提供附加信息，诸如密钥到期要求的指示，以符合任何密钥密码周期指南。密钥拓扑本身具有密钥拓扑密封锁以保护密钥拓扑的内容。唯一标识符和密钥拓扑密封锁值用于密钥列表(T/E)中以维护密码绑定。
应当注意的是，在这个实施例中，加密密钥列表不包含节点标识符。以这种方式，密钥列表密封锁可以保持不知道使用加密密钥列表的节点，并且有权访问加密密钥列表和密钥的任何合格(eligible)节点都可以对加密数据进行解密。这允许对加密过程进行持续控制，而不是在加密时将其固定(如果节点受到威胁，或者如果底层系统逻辑发生变化，这可能是非期望的)。可以通过添加新节点或移除旧节点来更改合格节点列表，而无需对相关联的加密密钥列表进行任何更新。这样的更新将消耗进一步的加密密钥列表引用值，其在非常大的系统中可能成为限制资源。
如图25A和图25B中所示，密钥列表简档用于配置密钥列表。它包含以下元素：
·类型(交易或加密)
·密钥列表支持的用例
·密码模型(例如，标准的或特定于国家)
·密钥管理——这提供了密钥管理方法和相关的(一个或多个)密钥拓扑标识符。
·函数——用于密钥列表服务的不同功能标识符。
·CVC编码(在需要它的用例中)
·限制(Limit)——使用密钥列表为服务定义的限制
·孤立(Isolation)——当只有单个节点被允许验证生成的交易凭证(或解密包含它们的消息)时，这被设置为真
·参数——使用密钥列表为服务定义的条件参数列表
·解密器——给定生成(或加密)节点的解密节点数组(这里使用区域标识符识别)
·验证器——给定生成节点的验证节点数组
·生成器——给定验证节点的生成节点数组
·状态—相关用例是活动的还是不活动的。
如上所讨论的，虽然使用相同的方法来识别和选择密钥，但由于用例不同，密钥轮换的方法有很大不同——生成和验证需要相对快速地更改密钥(24小时时间跨度)，但允许显著密钥重复利用，但加密和解密允许长得多的密钥有效期，并且可能期望完全避免密钥重复利用。
这可以通过对于加密密钥列表(比如，6比特)而不是交易密钥列表(上面识别为2比特)使用更长的密钥列表引用以及对于加密密钥列表而不是交易密钥列表采用长得多的有效期(数月或数年，而不是24小时)来实现。密钥列表之间的显著差异在示出交易密钥列表的图26A和示出加密密钥列表的图26B中列出。这里的交易密钥列表引用最多有四个值，并且将非常规律地循环，而加密密钥列表引用最多有六十四个值，并且可能根本不需要循环——重复利用对于加密密钥列表当然是例外，但它是交易密钥列表的标准操作。如上所述，另一个显著差异是每个交易密钥列表都是为特定节点定义的，而加密密钥列表是为可能会随时间变化的合格节点列表定义的，其中加密密钥列表和相关联的密钥在合格节点之间共享。
这种“合格节点”方法允许足够的灵活性来支持一系列使用模型。例如，交易方案提供商可以在每个合格节点列表上包括节点，以确保交易方案提供商可以解密来自任何节点的映射。可以对此施加限制以满足例如国家对加密数据的本土(on-soil)要求。这可以与可以访问其自己的所有加密密钥和密钥列表的合作伙伴节点(例如，对于支付服务提供商的合作伙伴节点)相结合，以允许他们完全操作其自己的节点。
如申请人在较早的编号为19178579.9的欧洲专利申请中所描述的，最近版本的电子交易协议可以用于传送比较早协议更多的信息。在通用持卡人认证字段(UCAF)可用的情况下，可以使用数个附加数字位。使用该方法，如图27中所示，可以传送完整的本地交易计数器值，并且可以使用更多的密码材料——8字节的密码，而不是如旧协议中那样使用2或3数字位。可以使用更多的节点，而不会因为电子交易协议要求中定义的交易数据中的可用空间有限而导致节点识别成为问题。也可以比24小时更频繁地轮换密钥列表，因为存在空间来使用多于一个的比特用于验证服务的密钥列表标识。可以利用交易数据中的可用空间来递送附加特征，例如通过支持商家锁定技术(在使用某种形式的商家标识将交易有效绑定到给定商家的情况下)、通过在密码过程中包含附加组件(诸如通过在生成器和验证器之间使用一些伪随机元素或可变内容)、或通过采取附加措施来提供符合任何监管要求的完全合规性。
如从图27中可以看出，使用适当的UCAF内容的布局(例如，格式7)有21个字节可用。可以在版本标识符和码本之间拆分一个字节以指定密码生成中使用的条件数据。完整的字节可以用于保持本地交易计数器——这意味着生成服务G将能够针对给定节点针对给定令牌每个密钥列表生成最多255个密码，这应该可以防止需要重试计数器并且在激活新密钥列表之前解决交易凭证的需求。另一个字节对于节点标识符数据和密钥列表引用是足够的，这为密码生成和/或验证中使用的条件数据留下完整的10个字节——每个用例都与码本中的值相关联——从而允许使用与授权消息中传送的数据不同的数据(传送的数据可以包括用于交易的不可预测的号码、商家数据，诸如商家类型和卡接受者或收单机构ID代码、金额相关信息…)。8个字节可以用于截断密码，从而显著提高安全性。
图28指示密码过程然后可以如何操作——PAN、LTC、节点标识符和引用都可以被轻松地包含在内，并且可以在加密数据中提供附加的信息，诸如附加的交易字段和其它条件数据。然而，在本公开的实施例中，使用UCAF的新结构，这里使用UCAF格式6。这在图29中示出。这包括加密部分241和未加密部分242。加密部分241包含凭证(密码)以及某些交易数据，这允许某些元素仅以加密形式保持。未加密部分242允许识别交易及其来源。这在下面更详细地描述。
未加密部分241包含建立版本、节点(以及与节点相关的信息)、交易和特定商家信息的4个字节的信息。版本信息2411是4比特字段，允许使用多个版本的格式。与节点相关的信息包括6比特节点标识符2412和与节点相关联的密钥列表引用——如前所述，这些包括2比特交易密钥列表引用2413和6比特加密密钥列表引用2414。交易本身由本地交易计数器(LTC)2415的1字节识别。如上所述，该信息足以允许节点通过重新生成凭证/密码来执行验证(如果允许这样做的话)。绑定到令牌的商家由在3比特未加密部分2416和3比特加密部分2421之间划分的商家ID散列提供。下面更详细地描述商家ID散列的创建。
使用加密允许其它交易信息以加密形式保持，但在将来解密后可用，使得交易可以被映射到PAN(主账号)，而无需维护特定的映射数据库——其它重要信息(诸如PAN序列号(PSN))可以以这种方式保持。加密数据242包括16个字节的数据，其第一个3比特是如上所述的商家ID散列的加密部分2421。密码2422构成加密数据的另外的22比特。一比特用作SCA标志2423以指示强客户认证是否用于交易。另外23比特用于近似交易金额2424——这些可以按照以下形式编码：
重建数量＝A*2B
其中A用于最左边的18比特，并且B用于最右边的5比特。另外的74比特与卡信息2425相关。这包括可以完整提供的PAN(63比特)和PSN(4比特，其足够一个数字位值)。7比特用于传送到期日期信息——因此这需要是部分到期日期，其将在下面讨论——下面描述的实施例还支持在生成交易凭证时可选的部分到期日期的传递。加密数据中的另一个元素是校验和2426——这也在下面进行更详细的描述。
商家ID可以使用远程商务接受者标识符，这是相对新的EMV字段，如果可用的话，那么用于(例如，通过商业网站URL或反向域)识别商家。商家ID散列通过以下方式提供：
·商家ID(通过转换或其它方式)被提供为十六进制(HEX)值
·缓冲区如下创建
ο商家ID的散列(32字节)
ο近似金额(剩下3个字节由Ob填充)
ο本地交易计数器(在2个字节上编码，剩下由Ob填充)
·使用适当的密码模型在缓冲区上计算散列
·商家ID散列是散列缓冲区的前两个字节
如上所述，在这里提供的实施例中，到期日期值的供给是可选的。如果提供，那么编码和解码活动将由NODES系统执行(如果它有效的话)——否则将返回错误。如果未提供，那么必须传送防止系统在验证或解密时返回到期日期值的信息。
需要使用有限量的可用空间——7比特——来提供此信息——从标准到期日期开始，其通过4个数字位(YYMM)编码，但对于一些字段的值有实际约束(因为一年中只有12个月，并且到期年份与本年度相差不远)。这通过首先定义到期日期的“基线”值来加以利用，它只是作为加密密钥列表的参数提供。在此之后，确定一个特殊值0[0000000b]，用于编码“未定义到期日期”(生成)——对于此值，在解码时不应返回到期日期(无论是用于验证还是用于任何其它解密)。所有其它值——1[0000001b]到127[1111111b]——仅用于指示从基线值到提供的到期日期(生成时)的月数，以提供对验证或任何其它解密可靠的解码。如果返回供应的到期日期，其小于或等于基线值，或超过基线之后127个月，那么这是无效的，并且返回错误。
如上所述，加密数据还包括校验和。这之所以被提供是因为特别期望能够获得对数据完整性解密的保证，因为在验证以外的情况下，这不能通过密码验证来完成。因此，校验和提供了第二种形式的完整性校验，其可以用于任何解密事件。在这些情况下，其它绑定信息(诸如商家身份、交易金额、SCA标志)可能根本不可用或可核实，因此需要另一种方法来防止攻击的可能性，在该攻击中加密数据具有正确形式但包含乱码(一种模糊攻击)作为传播恶意映射信息的方法。
图30图示了用于提供校验和以实现此目的的数据。此数据用于在不验证密码的情况下检查解密数据的完整性——它被包括在要加密的数据中，但它未被明确包括在密码生成或验证中。
有效的校验和可以使用通过以下如图30中所示计算的散列的最左边4比特来生成：
·UCAF的头部271——这是明文中提供的内容(5字节)
·用作加密输入272的部分数据(102比特)——这包括FPAN和相关联的数据，诸如PSN和部分到期日期
·密码273(22比特)
·填充符274(4比特)
·DPAN 275——这是令牌，或令牌化的PAN(n字节)
根据实施例中使用的密码模型进行散列(在这种情况下，SHA256和SM3是考虑的选项)。这个校验和(在密码生成之后和数据加密之前生成)可以在没有密码验证的情况下被验证。它可以防止模糊攻击，因为这些攻击通常需要伪造数据，以便解密过程的结果将导致传递有意义的(恶意)数据，这些数据可以通过校验和的验证，但也需要覆盖被加密数据以外的数据，诸如商家ID散列或LTC(本地交易计数器)。当攻击者想要例如通过尝试对真正的UCAF v6使用不同的令牌，同时尝试在映射数据中嵌入的资金账户上对交易收取费用来滥用为给定令牌和给定映射数据生成的UCAF v6时，校验和还针对数据替换提供保护。将交易数据和账户信息(令牌和资金PAN)绑定为校验和的一部分将防止此类攻击成功。
应该注意的是，解密的PAN的Luhn校验数字位也提供了一些附加的保证，但是这的主要好处是检查PAN是否正确形成，并且它不提供与如上所述的校验和相同类型的保证。
以这种方式，可以有效地提供交易信息以包含加密形式的关键信息。这种方法非常有益，因为它支持令牌与其对应的PAN之间的绑定，而无需使用标准映射服务——使用这种具有极高交易量的映射服务将带来巨大的计算和存储负担。该交易信息还可以用作在不验证密码的情况下检查解密数据的方式，这将在下面进一步描述。
现在将更详细地描述使用上述方法生成(和验证)凭证的具体过程。
这里的密码生成涉及使用密钥散列函数从交易数据产生22比特——呈现了两个散列选项，SHA-256和SM3。每个的示例性过程如下：
3:generateCryptoXHmacSha256()
生成22比特密码如下：
1.创建符合密码(输入)模式的JSON对象
2.使用转换成十六进制格式的JSON内容(ASCII)准备输入数据，并移除所有填充符和分隔符
3.根据ISO/IEC 9797-2MAC算法2(HMAC)使用SHA256(ISO/IEC 10118-3)截断为16字节(最左边)，在输入数据上生成MAC
4.取结果的最左边22比特用作响应。
13:generateCrytoXHmacSm3()
生成22比特密码如下：
1.创建符合密码(输入)模式的JSON对象
2.使用转换成十六进制格式的JSON内容(ASCII)准备输入数据，并移除所有填充符和分隔符
3.根据ISO/IEC 9797-2MAC算法2(HMAC)使用SM3(ISO/IEC 10118-3)截断为16字节(最左边)，在输入数据上生成MAC
4.取结果的最左边的22比特用作响应。
验证过程是对生成过程的补充。
3:validateCryptoXHmacSha256()
验证22比特密码如下：
1.创建符合密码(输入)模式的JSON对象
2.使用转换成十六进制格式的JSON内容(ASCII)准备输入数据，并移除所有填充符和分隔符
3.根据ISO/IEC 9797-2MAC算法2(HMAC)使用SHA256(ISO/IEC 10118-3)截断为16字节(最左边)，在输入数据上生成MAC
4.取结果的最左边22比特用作生成的值
5.将生成的值与供应用于验证的值进行比较
6.基于比较结果将响应设置为真(true)或假(false)。
13:validateCryptoXHmacSm3()
验证22比特密码如下：
1.创建符合密码(输入)模式的JSON对象
2.使用转换成十六进制格式的JSON内容(ASCII)准备输入数据，并移除所有填充符和分隔符
3.根据ISO/IEC 9797-2MAC算法2(HMAC)使用SM3(ISO/IEC 10118-3)截断为16字节(最左边)，在输入数据上生成MAC
4.取结果的最左边22比特用作生成的值
5.将生成的值与供应用于验证的值进行比较
6、基于比较结果将响应设置为真或假
如上所述，加密部分中的数据可以用于检查以提供例如稍后的交易与较早交易相关的置信度，而无需验证密码。参考图31描述了凭证生成和交易验证的使用，并且图32和图33示出了当凭证的验证尚未发生或可能不再可能时，本公开的实施例可以如何用于提供关于其它交易元素的保证。图34提供了可以在这些过程中采取的动作类型的总结。
为了执行带有凭证的生成和验证的交易，过程如图31中所示。交易由商家或由支付服务提供商(PSP)代表商家执行。交易是数字化的，因此使用这里所示的体系架构来执行。与交易相关联的是，客户通常会有主账号(PAN)，但数字化交易通常会被令牌化，并且账户PAN将被令牌唯一引用(TUR)及其相关联的代理PAN值取代。令牌将被映射到至少由PAN和PSN表示的账户上。
一旦建立了交易详细信息，商家或PSP就将调用交易基础设施(这里的多个服务提供节点的系统被称为NODES——该术语在下面使用)用于生成交易凭证。令牌及其映射信息连同交易数据一起被提供给节点，从而被提供给生成服务以生成凭证。然后将此凭证与其它交易数据一起加密以形成加密部分，并且包含此加密部分的交易信息与上述UCAF数据格式中的某些未加密交易信息一起提供。如图28中所示，令牌本身用于生成密码，而生成的密码(与令牌在密码上相关联)和用于建立令牌到账户数据(诸如PAN和PSN)的映射的信息位于加密部分中。UCAF 8格式交易数据被返回给商家/PSP。
商家或PSP可以存储该UCAF 8格式信息(包括密码(与令牌相关联)和加密映射信息)。这样做时，商家/PSP不会因此以明文形式存储客户的账户信息——此类账户信息仅以加密形式保持。当交易现在在线提交以供商家/PSP处理时，需要由支付方案提供商(诸如本申请人)验证。再次地，通过首先使用未加密的信息建立解密密钥，然后通过使用该解密密钥来解密UCAF信息的加密部分，调用NODES服务来执行此验证。该解密揭示凭证，并且可以看出，通过使用如上所述的方法，可以获得足够的信息来使得凭证被验证。
虽然这样完成了交易过程，但从图31中可以明显看出，商家/PSP仍然可以调用解密服务来获得对加密信息的访问——这通常可能是针对与相关交易相关使用的令牌的映射信息。
在验证阶段，商家/PSP可以使用验证过程的结果作为对与其一起存储在UCAF数据的加密部分中的映射信息的完整性的确认。此验证过程只能发生一次，并且只有在相关联的交易密钥列表仍处于活动时才能执行。如上所述，期望能够独立于验证过程建立映射信息的完整性，例如用于后续交易——在一些情况下甚至可能期望在验证发生之前就这样做。
如从图32中可以看出，有附加的信息可用于在不验证密码的情况下检查解密数据：商家ID散列(在未加密部分和加密部分之间拆分)；SCA标志；以及交易的近似金额。商家ID、SCA标志和近似金额一起构成整体交易数据的一部分，这里称为“部分交易数据”。如果商家/PSP本身在交易时存储了部分交易数据，那么当它调用解密服务以从UCAF数据中获取映射信息时，它可以在调用中包括该部分交易信息。然后，解密服务可以根据商家ID来计算商家ID散列以及根据调用和LTC(可根据UCAF数据的未加密量确定)来计算近似金额、对加密数据进行解密、并且针对计算出的和供应的信息检查从UCAF 8加密数据中导出或部分导出的商家ID散列、SCA标志和近似金额，以返回具有完整性确认(或者在检查失败情况下的错误)的映射信息。
此过程不以任何方式依赖于验证，因此它可以在验证发生之前或之后(甚至很久之后)发生。图32指示在验证之前进行解密的情况——所需要的只是已经生成凭证并创建UCAF数据，并且商家/PSP已经将其与部分交易数据一起存储。
图33更详细地指示“后续”交易的过程。此时，相关交易已经被验证，因此加密部分仅保护映射信息——但商家具有“旧”交易的信息和相关联的“旧”UCAF数据。但是，这可以用于解密旧UCAF数据的加密部分以揭示映射信息，并且如果打算将其作为对“旧”交易的后续交易，那么该映射信息可以应用于“新”交易。账户详细信息与交易数据的任何新元素一起用于新交易——这会产生新的UCAF数据，其中映射数据将再次被加密。
图34总结了用例。原始服务请求3010包括映射数据——PAN、PSN和(可选)到期日期——以及交易数据——(可选)用于识别商家、交易金额和强持卡人认证标志的RCAI——以及与PAN相关联的用于凭证的生成3020的令牌，随后是加密3030以形成包括加密数据的UCAF v6对象3030。这可以在任何后续时间——无论是在验证之前还是之后——由被允许访问加密密钥的节点进行加密。这里，第一解密过程3040发生在UCAF v6对象被提供有用于验证的令牌和交易数据时。随后的——并且只能只发生一次的——验证过程3050建立验证结果、提供对金额和商家的检查，并且揭示强持卡人认证标志和映射信息，从而允许交易授权。可能还存在其它解密事件——一个在这里示出为在凭证验证之后，但可能在它之前发生——这也将提供令牌和UCAF v6对象，但它可能不提供相同的交易数据(但是RCAI或其它商家标识符可能持续存在)。这样的解密事件3060将提供对于解密是否成功(以及消息是否具有完整性)和商家检查结果的确定，并且将揭示映射信息，但它不会使得密码的验证作为交易凭证的一部分进行传送。
如本领域技术人员将认识到的，上述实施例是示例性的，并且落入本公开的精神和范围内的其它实施例可以由本领域技术人员根据上述原理和示例开发。特别地，上面详细描述的实施例特别涉及凭证的生成和验证，以及这些凭证与其它数据的加密和解密，其中凭证和其它数据两者都用于金融交易。凭证的生成和验证，以及凭证与其它数据的加密，以这种方式不限于金融交易——这种方法可以用于其中一方需要确认另一方采取了合法行动、其中两方可能正在访问分布式系统的不同节点的任何分布式系统。

Claims (25)

1.一种在计算节点处为计算节点外部的请求方提供安全服务的方法，所述方法包括在计算节点处：
从请求方接收服务请求，其中该服务请求包括生成凭证的请求；
生成凭证；
获得服务相关信息，
创建包括服务识别信息的明文消息部分；
从服务识别信息的至少一部分和从服务相关信息和凭证的至少一部分创建校验和；
使用加密过程来加密凭证、服务相关信息和校验和，以形成加密的消息部分；以及
向请求方发送包括明文消息部分和加密的消息部分的消息。
2.如权利要求1所述的方法，其中加密过程包括块密码。
3.如权利要求1或权利要求2所述的方法，其中使用密码过程来生成凭证。
4.如权利要求3所述的方法，其中共享机制用于为加密过程和密码过程提供密钥。
5.如权利要求4所述的方法，其中用于加密过程的密钥的密钥有效期长于用于密码过程的密钥的密钥有效期。
6.如权利要求4或权利要求5所述的方法，其中密码过程特定于执行密码过程的节点，而加密过程不特定于执行加密过程的计算节点。
7.如权利要求3至6中的任一项所述的方法，其中密码过程包括密钥散列算法。
8.如前述权利要求中的任一项所述的方法，其中安全服务包括为交易提供凭证以允许交易在验证所述凭证的情况下被授权。
9.如权利要求8所述的方法，其中未加密的消息部分包括用以识别如何处理交易的信息。
10.如权利要求9所述的方法，其中加密的消息部分包括交易数据以及凭证。
11.如权利要求10所述的方法，其中交易数据包括账户数据和交易详细信息，其中交易详细信息适于独立于凭证的验证来检查账户数据的有效性。
12.一种在计算节点处为计算节点外部的请求方提供安全服务的方法，所述方法包括在计算节点处：
从请求方接收服务请求，其中该服务请求包括验证凭证的请求，其中该服务请求包括包含凭证的消息，其中该消息包括包含服务识别信息的明文消息部分以及包含凭证、服务相关信息和校验和的加密部分，该校验和是从服务识别信息的至少一部分以及服务相关信息和凭证的至少一部分生成的；
使用服务识别信息执行解密过程以解密消息的加密部分；
使用校验和来确定消息中的信息的完整性；以及
进一步使用服务识别信息来验证所述凭证。
13.如权利要求12所述的方法，其中解密过程包括块密码。
14.如权利要求12或权利要求13所述的方法，其中使用密码过程来生成凭证。
15.如权利要求14所述的方法，其中密码过程包括密钥散列算法。
16.如权利要求12至15中的任一项所述的方法，其中安全服务包括验证交易的凭证以允许交易被授权。
17.如权利要求16所述的方法，其中未加密的消息部分包括用以识别如何处理交易的信息。
18.一种在计算节点处为计算节点外部的请求方提供安全服务的方法，所述方法包括在计算节点处：
从请求方接收服务请求，其中该服务请求包括确认服务相关信息的完整性的请求，其中
消息包括包含服务识别信息的明文消息部分以及包含服务相关信息和校验和的加密部分，该校验和是从服务识别信息的至少一部分和服务相关信息的至少一部分生成的；
使用服务识别信息执行解密过程以解密消息的加密部分以提供服务相关信息；
使用校验和来确定消息的完整性；以及
进一步使用服务相关信息的第一部分来确认服务相关信息的第二部分的完整性，其中服务相关信息的第一部分是在服务请求中提供的。
19.如权利要求18所述的方法，其中解密过程包括块密码。
20.如权利要求18或权利要求19所述的方法，其中安全服务包括向有权接收交易相关数据的一方提供交易相关数据。
21.如权利要求20所述的方法，其中未加密的消息部分包括用以识别如何处理交易的信息。
22.如权利要求21所述的方法，其中加密的消息部分包括交易数据。
23.如权利要求22所述的方法，其中交易数据包括账户数据和交易详细信息，其中交易详细信息适于检查账户数据的有效性。
24.如权利要求18至23中的任一项所述的方法，还包括计算节点确定其是否有权获得密钥以执行解密过程，并且如果是的话，则访问所述密钥。
25.一种包括处理器和存储器并适于发送和接收消息的计算装置，其中所述处理器被编程以在所述存储器的帮助下执行如权利要求1至24中的任一项所述的方法。
CN202180060004.7A 2021-05-28 2021-07-22 分布式计算系统中的数据管理和加密 Pending CN116250209A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2107661.7 2021-05-28
GB2107661.7A GB2607289A (en) 2021-05-28 2021-05-28 Data management and encryption in a distributed computing system
PCT/US2021/042744 WO2022250716A1 (en) 2021-05-28 2021-07-22 Data management and encryption in a distributed computing system

Publications (1)

Publication Number Publication Date
CN116250209A true CN116250209A (zh) 2023-06-09

Family

ID=76741412

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180060004.7A Pending CN116250209A (zh) 2021-05-28 2021-07-22 分布式计算系统中的数据管理和加密

Country Status (5)

Country Link
US (1) US20240305442A1 (zh)
EP (1) EP4348919A1 (zh)
CN (1) CN116250209A (zh)
GB (1) GB2607289A (zh)
WO (1) WO2022250716A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4432141A1 (en) 2023-03-13 2024-09-18 Mastercard International Incorporated Credential management in a decentralized heterogeneous transaction system
EP4432199A1 (en) 2023-03-13 2024-09-18 Mastercard International Incorporated Cryptographic service delivery in a decentralized transaction system
GB202406906D0 (en) 2024-05-15 2024-06-26 Mastercard International Inc Identity management in crytographic service provision

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19830055B4 (de) * 1998-06-29 2005-10-13 Francotyp-Postalia Ag & Co. Kg Verfahren zur sicheren Übertragung von Dienstdaten an ein Endgerät und Anordnung zur Durchführung des Verfahrens
US7231663B2 (en) * 2002-02-04 2007-06-12 General Instrument Corporation System and method for providing key management protocol with client verification of authorization
US10313123B1 (en) * 2016-12-14 2019-06-04 Amazon Technologies, Inc. Synchronizable hardware security module
WO2019010101A1 (en) * 2017-07-01 2019-01-10 Shape Security, Inc. SECURE DETECTION AND MANAGEMENT OF COMPROMISED IDENTITY SUPPORTERS
KR20210065961A (ko) * 2018-10-02 2021-06-04 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US11256675B2 (en) * 2019-02-22 2022-02-22 Visa International Service Association Method and system for creating rapid searchable altered data in a database
EP3748526A1 (en) * 2019-06-05 2020-12-09 Mastercard International Incorporated Security model for distributed computing system

Also Published As

Publication number Publication date
US20240305442A1 (en) 2024-09-12
GB202107661D0 (en) 2021-07-14
EP4348919A1 (en) 2024-04-10
GB2607289A (en) 2022-12-07
WO2022250716A1 (en) 2022-12-01

Similar Documents

Publication Publication Date Title
CN107210914B (zh) 用于安全凭证供应的方法
US6523012B1 (en) Delegation of permissions in an electronic commerce system
US20150310427A1 (en) Method, apparatus, and system for generating transaction-signing one-time password
CN113841144B (zh) 分布式信息安全系统、计算节点及其方法
CN112950367A (zh) 生成和执行智能合约交易的方法及装置
US20190139039A1 (en) Electronic payment method and electronic device using id-based public key cryptography
CN116250209A (zh) 分布式计算系统中的数据管理和加密
CN116210199A (zh) 分布式计算系统中的数据管理和加密
JP2010514000A (ja) 電子装置にプログラム状態データをセキュアに記憶するための方法
CN114902264A (zh) 分布式计算系统中的监视
WO2021035295A1 (en) "secure environment for cryptographic key generation"
CN101639957A (zh) 一种实现圈存或圈提的方法、终端及银行业务系统
EP3748525B1 (en) Credential management in distributed computing system
CN113841206A (zh) 分布式计算系统中的事件管理
EP3748526A1 (en) Security model for distributed computing system
KR20080012402A (ko) 공개키 기반의 무선단문메시지 보안 및 인증방법
EP4175216A1 (en) Data communication and cryptographic operations using a restricted data channel
US11539510B2 (en) System and method of cryptographic key management in a plurality of blockchain based computer networks
Sood et al. Cloudbank: A secure anonymous banking cloud
RU2796046C1 (ru) Управление учетными данными в распределенной вычислительной системе
EP4432199A1 (en) Cryptographic service delivery in a decentralized transaction system
EP4432141A1 (en) Credential management in a decentralized heterogeneous transaction system
EP4307610A1 (en) Rapid secure wireless transaction
WO2024015179A1 (en) Data communication and cryptographic operations for secure wireless interactions
Sadeghi et al. Securing Financial Sector Applications in the Quantum Era: A Comprehensive Evaluation of Nist's Recommended Algorithms Through Use-Case Analysis

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination