CN115191102A - 受限数据通道中的敏感数据的通信 - Google Patents

受限数据通道中的敏感数据的通信 Download PDF

Info

Publication number
CN115191102A
CN115191102A CN202180017279.2A CN202180017279A CN115191102A CN 115191102 A CN115191102 A CN 115191102A CN 202180017279 A CN202180017279 A CN 202180017279A CN 115191102 A CN115191102 A CN 115191102A
Authority
CN
China
Prior art keywords
transaction
event
data
information
elements
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
CN202180017279.2A
Other languages
English (en)
Inventor
M·克林吉
O·拉齐马尼
A·约翰逊
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 CN115191102A publication Critical patent/CN115191102A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • 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/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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
    • H04L9/321—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 involving a third party or a trusted authority
    • H04L9/3213—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 involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (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

受限数据通道中的敏感数据的通信
相关申请的交叉引用
本申请要求2020年2月26日提交的欧洲专利申请No.20159634.3的优先权，该临时申请的内容通过引用包含在本文中。
技术领域
本公开涉及受限数据通道中的敏感数据的通信。
背景技术
涉及通过一个或多个网络链接的多个实体的复杂数据处理系统通常需要用于传递数据的特定协议，以确保数据在整个系统中被正确识别和处理。这些协议通常会对系统中的不同实体提出特定的要求，并且它们通常会随着时间的推移而发展，以提供新的能力并反映新的技术发展。
一旦建立了协议的新版本，就升级这种类型的分布式系统中的每个实体以支持协议的新版本的每种能力通常并不现实。这是通过在此类协议的新版本中提供向后兼容性来解决的，使得有可能使用比完全实现协议的最新版本所需的能力更受限的一组能力来提供持续的功能。这种方法的一个例子是蜂窝通信标准--其中系统的一部分不适合于支持4G，协议中的向后兼容性允许使用3G、EDGE或GPRS。
交易方案的实现具有类似的问题。扩展的基础设施通过一系列不同的网络将银行、商户和持卡人与交易方案基础设施连接，所述交易方案基础设施调解交易的授权以及结算和清算过程。交易方案基础设施本身将适合于实现协议的最新版本，但是特定的系统元件-例如，处理交易的商户的计算硬件-可能并不适合于实现协议的最新版本。这可能需要采用协议的较旧版本的约束条件-这些约束条件例如可以包括使用有限数量的数据字段，因为在协议的早期版本中对数据传输有很重的限制。
如果对协议的增强是出于对系统的有效技术操作至关重要的原因，那么这可能是有问题的。一个这样的原因可能是系统安全性-如果协议的较旧版本提供不令人满意的安全性，那么可能非常希望找到一种新方法，该方法成功地解决安全关切-例如在数据的安全传输或用户的安全认证方面-同时仍然遵守在协议的较旧版本中所要求的约束，因为这些约束是内置在特定系统元件的实现中的。在交易方案的情况下，协议的较旧版本例如可能只适合于识别交易中支付卡的特定元素(PAN-主账号-有效期，以及CVC2代码)。可取的是解决由协议的更高级版本所解决的安全关切，同时保持较旧协议对可传递的卡数据的数量施加的约束。可取的是以能够满足交易方案的要求-例如，允许在生成交易细节之后最多24小时内验证它们-的方式实现这一点。
发明内容
在第一方面，本公开提供一种使用数据字段传递与事件相关的信息的方法，所述方法包括：获得与所述事件相关的信息的一个或多个元素，并使用信息的所述一个或多个元素确定所述事件的加密记录；将每个元素中的一些或全部与和事件的记录相关的时间信息相组合，以填充数据字段中的第一组位置，并使用所述加密记录填充数据记录中的第二组位置；传递包括所述数据字段的消息，其中接收所述消息可以使用所述时间信息来恢复所述一个或多个元素，并且可以通过从恢复的元素重新计算所述加密记录，并将重新计算的加密记录与从所述数据字段恢复的加密记录进行匹配来验证元素被正确地恢复。
使用该方法，可使用受限数据字段来传递关于事件的重要信息，当传输了足够的重要信息时，接收方可以重建完整的信息，同时加密记录可用，使得接收方可以确定重建的完整信息是正确的。这在需要通过不允许完整信息传送的协议从第一方向第二方传递信息时，例如，在信息需要通过只支持有限数据传送协议的第三方传送时，特别有价值。
在实施例中，事件是服务实例，比如交易记录或交易凭证的生成。这例如可以在交易方案内应用。说明了与数字交易的执行相关的实施例，然后约束条件可能是虽然可以按照最新的协议生成并随后验证交易凭证，但是交易数据可能需要通过只支持具有有限数据字段的较旧协议的通道或实体(比如商户服务器或支付服务提供商)。
在这种交易上下文中，所述元素可以包括交易计数器。在某些实施例中，例如那些涉及电子商务交易的实施例中，所述元素可以包括随机数或不可预测数。在其他实施例中，例如，涉及全数字交易的实施例中，所述元素可以包括密钥标识符-在这种情况下，可以使密钥标识符的变更与时间信息的变更同步，并且由密钥标识符识别的密钥可以用于计算加密记录。
在实施例中，第一组位置还包括用于时间信息的识别的一个或多个校验位。这种方法对于使信息元素能够在没有重试过程的情况下被恢复是特别有益的，因为它可以消除时间信息模糊的可能性。
在第二方面，本公开提供一种使用数据字段获得与事件相关的信息的方法，所述方法包括：接收与事件相关的消息，其中所述消息包括数据字段；将所述数据字段分解为包含组合的交易元素的第一组位置和包含所述事件的加密记录的第二组位置；确定与所述事件的所述记录关联的时间信息，并使用所述时间信息来建立与所述事件相关的信息的全部或部分元素，所述信息的全部或部分元素已经与所述时间信息组合以填充所述数据字段中的第一组位置；从与所述事件相关的信息的任何部分元素建立与所述事件相关的信息的全部元素；以及从与所述事件相关的信息的元素计算加密记录数据，并且通过将计算的加密记录数据与来自所述数据字段中的第二组位置的加密记录进行匹配来确定与所述事件相关的信息的元素是正确的。
该事件可以是服务实例。例如，在交易方案的上下文中，它可以包括交易记录或交易凭证的生成，在这种情况下，所述方法还包括在获得与所述事件相关的信息之后验证所述交易记录或交易凭证。
这些元素可以包括交易计数器。在实施例中，所述元素可以包括随机数或不可预测数。在其他实施例中，所述元素可以包括密钥标识符。在这种情况下，可以使密钥标识符的变更与时间信息的变更同步，并且由密钥标识符识别的密钥用于计算加密记录。
在实施例中，从与所述事件相关的信息的任何部分元素建立与所述事件相关的信息的全部元素可以包括计算加密记录数据，并将其与来自所述数据字段中的第二组位置的加密记录进行匹配，以及如果没有匹配，则改变时间信息，并使用改变的时间信息从与所述事件相关的信息的任何部分元素重新建立与所述事件相关的信息的全部元素。这样的重试过程使所述方法即使在事件可能在延长的时间段内的某一时间发生时也是有效的，在这种情况下，时间信息模糊的可能性很大。
在其他实施例中，第一组位置还包括用于时间信息的识别的一个或多个校验位，并且所述一个或多个校验位用于在建立信息的全部或部分元素之前建立正确的时间信息。这是解决时间信息的模糊性的备选方法-它可以避免重试的需要，但代价是丢失了对于元素之一可以传递的少量信息。
在实施例中，从与所述事件相关的信息的任意部分元素建立与所述事件相关的信息的全部元素可以包括计算加密记录数据，并将其与来自所述数据字段中的第二组位置的加密记录进行匹配，以及如果没有匹配，则改变所述元素之一，并按照预定计划重新计算和重新匹配所述加密记录数据，直到存在成功匹配。即使当对于该元素能够传输的信息量的严苛约束条件导致模糊可能性时，这种重试过程也允许精确地建立元素。
在第三方面，本公开提供一种适合于进行第一方面的方法和/或第二方面的方法的计算节点。
附图说明
现在参考附图，举例说明本公开的具体实施例，附图中：
图1示出了本公开的各个元件在解决与通过受限数据通道的敏感数据的通信关联的技术问题时采用的一般方法；
图2示意地示出了使用四方模型的分布式交易架构；
图3图解说明适合于实现图2的交易架构的复杂分布式系统的各个要素；
图4示意地示出了能够在图2和3的交易架构中实现数字交易的示例性系统；
图5图解说明在EMV协议中使用的有效期字段；
图6图解说明重新利用有效期字段的备选策略及关联的有效性挑战；
图7图解说明用于生成、传输和验证动态交易数据(DTD)的一般方法；
图8示意地图解说明按照本公开的实施例的用于生成动态交易数据的过程；
图9图解说明可以在图8的过程中使用的生成不可预测数的一种方法；
图10图解说明可以在图8的过程中使用的生成不可预测数的备选方法；
图11更详细地图解说明图8中所示的动态CVD生成的过程；
图12示意地图解说明按照本公开的实施例的用于验证动态交易数据的过程；
图13图解说明通过包括具有ATC数据的控制比特来进行日期控制的备选策略；
图14示意地图解说明用于交易的数字使能的分布式系统的安排；
图15更详细地图解说明图14的安排的计算节点；
图16图解说明图15的计算节点内的元件；
图17使用传统用例和图15和16的节点，图解说明交易的示例性改进令牌化过程；
图18使用传统用例，图解说明系统的密钥轮换过程；
图19使用传统用例，图解说明用于数字化交易的一组示例性的加密机制；
图20使用适于与图15和16的节点一起使用的传统用例，图解说明携带本地交易计数器的方法；
图21使用与图15和16的节点一起使用的卡验证码(CVC)，图解说明使用图20的方法交付本地交易计数器；
图22指示对于偶数节点和奇数节点，围绕月末对于传统用例使用动态有效期的结果；
图23示出了在图22中所示的上下文中，对于节点信息、重试标志和密钥列表引用的后果；
图24示出了在图22中所示的上下文中，使用密钥列表引用来识别密钥列表的后果；
图25提供了在图22中所示的上下文中，当关于月初和月末问题在传统用例中使用动态有效期时，使用密钥列表引用来识别密钥列表的更多细节。
具体实施方式
一般来说，图1中图解说明了本公开解决的问题。第一计算实体1001生成它希望第二计算实体1002可以得到以便进行验证的敏感数据。然而，通信需要通过第三计算实体1003进行中介，该通信涉及受限数据通道1004。
至少有两种可能的方式可以限制数据通道1004。一种是可以传输的数据的总量是有限的-在这种情况下，数据通道仅包含用于要传输的特定类型的数据的n个位置。另一种是可能存在对可在特定字段中使用的值的约束。在这种情况下，总共n个位置中的x个位置被约束在可接受的值中。
在实施例中，通过重新利用(repurpose)原始数据字段来携带满足安全要求的信息。特别地，用于静态数据的数据字段可以被重新用于包含供附加安全协议之用的信息的动态数据。两种类型的约束都产生了技术挑战。有限数量的位置使得难以传送所需的信息量。可以使用各种机制来解决该问题。一种机制是直接传送有限数量的信息，但是通过包括校验机制-比如散列-来确保生成器和验证器对相同的数据进行相同的计算。另外，重新利用的数据字段的原始目的可能对可使用的值产生约束，特别是如果第三计算实体1003继续好像原始协议还在似地行事，并且相应地检查数据的话。
由重新利用的字段引起的问题的一个例子是原始字段用于日期的地方。一个例子是在交易方案中，其中一个交易数据字段用于以MMYY格式表示的相关支付卡的有效期。如果第一计算实体1001是支付卡或其他支付设备，第二计算实体1002是交易的授权者(发卡银行或代表发卡银行行事的交易方案基础设施)，而第三计算实体1003是商户销售点终端，那么第三计算实体1003可能被编程为如果有效期明显不正确-例如如果月份值是不可能的，或者年份值是太遥远的未来或过去，则拒绝该潜在交易而不将其转发以进行授权。此类字段的任何重用都需要确保第三计算实体1003甚至不会阻止数据通过受限数据通道传到第二计算实体1002。
这种约束的组合会带来重大的技术挑战，因为为了满足安全要求，可能可取的是因事件而异的动态数据，而不是静态数据。一种重要的安全机制是凭证的有效性是有时间限制的。这需要在从生成器传输到验证器的数据中包含某种形式的时间信息。信息的有效性的长度也提出了挑战-有效时段越长，通常需要传送的信息就越多，特别是如果其他相关标准-比如用于编码的加密密钥--在有效时段内变更的话。
本公开的实施例举例说明了用于重新利用有限数量的字段(其中至少一些字段受到约束)以包含动态数据的不同策略。方法包括提供关键变量的最低有效位数据，然后使得能够从已知数据重建完整的关键变量。方法还包括纳入可变数据和时间数据的组合，以及通过减去时间数据来建立可变数据。在这种情况下，记录的时间值可能不同于当前的时间值-这可能在存在延长的有效时段的情况下，以及交易可能在传输之前进行的情况下，或者在可能不按顺序提供数据的情况下发生。时间值的变化于是将受到限制，并且从而可以通过迭代的重试过程或通过包含校验数据来解决。
将在交易方案的上下文中更详细地说明实施例。首先将更详细地说明合适的交易方案和基础设施。图2是典型的四方模型或四方支付交易方案的框图。该图图解说明了存在于模型中的实体以及在在卡组织(card scheme)中操作的实体之间发生的交互。
通常，卡组织-链接到支付卡的支付网络-基于两种模型之一：三方模型或(本申请人采用的)四方模型。对本文献来说，下面更详细地说明四方模型。
四方模型可以用作交易网络的基础。对于每个交易，该模型包括四种实体类型：持卡人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支付交换费，作为资金结算的回报。
在四方系统模型的实际实现中，特定方的角色可能涉及共同作用的多个元素。在已超越客户卡和商户终端之间基于接触的交互，发展到在诸如智能电话机之类的用户计算设备上使用代理或虚拟卡的数字实现的实现中，情况通常就是这样。
图3示出了按照本公开的实施例的适合于持卡人和商户之间的交互的架构。这图示出了供参考的通用架构，但是该图示出了当持卡人与商户服务器进行在线交易时所使用的架构的元件。
对于常规交易，持卡人将使用他们的支付卡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，检查令牌的状态(以确保它在有效期内和在其他方面有效)以及所使用的任何客户验证方法，在交易方案中验证交易。这允许发卡方以正常的方式授权交易。
图4更详细地示出了支持来自移动设备的数字化支付的交易基础设施的元件。作为具体例子，该图示出了申请人的万事达卡基于云的支付(MCBP)架构-这是示例性的，而不特定于本发明，并且图解说明了该架构如何用于支持移动设备(比如智能电话机11)上的移动支付应用215-这里，移动支付应用215被表示为包含在钱包应用或数字钱包41内。此类数字钱包41可以与钱包服务器17通信以允许移动支付应用的管理，并且它还可以用于请求支付卡6的数字化，以便由移动设备11使用。
万事达卡数字使能服务(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内，但是它可以是单独控制的独立元件-是令牌信息的储存库，令牌信息包括令牌和关联卡之间的对应关系。在处理令牌化交易时，MDES42将参考令牌库45，并且卡的令牌化将导致在令牌库45中创建新的条目。
交易管理系统(TMS)46在处理令牌化交易时使用。如果交易被交易方案识别为被令牌化，则它被路由到TMS 46，TMS 46通过使用令牌库45对交易进行去令牌化。去令牌化的交易然后被路由到发卡方(这里由金融授权系统47代表)，以常规方式进行授权。TMS 46还与CMS 44交互，以确保与持卡人账户和凭证的同步。
本公开的实施例可以使用图3和4中所示的架构来进行。如前所述，特别感兴趣的是诸如在在线商务中进行的数字交易之类的数字交易。在在线商务中，消费者通常将通过用户计算设备上的浏览器(或特定app)，通过网站与商户服务器交互。用户将使用他们的信用卡进行交易，但是该卡不会在场，并且这里消费者不是通过他们自己的计算设备上的支付应用进行交易，而是以类似于常规的“持卡人不在场”(CNP)交易的方式使用支付卡，在CNP交易中，商户接收支付卡的具体细节，但不会接收由支付卡本身或由用户计算设备上的支付应用生成的应用密文。
在此类情况下，可能的限制是诸如商户服务器之类的系统实体-或支持商户的支付服务提供商网关-可能按照旧的协议版本操作，因此将只能支持非常有限的支付卡数据的提供。参考图5-12说明了通过使用较旧的协议版本所允许的有限数据字段，管理动态数据的提供的方法。该方法涉及使用交易方案的数字交易的进行，并且适用于如上所述的在线支付-它与在线商务，尤其是与安全远程商务(SRC-https://www.emvco.com/emv-technologies/src/)特别相关，SRC是由EMVCo开发或为EMVCo开发的一组规范，提供了处理电子商务交易的安全方法。使用SRC，交易可以由动态令牌数据(DTD)识别，其中交易是使用令牌(由如图3和4中所示的架构管理)而不是PAN进行的，并且内容随每个交易而变化。持卡人认证是使用单独的机制，3DS(例如在https：//en.wikipedia.org/wiki/3-D_Secure讨论的适合于在无卡(CNP)交易中用于持卡人认证的3-D安全的版本)进行的。于是，DTD数据需要足以识别交易并允许授权者判定交易是合法的，并且可取的是DTD数据生成独立于3DS过程(优选地使得DTD数据生成可以在对3DS过程的任何调用之前或之后进行)。
正如上面讨论的例子中那样，假设交易数据中只有传统的字段可以用于DTD数据：PAN、有效期和CVC2。DTD数据应当使得内容随每笔交易而变化，但是存在与所使用的相关令牌的明确绑定，并且虽然数据不需要是现有类型的EMV密文，但是数据需要使得交易的合法性能够被验证。
现在将说明动态令牌数据-特别地，形成动态令牌数据的一部分的动态有效期和动态CVC-的示例性内容，以及用于在安全远程商务交易的上下文中生成和验证这些值的过程。应注意的是，该方法可以应用于使用令牌化交易的任何产品或服务，而不限于SRC，并且下面在引用SRC交易时，本领域技术人员会意识到，并不意图将所描述的功能的使用限制于SRC交易的上下文。
如上所述和如图5中所示，有效期包括YYMM形式的四个值，其中YY用于携带“年份”信息(YY是介于00和99之间的两位值)，MM用于携带“月份”信息(MM是介于01和12之间的两位值)。在原始的传统EMV上下文中，这是静态值，定义了(物理)支付卡的寿命，该卡在有效期过去之后不再有效。
如果有效期值似乎无效或不可能，则使用该协议的传统版本的中间计算系统-支付服务提供商或商户服务器-可以使交易无效。这对可在该字段中携带的动态数据造成很大限制-该动态数据必须对应于可能的日期，该日期必须不是过去的，但是也必须在不太远的未来才可信。如果携带6比特数据，则这将要求高达未来5-6年的日期值-这些日期值不应被传统系统拒绝。然而，使用7比特将要求高达未来10年的有效期，8比特为20年，9比特为40年-7比特解决方案将有失败的风险，而8比特或9比特解决方案将是不可行的。这在图6中以示例形式示出。
可取的是在有效期字段中携带的数据类型有两种。一个是应用交易计数器(ATC)数据-这已经在上面描述，并且是设置在交易数据生成器处的、在创建相关交易数据时递增的计数器。另一个是不可预测数(UN)数据。不可预测数是用于在密文生成时提供可变性和唯一性的值-不同的UN生成方法是可能的，UN的总体大小和生成它的过程不可能被攻击者复制是安全性的主要因素。ATC和UN值用于在DTD交易中生成密文，并由负责动态令牌数据的验证的实体恢复。
如果6比特可用，则优选的选择是3比特分配给ATC，3比特分配给UN。其次的最佳选择是2比特分配给ATC，4比特分配给UN-然而，人们认为处理来自几个商户的一篮子商品或服务时出错的风险超过了UN安全性的随之增加，因为这可能涉及许多交易的非常快速的执行，并且如果只使用2比特，则可以循环ATC值。
如前所述，CVC2(卡安全代码)是三位字段，最初用于携带介于000和999之间的静态三位值-它被印在常规支付卡的背面，并用作持卡人正在进行交易的确认，因为持卡人应该实际拥有该支付卡。
使用动态令牌数据，该静态值被动态CVC替换-动态CVC是作为DTD交易的一部分而生成的3位密文。
现在将参考图7说明DTD生成、传送和验证过程。在生成和验证过程中，相关的计算实体适合于执行EMV协议的当前版本，并且知道并适合于进行相关的DTD过程功能。然而，在传送过程中，如果EMV交易数据和/或3DS交易数据被用作交易流的一部分，则DTD相关数据的传送必须不影响EMV交易数据和/或3DS交易数据的任何传送。
下面参考图8详细说明DTD生成过程。生成器可以从卡简表访问信息：这里，相关数据是PAN(或令牌)，这里称作dtdToken；以及用于DTD交易的初始向量(IV)ivCvcTrackDtd。初始向量可使用对数据列表的加密操作来生成，该数据列表包含例如令牌的某些标识，比如在使用包括PAN、服务代码、静态有效期等的跟踪数据时所定义的。生成器还能够为DTD交易提供唯一的交易凭证：ATC dtdATC；以及会话密钥SK。还将存在与交易关联的参数列表：在生成器和验证器之间共享的可选附加数据dtdAdditionalData；使用动态有效期携带的ATC的比特数dynamicExpiryDateNbrATCBits；和使用动态有效期携带的UN(如下所示，在本实施例中它是基于时间的)的比特数dynamicExpiryDateNbrUNBits。如果使用上述优选实现(对于ATC和UN都使用3比特)，则后两个值可以保持静态并等于3。
参见图8，说明用于生成动态令牌数据的完整过程。首先，在201获得历元时间值。获得的初始值是启动动态令牌数据生成时的Unix历元时间-这里是dtdGenUET。这是自1970年1月1日午夜(UTC)以来经过的秒数，不考虑闰秒。通过适当的比例调整该值以提供值dtdAdjGenUET，并且通过使用调整后的Unix历元时间的模100000来获得参考时间，以提供值dtdRefTimeGenUET。
之后，在202获得所需的卡简表数据-这包括PAN/令牌dtdToken的值和用于生成DTD动态CVC的会话密钥(SK)的ATC，dtdATC的值。
然后在203，提取ATC的相关部分并重新格式化。ATC的n个最低有效位(最右边的)被提取为dtdLSbATCBin，其中n由参数dynamicExpiryDateNbrATCBits定义。然后将该值dtdLSbATCBin转换为十进制值dtdLSbATCNum。
下一步骤是在204生成基于时间的不可预测数。为此，创建令牌值和ATC的相关部分的缓冲器：
缓冲器＝dtdToken|dtdLSbATCNum
如果可选数据dtdAdditionalData是非零的，则可以将其附加到缓冲器的右侧-填充也可以用来使缓冲器的长度均匀。然后使用SHA256散列该缓冲器以形成dtdGenHash，此后擦除该缓冲器。对于散列可以作出其他选择-例如，可以使用SHA512而不是SHA256，或者可以使用诸如SM3的其他散列机制。
如前关于ATC一样，散列的三个最低有效位被提取为dtdLSBGenHash，并被转换为数值dtdLSBGenHashNum。然后将其转换为模100000值dtdLSBGenHashNumMod，并且通过将该值和时间值相加再模100000来计算基于时间的不可预测数。
dtdGenUN＝(dtdRefTimeGenUET+dtdGenHashNumMod)MOD 1000000
如图9和10中所示，在生成不可预测数方面时可能有许多变型-图9和10示出了都采用UTC日期的不同形式，但是采用两种不同的方法来包括ATC数据的其他方法。在两种变型中，Y字节缓冲器由4字节BCD(二进制编码十进制)UTC日期-在这种情况下，是YYYYMMDD格式-和适当的PAN和ATC贡献构成。在两种情况下，PAN都是作为n位值提供的，必要时进行填充，由此形成X字节的BCD值。然而，提供ATC值的方法不同：在图9中所示的第一种情况下，使用完整的ATC值并且是作为2字节十六进制值提供的，而在图10中所示的第二种情况下，提供4个最低有效位并形成1字节十六进制值。在这两种情况下，这些用于形成Y字节输入缓冲器，单向函数(比如SHA256)对该Y字节输入缓冲器进行操作，以提供32字节输出，4个最低有效位用于提供不可预测数。本领域技术人员会意识到，这里所应用的原理可以通过较小的变化来实现，以提供不可预测数生成过程的其他实现。
所有元素现在对要在205生成的动态有效期都是可用的。从参考时间提取n个最低有效位-n由dynamicExpiryDateNbrUNBits定义，并且作为结果的输出是dtdRefTimeGenUETBin。然后将ATC和时间值表示为月份数：
dtdGenNbrMonthsBin＝dtdLSbATCBin|dtdRefTimeGenUETBin
然后将该二进制值转换为数值dtdGenNbrMonths。使用dtdGenUET识别下一个月份，并表示为值dtgGenYYMM Next，它为dtdGenYYMM+1。通过简单地将计算的数值与下一个月份值相加来计算动态有效期：dtdDynamicExpiryDate＝addMonths(dtdGenYYMMNext,dtdGenNbrMonths)
其中dtdGenYYMMNext是参考值，而dtdGenNbrMonths是要相加的月份数。使用该方法，动态有效期对于传统处理器似乎是有效的有效期，因为它具有正确的格式，既不在过去，也不在遥远的未来。
下一步骤是在206生成DTD动态CVC。该过程也示于图11中。由IV值ivCvcTrackDtd、4字节基于时间的UN dtdGenUN和2字节ATC值dtdATC的级联形成8字节输入缓冲器。然后通过适当的加密过程，比如DES3(使用ECB模式的2密钥三重DES加密(EDE))，使用会话密钥SK从缓冲器加密地计算动态CVC值，其中以十进制表示的8字节结果的3个最低有效位被用作CVC。这可以表述为：
dtdDynamicCVC＝LSD(3,Byte2Dec(LSB(2,DES3(SK)[buffer])))
其中LSB(n,X)是字节串X的n个最低有效字节，Byte2Dec(X)将一串字节转换成以十进制表示的整数(例如，Byte2Dec(‘C07E-)＝49278)。LSD(n,D)是以十进制表示的整数的n个最低有效位。一旦创建了动态CVC值，就可以擦除缓冲器。
之后，在207可以擦除ATC值和会话密钥，然后在208，将DTD值交付给商户(从而交付给收单方)，作为交易数据供在交易的在线授权请求中使用：PAN(令牌)值dtdToken，使用DTD动态有效期dtdDynamicExpiryDate的有效期值，以及使用DTD动态CVC dtdDynamicCVC的CVC2。之后，在209可以擦除在该过程中使用的所有剩余数据。
传送过程是直截了当的，因为所有交易数据都具有传统交易数据的格式。如果商户或收单方或任何关联的系统实体(比如商户的支付服务提供商(PSP))只适合于使用协议的传统版本，这将不影响交易数据从商户到收单方到交易方案的路由以进行授权。此时，需要验证动态令牌数据。
图12中详细说明了该验证过程-特别需要DTD动态CVC值dtdDynamicCVC的验证，dtdDynamicCVC通过CVC2字段，连同dtdToken和dtdDynamicExpiryDate值一起被提供给验证器，dtdToken和dtdDynamicExpiryDate值是分别通过来自设置在传统的格式化EMV授权请求中的交易日期中的PAN(令牌)和有效期字段提供的。
验证器可以访问各种信息，还可以访问能够执行必要的加密计算的HSM(硬件安全模块)。具体地，这些资源如下。
验证器可以访问与PAN(令牌)关联的以下信息：
o加密密钥，比如发卡方主密钥：IMK
o最后的已知ATC：dtdLastKnownATC
o使用以下值构造用于生成IV值(ivCvcTrackDtd)的跟踪数据(trackDtd)的信息：
trackDtdExpiryDate："trackDtd"中的“xxxx”值
trackDtdServiceCode："trackDtd"中的“yyy”值
trackDtdPanSequenceNumber："trackDtd"中的“z”值
其中(trackDtd)是19字节值："<PAN>Dxxxxyyyz000000000000F"
其中<PAN>被设定为dtdToken，D被定义为定界符，“000000000000F”被定义为填充符。
本领域的技术人员会意识到的是，该格式类似于通常用于创建跟踪(Track)2数据的格式，但是可以使用任何等同的机制来识别令牌。
验证器可访问以下参数列表：
ο在“生成器”和“验证器”之间共享的任何可选的附加数据：
dtdAdditionalData(在简化版本中可以不使用)
ο使用动态有效期携带的ATC的比特数：
dynamicExpiryDateNbrATCBits(在简化版本中可以被设定为3)
ο使用动态有效期携带的基于时间的UN的比特数：
dynamicExpiryDateNbrUNBits(在简化版本中可以被设定为3)
ο在DTD验证失败的情况下用于调整有效期(调高)的阈值：
dtdMonthShiftUpThreshold，使用GMT时区表示的值hh:mm:ss PM(例如，11:55:00PM GMT)
ο在DTD验证失败的情况下用于调整有效期(调低)的阈值：
dtdMonthShiftDownThreshold，使用GMT时区表示的值hh:mm:ss AM(例如，00:05:00AM GMT)
HSM能够从发卡方主密钥(IMK)生成卡主密钥(CMK)和会话密钥(SK)，能够从如上所述的跟踪数据和卡主密钥(CMK)生成IV，并且能够将会话密钥SK、IV、UN和ATC用于CVC验证。
图12中概略地图解说明了验证器进行的操作，下面详细说明这些操作。首先，在401必须获得时间信息。这可以以与生成器完全相同的方式进行，因为完全相同的信息是可用的。在402，可以简单地从交易数据中提取PAN(令牌)值，作为dtdToken。在403，还可以从DTD交易数据重建IV值，因为DTD交易数据包含重建用于生成IV值(ivCvcTrackDtd)的跟踪数据(trackDtd)所需的所有内容。值trackDtd是用于识别用于交易的令牌的19字节值“<PAN>Dxxxxyyyz000000000000F”，其中xxxx是trackDtdExpiryDate(没有链接到在DTD交易的上下文中使用的动态有效期的静态值)，yyy是trackDtdServiceCode(在传统系统中使用的限定对于交易所支持的服务的静态值)，z是trackDtdPANSequenceNumber(可以用于识别共享同一PAN值的几个卡的静态值)。
下一步骤是验证过程特有的，涉及在404设定月份偏移值，它可以为0(默认)、1或-1。其第一部分是通过向为dtdValUET的YYMM格式的当前时间dtdValYYMM加1来建立下一个月份值dtdValYYMMNext。然后从DTD交易数据中检索DTD动态有效期(dtdDynamicExpiryDate)，并从中减去下一个月份值，以给出由生成器计算的月份数-dtdGenNbrMonths。
下一步骤是尝试确定月份偏移值是否正确，这是通过确定DTD动态CVC是否可被验证来确定的，如下进一步所述。月份数被转换为二进制值(dtdGenNbrMonthsBin)，在405从DTD动态有效期中提取可用的ATC和UN信息-dtdGenNbrMonthsBin的n个最高有效位形成ATCdtdLSbATCBin的n个最低有效位，dtdGenNbrMonthsBin的m个最低有效位形成参考时间dtdRefTimeGenUETBin的m个最低有效位，其中n由dynamicExpiryDateNbrATCBits定义，m由dynamicExpiryDateNbrUNBits定义。
之后的下一步骤是在406，从该数据构造ATC候选者。这是通过对于该PAN(令牌)dtdToken检索最后的已知ATC值dtdLastKnownATC来完成的，验证器通过先前的验证过程将可以访问该值。最后的已知ATC值和从动态有效期检索的ATC信息将一起用于重建候选ATC值dtdCandidateATC，通常是与来自动态有效期的ATC信息一致但高于最后的已知ATC值的最低值。然后将其转换为十进制值dtdLSBATCNum。
通过重复用于创建基于时间的UN的过程，在407所有相关元素都可用于恢复基于时间的UN。如前所述，创建令牌值和ATC的相关部分的临时缓冲器：
缓冲器＝dtdToken|dtdLSbATCNum
如果可选数据dtdAdditionalData是非零的，则可以将其附加到缓冲器的右侧-填充也可以用来使缓冲器的长度均匀。然后使用SHA256散列该缓冲器以形成dtdValHash，之后擦除该缓冲器。
提取dtdValHash的3个最低有效位作为dtdLSBValHash，并将其转换为数值dtdLSBValHashNum。然后将其以模100000表示为dtdLSBValHashNumMod。为了创建不可预测数候选者，掩蔽dtdRefTimeValUET的n个最低有效位(其中n由dynamicExpiryDateNbrUNBits定义)，创建用于UN重建的第一候选者dtdCandidateUN，其中
dtdCandidateUN＝dtdRefTimeValUETMasked+dtdRefTimeGenUETBin
此时，还创建用于UN重建的附加候选者：dtdCandidateUN”-1”、dtdCandidateUN”-2”和dtdCandidateUN”+1”。这些候选者具有以下值：
·dtdCandidateUN”-1”＝dtdCandidateUN–幂(2,n)
·dtdCandidateUN”-2”＝dtdCandidateUN–幂(2,n+1)
·dtdCandidateUN”+1”＝dtdCandidateUN+幂(2,n)
这4个候选者具有以下恢复的UN值：dtdRecoveredUN、dtdRecoveredUN”-1”、dtdRecoveredUN”-2”和dtdRecoveredUN”+1”,其中：
·dtdRecoveredUN＝(dtdLSBValHashNumMod+dtdCandidateUN)MOD100000
·dtdRecoveredUN”-1”＝(dtdLSBValHashNumMod+dtdCandidateUN”-1”)MOD100000
·dtdRecoveredUN”-2”＝(dtdLSBValHashNumMod+dtdCandidateUN”-2”)MOD100000
·dtdRecoveredUN”+1”＝(dtdLSBValHashNumMod+dtdCandidateUN”+1”)MOD100000
这些值分别是最当前的可能生成时间和两个较早的候选时间，以及与验证相比未来的下一个可用时间(在无序事件的情况下是可能的)的UN值。下一步骤是如上所述计算用于动态令牌数据的验证的参考时间和用于UN重建的候选者列表之间的增量：
·dtdValDelta＝dtdRefTimeValUET-dtdCandidateUN
·dtdValDelta”-1”＝dtdRefTimeValUET-dtdCandidateUN”-1”
·dtdValDelta”-2”＝dtdRefTimeValUET-dtdCandidateUN”-2”
·dtdValDelta”+1”＝dtdRefTimeValUET-dtdCandidateUN”+1”
然后对时间排序，“过去的”时间排在“未来的”时间之前。
下一步骤是在408尝试验证DTD动态CVC。为此，使用了下述：
·跟踪数据(19字节)：trackDtd–这是已知的；
·恢复的UN(4字节)：dtdRecoveredUN–这是当前“最佳的”候选者
·候选ATC(2字节)：dtdCandidateATC–这同样是当前“最佳的”候选者
使用加密函数验证DTD动态CVC，该函数将提供的动态CVC与使用利用ivCvcTrackDtd,dtdRecoveredUN和dtdCandidateATC的级联创建的8字节缓冲器计算的CVC值进行比较。
computedCVC＝LSD(3,Byte2Dec(LSB(2,DES3(SK)[具有IV、UN和ATC的缓冲器]))),其中
·DES3是使用ECB模式的2密钥三重DES加密(EDE)
·LSB(n,X)是字节串X的n个最低有效(最右侧)字节
·Byte2Dec(X)将一串字节转换为以十进制表示的整数。
例如，Byte2Dec('C07E')＝49278
·LSD(n,D)是以十进制表示的整数的n个最低有效(最右侧)位
该验证过程将成功或失败，并且这标记了决策点409。如果成功410，则可以认为(UN和ATC的)当前候选者是正确的。使用dtdCandidateATC更新dtdLastKnownATC的值，将会话密钥的ATC标记为已使用，并报告验证的结果(报告为成功)。如果失败，则存在按照以下准则的重试过程：
·按照基于增量值(dtdValDelta***)的排序，尝试使用下一个恢复的UN值(dtdRecoveredUN***)来验证动态CVC；
·如果不再有可用的dtdRecoveredUN***，则再次尝试使用另一个ATC候选者(dtdCandidateATC)来验证动态CVC-可以对所有恢复的UN候选者进行这种尝试；
·如果不再有可用的dtdCandidateATC，则在调整月份数(dtdGenNbrMonths)之后再次尝试验证动态CVC-这将需要重新计算ATC候选者和恢复的UN候选者，并且可以按照前两个步骤对所有这些新的候选者执行该过程。如果这也失败，则可以使用进一步的月份调整。如前所述，当生成发生在一个月中而验证发生在另一个月中时，月份调整可以解决“月末”问题。
·如果在处理了所有月份调整选项之后，验证(#23)仍然失败，则有必要报告验证结果(报告为失败)
在411交付结果之后，在412可以擦除没有在上述步骤中主动存储的计算的和生成的值。
本领域的技术人员会意识到，在这种情况下，各种策略都是可能的。通过在动态字段中携带略少的ATC或UN信息，并通过改为包含附加数据来指示时间，可以消除对迭代的一些需要。图13示出了示例性情况，其中2位数据被重新利用以提供日期控制。这里，这2比特可以在4个值之间循环，使得我们可以对验证日期和恢复的日期信息之间的一致性进行验证。控制日期值可以使用对基线值和生成(或验证)日之间的天数的模4运算来计算。它可用于判定动态CVC的生成是在验证所提供的值的同一天还是前一天执行的。例如，当生成是在一个月的最后一天进行的，而验证是在下一个月的第一天进行的时，前一天会导致调整参考月份。这消除了通过重试机制进行月份调整的需要，因为这将确保在任何使用恢复的数据来验证动态CVC之前，使用确定性过程来识别正确的月份，而不需要重试。这种逻辑也适用于闰年，和/或当生成和验证是在两年内完成时(即生成在一年的最后一天进行，而验证在第二年的第一天进行)。
提出了一种新形式的用于数字交易的去中心化架构，并且在申请人的欧洲专利申请No.19178583.1中说明了这种新形式的去中心化架构。如图14-16中所示，本公开的实施例也可以在这种用于进行数字交易的去中心化架构上进行，该去中心化架构涉及一组去中心化的节点，每个节点都能够进行凭证管理。这些去中心化的节点可以进行如图1中所示的系统中的第一计算实体1001(在生成凭证时)或第二计算实体1002(在验证凭证时)的功能，具有传统约束的任何居间实体(例如，商户销售点装置或服务器)都是第三计算实体1003。
图14示出了计算节点Nx的去中心化系统，每个节点都能够生成G凭证和验证V凭证。这些凭证可以在整个系统中有效(除非由于on-soil监管等而局限于一些节点)，并且在这种情况下与一组用户(客户端)的交易关联，所述一组用户(客户端)的交易通常通过地理邻近性被路由到该节点。节点作为服务向客户端提供凭证生成G和凭证验证V，并且需要能够安全地生成凭证，并且至少在凭证有效时安全地验证它们。在所示的架构中，不存储凭证-它们是根据请求而生成的，并且是随时验证的。如图14和15中所示，除了凭证生成和验证之外，密钥管理K和监控M也可以被视为节点本地和整个系统的服务，并且为了允许访问服务，通常需要访问控制AC。
图16中表示了适当计算节点的元件。节点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)，因此处理将是苛刻的并且也非常昂贵，并且数据存储，特别是网络时延将成为不可能管理的问题。
目前，设备安全模型也用于全数字交易。该安全模型涉及存储在交易系统HSM中并用于从相关IMK和卡PAN(主账号)导出卡主密钥(CMK)的发卡方主密钥(IMK)。这些CMK然后被存储在设备(通常是安全元件或替代技术)中。当使用基于软件的解决方案来使用移动设备生成交易凭证时，使用相关CMK和卡/设备的ATC(应用交易计数器)来生成会话密钥(SK)-这目前由凭证管理系统(CMS)生成，如图4中所示。目前，所有令牌，即使对于全数字交易，都被绑定到这种IMK/CMK/SK导出。这也适用于服务器通过交易系统为远程支付交易开放的API生成的交易凭证。
虽然下面一般使用术语PAN，但是在数字化交易的上下文中，使用术语TUR(令牌唯一引用)来指代卡或账户的唯一标识符也是合适的。字面上，在希望相互区分这两个术语的情况下，应如下使用它们：
·PAN是与账户直接关联的值-这是识别账户的正常(数字)方式-术语FPAN或资金PAN可用于指示对发卡行账户的引用；
·TUR或“令牌唯一引用”是允许识别令牌而不暴露任何PAN值的值，在交易系统内存在确定哪个PAN与TUR关联的机制。
然而，当下面使用术语PAN时，应当理解的是，这是在可以与识别它的账户关联的标识符的广义上使用的-因此下面PAN的使用可以包括TUR。
常规的方法需要非常大的密钥管理负载，并不适合于全数字交易。SK的生成，因此应用密文(AC-EMV交易中的标准机制)需要多个加密操作，而不是所有这些加密操作都可以由常规的现成HSM进行，因此需要定制的HSM。需要在整个系统中大规模分发密钥，以便无论交易在哪里发生，都可以支持交易的进行，并且ATC管理复杂。可取的是使用标准HSM，在具有直接可用的密钥的同时避免大规模的密钥复制，并且能够提供限制总的HSM数量的解决方案(因为这些HSM通常只支持几千个密钥)。
这种安全性在很大程度上是为了提供安全性的保证，即使在系统端点(例如，在持卡人设备)存在妥协的可能性。加密函数的主要目的是提供保证-这既涵盖数据的完整性又涵盖认证。由加密数据保护的交易相关数据包括交易和关联令牌的标识，以及所使用的任何加密过程和任何相关金融数据的指示(以及需要保证的交易的任何其他方面)。这由交易凭证表示-交易凭证需要被生成G，随后被验证V，这些过程被监控M以确保整个系统的完整性，并由某种密钥管理系统K支持。在全数字交易的情况下，这些过程在端点安全性不是问题的受约束环境中以与设备相同的方式发生。在该领域中，令牌不会到达常规交易管理系统的任何一个端点-持卡人或发卡方。相反，它在商户系统或支付服务提供商(PSP)和交易方案提供商之间操作。
这种方法允许将凭证系统从复杂的中央服务器分散到多个提供服务的节点中。这些节点通常在地理上是分布的，但是可以在多个数据中心上扩展(例如，通过使用云基础设施来实现节点内的数据共享)。这些节点利用定义的对服务的访问控制规则提供服务-对于凭证来说，生成服务G和验证服务V。商户或PSP与生成服务G通信以获得凭证，然后在标准授权过程中使用所述凭证，在需要时调用验证服务V来验证凭证。这些服务可以访问节点的计算基础设施(HSM，数据库)。还提供了监控服务M和密钥管理服务K-这些服务可以是集中组织的，或者包括协同功能和本地功能的混合。下面更详细地说明所有这些服务及其相互关系。
通过替换将令牌绑定到特定的分层导出密钥，改为允许将密钥堆栈中的第一个可用密钥分配给令牌化交易，可以支持这种分布式方法。通过使用灵活并且动态的密钥管理，这种方法允许可缩放的解决方案。可以以这样的方式进行监控，以确保分布式架构是安全的，而不需要传输或复制大量的敏感信息。该方法也可以使用完全符合FIPS的过程在标准HSM中执行-例如，不需要使用DES和3DES。在申请人的欧洲专利申请No.19178583.1中更详细地说明了这种方法。该申请说明了如何在提供确定性过程的同时，将有限数量的密钥分配给节点，以便挑选密钥来生成凭证。验证实体可以使用相同的过程来确定由生成器所使用的密钥，使得它可以验证作为为验证而提交的凭证的一部分的任何加密材料。
对于每个节点，生成服务G和验证服务V可以访问HSM池。HSM包含密钥，每个密钥由一组密钥标识符(KeyID)唯一识别。KeyID可以是标签、值、诸如UUID之类的明确唯一值，或者具有适当性质的任何其他事物。这些KeyId被存储在唯一识别的(标识符)密钥列表中-这些密钥列表提供标识符(Id)和存储的密钥(KeyId)之间的关系列表。如下进一步所述，标识符(Id)是为了确定将使用什么密钥而由确定性过程确定的事物。每个密钥列表的完整性可以使用印章(Seal)来保证-如果密钥列表是从中心位置提供的，则这可以由与该中心位置关联的受信任方应用。可以支持几种其他分发模型，例如，使用作为本地功能而不是中心位置的受信任方。节点通常具有许多可用的密钥列表，但是在给定时间只有一个活动用于生成凭证(G)-然而，对验证服务(V)来说，通常需要能够访问可能与仍然有效的凭证关联的任何密钥列表。该方法中的密钥轮换(rotation)是非常直截了当的-它可能只涉及用另一个密钥列表替换活动密钥列表。然而，非常直截了当的是告诉验证凭证需要哪个KeyId-它将完全由节点标识符和密钥列表的引用来确定。该信息是凭证的一部分，并用作从密钥列表中挑选密钥的确定性过程的输入。
在任何给定的时间点，这些服务G需要使用给定的密钥列表-比如说第一实例中的密钥列表A，因此，相关密钥必须被加载到由生成服务G使用的HSM中。在一段时间结束之后，密钥轮换过程例如可能强制使用密钥列表B，这可能需要如果还不存在，则需要被加载到相关HSM中的新的密钥。通过确定性过程从密钥列表中选择要使用的特定密钥-这通常会在密钥轮换之后会给出不同的结果，但是情况并非必然如此。虽然生成服务G在密钥轮换之后不需要密钥列表A，但是验证服务V仍然需要-它们需要访问与可能有效的凭证相关的任何密钥列表。为了验证凭证，验证服务V必须能够准确地确定生成服务G使用了哪个密钥来生成凭证。
要加密保护的交易相关数据包括与交易关联的令牌的标识，但是也包括交易本身的标识。为此，需要某种交易标识符。在每个节点，凭证生成服务和验证服务可以访问可用于管理此类数据的本地数据库。为了确保跨系统有效地管理交易，给定令牌的交易凭证的任何生成应当与每个交易的唯一交易标识符关联。这可以是UUID，但是如前所述，在其中交易的识别可能需要由许多分布式节点中的一个来完成的分布式系统中建立UUID是有挑战性的。在本公开的实施例中，可使用适当的标识符结构(比如n比特节点标识符、e比特历元时间和c比特本地计数器的级联)。
在本公开的实施例中，通过使用本地交易计数器，可以将交易凭证中所要携带的数据的大小减少到几位。这可以简单地存储在节点的本地数据库中，并且当本地生成服务G生成新的令牌时，本地(而不是全局)值递增。于是，本地交易计数器(LTC)可以有助于上述有效唯一的标识符结构，节点标识、时间和本地交易计数器的结合用于有效且唯一地识别交易。使用基于时间的密钥列表轮换过程允许LTC值在时间段结束时被重置而不丢失这些性质，同时限制作为交易流的一部分携带LTC值所需的数据的大小。
在交易数据内，应当存在表示在交易过程中生成的应用密文的信息。这可以是密文的简化形式-如下所述，在其中存在非常受限的数据通道的“传统”交易中，这可以作为CVC2字段来提供(在常规EMV交易中，CVC2是静态字段-在物理支付卡背面以三位值的形式提供-用于确认该卡的知识，而不仅仅是PAN)。这是重要的，因为验证服务V必须能够访问由生成服务G用于生成密文的所有数据-这将包括以下内容:
作为交易流的一部分携带的动态信息；
来自以下之一的共享信息:
重复的过程(比如密钥列表的管理)；
用于特定用例的系统参数。
传统交易用例对本公开的实施例来说特别有意义。这在商户和/或PSP只能管理PAN、有效期和CVC2作为交易流的一部分，而不能访问由最新的发展提供的附加数据字段时提供了一种解决方案。
所涉及的挑战是有效地识别在交易中凭证是如何生成的，以便使它们随后能够被验证-特别地，识别哪个节点生成了凭证和使用了哪个密钥列表来生成凭证，以及本地交易计数器的状态。这是具有挑战性的，因为交易数据是高度受约束的，并且为了提供任何这种信息，都需要改变现有的电子交易协议(比如ISO 8583)或重新利用现有的字段。
对于传统的电子交易协议，原则上可以重新利用的字段是主账号(PAN)(因为在这种类型的交易的上下文中，PAN内的一些数字可能是隐式的，结果可以被重复使用)，有效期(其中一些信息可以以压缩格式来携带)以及CVC2。使用有效期作为载体可以直接释放6比特，但是这是不够的-对于任何扩展系统，节点标识符通常需要至少4比特，并且1比特对于密钥列表引用或交易计数器来说可能都不够。
可以使用的一种方法是使用一组特定的银行信息号码(BIN)，它们构成PAN中的前六个数位，以支持上述实现-当检测到这些BIN之一时，可以采用特殊的处理。这可以涉及将令牌与多个PAN值关联。图17中表示了该模型。可以将FPAN(资金主账号-对应于物理卡账户)映射到一个或多个令牌，但是特定的令牌与特定技术关联。上面一行示出了传统的令牌化过程-FPAN与单个令牌关联。在使用上述方法的情况下，令牌可以与传统验收用例的9个PAN值关联(下面一行)，不过如下所述，对于某些新格式，仍然可以使用一对一的映射。
因此，传统情况下的交易字段的重用可以如下所示。对于PAN，14个数位可用于令牌的完全识别，其中1个数位用于关联到给定号码的令牌的计数器，1个数位用于Luhn数(它需要作为校验和被保留以确保使用有效的数字)。有效期的6比特可以被重新利用，其中x比特用于识别节点，y比特用于引用该节点的相关密钥列表。CVC2提供了可用于密文的三个数位。
考虑到安全性，可取的是定期改变密钥列表以确保系统安全不受攻击。另外重要的是，能够允许在已创建凭证之后的一段时间内验证它们-建议的方法是允许在创建凭证之后的24小时内验证凭证。如果将其与每24-36小时操作一次的密钥轮换过程相结合，这意味着虽然生成过程对于给定节点将永远只有一个活动密钥列表，但是验证过程将只需要考虑两个密钥列表(当前活动的用于凭证生成的密钥列表和紧接在其之前活动的密钥列表)。使用所建立的基于交易计数器的确定性过程从而建立要使用的密钥。这种类型的二进制信息(即一个或另一个)通常可以使用1比特信息来编码。密文在保护交易的完整性方面起着关键作用-使用正确密钥对于给定的一组数据计算的密文的成功验证确认最初用于凭证生成的数据是真实的。验证过程中的任何失败都可能来自使用了错误的加密材料和/或被破坏的交易数据。
在每个节点中，每个生成服务(G)和验证服务(V)都可以访问本地数据库。将给定令牌的交易凭证的任何生成与每个交易的唯一交易标识符相关联。如上所述，使用与给定用例关联的给定密钥列表，在给定节点中通过关于给定令牌的“G”管理本地交易计数器(LTC)。相同的过程在通过“V”进行验证时也适用。该信息可以如图20中所示携带在PAN字段(数位15，或数位14和15)中，或者如图21中所示使用CVC2字段，在有效期字段中具有重试标志，如果LTC值较高，则在必要时生成“完整计数器”。然而，重要的是为给定密钥列表，给定节点，给定令牌，对可通过G生成和通过V验证的密文的数量设定限制，以确保有效的访问控制-该值“MaxTransactionCounter”可以存储在密钥列表中并由密钥列表印章保护。
图19中表示了关于该传统情况的加密过程。在这种情况下，选择HMAC作为加密函数，因为它允许在交付有效功能的同时使用通用HSM。令牌的标识使用PAN值。交易的标识从有效期(ISO 8583字段DE14)-特别是节点标识符和引用，可能还带有重试标志-以及从保存本地交易计数器的PAN字段获取信息。密钥和加密方法的标识由本地交易计数器(它确定从密钥列表中选择哪个密钥)以及密钥列表中密钥管理系统共享的信息提供。定义交易的各种字段可以用作用于生成密文的金融数据(如图18中所示)，所有这些字段用于生成密文，密文然后被十进制化，并在CVC2字段中使用3个最低有效位。
本领域技术人员会意识到，对这些协议的一些变化可能会优先考虑某些选择或优先事项。例如，可能认为可取的是找到一种更有效的方法来携带数据，比如本地交易计数器，当在交易流中可以携带更多的数据时，这可以避免使用重试过程-如图20所示，上述过程允许将PAN的最多两个数位用于交易计数器(并且两个数位的使用限制了可以提供的令牌的数量)，同时减少了保持在3个CVC2数位中的密文。一种不同的方法是只使用来自密文的CVC2字段的2个数位，而不是3个数位，而另一个数位用于保存本地交易计数器的最右侧数字。这可以通过将3个数位重新排列成不同的顺序以更动态的方式来提供-这可以通过将CVC2编码表添加到密钥列表来实现，以便当使用密钥列表时，同样由印章保护的编码表确定将被选择用于提供CVC2字段的编码。代码可以由G和V服务都已知的任何值来选择-例如，PAN的Luhn数。然后，新的密钥列表可以使用完全不同的编码表，使得该过程具有显著的动态性。
图21中表示了这种安排。PAN数字识别令牌，并提供Luhn数，并且Luhn数用于确定CVC2字段的数位的排序-在这种情况下，选择选项3，指示密文的最低有效位和次低有效位在前两个位置，计数器的最低有效位在第三个位置。这导致CVC2输出，该CVC2输出可以由G服务和V服务两者导出。
本公开的实施例中的本地交易计数器(LTC)可以用于多种功能。如上所述，LTC有助于提供交易的唯一标识符。LTC本身不是唯一的，但是当与其他值组合时-例如如上所述的节点标识符和时间段标识符，也可能是其他值，比如密钥列表标识符和PAN/TUR-它可以提供唯一标识符，特别是对于给定PAN/TUR，利用给定密钥列表使用给定节点进行的交易的唯一标识符。另外如上所述，LTC还可以用于提供从密钥列表中选择密钥，以便进行密文生成和验证的确定性手段。
除了这些功能之外，LTC可以用于跟踪与交易相关的各种活动，并且当交易字段中只能携带有限的数据时(比如上面讨论的传统用例)，LTC可以提供特别的好处。在传统情况下，如上所述，动态有效期字段用于携带与LTC相关的附加信息-动态有效期对验证过程的影响也将在下面讨论。
本地交易计数器在生成服务G和验证服务V的基本操作如下。
生成服务
LTC在服务的执行以及在生成服务G的数据库(dbG)中的服务操作的记录方面起着关键作用。该数据库用于对于使用利用keyList.Identifier识别的给定活动密钥列表的给定节点(Ni)，跟踪各个LTC值。当对于给定PAN或TUR(以下称为PAN/TUR)首次生成交易时，在数据库中创建条目。该条目只包含一个LTC值，并且当在该给定节点中，使用该给定密钥列表对于该PAN/TUR后续生成交易凭证时被更新。
这样做的过程如下。首先，为首先生成的交易凭证建立LTC的默认值，并对于所示的给定PAN/TUR在数据库(dbG)中创建条目。对于针对该PAN/TUR的交易凭证的任何后续生成，计数器将被递增，直到对于该PAN/TUR达到LTC的极限值为止。该极限值可以在密钥列表(keyList.Limit.LTC)中定义。然后，交易凭证生成服务G将停止使用该密钥列表为该PAN/TUR生成交易凭证，直到新密钥列表对于该节点变得活动为止。
验证服务
凭证验证服务(V)还使用数据库(dbV)，数据库(dbV)使用已经过验证的凭证的LTC值。该数据库存储使用利用keyList.Identifier识别的给定-活动的-密钥列表的任何给定节点(Ni)的LTC值的列表。当使用与给定节点关联的给定密钥列表，对于给定PAN/TUR首次验证交易凭证时，将创建条目。数据库(dbV)中的每个条目与LTC值列表、计数器列表(重放、加密失败和重试-所有都默认为0，并由适当的事件递增，如下所述)关联。使用与给定节点关联的给定密钥列表对该PAN/TUR的交易凭证的任何后续验证将导致更新数据库条目。在密钥列表去激活时，当使用该密钥列表生成的凭证不能再被合法验证时，数据库(dbv)的用于验证对于使用keyList.Identifier的那个密钥列表，由给定节点生成的交易凭证的那部分内容将被删除。生成器所使用的密钥列表的去激活和生成的交易凭证的用于验证器的密钥列表的去激活之间存在延迟。该延迟由商业规则驱动，例如允许在交易凭证的生成和它们的有效验证之间间隔高达24小时。
除了在交易成功时修改条目之外，如下进一步所述的加密验证过程还将更新数据库(dbV)的内容，用于其他目的：重放的检测和跟踪；加密失败的跟踪；以及跟踪重试次数。这些在申请人的欧洲专利申请No.19208139.6中进一步说明。
现在将特别关注LTC管理问题，更详细地说明验证过程。在本上下文中，验证过程涵盖以下内容：
·服务请求管理
·收集和处理交易相关数据，包括：
ο令牌(PAN/TUR)的识别
ο交易的识别(使用LTC)
ο密钥列表的识别(使用节点信息和密钥列表的标识符)
ο交易密钥和加密函数的使用
ο任何金融或其他数据的处理
·密文的验证
·交易凭证的验证
·为任何用例(L、U、D1和D2)所共有的过程
·所选用例(L、U、D1和D2)的特定过程
·向本地监控(MV)报告
如上所述，本文献的焦点只在LTC使用上，因此这里不再详细说明验证过程的其他方面。
现在讨论对于传统用例的LTC管理的特殊考虑。由于由捕捉LTC和其他数据的空间的有限可用性导致的问题，传统用例(L)明显更加复杂，如上参考图18-21所示。如上所述，传统用例(L)对可以作为交易数据的一部分携带的数据具有严格的大小限制，并且只能携带LTC值的一部分-通常为1位(C)。这意味着必须采用恢复过程来有效且可靠地恢复LTC数据。如上所述，验证过程在欧洲专利申请No.19208139.6中进一步说明。
如上所述，传统(L)用例由于缺乏可用于在交易中携带LTC数据的空间而变得复杂。一个特别的问题是动态有效期的使用及其后果，特别是管理月末的困难性，在月末，某些可以在其他时间被有效地重新利用的字段变得重要。
下面的讨论涉及在传统(L)用例中使用“动态有效期”来携带信息。通过将exp月份添加到使用tx(UTC)作为参考计算的下一个月份值(YYMM)，使用有效期字段来携带6比特值(exp)。
b6 b5 b4 b3 b2 b1 描述
x 密钥列表引用
x 重试标志
x x x x 节点标识符
样例如下：
Figure BDA0003817701970000321
Figure BDA0003817701970000331
·tX(10:30:00AM CST,星期三，2019年6月26日)＝03:30:00PM UTC,星期三，2019年6月26日
·基于tX(UTC)的下一个月份(YYMM)＝1907
·动态有效期＝1907“+”19＝2102
作为关于“L”用例的交易凭证的生成的一部分，动态有效期由G计算-这里使用它是因为PAN、有效期和CVC2是商户/PSP及其收单方可以处理的最小数据集，从而需要一些机制来携带额外的必要信息。
在大多数情况下，可以使用简单的确定性过程来可靠地提取信息。G知道与交易凭证的生成对应的时间tG。
·时间tG可以转换为UTC时区，UTC时区可作为整个系统的参考
·该转换值可以唯一地确定“下一个月份”的值；
·动态有效期是“下一个月份”与对应于如上所述的6比特信息的值的组合。
总之，对于给定的交易凭证生成，我们可以具有使用确定性过程建立的动态有效期的一个值。验证服务V遵循相同的逻辑，但是使用与交易凭证的验证相对应的时间tV作为参考。
复杂性是由在实际系统中凭证的生成和验证之间可能存在显著的时间滞后而引起的。通常的商业规则可能是在交易凭证生成后24小时内进行交易凭证的验证。
在两种情况下这可能会有问题。一种情况是tG接近月末，从而，tG和tV可能不具有“下一个月份”的相同值，导致在V在解码动态有效期时恢复无效值。这会影响节点、密钥列表引用和/或重试标志的值的识别。
另一种边缘情况是具有在生成时间之前的验证时间。我们期望在同一节点中或跨节点的G和V使用可靠的时间信息源，使这种风险降至最小。
这会导致：
1.验证过程的失败，需要使用具有“下一个月份”的调整值的另一个有效期进行重试；
2.传统情况下无效交易的虚假批准，其中我们需要匹配2(或3)位数字，以认为密文验证成功。这会影响以后的有效交易，因为它们可能被错误地报告为重放。
两种情况都是技术挑战，因为验证过程使用计数器并基于LTC值(例如LTC跟踪)来进行数据库内容的更新。在验证交易凭证时对于决策过程使用错误的信息会破坏交易的处理。
监控也会受到影响，会虚假地报告系统误用，而根本原因只是交易凭证是在月份的最后一天生成并在第二天验证的。
图22提供了在月末生成交易凭证，并在同一天或下个月的第一天进行验证的一些例子。还提供了生成是在月份的第一天完成，并且验证在同一天或第二天完成的例子。
解决这种情况的一种可能性可以是使用重试来解决该问题。如果可以依赖监控来包含任何虚假的批准问题，则这是可能的。当前的tV可以用于进行跟踪任何数据库更改的验证过程，对更改的提交(expiryDate＝STANDARD)取决于成功的密文验证。如果验证失败，则尝试备选的动态有效期并作出适当的更改，这些更改在密文验证成功时被提交(expiryDate＝SPECIAL)。然而，下面更详细说明的解决该问题的实施例使用了不同的方法。
图23示出了值列表，该值列表指示在时间tG由G定义并使用动态有效期携带的值，与在时间tV由V使用与G实际使用的值相比发生偏移(即，额外的一个月)的“下一个月”值检索的值之间的增量的影响。
当分析右侧的信息(使用由V检索的节点标识符排序)时，我们可以识别出模式：V所见的节点N0是G所见的
Figure BDA0003817701970000341
Figure BDA0003817701970000342
除外。
该信息指示解决该问题的另一种可能方式可以是将某些节点临时列入黑名单-在月份的第一天，适合于验证来自具有奇数编号i(Ni)的生成服务节点的交易的验证节点可以拒绝来自偶数编号节点的与生成服务相关的验证请求，以此类推。如果这是在路由层面处理的，则是最有效的。同样，下面详细讨论的解决方案使用了不同的方法。
然而，进一步审视可以看出除了节点0以外，密钥列表引用(KR)不受月末挑战的影响。这如图24中所示。
密钥列表需要具有有限的寿命。这对于传统用例来说是特别必要的，因为存在只能使用一个数位携带的计数器信息。这确实意味着为了重置LTC，必须发生密钥列表(及其关联的密钥列表引用)的某种轮换。
下面参考图25说明基于此的完整解决方案。图25说明了涉及围绕月末轮换密钥列表的解决方案。图25还示出了交易凭证的验证可以在它们生成之后24小时内完成。
当轮换密钥列表时，另一个密钥列表引用(KR)将被分配给该密钥列表。
当使用传统用例时，这可以看作值0和值1之间的翻转。如果我们认为密钥列表的有效寿命被设定为24小时，同时激活是在12:00:00AM(UTC时间)进行的，去激活是在11:59:59PM(UTC时间)时行的，则密钥列表引用值的翻转可以由验证过程用于判定交易凭证的生成是在同一天还是在前一天完成的。
当例如在月份的第一天进行交易凭证的验证时：
·V知道G在那天使用的活动密钥列表引用的值(比如说在上面的例子中KR＝0)。
·V知道在G的层面，在前一天使用的密钥列表(KR＝1)已经在午夜被去激活。
·按照商业规则，在G有效地生成交易凭证之后24小时内，V仍然能够验证使用密钥列表(KR＝1)生成的交易凭证。
如果我们认为对于传统用例启用的所有节点都遵循通过密钥列表引用的关联翻转，在午夜去激活的相同规则，则V可以判定是否需要调整用于恢复使用动态有效期携带的信息的时间：
·任何恢复的与生成节点的当前活动密钥列表引用相等的密钥列表引用意味着生成是与进行中的验证在同一天进行·的。
·活动密钥列表引用与在交易数据中发现的密钥列表引用之间的任何差别意味着与进行中的验证相比，生成是在前一天完成的。
如果验证是在月份的第一天完成的，则：
ο调整“下一个月”值，以从密钥列表恢复准确的信息(包括节点信息和重试标志)。
ο使用SetValidationOutcome(expiryDate＝SPECIAL)而不是SetValidationOutcome(expiryDate＝STANDARD)
节点0需要定制的过程，因为在使用错误的“下一个月”值之后，恢复的密钥列表引用可能被破坏。为了避免任何这样的复杂过程，在使用传统用例时，实际上可能最简单的是排除节点0的使用。
技术人员会意识到，上面说明的实施例是示例性的，根据上面陈述的原理和例子，技术人员可以得出落入本公开的精神和范围内的其他实施例。

Claims (21)

1.一种使用数据字段传递与事件相关的信息的方法，所述方法包括：
获得与所述事件相关的信息的一个或多个元素，并使用信息的所述一个或多个元素确定所述事件的加密记录；
将每个所述元素中的一些或全部与和事件的记录关联的时间信息相组合，以填充数据字段中的第一组位置，并使用所述加密记录填充数据记录中的第二组位置；
传递包括所述数据字段的消息，其中接收所述消息能够使用所述时间信息来恢复所述一个或多个元素，并且能够通过从恢复的元素重新计算所述加密记录，并将重新计算的加密记录与从所述数据字段恢复的加密记录进行匹配，来验证元素被正确地恢复。
2.按照权利要求1所述的方法，其中所述事件是服务实例。
3.按照权利要求2所述的方法，其中所述事件是交易记录或交易凭证的生成。
4.按照权利要求3所述的方法，其中所述元素包括交易计数器。
5.按照权利要求3或4所述的方法，其中所述元素包括随机数或不可预测数。
6.按照权利要求3或4所述的方法，其中所述元素包括密钥标识符。
7.按照权利要求6所述的方法，其中使密钥标识符的变更与时间信息的变更同步。
8.按照权利要求6或7所述的方法，其中由所述密钥标识符识别的密钥用于计算所述加密记录。
9.按照任意前述权利要求所述的方法，其中第一组位置还包括用于时间信息的识别的一个或多个校验位。
10.一种使用数据字段获得与事件相关的信息的方法，所述方法包括：
接收与事件相关的消息，其中所述消息包括数据字段；
将所述数据字段分解为包含组合的交易元素的第一组位置和包含所述事件的加密记录的第二组位置；
确定与所述事件的所述记录关联的时间信息，并使用所述时间信息来建立与所述事件相关的信息的全部或部分元素，所述信息的全部或部分元素已经与所述时间信息组合以填充所述数据字段中的第一组位置；
从与所述事件相关的信息的任何部分元素建立与所述事件相关的信息的全部元素；以及
从与所述事件相关的信息的元素计算加密记录数据，并通过将计算的加密记录数据与来自所述数据字段中的第二组位置的加密记录进行匹配来确定与所述事件相关的信息的元素是正确的。
11.按照权利要求10所述的方法，其中所述事件是服务实例。
12.按照权利要求11所述的方法，其中所述事件是交易记录或交易凭证的生成，所述方法还包括在获得与所述事件相关的信息之后验证所述交易记录或交易凭证。
13.按照权利要求12所述的方法，其中所述元素包括交易计数器。
14.按照权利要求12或13所述的方法，其中所述元素包括随机数或不可预测数。
15.按照权利要求12或13所述的方法，其中所述元素包括密钥标识符。
16.按照权利要求15所述的方法，其中使密钥标识符的变更与时间信息的变更同步。
17.按照权利要求15或16所述的方法，其中由所述密钥标识符识别的密钥用于计算所述加密记录。
18.按照权利要求10-17任意之一所述的方法，其中从与所述事件相关的信息的任何部分元素建立与所述事件相关的信息的全部元素包括计算加密记录数据，并将计算的加密记录数据与来自所述数据字段中的第二组位置的加密记录进行匹配，以及如果没有匹配，则改变时间信息，并使用改变的时间信息从与所述事件相关的信息的任何部分元素重新建立与所述事件相关的信息的全部元素。
19.按照权利要求10-17任意之一所述的方法，其中第一组位置还包括用于时间信息的识别的一个或多个校验位，并且所述一个或多个校验位用于在建立信息的全部或部分元素之前建立正确的时间信息。
20.按照权利要求18或19所述的方法，其中从与所述事件相关的信息的任何部分元素建立与所述事件相关的信息的全部元素包括计算加密记录数据，并将计算的加密记录数据与来自所述数据字段中的第二组位置的加密记录进行匹配，以及如果没有匹配，则改变所述元素之一，并按照预定计划重新计算和重新匹配所述加密记录数据，直到存在成功匹配。
21.一种适合于进行按照权利要求1-9任意之一所述的方法，或者按照权利要求10-20任意之一所述的方法的计算节点。
CN202180017279.2A 2020-02-26 2021-02-17 受限数据通道中的敏感数据的通信 Pending CN115191102A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20159634.3A EP3872733A1 (en) 2020-02-26 2020-02-26 Communication of sensitive data in restricted data channel
EP20159634.3 2020-02-26
PCT/US2021/018344 WO2021173396A1 (en) 2020-02-26 2021-02-17 Communication of sensitive data in restricted data channel

Publications (1)

Publication Number Publication Date
CN115191102A true CN115191102A (zh) 2022-10-14

Family

ID=69742668

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180017279.2A Pending CN115191102A (zh) 2020-02-26 2021-02-17 受限数据通道中的敏感数据的通信

Country Status (4)

Country Link
US (1) US20230164122A1 (zh)
EP (1) EP3872733A1 (zh)
CN (1) CN115191102A (zh)
WO (1) WO2021173396A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4175216A1 (en) * 2021-10-26 2023-05-03 Mastercard International Incorporated Data communication and cryptographic operations using a restricted data channel
GB2612349A (en) * 2021-10-29 2023-05-03 Mastercard International Inc Transaction key generation

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5434919A (en) * 1994-01-11 1995-07-18 Chaum; David Compact endorsement signature systems
US6038549A (en) * 1997-12-22 2000-03-14 Motorola Inc Portable 1-way wireless financial messaging unit
US7027773B1 (en) * 1999-05-28 2006-04-11 Afx Technology Group International, Inc. On/off keying node-to-node messaging transceiver network with dynamic routing and configuring
US7784684B2 (en) * 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US10304047B2 (en) * 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US9774401B1 (en) * 2013-07-15 2017-09-26 Paul Borrill Entangled links, transactions and trees for distributed computing systems
AU2015231418A1 (en) * 2014-03-18 2016-09-29 Visa International Service Association Systems and methods for locally derived tokens
GB201423362D0 (en) * 2014-12-30 2015-02-11 Mastercard International Inc Trusted execution enviroment (TEE) based payment application

Also Published As

Publication number Publication date
EP3872733A1 (en) 2021-09-01
US20230164122A1 (en) 2023-05-25
WO2021173396A1 (en) 2021-09-02

Similar Documents

Publication Publication Date Title
US10909522B2 (en) Cloud-based transactions methods and systems
US20220019995A1 (en) Limited-use keys and cryptograms
US11997190B2 (en) Credential management in distributed computing system
US20240305442A1 (en) Data management and encryption in a distributed computing system
CN115191102A (zh) 受限数据通道中的敏感数据的通信
EP4205347A1 (en) Data management and encryption in a distributed computing system
US20220329409A1 (en) Event management in distributed computing system
EP3748525B1 (en) Credential management in distributed computing system
EP4175216A1 (en) Data communication and cryptographic operations using a restricted data channel
US20200167767A1 (en) Security and authentication of interaction data
RU2796046C1 (ru) Управление учетными данными в распределенной вычислительной системе
EP4432141A1 (en) Credential management in a decentralized heterogeneous transaction system
EP4432199A1 (en) Cryptographic service delivery in a decentralized transaction system
EP3819766A1 (en) Event management in distributed computing system
WO2023075950A1 (en) Transaction key generation
WO2024025706A1 (en) Method and system for payment processing using distributed digitized surrogates

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