Cryptographic service provision

Abstract

A method at a compute node for providing secure services for requesters external to the compute node is described. This computing node is a computing node suitable for providing security services among a plurality of computing nodes in a distributed computing system. The method includes the following steps performed at a compute node. A service request is received from a requester, wherein the service request includes a request to generate credentials. The credential is then generated using a cryptographic key and an instance counter, where the cryptographic key is determined from a currently active key list of cryptographic keys used by the computing node, where the key list is alternated at a predetermined alternation frequency to provide a new currently active key list, and wherein the instance counter is determined by the number of instances executing the service within the predetermined time window. The credential is provided such that a key list reference and an instance counter value can be determined from the credential without decryption. However, the credentials also include key list enhancements such that the key list enhancements are used to prevent conflicts between credentials having a common key list reference and a common instance counter value. A supplemental method of verifying such credentials is also described, as well as a computing device adapted to perform such a method.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of European Patent Application No. 23164771.0, filed on 28 March 2023, the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0003] This disclosure relates to the provision of cryptographic services. Background Technology

[0004] Demanding that a centralized system serve a very large number of clients presents numerous technical challenges, especially when these clients are geographically dispersed. It is logical to consider a distributed system where the relevant services can be provided by a set of geographically distributed servers, rather than by a central server or data center.

[0005] This decentralization can utilize any suitable architecture that delivers services to clients using geographically distributed servers—or data centers (this could be a public cloud, a private cloud, or a simple private distributed system). The architecture can be viewed as comprising multiple nodes—when using such a distributed architecture, a node can be an aggregation of multiple computers, and can cover more than one data center with “real-time” connectivity and data sharing within a given node.

[0006] Decentralization itself can be problematic, especially when different service instances need to be related to each other in some way—for example, if a service needs to establish details of how a service was executed in the past. This might require, for example, other clients (or other system nodes) to trace back to the service-providing node, or otherwise understand how the service-providing node executed the service. In transaction systems—where credentials are typically generated during transaction authorization and then verified—credential verification will often require this information related to credential generation. WO2020 / 247092A1 teaches a method to address many of these problems by using a periodically rotating list of keys to generate and verify credentials, and using a transaction counter associated with the credential generation process to identify transactions.

[0007] The methods taught in WO2020 / 247092A1 prevent an explosive growth in messaging and overall infrastructure demands as transaction volume increases. However, many practical challenges remain, particularly in ensuring that cryptographic services are fed the right data at the right time to perform as intended. One such challenge is ensuring that all generated credentials can be verified if appropriate verification conditions exist. To prevent increased system demands, it is necessary to reuse references to the key list and transaction counters (typically reset after a period of time), but this also carries the risk of reusing specific references to the key list and its associated unique key list in such a way that they can have different valid meanings from the perspective of the entity responsible for generation compared to the entity responsible for verification, which then uses the reference as a means of identifying the key list to be used, potentially affecting credential verification. Addressing this issue would be desirable. Summary of the Invention

[0008] In a first aspect, this disclosure provides a method for providing security services at a computing node to a requester outside the computing node, wherein the computing node is one of a plurality of computing nodes in a distributed computing system suitable for providing security services. The method includes, at the computing node: receiving a service request from the requester, wherein the service request includes a request to generate credentials; generating credentials using a cryptographic key and an instance counter, wherein the cryptographic key is determined from a currently active key list of cryptographic keys used by the computing node, wherein the key list is rotated at a predetermined rotation frequency to provide a new currently active key list, and wherein the instance counter is determined by the number of instances performing the service within a predetermined time window; wherein the credentials are provided such that a key list reference and an instance counter value can be determined from the credentials without decryption; and wherein the credentials further include key list enhancements such that the key list enhancements are used to prevent conflicts between credentials having a shared key list reference and a shared instance counter value.

[0009] In a second aspect, this disclosure provides a method for providing security services at a computing node to a requester outside the computing node, wherein the computing node is one of a plurality of computing nodes suitable for providing security services. The method includes, at the computing node: receiving a service request from the requester, wherein the service request includes a request to verify credentials, wherein the credentials have been generated by one of the plurality of computing nodes using a cryptographic key and an instance counter, wherein the cryptographic key has been determined from a currently active key list of the cryptographic key used by the generating computing node, wherein the key list is rotated at a predetermined rotation frequency to provide a new currently active key list, and wherein the instance counter is determined by the number of instances performing a credential generation service at the generating computing node within a predetermined time window; wherein the credentials are provided such that a key list reference and an instance counter value can be determined from the credentials without decryption, and wherein the credentials also include key list enhancements to prevent conflicts between credentials having a shared key list reference and a shared instance counter value; determining, at least from the key list reference and key list enhancements, whether the verification of the credentials is reasonable, and if reasonable, then attempting to verify the credentials.

[0010] Using key list enhancement in the indicated manner allows for the efficient management of the problem of mismatches between generated and verified results caused by repeated key list references, and in most contexts, eliminates the problem for practical purposes.

[0011] The following features apply to the first and second aspects of this disclosure.

[0012] In one embodiment, key list enhancement provides an extension to key list references, thereby extending the time during which key list references are repeated when rotated at a predetermined rotation frequency.

[0013] In an embodiment, key list enhancement may include additional fields to check whether the key list reference is related to the use of the relevant key list currently available for verification. If related, the key list enhancement may include time, such as an indication of the month in which the credential was generated, or possibly an indication of the week in which the credential was generated. The predetermined rotation frequency of the key list reference may be weekly.

[0014] In a third aspect, this disclosure provides a computing device suitable for acting as a computing node providing security services, the computing device including a processor, a memory, and components for communicating over a network, wherein the memory includes instructions for programming the processor to perform the methods of the first or second aspect using the components for communicating over a network.

[0015] In an embodiment, the computing device is adapted to perform both the first and second aspects of the method.

[0016] In the fourth aspect, a distributed computing system includes multiple instances of computing devices according to the third aspect, each such computing device acting as a computing node for providing security services as part of the distributed computing system. Attached Figure Description

[0017] Specific embodiments of the present disclosure will now be described by way of example with reference to the accompanying drawings, in which:

[0018] Figure 1 This shows multiple clients interacting with the central server;

[0019] Figure 2 It shows and provides with Figure 1 The central server is a distributed computing architecture that provides the same services to multiple clients interacting with each other.

[0020] Figure 3 It shows things like Figure 2 The diagram illustrates the operation of a distributed system, where distributed nodes provide cryptographic services involving the creation and verification of proofs using a limited number of cryptographic keys, and also illustrates potential problems related to key list referencing.

[0021] Figure 4 The embodiments of the present disclosure are shown for... Figure 3 Solutions to the potential problems indicated in the document;

[0022] Figure 5 This schematically illustrates a distributed transaction architecture using a four-party model;

[0023] Figure 6 The diagram illustrates what is suitable for implementation. Figure 5 The elements of a complex distributed system in terms of transaction architecture;

[0024] Figure 7 The illustration schematically shows the means to enable Figure 5 and Figure 6 An exemplary system for implementing digital transactions within a transaction architecture;

[0025] Figure 8 The diagram illustrates the layout of a distributed system for digital enablement of transactions.

[0026] Figure 9 A more detailed illustration is provided. Figure 8 The arrangement of computational nodes;

[0027] Figure 10 The diagram shows... Figure 9 Elements within a compute node;

[0028] Figure 11 Instructions and Figure 9The transaction process related to the operations performed by the node;

[0029] Figure 12 Instructions in Figures 9 to 11 Tokenization is used in the implementation of the arrangement;

[0030] Figure 13 Instructions in Figures 8 to 12 The key management method used in the layout;

[0031] Figure 14 An exemplary method for transaction identification is illustrated;

[0032] Figure 15 The diagram shows... Figures 8 to 14 A set of exemplary cryptographic mechanisms used for digital transactions in the setup;

[0033] Figure 16 The illustration shows a diagram with the following features: Figure 13 The global model of key management for each of the various modes shown in the diagram;

[0034] Figure 17 The diagram illustrates the relationship with Figure 13 and Figure 16 The key management model is associated with a global monitoring model;

[0035] Figure 18 The diagram illustrates the UCAF format (UCAF format 6), which is particularly suitable for credential communication, used to communicate with... Figure 9 The exemplary nodes of the type shown herein conduct certain forms of digital transactions;

[0036] Figure 19 Different routes that digital transactions may take are illustrated, and context is provided for embodiments of this disclosure;

[0037] Figure 20 A UCAF format (UCAF format 5) is provided for communication of credentials, which is used to communicate with... Figure 9 The exemplary nodes of the type shown herein conduct certain forms of digital transactions;

[0038] Figure 21 It is used as a diagram. Figure 20 The table provided by the UCAF format code;

[0039] Figure 22 and 23 The illustration shows that in Figure 20 The alternative headers used in embodiments of this disclosure in the UCAF format are used for the plaintext and encrypted body portions of UCAF, respectively.

[0040] Figure 24 and 25The diagrams illustrate the copying of UCAF format 0 and 0+ respectively. Figure 20 The plaintext and encrypted body portions of embodiments of this disclosure in UCAF format;

[0041] Figure 26 and 27 The diagrams illustrate the copying of UCAF formats 3 and 3+. Figure 20 The plaintext and encrypted body portions of embodiments of this disclosure in UCAF format;

[0042] Figure 28 and 29 The diagrams illustrate the original UCAF format 5. Figure 20 The plaintext and encrypted body portions of embodiments of this disclosure in UCAF format;

[0043] Figure 30 Summary of Figure 9 Issues related to key list rotation and counter management for nodes of the type shown;

[0044] Figure 31 Indication in UCAF format 6 Figure 30 The problem, and Figure 32 Instructions are provided for solutions based on embodiments of this disclosure;

[0045] Figure 33 Indication in UCAF format 6 Figure 30 The problem, and Figure 34 Instructions are provided for solutions based on embodiments of this disclosure. Detailed Implementation

[0046] Generally speaking, the context of this disclosure is... Figures 1 to 3 The diagram is shown in the image. Figure 1 This illustrates a centralized system that performs functions in response to requests from a large number of geographically distributed entities. This places heavy demands on the centralized system in terms of processing power, storage, and messaging, often resulting in significant system load due to bottlenecks and messaging requirements. In addition to network latency issues caused by travel time, other problems arise when requests originate from geographically distant requesters communicating with the centralized system.

[0047] Figure 2An alternative arrangement is illustrated, in which the role of the central system is replicated, with the same functionality performed by a set of distributed nodes, each capable of performing some or all of the functions provided by the central system. Individual nodes should see significantly lower demand than the central system, and network latency is potentially reduced because entities should be able to interact with more local nodes than the central system. However, as discussed generally above and in the specific context of transaction processing systems below, realizing this benefit presents significant technical challenges—in particular, with direct replication, all the same information needs to be distributed to all nodes replicating the centralized system, often making the overall situation worse rather than better.

[0048] There are particular difficulties when a second user of the system needs to be certain that the action taken by the first user is legitimate. Figure 1 In this case, it's relatively simple—because the service is executed centrally, and the central system has all the information, there usually won't be a problem if the user trusts the central system. Figure 2 In a scenario where a first user might be interacting with one node and a second user might be interacting with another node, the same level of confidence cannot be achieved unless all necessary information is consistently and properly synchronized across all nodes (which would cause the decomposition points to fail when replicating a centralized system). If the product of the first service performed by the first user is valuable information—such as proof of payment made by the first user that will be used by the second user to complete the transaction—then the risk of system failure or compromise due to, for example, multiple second users using proofs at multiple nodes to complete the relevant transaction needs to be addressed.

[0049] Generally speaking, Figure 3 This scenario is illustrated below. First user 51 requests execution of first service 53—in this case, creating credentials, proof of an event such as a payment from a specific account—and second user 52 requests verification from second service 54 by verifying the proof of that event, for example, to determine if a payment was validly made. First user 51 has already invoked first service 53 at first node 55. Second user typically cannot choose where to invoke second service 54—this could be due to geographical or other administrative factors—specifically, it might not be possible to invoke second service 54 at first node 55 (although this is a possibility). In practice, second service 54 will then be invoked at another node 56a, 56b, 56c with sufficient information to implement the verification process. Here, this involves a shared set of access cryptographic keys (key list 57) and a minimal set of information required to regenerate proof or otherwise determine that the proof is correct, including instance counter 58.

[0050] For such a system to operate reliably and securely, it is necessary to address the scenario where such proof, or an object claiming to be such proof, is provided to one or more secondary services at one or more nodes. To prevent key proliferation (which would also lead to message proliferation, causing the system to fail), a finite number of key list references 57 are used, and available keys are rotated periodically. This means that key list reference 57 becomes valid, then invalidates for a prolonged period, and then becomes valid again. To prevent multiple verification attempts, an instance counter 58 is used—during a verification attempt, the instance counter value is captured, and this value is used to prevent further attempts to verify the "instance" successfully.

[0051] This can lead to Figure 3 The following is an incorrect result in the scenario shown. If verification occurs during the normal usage period of the key list retrieved using the key list reference, as shown at the first verification node 56a, then the relevant key in the key list is used and the associated instance counter is marked as used—this is the normal operating state of the system. Later, as shown at the second verification node 56b, the key list value will be different, and the verification process will fail before instance counter 58 is considered—this is also the normal operating state of the system. However, the third verification node attempts verification at a later time, when successive key list rotations mean that the same key list reference used initially becomes a valid reference to the key list again. In this case, the verification process will eventually fail, but at a later stage of the verification process and the instance counter value will be marked as used at this time. This is not a problem for the current verification attempt (it should fail, and it does), but it is problematic for the "current" generation process, which has the same instance counter value as the "old" credential used for verification. Verification of the "current" credential should succeed, but will actually fail because the instance counter value has already been marked as used when attempting to verify the "old" credential.

[0052] This disclosure teaches a solution to this problem, such as Figure 4As shown in the diagram. This solution involves providing a key list enhancement 59 to significantly reduce or eliminate the risk that the instance counter value of a newly verified credential might be incorrectly marked as "used" due to attempts to verify "old" credentials using the same key list. One type of key list enhancement 59 could be providing additional message space to allow for a significantly longer repetition time between references to the same key list, thus significantly reducing the risk as the likelihood of attempting to verify "old" credentials decreases significantly over time. Another type of key list enhancement 59 could be a check factor (an additional factor that must be checked before marking an instance counter value as "used"), for example, this could be the date or a portion of the date (such as the month). This check factor further reduces the likelihood of problematic conflicts, or even eliminates them entirely.

[0053] This issue is particularly relevant to transaction processing systems, especially those used to process digital transactions. The volume of digital transactions is growing extremely rapidly, requiring them to be executed reliably and quickly. Support for these transactions can be provided by transaction processing systems developed for device-based payments using payment cards, and using the protocols of such payment systems, but these transactions actually have different characteristics from device-based transactions. This will be discussed below, first referring to the general elements of a transaction processing system, and then discussing in more detail the infrastructure used to support digital transactions.

[0054] Figure 5 This is a block diagram of a typical four-party model or four-party payment transaction scheme. The diagram illustrates the entities existing in the model and the interactions that occur between the entities operating in the card scheme.

[0055] Typically, card schemes—payment networks linked to payment cards—are based on one of two models: a three-party model or a four-party model (adopted by the applicant). For the purposes of this document, the four-party model is described in more detail below.

[0056] The four-party model can be used as the basis for a transaction network. For each transaction, the model includes four entity types: cardholder 110, merchant 120, issuer 130, and acquirer 140. In this model, cardholder 110 purchases goods or services from merchant 120. Issuer 130 is the bank or any other financial institution that issues the card to cardholder 110. Acquiring party 140 provides services for card processing to merchant 120.

[0057] The model also includes a central switch 150—interactions between issuer 130 and acquirer 140 are routed via switch 150. Switch 150 enables a merchant 120 associated with a particular bank acquirer 140 to accept payment transactions from cardholders 110 associated with different bank issuers 130.

[0058] In a four-party model, a typical transaction between entities can be divided into two main phases: authorization and settlement. Cardholder 110 initiates a purchase of goods or services from merchant 120 using their card. Card and transaction details are sent to issuer 130 via acquirer 140 and exchange 150 to authorize the transaction. Cardholder 110 may have already provided verification information in the transaction and, in some cases, may need to undergo additional verification processing to verify their identity (such as 3D security in the case of online transactions). Once the additional verification processing is complete, the transaction is authorized.

[0059] After the transaction between cardholder 110 and merchant 120 is completed, merchant 120 submits the transaction details to acquirer 140 for settlement.

[0060] The transaction details are then routed from the acquiring party 140 to the relevant issuing party 130 via the switch 150. Upon receiving these transaction details, the issuing party 130 provides settlement funds to the switch 150, which then forwards these funds to the merchant 120 via the acquiring party 140.

[0061] Individually, the issuer 130 and the cardholder 110 settle payment amounts between themselves. In return, the merchant 120 pays a service fee to the acquiring party 140 for each transaction, and the acquiring party 140 pays an interchange fee to the issuer 130 in exchange for fund settlement.

[0062] In practical implementations of the four-party system model, the role of a particular party may involve multiple elements working together. This is often the case in implementations that have evolved beyond contact-based interactions between customer cards and merchant terminals to digital implementations using agents or virtual cards on user computing devices such as smartphones.

[0063] Figure 6 An architecture suitable for interaction between cardholders and merchants, according to embodiments of the present disclosure, is illustrated. The figure shows a general architecture for reference, but specifically illustrates elements of the architecture used when a cardholder conducts an online transaction with a merchant server.

[0064] For regular transactions, the cardholder will use their payment card 6—or a mobile computing device such as a smartphone 11 suitable for use as a contactless payment device—to transact with the merchant 2's POS terminal 7. However, in embodiments relevant to this disclosure, the cardholder will use his or her computing device—which can be any or all of a cellular phone, tablet, laptop, stationary PC, or any other suitable computing device (a mobile phone or smartphone 11 is shown here)—and may also use other computing devices (such as a smartwatch or other wearable device)—to act as an agent for the physical payment card 6 or as a virtual payment card operating only in the digital domain. As described below, the smartphone 11 can achieve this through mobile payment applications and digital wallets. The smartphone 11 can use it to transact with the merchant's POS terminal 7 using NFC or other contactless technologies, or to make payments in association with its wallet service as discussed below. However, embodiments of this disclosure are particularly concerned with online transactions with merchants, rather than contact or contactless transactions with the merchant's POS terminal 7. In order to conduct online transactions, the smartphone 11 is also able to interact with the merchant server 12 representing the merchant 2 via any suitable network connection (such as the public Internet) – the connection to the merchant can be provided by an app or application on the computing device.

[0065] The transaction infrastructure (transaction infrastructure) 5 here provides not only the computing infrastructure required for the card scheme and transaction routing and other messaging to parties such as acquirer 3 and issuer 4, but also a wallet service 17 supporting digital wallets on the cardholder's computing device, and an internet gateway 18 to accept internet-based transactions for processing by the transaction infrastructure. In other embodiments, the wallet service 17 may be similarly provided by a third party with an appropriate trust relationship with the transaction scheme provider. To support tokenization, there is a token service provider 19 (again, this is shown as part of the transaction infrastructure 5, but may be provided by a third party with an appropriate trust relationship), and the transaction infrastructure provides digital enabling services 16 to support the execution of tokenized digital transactions and to interact with other elements of the system to allow transactions to be executed correctly—such digital enabling services may include other elements such as token service provisioning.

[0066] For tokenized transactions, the transaction is verified within the transaction scheme by mapping the cardholder's token to their card PAN, checking the token's status (to ensure it is valid or otherwise effective), and using any customer verification methods employed. This allows the issuer to authorize transactions in a normal manner.

[0067] Figure 7The elements of the transaction infrastructure supporting digital payments from mobile devices are illustrated in more detail. The diagram shows the applicant's Mastercard Cloud Based Payment (MCBP) architecture as a specific example—this is exemplary and not specific to this disclosure—and illustrates how this architecture can be used to support a mobile payment application 215 on a mobile device, such as smartphone 11—here, mobile payment application 215 is shown as being contained within a wallet application or digital wallet 41. Such a digital wallet 41 can communicate with a wallet server 17 to allow management of the mobile payment application, and it can also be used to request the digitization of payment card 6 used by mobile device 11.

[0068] Mastercard Digital Enablement Service (MDES) 42 performs various functions to support mobile payments and digital transactions. As mentioned above, MDES 42 is merely exemplary—other embodiments may use digitization, tokenization, and provisioning services associated with other transaction processing infrastructure. Wallet server 17 is not part of MDES 42—and is not required if, for example, mobile payment application 215 is not embedded within digital wallet 41—but rather acts as an interface between mobile device 11 and MDES 42. MDES 42 also mediates tokenized transactions, allowing them to be processed through transaction schemes like regular card transactions. The following functional elements are shown within MDES 42: Account Enablement System (AES) 43, Credential Management System (CMS) 44, Token Vault 45, and Transaction Management System (TMS) 46. These will be briefly described below.

[0069] The Account Enablement System (AES) 43 is used for card digitization and user creation. It will interact with the mobile payment application (here via wallet server 17) to make card digitization requests, and it will populate the token treasury 45 during tokenization and interact with the CMS 44 to create a card profile with associated keys for the digitization of the card.

[0070] The Credential Management System (CMS) 44 supports the management of cardholder credentials and is the key system within the MDES 42. The core system 441 manages synchronization with the entire transaction system through interaction with the TMS 46 and manages the channel to the AES 43. The dedicated system 442 provides the necessary elements (such as digital cards, credentials, and keys) to the mobile payment application in the form required by the application. This system can also interact with the wallet server 17 to manage the mobile payment application.

[0071] The token store 45—shown here as being within MDES 42, but which can be a separate element under separate control—is a repository for token information, including the mapping between tokens and associated cards. When processing tokenized transactions, MDES 42 references the token store 45, and the tokenization of a card results in the creation of a new entry in the token store 45.

[0072] The Transaction Management System (TMS) 46 is used when processing tokenized transactions. If the transaction scheme recognizes a transaction as tokenized, the transaction is routed to the TMS 46, which detoxifies the transaction using a token store 45. The detoxified transaction is then routed to the issuer (represented here by the Financial Authorization System 47) for authorization in the usual manner. The TMS 46 also interacts with the CMS 44 to ensure synchronization with cardholder accounts and credentials.

[0073] The applicant's earlier European patent application No. 19178579.9 describes the implementation for performing, as Figure 7 The methods for various aspects of the digital transaction system shown—particularly enabling decentralized management of credentials—are incorporated herein by reference to the extent permitted by applicable law. This is accomplished by replacing the central node with a set of decentralized nodes, each capable of credential management, such as… Figures 8 to 10 As shown in the diagram. This architecture is referred to below as NODES (Distributed E-commerce Security Network).

[0074] Figure 8 A decentralized system of compute nodes Nx is illustrated, each capable of generating G and validating V credentials. These credentials are valid throughout the system (unless limited to certain nodes due to on-soil regulation, etc.) and in this case associated with transactions from a set of users (clients), whose transactions are typically routed to that node based on geographical proximity. Nodes provide credential generation G and credential verification V as services to clients, and they need to be able to securely generate credentials and at least securely verify them while they are valid. In the illustrated architecture, credentials are not stored—they are generated on request and verified on the fly. Figure 8 and Figure 9 As shown, besides credential generation and verification, key management (K) and monitoring (M) can be viewed as services both locally on the node and across the system, and typically require access control (AC) to allow access to these services. These aspects will be described in more detail below.

[0075] Figure 10The elements of a suitable computing node are shown. Node 80 includes at least one network connection 81 to allow communication with client 90 and other nodes 91, as well as (in this example) the central node 91a. Communication is shown here as being via separate networks to each group of other parties—via a first network cloud 92 for connecting to clients and a second network cloud 92a for connecting to other nodes within the distributed system. This reflects that these networks can be physically different, or they can have different security requirements and protocols.

[0076] Node 80 comprises multiple conventional servers 83 (which will contain their own processors and memory—not shown—as well as other components typically found in servers) and a memory 84 containing a central database. Node 80 also includes multiple hardware security modules 85 (HSMs) adapted to hold cryptographic material in the form of keys required to perform cryptographic functions and to securely execute cryptographic functions. The elements within node 80 are shown communicating via a bus 86. While node 80 is represented as a single data center in this context, this is not necessary—the “bus” could, for example, include a dedicated network connection between a group of related data centers, allowing this group of related data centers to provide real-time responses, making them appear to other entities communicating with the node as part of an integrated whole.

[0077] Existing credential management processes in payment systems are centralized—any request to create or verify a credential results in a query to the centralized system. For payment systems implementing the EMV standard, credentials are generated using keys derived from a hierarchical process. An issuer master key (IMK) is associated with a specific range of tokens, and the keys used for credentials are derived hierarchically (the card master key (CMK) comes from the IMK, and then the session key (SK) comes from the CMK). This approach is used for devices (such as physical cards) but also for digital transactions. The number of digital transactions is growing much more rapidly than device-based interactions, where this growth is more aligned with available resources.

[0078] In the digital ecosystem, while there is a very rapidly growing demand, there is also often a more secure environment because interactions are typically conducted between merchant systems (or payment service providers) and transaction systems via secure pathways between clearly identified participants. Therefore, when all assets are kept securely within a restricted environment that includes key management and cryptographic operations, and when services are provided in a server context when exposing access APIs, there are interactions that can require multiple cryptographic operations for security within the device context that can be pipelined.

[0079] While scaling trading systems for executing digital EMV transactions by using a set of distributed servers to generate and verify credentials seems desirable, this approach has been found to be unscalable. The overall level of key generation remains unchanged, but the amount of messaging within the system increases dramatically due to the need to manage and replicate a very large number of tokens. Because existing EMV key generation methods require custom rather than off-the-shelf hardware security modules (HSMs), processing requirements are high and costs are exorbitant, and data storage (especially network latency) becomes unmanageable.

[0080] This distributed approach is supported by allowing the allocation of the first available key from the key stack to tokenized transactions by replacing the token binding with a key derived from a specific hierarchy. This approach, using flexible and dynamic key management, allows for scalable solutions. Monitoring can be performed to ensure the security of the distributed architecture without requiring the transmission or duplication of large amounts of sensitive information. This approach can also be implemented in standard HSMs using fully FIPS-compliant processes (e.g., without the need for DES and 3DES). This approach is described in more detail below.

[0081] Currently, the device security model is also being used by the applicant for fully digital transactions. This security model involves the issuer's master key (IMK) stored in the transaction system HSM and used to derive the card master key (CMK) from the associated IMK and card PAN (primary account). These CMKs are then stored in the device (typically a secure element or alternative technology). When generating transaction credentials using a software-based solution with a mobile device, the associated CMK and card / device ATC (Application Transaction Counter) are used to generate the session key (SK)—this is currently handled by, for example... Figure 7 The credential management system (CMS) shown is used for generation. Currently, all tokens, even for fully digital transactions, are bound to this IMK / CMK / SK export. This also applies to transaction credentials generated by the server through the API exposed by the transaction system for remote payment transactions.

[0082] This method requires a very heavy key management workload, which is not suitable for fully digital transactions, as shown in the reference below. Figure 11 and Figure 12 The generation of SKs and the subsequent application of cryptography (AC—the standard mechanism in EMV transactions) require multiple cryptographic operations, not all of which can be performed by a regular, off-the-shelf HSM, thus necessitating a custom HSM. This requires the large-scale distribution of keys throughout the system to support transaction execution wherever it occurs, and ATC management is complex. The desired outcome is to use a standard HSM, avoid extensive key duplication, ensure direct key availability, and provide a solution that limits the overall number of HSMs (as they typically only support a few thousand keys).

[0083] Much of this security is provided through appropriate preventative mechanisms, even when the system endpoint (e.g., at the cardholder's device) is potentially vulnerable to attack. Beyond this, the role of security is limited, such as... Figure 11 As shown in the diagram. The primary purpose of cryptographic functions is to provide guarantees—covering both authentication and data integrity. Transaction-related data protected by cryptographic data includes the transaction's identifier and associated token, as well as instructions for any cryptographic processing used and any related financial data (and any other aspects of the transaction requiring guarantees). This is represented by transaction credentials—which require the generation of G and subsequent verification of V, processes monitored by M to ensure overall system integrity and supported by some kind of key management system K. This disclosure relates to methods for monitoring that effectively address the consequences of erroneous or malicious actions through appropriate detection, messaging, and responses—as will be described—which occur largely separately from the actual execution of the transaction.

[0084] In the case of fully digital transactions, these processes occur in constrained environments where endpoint security is not an issue as much as device security. For example, from... Figure 12 As can be seen, in this domain, the token does not reach either endpoint of the regular transaction management system—the cardholder or the issuer. Instead, it operates across merchant systems or payment service providers (PSPs) and transaction solution providers.

[0085] This approach allows the credentialing system to be distributed from a complex central server to multiple nodes providing services. These nodes will typically be geographically distributed but may extend to multiple data centers (e.g., by using cloud infrastructure to enable data sharing within nodes). These nodes provide services—related to credentials, generation service G, and verification service V—along with defined rules for access control of those services. Merchants or PSPs communicate with generation service G to obtain credentials, which are then used in standard authorization processes performed through the payment system's payment network, invoking verification service V when credentials need to be verified. These services have access to the nodes' computing infrastructure (HSM, database). Monitoring service M and key management service K are also provided—these services can be centrally organized or include a hybrid of central and local functions.

[0086] In the discussion above, it was assumed that a node simultaneously has a generation service G and a verification service V—but this is not the case. Figure 7 The arrangement shown illustrates either a node that provides only generation services or only verification services. Both arrangements are likely to occur.

[0087] Access control to services can be provided in a largely conventional manner. A set of general controls can be defined for nodes and can be modified locally—for example, to meet local regulatory or other specific security requirements. This approach makes it easy to implement localization strategies, such as by restricting all business in a particular country to a specific set of nodes, or by taking other region- or market-specific actions. Access control can be enforced at more than one level (e.g., for individual services but also for nodes), and specific rules or checks can exist for specific service types. Access control can be potentially very granular and can provide specific solutions in a variety of ways—for example, it can be used to allow a given merchant to perform a maximum number of transaction credential generation operations during a defined time period for a given token.

[0088] Figure 13 The key management mechanism illustrated here demonstrates how a limited number of keys can be allocated to nodes, while providing deterministic processing for selecting the key used to generate credentials. The verification entity can use the same processing to determine the key used by the generator, enabling it to verify any cryptographic material submitted as part of the verification credentials.

[0089] For each node, both the Generate G and Verify V services can access the HSM pool. The HSM contains keys, each uniquely identified by a set of key identifiers (KeyIds). KeyIds can be tags, values, explicitly unique values ​​(such as UUIDs), or anything else with appropriate attributes. These KeyId values ​​are stored in uniquely identified (identifier) ​​key lists—lists that provide a list of relationships between identifiers (Ids) and stored keys (KeyIds). The identifiers (Ids) are determined by deterministic processing to establish which keys to use, as will be further described below.

[0090] The integrity of each key list is guaranteed using a seal—if the key list is supplied from a central location, this can be applied by a trusted party associated with that central location. Several other distributed models can be supported, for example, by a trusted party acting as a local function instead of a central location. Nodes typically have multiple available key lists, but only one active key list is used at any given time for generating credentials (G)—however, the verification service (V) typically needs to be able to access any key list that can be associated with a still valid credential. Key rotation in this approach is very simple—it may simply involve replacing the active key list with another key list. However, determining which KeyId is needed to verify the credential is very simple—this will be determined entirely by the node identifier and references to the key lists. This information is part of the credential and is used as input to deterministic processing to select a key from the key list.

[0091] Figure 13 The diagram illustrates an exemplary arrangement of node Ni, which has two generation services G capable of generating credentials associated with transactions. At any given point in time, these services G will need to use a given list of keys—such as key list A in the first instance. This uses yellow and blue keys, so these keys must be loaded into the HSM used by generation service G. After a period of time, a key rotation process may, for example, force the use of key list B—which uses yellow and blue keys, but also green keys, so green keys must be loaded into the relevant HSM (if they do not already exist). The specific key to be used is selected from the key list through a deterministic process, which typically yields different results after key rotation, but this is not inevitable (e.g., Id=3 or Id=6 will result in blue keys before or after rotation). While generation service G does not need key list A after key rotation, verification services V still do—they need access to any list of keys associated with potentially valid credentials. Verification services V must be able to determine exactly which key generation service G used to generate the credentials in order to verify them.

[0092] Password-protected transaction-related data includes the identifier of the token associated with the transaction, but also the identifier of the transaction itself. For this, some kind of transaction identifier is required. At each node, the credential generation and verification services can access a local database that can be used to manage this type of data. To ensure effective transaction management across the system, any transaction credential generation for a given token should be associated with a unique transaction identifier for each transaction. This could be a UUID or any suitable identifier structure (such as a cascade of an n-bit node identifier, an e-bit epoch time, and a c-bit local counter).

[0093] However, by using a local transaction counter, the data size carried in the transaction credential can be reduced to a few digits. This can be simply stored in the node's local database, and the local (rather than global) value increments when the local generation service G generates a new transaction credential for the token, such as... Figure 14 The processing is shown in the general terms in the table.

[0094] Now refer to Figure 13 This describes an exemplary process for identifying keys used in transactions. As described above, at any given time, the generation service G can access a set of keys in its local HSM and use those keys based on its currently active key list. This key list is uniquely identifiable by an Identifier and contains a list of entries (represented by KeyId) that correspond to the identifier (Id) and the stored keys. In the case of key list A, there are ten entries, and each Id is an integer.

[0095] A deterministic process associated with a list of keys determines which key will be associated with a given transaction. For each list of keys, the deterministic process does not need to be the same, but it needs to be consistently applied to that list so that both the generation and verification services will achieve the same result. To provide this association, the deterministic process should operate on information that identifies the transaction, such as some kind of transaction identifier—in this case, a local transaction counter (LTC) is a particularly effective choice because it is readily available and easy to process.

[0096] There are many options available for the function, but the simplest is the MOD operation—for example, here, Id = LTCMOD 10 would be suitable for providing a deterministic result that can point to any available Id value. Any verification service V with access to a transaction counter value (or any counter derived from that value) in the transaction data can then determine the logical key identifier used by the generation service G, which generates credentials and accesses the correctly stored key, without any trial-and-error mechanism. Associating a deterministic processing function (hereinafter referred to as keyList.GetIdFunction, or GetId) with the properties of the key list in this way allows for a scalable solution that can accept any number of logical key identifiers given a key list.

[0097] HSM cryptographic functions should be suitable for ensuring data integrity and authentication through credential generation and verification. The cryptographic function operates on selected transaction data using a key and provides an output that does not expose the key. Various alternative cryptographic functions can be used—HMAC is a particularly effective choice with several options regarding hash functions, but CMAC and CBC MAC are possible alternatives that don't even discuss solutions using asymmetric cryptography. The cryptographic function used should be specified in the key list (e.g., keyList.CryptoFunction) and is also driven by the capabilities of the HSM used for generation and verification. Domestic regulations, export of cryptographic materials, or other security considerations may lead to the selection of a particular cryptographic function.

[0098] Within the transaction data, there should be information indicating the application password generated during transaction processing. This could be a simplified form of the password—for example, in a traditional EMV transaction, this could be provided as a CVC2 field. This is important because the verification service V must be able to access all the data used by the generation service G to generate the password—this would include the following:

[0099] Dynamic information carried as part of the transaction process;

[0100] Shared information from one of the following:

[0101] Copying processes (such as key list management);

[0102] System parameters for a specific use case.

[0103] Different methods can be used for different transaction information formats—traditional transactions, UCAF, and DPD field transactions. The traditional transaction use case provides a solution when merchants and / or PSPs can only manage PAN, expiry date, and CVC2 as part of the transaction process and lack access to more recent developments. The UCAF use case aims to leverage the universal cardholder authentication field to carry more data as part of the transaction process. The DPD use case covers recently introduced digital payment data, which is a container capable of carrying all the data required as part of the transaction process. As described below, additional capabilities of formats such as UCAF can support the additional capabilities provided by embodiments of this disclosure.

[0104] Figure 15 The document illustrates a complete set of cryptographic mechanisms. (Reference) Figure 16 Key management is discussed. Key management in this model has two aspects: the management of the keys themselves, including their generation and delivery to the HSM associated with the nodes, and the management of the key list, including its generation, distribution, activation, and deactivation. The key list is a sensitive asset, while the keys are considered secret assets—the key list defines the keys to be used for cipher generation and verification. When loading keys into the HSM, end-to-end security is required, where wrapping / unwrapping techniques are used to securely transmit the keys. Their use should not be affected by the key list to prevent attackers from altering its contents to change key selection processing. The integrity of the key list is guaranteed by a sealing lock—providing a sealing lock to the key list by the generating party or an associated trusted party involves appropriate cryptographic processing (such as having an appropriate private key or using HMAC with a digital signature generated using, for example, an asymmetric algorithm such as RSA, ECC, SM2, etc.), and its effect is that any relevant part of the system can be confident that the key list was generated by the appropriate party and has not been modified. Furthermore, the key list sealing lock can be used for cipher generation and verification to protect credentials.

[0105] Different control models are possible. Centralized control may exist, where a central service generates keys and key lists and distributes them to different nodes. However, localized control may also exist if dedicated processing is required at specific nodes. This may be particularly suitable if there are specific requirements for a particular country—for example, local regulations or restrictions on the export of cryptographic materials. This may also be suitable if HSM management requires proprietary mechanisms—for example, a specific cloud service provider. This is not node-dependent—it can be applied to regional control with a central service within a region (this may be particularly suitable for situations where a particular country has a specific security model to meet local legal requirements). Hybrid or composite models may also exist, where some key and key list supply is centralized and some is local—a distributed model may also exist, where distributed peers collectively assume the role of the central service.

[0106] Figure 17 Monitoring is illustrated in general terms. Here, monitoring complements security measures taken directly within the service to prevent fraud or abuse (such as the service's fundamental purpose—generating credentials using passwords and performing subsequent verification). This monitoring aims to detect security anomalies associated with transactions—which can then trigger appropriate response mechanisms to encompass any security risks and identify any attackers. In principle, this can be both local and centralized. A hybrid approach has been found to be particularly effective, providing both efficient detection of any issues and efficient responses to the risks associated with a fully distributed architecture.

[0107] Monitoring such a system involves addressing three categories of issues: the integrity of the distributed system; the generation of transaction credentials; and the verification of transaction credentials. Since transaction credentials can be generated or verified anywhere, effective monitoring of the entire distributed system is crucial.

[0108] For example, as described in the applicant's earlier WO 2022 / 250716A1, the latest version of the electronic transaction protocol can be used to carry more information than the earlier version. Multiple additional digital bits are available where the Universal Cardholder Authentication Field (UCAF) is available. UCAF is a format type developed for Digital Secure Remote Payments (DSRP), a technology the applicant uses to effectively utilize EMV methods—including the use of applied ciphers—for online and other digital transactions via tokenization. UCAF is used to carry cipher data in the authorization request. The UCAF data format will carry a set of predefined data objects in a specific field—this set of data objects may differ between different UCAF data formats, and the space allocated to different data objects may also differ.

[0109] UCAF Format 0 was the first to be developed and used by applicants with specific technologies (e.g., Mastercard Cloud-based payments, TEE-based payments, and some variants of Mobile PayPass). This format contains necessary password information (such as the application password, application transaction code, and unpredictable number) but does not include merchant binding. UCAF Format 0+ (used by later versions of Mastercard Cloud-based payments) expanded this to include card verification results but still does not provide merchant binding. UCAF Format 1 (used by MChip Mobile) also does not include any merchant binding but does include PIN attempt counter results. Merchant binding is provided in UCAF Format 3, which includes a merchant ID hash and an approximate amount (this is used in newer versions of the transaction protocol that require merchant binding). UCAF Format 3+ also includes card verification results.

[0110] When UCAF is carried in the payment network, it is Base64 encoded—it is carried as a 28-character alphanumeric string. Therefore, it needs to be Base64 decoded before processing.

[0111] One architecture that utilizes a very complete set of capabilities is the DXD (Default Number) architecture, used for country-specific digital transactions. For this purpose, a specific UCAF format, UCAF Format 6, has been developed, possessing a very complete set of capabilities—it can use more cryptographic material, can use more nodes without causing node identification problems due to limited available space in transaction data as defined in electronic transaction protocol requirements; and it can rotate key lists more frequently than 24 hours because there is space to use more than one bit for key list identification for verification services. The available space in the transaction data can be used to deliver additional features, such as by supporting merchant locking technology (effectively binding a transaction to a given merchant using some form of merchant identifier), by including additional components in cryptographic processing (such as using some pseudo-random element or variable content between the generator and validator), or by taking additional measures to provide full compliance with any regulatory requirements.

[0112] Figure 18 The UCAF Format 6 structure is illustrated herein. This is not an embodiment of this disclosure, but is shown here only as a comparison of the data types that can be carried in this format and how they are carried. The UCAF Format 6 structure includes an encrypted portion 241 and an unencrypted portion 242. The encrypted portion 241 contains credentials (passwords) and certain transaction data, which allows certain elements to be kept in encrypted form only. The unencrypted portion 242 allows for the identification of the transaction and its origin.

[0113] In this example, the unencrypted portion 241 contains 4 bytes of information: version, node (and node-related information), transaction, and specific merchant information. Version information 2411 is a 4-bit field, allowing for multiple version formats. Node-related information includes a 6-bit node identifier 2412 and key list references associated with the node—as previously mentioned, these include a 2-bit transaction key list reference 2413 and a 6-bit encryption key list reference 2414. The transaction itself is identified by a 1-byte Local Transaction Counter (LTC) 2415. As mentioned above, this information is sufficient to allow the node to perform verification by regenerating credentials / passwords (if permitted). The merchant bound to the token is provided by a merchant ID hash divided between a 13-bit unencrypted portion 2416 and a 3-bit encrypted portion 2421. The creation of the merchant ID hash is described in more detail below.

[0114] Encryption allows other transaction information to be stored in encrypted form but made available upon future decryption, enabling transactions to be mapped to the PAN (Master Account) without maintaining a dedicated mapping database—other important information, such as the PAN serial number (PSN), can be stored in this way. The encrypted data 242 consists of 16 bytes of data, the first 3 bits of which is the encrypted portion 2421 of the merchant ID hash as described above. The password 2422 constitutes the remaining 22 bits of the encrypted data. One bit is used as the SCA flag 2423 to indicate whether strong customer authentication is used for the transaction. The remaining 23 bits are used to approximate the transaction amount 2424—these can be encoded in the following form:

[0115] Reconstruction cost = A * 2 B

[0116] A is used for the leftmost 18 bits, and B is used for the rightmost 5 bits. The remaining 74 bits are related to card information 2425. This includes the PAN (63 bits) and PSN (4 bits, which is sufficient for a single digital value), which can be provided in full. 7 bits are used to carry expiration date information—therefore this needs to be a partial expiration date, which will be discussed below—and the embodiments described below also support the optional transmission of a partial expiration date when generating a transaction certificate. Another element in the encrypted data in this case is the checksum 2426.

[0117] The Merchant ID can use a Remote Business Recipient Identifier, a relatively new EMV field, which, if available, is used to identify the merchant (e.g., via the business website URL or reverse domain). The Merchant ID hash is provided in the following ways:

[0118] The merchant ID (through conversion or other means) is provided as a hexadecimal (HEX) value.

[0119] The buffer is created as follows:

[0120] ο Hash of Merchant ID (32 bytes)

[0121] o Approximate amount (3 bytes, the remainder is padded with ob)

[0122] ο Local transaction counter (encoded on 2 bytes, with the remainder filled by Ob)

[0123] • Calculate hashes on buffers using an appropriate cryptographic model

[0124] The merchant ID hash is the first two bytes of the hash buffer.

[0125] As described above, in the embodiment provided herein, the supply of the expiration date value is optional. If supplied, the encoding and decoding activities will be performed by the NODES system (if it is valid) – otherwise, an error will be returned. If not supplied, then information must be carried to prevent the system from returning the expiration date value during verification or decryption.

[0126] A limited amount of available space—7 bits—is required to provide this information—starting from a standard expiration date encoded with 4 numeric bits (YYMM), but with practical constraints on the values ​​of some fields (because there are only 12 months in a year, and the expiration year is not far from the current year). This is utilized by first defining a “baseline” value for the expiration date, which is provided simply as a parameter to the list of encryption keys. After this, a special value 0 [0000000b] is determined to encode “undefined expiration date” (generated)—for which the expiration date should not be returned during decoding (whether for verification or any other decryption). All other values—1 [0000001b] to 127 [1111111b]—are used only to indicate the number of months from the baseline value to the provided expiration date (generated) to provide reliable decoding for verification or any other decryption. If a supplied expiration date is returned that is less than or equal to the baseline value, or more than 127 months after the baseline, then this is invalid, and an error is returned. As mentioned above, the encrypted data also includes a checksum. The reason for providing a checksum is that in some cases, in addition to the guarantees provided by password verification, it may be desirable to obtain guarantees of data integrity during decryption.

[0127] Figure 18 The UCAF format 6 shown indicates the types of information that can be carried if all relevant parties support this format. However, in practice, credential generation and verification infrastructure may need to support service requests from different parties using various transaction flows and transaction types. In some cases, all parties will be able to support... Figure 18The structure shown is of this type. In other cases, the parties may only be able to support a very limited exchange of information. Figure 19 The diagram illustrates this situation—it shows the various scenarios the system might need to support. While the NODES architecture is generally designed to operate using the more recent UCAF format—here, UCAF format 5—earlier digital transaction solutions had more limited capabilities. Therefore, to use credential generation and verification within the NODES architecture, some solution other than the existing UCAF format 5 needs to be found, as that format does not properly support these earlier architectures.

[0128] Figure 19 This illustrates different routes for digital transactions supported by the Mastercard Digital Enablement Service—a service used for online transactions and relying on card tokenization, as discussed earlier in this specification. The token is referred to herein as the Digital Master Account (DPAN) and, in some architectures, may be identified by a Token Unique Reference (TUR) rather than the DPAN. In digital architecture solutions prior to NODES, such as MDES (M4) for merchants and Secure Remote Commerce (SRC), the transaction and encryption key were bound to the token; in NODES, the key is bound to the node, not the token. This means there is a mismatch in the required information between transactions carried in the standard UCAF Format 5 (designed to carry the information required by NODES) and those carried in earlier formats such as Format 0 or 0+ which can support M4M or SRC, or Format 3 or 3+ which can support SRC. As discussed above, Format 0 has no transaction binding, while Format 3 has a merchant binding and supports strong customer authentication (and is therefore compatible with PSD2), where the + indicates the presence of a card verification result.

[0129] The UCAF format 5 has been developed, and it is constructed in different ways depending on the type of transaction it needs to serve. For example, for M4M transactions, the NODES schema can be required to generate (and subsequently verify) credentials, but in a manner that includes elements of UCAF format 0+.

[0130] like Figure 20As seen above, this is implemented using a type of UCAF format 5, which can employ various sub-formats, each identified by a suitable code. These sub-formats contain different information within different structures to support different types of transactions. UCAF format 5 consists of 21 bytes of Base64-encoded hexadecimal data—carried within data element 104 (DE104) in the ISO8583 message (the ISO standard for financial transaction card initiation messaging, used by most transaction system providers for authorization messages). Data element 104 (DE104) is a field reserved for transaction description, specifically DE104SE1001. This applies to all UCAF formats, where the format version is encoded in the leftmost 4 bits for Digital Secure Remote Payments (DSRP) via MDES. The organization of UCAF format 5 information varies depending on the needs of the requesting client—in the example above, UCAF format 5 information is organized using a form of UCAF format 5 that can be used by the requesting client (who requires information provided by UCAF format 0+) while still meeting the requirements of the NODES architecture. This can be achieved by using a codebook approach—the code value in UCAF format 5 indicates the subformat to be adopted (here, the subformat with the information carried by UCAF format 0+), and the codebook will indicate the subformat associated with that code and carrying the correct set of information.

[0131] In this form of UCAF Format 5, the 21-byte message is divided into a 5-byte header containing technical data (always in plaintext) and a 16-byte body containing transaction data (which may be in plaintext or encrypted depending on the implementation). The example codebook provided here allows 32 possible combinations—4 headers and 8 bodies. The technical data provided in the header can include information such as version, DPAN or TUR and SCA information, as well as information such as node identifier, key list, and transaction counter. The transaction data in the body can include token PSN, amount and merchant binding, CDCVM information, transaction initiator (client or merchant), transaction type, and transaction reference. The header enables the information to be identified as UCAF Format 5 and provides the information required to effectively invoke the NODES service. The body provides everything needed for (secure) control of the transaction and allows for the mimicry of "older" transaction formats when needed, while allowing a full set of capabilities where supported.

[0132] Using this approach, many different sets of requirements can be supported using only one format—UCAF Format 5. Unique token identification can be achieved by combining DPAN or TUR with the token expiry date (and token PSN)—this is robust even for re-digitization. The presence of additional information allows for the detection of replay (the same transaction credential being submitted for verification more than once) and double-spending (the same transaction credential being submitted to multiple verification services) during verification. In addition to supporting earlier suitable versions of Format 5 (here referring to versions 0, 0+, 3, and 3+), this Format 5 is fully compliant with compliance requirements (such as PSD2 and Token Assurance Framework requirements)—it supports SCA, can provide CDCVM information, and can provide amount binding and merchant binding. Other capabilities can also be provided (e.g., using space identified as reserved for future use in the embodiments described below): for example, identification of the transaction initiator (cardholder-CIT, or merchant-MIT); transaction type identification; and merchant or PSP reference. Using this reserved space allows new data to be carried over when needed without impacting the acquirer or data processor.

[0133] This UCAF Format 5 solution splits UCAF into a 5-byte plaintext header and a 16-byte body, which can be plaintext or encrypted. The codebook provides options for both the header and body within a single format version. This approach can be used with DPAN or TUR, optimizing space for node identifiers, key list references, and LTC values, thus allowing for reduced key rotation frequency and providing the possibility of adding multiple new capabilities while reserving space for future additions.

[0134] The main features of UCAF format 5 are as follows: Figure 20 As shown in the figure, the codebook digest is in Figure 21 As shown in the image. Figure 20As shown, the UCAF format 5 includes a 5-byte header and a 16-byte body. The header 2010 has five basic fields. The version field 2011 has 4 bits and is set to 0101 (5) here. The node identifier field 2012 has 10 bits and thus allows identification of 1024 nodes. The version field and the node identifier field will be used for message routing. The common header field 2013 includes two subfields for identifying specific information about the transaction—the first subfield 20131 identifies whether the token is identified by DPAN or TUR—this is a single bit, set to 0 for DPAN and 1 for TUR. The second subfield provides information about SCA (Strong Client Authentication), as required by PSD2 (for example)—it has 2 bits. The codebook identifier field 2014 has two bits—identifying four possible codebooks—and they have a 21-bit associated codebook content field 2015. The main body 2020 has a simpler basic structure: a 3-bit codebook identifier 2021 and a 125-bit codebook content field 2022. The use of these fields will be described in more detail below.

[0135] Figure 21 The currently used codebook combinations are shown: Header 00 can be used with Body 000 (copying v0 and v0+), Body 011 (copying v3 and v3+), and Body 101 (using v5 only), in each case the body is plaintext; while Header 01 provides the same option where the body is encrypted. As can be seen, this method still retains 24 header and body combinations.

[0136] These eight codebooks (the two header codebooks and six body codebooks currently in use) are in Figures 22 to 29 As shown in the image. Figure 22 and Figure 23 The following discussion focuses on implementing embodiments of this disclosure. Figures 24 to 29 Further details are provided below.

[0137] Figure 22 and 23 The two codebook options for the header are indicated—codebook 00 supports a plaintext body, while codebook 01 supports an encrypted body. Both have 3 bits for a transaction key list reference—both provide bits for a local transaction counter and bits reserved for future use, but codebook 01 also reserves 6 bits for an encrypted key reference. Therefore, codebook 01 provides fewer bits for the local transaction counter and future use than codebook 00 (codebook 01 provides 11 bits for the local transaction counter instead of the 14 bits provided by codebook 00, and for future use, codebook 01 provides 1 bit instead of the 4 bits provided by codebook 00).

[0138] However, both UCAF Format 6 and UCAF Format 5 solutions suffer from limited space available for key list rotation and excessively frequent key list rotation. Excessive rotation leads to the incorrect "use" of transaction counter values ​​when "old" credentials become available for verification with the correct key list values, resulting in the risk of subsequent verification failures when using those transaction counter values. This is the above. Figure 3 The general situation is illustrated. Embodiments of this disclosure provide solutions involving key list enhancement that significantly reduce or even eliminate this risk. Two different embodiments and their alternatives are described below—these different embodiments are proposed for UCAF format 6 and UCAF format 5 respectively, and are illustrated with... Figure 4 The two types of enhancements described are: a mechanism that allows for longer key list cycles before a given key list is repeated; and a check mechanism that prevents collisions before a transaction counter value is marked as used.

[0139] For convenience, Figure 30 This document summarizes the issues related to key list rotation. Transactions are executed on tokenized identifiers using the current transaction key list. To generate credentials, there will be an active transaction key list at any given time. The key list is defined by multiple profiles (key list, key topology, use case, node, etc.), and service G operates on the token to generate credentials, where the Local Transaction Counter (LTC) value is one of the elements used in credential generation. Validation is then performed by an instance of service V—there can be more than one active transaction key list at a given time because there exists a validation time window during which validation can be legally performed. When this window ends, the transaction key list used for generation becomes invalid for a period of time. However, as the key list is rotated to prevent uncontrolled key expansion, another period will occur during which the transaction key list becomes available again—this is the period when attempts to validate outdated credentials may lead to the failure of subsequent validation of legitimate, timely credentials as perceived replay attacks.

[0140] For use case X using UCAF format version 6, the problem is... Figure 31 The solutions described herein, and those using embodiments of this disclosure, are... Figure 32 This is explained in the text. Positioning UCAF format version 6 is quite challenging because the available space is very limited—only 8 bits are available for the LTC, and only 2 bits (four values) are available for the Transaction Key List (TKL). If the TKL rotates daily, the same key list (with the same TKL reference values) will appear after only three days. This means that there will be LTC value "conflicts" half the time, with the greatest risk on the fourth and fifth days after the certificate is generated.

[0141] A practical solution here is to provide key list enhancement by extending the time period before the key list repeats—this can be achieved by finding additional bits in the UCAF format version 6 structure to use or reuse to accommodate larger key list reference values. For example... Figure 32 As shown, if two bits can be freed, then the key list reference can use 16 values ​​instead of 4, thus significantly reducing the risk of problematic LTC collisions. Other options are possible (using one bit of the node identifier to reduce the number of available nodes, or using one or more bits to establish another identifier or other distinguishing factor and using it as a method to prevent collisions), but it is currently unclear whether these schemes are equally effective.

[0142] For use case U delivered in UCAF format version 5, there is more available space, thus providing an opportunity to eliminate this problem for practical purposes by enhancing the key list with appropriate key list. Figure 33 The current situation is illustrated—the LTC is carried using 14 bits (16384 values), and 3 bits are used for TKL references (8 values). Furthermore, while daily key rotation is possible for this use case, the nature of the use case means that weekly TKL rotation is the most efficient practical model due to the low exposure of the key list outside the NODES system. This implies that TKL references are only reused after 7 weeks.

[0143] As indicated in the previous discussion of UCAF format version 5, there are several places where bits are available: 1-4 bits in the codebook header; 1 bit to several bytes in the codebook body; and further possibilities for removing bits from other fields that could reduce the definition. Extending the TKL reference is one possibility, but here is a better, more practical solution—also record some or all of the creation time of the TKL generation and use this time to check the credentials as part of the initial matching process. This is in Figure 34 As shown, it records the month used by the TKL when it was generated—the month value can be recorded with 4 bits of information, and this information can be obtained from the main body of the codebook in all cases. Figure 34The example illustrates an attempt to submit a credential for verification using TKL reference 0, but the submission is in June, while the original generation was in April. The verification service rejects the credential directly based on the month mismatch (even if a key list match exists), and the rejection does not jeopardize credentials generated in June with the same LTC value using TKL reference 0. The risk is reduced to the risk of submitting a transaction credential a year later—this is the lowest risk. This could be achieved using weeks instead of months—by using additional logic, a deliberate mismatch with the TKL rotation could allow for separate 3-bit numbering of weeks—however, the additional logic requirements and the slightly earlier occurrence of conflicting repetitions make this approach less attractive overall.

[0144] This strategy (which can be viewed as providing a "TKL checksum") is used in the main body of UCAF format version 5, as shown in the reference below. Figures 24 to 29 As stated above.

[0145] Figure 24 and Figure 25 Provides the main body of the UCAF format 0 / 0+ information, in which Figure 24 Provide a plaintext version, while Figure 25 An encrypted version is provided (the codebook is 000 in each case). Both main sections have the same structure for transaction-related information, including reserving one byte (“byte 21”) for CDCVM information (for 0+ format). They also both reserve 4 bits for the PAN Serial Number (PSN) and 41 bits for future use. The 4 bits are used for the transaction key list checksum—enough to hold the month value (TKL creation timestamp). The difference lies in how the transaction password is preserved—in the plaintext case, this is preserved as a 68-bit value, while in the encrypted case, it is preserved as a 60-bit value, with 8 bits reserved for decryption checksum.

[0146] Figure 26 and Figure 27 Provides the main body of the copied UCAF format 3 / 3+ information, in which Figure 26 Provide a plaintext version, while Figure 27 An encrypted version is provided (the codebook is 011 in each case). As before, both main parts have the same structure for transaction-related information, but... Figure 24 and Figure 25The situation is slightly different. Here, the PSN remains 4 bits as before, and the CDCVM information is 8 bits, including 21 reserved bytes for the + format. 4 bits are again used for the transaction key list checksum. However, this time there is also a amount binding field (one bit subfield indicates whether a portion of the amount has been supplied, 0 or 23 bits are used for the generated value) and a 16-bit merchant binding field (bytes 19 and 20 of the field) – depending on whether the amount binding field needs a value, 24 bits or 1 bit are reserved for future use. This allows for UCAF format 3 / 3+ replication. Password retention and Figure 24 and Figure 25 The situation is the same – for plaintext, it is kept as a 68-bit value, while for encrypted text, it is kept as a 60-bit value, with 8 bits reserved for decryption checksum.

[0147] Figure 28 and Figure 29 It provides a main body with "native" UCAF format 5, in which Figure 28 Provide a plaintext version, while Figure 29 Provides an encrypted version (the codebook is 101 in either case). As before, 4 bits are reserved for the transaction key list checksum. This method allows for the carrying of new information. Figure 26 and Figure 27 In contrast, the main body contains a new field (2 bits, with codes for CIT and MIT as allowed values) for the transaction initiator and a new 7-bit field for the transaction type. This can be achieved using the first two digits of the transaction processing code as described in ISO 8583:1987—which can be efficiently encoded and decoded with 7 bits, but the number of bits can be further reduced by using a translation table.

[0148] In an embodiment, these two strategies can be combined—key list enhancement may include releasing additional bits to extend the key list reference, thereby extending the time before the key list is reused, and having a "verification" field as discussed above that indicates when the key list was generated.

[0149] As those skilled in the art will recognize, the above embodiments are exemplary, and other embodiments falling within the spirit and scope of this disclosure can be developed by those skilled in the art based on the above principles and examples. In particular, the embodiments described in detail above relate specifically to the generation and verification of credentials, and the encryption and decryption of these credentials along with other data, where both credentials and other data are used in financial transactions. The generation and verification of credentials, and the encryption of credentials along with other data, are not limited to financial transactions in this way—this method can be used in any distributed system where one party needs to verify that the other party has taken legitimate action, and where the two parties may be accessing different nodes of the distributed system.

Claims

1. A method for providing security services at a computing node to a requester outside the computing node, wherein the computing node is one of a plurality of computing nodes in a distributed computing system suitable for providing security services, the method comprising, at the computing node: Receive service requests from requesters, including requests to generate credentials; Credentials are generated using a cryptographic key and an instance counter, wherein the cryptographic key is determined from a list of currently active keys used by the compute nodes, wherein the key list is rotated at a predetermined rotation frequency to provide a new list of currently active keys, and wherein the instance counter is determined by the number of instances performing the service within a predetermined time window; The provided credentials enable the determination of the key list reference and instance counter value from the credentials without decryption; The credentials also include key list enhancements, which enable key list enhancements to be used to prevent conflicts between credentials that have shared key list references and shared instance counter values.

2. A method for providing security services at a compute node to a requester outside the compute node, wherein the compute node is one of a plurality of compute nodes suitable for providing security services, the method comprising, at the compute node: Receive a service request from a requester, wherein the service request includes a request to verify credentials, wherein the credentials have been generated by one of the plurality of computing nodes using a cryptographic key and an instance counter, wherein the cryptographic key has been determined from a currently active key list of the cryptographic key used by the generating computing node, wherein the key list is rotated at a predetermined rotation frequency to provide a new currently active key list, and wherein the instance counter is determined by the number of instances performing the credential generation service at the generating computing node within a predetermined time window; The credentials provide credentials that enable the key list reference and instance counter value to be determined from the credentials without decryption, and the credentials also include key list enhancements to prevent conflicts between credentials that have a shared key list reference and a shared instance counter value. At least determine whether the verification of the credentials is reasonable from the key list references and key list enhancements, and if so, then attempt to verify the credentials.

3. The method of claim 1 or claim 2, wherein the key list enhancement provides an extension to the key list reference, thereby extending the time during which the key list repeats itself when it is rotated at a predetermined rotation frequency.

4. The method as described in any of the preceding claims, wherein the key list enhancement includes an additional field to check whether the key list reference is related to the use of the relevant key list currently available for verification.

5. The method of claim 4, wherein the key list enhancement includes time.

6. The method of claim 5, wherein the key list enhancement includes an indication of the month in which the credential was generated.

7. The method of claim 5, wherein the key list enhancement includes an indication of the week in which the credentials are generated.

8. The method of claim 5 or claim 6, wherein the predetermined rotation frequency of the key list is weekly.

9. A computing device suitable for acting as a computing node providing security services, the computing device comprising a processor, a memory, and components for communicating over a network, wherein the memory includes instructions for programming the processor to perform the method of any one of the preceding claims using the components for communicating over a network.

10. The computing device of claim 9, wherein the computing device is adapted to perform both the method of claim 1 and the method of claim 2.

11. A distributed computing system comprising multiple instances of computing devices as claimed in claim 9 or claim 10, each such computing device acting as a computing node for providing security services as part of the distributed computing system.

Images