Event management in distributed computing system

Abstract

The invention relates to event management in a distributed computing system. A method of managing service events in a distributed computing system is described. A distributed computing system includes a plurality of computing nodes capable of executing a service using a service process. The method occurs at one of the compute nodes. A service event is received or created. The service event is identified by a combination of a node identifier, a time element, and a local counter value. The local counter value represents the number of service events performed for the user by the service process since the last reset. The identified service event is then stored in a service process database according to the node identifier and the local counter value. The service process database is used for managing service events in the distributed system. When the service event is no longer valid, the service event is removed from the service process database using the temporal element. Appropriate compute nodes and appropriate distributed systems are also described.

Description

[0001] This application is a divisional application of the PCT application entering the Chinese national phase, with an international filing date of April 22, 2020, national application number 202080036913.2, and invention name “Event Management in Distributed Computing Systems”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is based upon and claims the benefit of and priority to European patent application serial number 19178579.9, filed on June 5, 2019; European patent application serial number 19178583.1, filed on June 5, 2019; and European patent application serial number 19208139.6, filed on November 8, 2019, the contents of which are incorporated herein in their entirety for all purposes. Technical Field

[0004] The present disclosure relates to event management in distributed computing systems. Background Art

[0005] There are many technical challenges that require a centralized system to provide services to a very large number of clients, especially when those clients are widely distributed geographically. It is logical to consider a distributed system so that related services can be provided by a set of geographically distributed servers rather than by one central server or data center.

[0006] In practice, this decentralization may use a cloud architecture, which will typically use multiple geographically distributed servers - or data centers - to deliver services to clients. A cloud architecture can be thought of as comprising multiple nodes - when using a cloud architecture, a node can be an aggregation of multiple computers and can span more than one data center with "real-time" connectivity and data sharing within a given node.

[0007] Decentralization itself can be problematic, especially if it is necessary to provide services in such a way that the provision of services has consequences beyond the servers providing the services and the clients receiving the services. For example, if other clients (or other system nodes) need to trace back to the service providing node to check whether or how the service has been provided, or if it is necessary for the central system to know how the service has been provided or the performance of the distributed server nodes, then new bottlenecks may appear at the central server in place of previous bottlenecks, the total amount of messaging in the system may increase, and network latency may become a serious problem.

[0008] In particular, the management of events becomes more problematic in distributed systems. One node may need to know about an event that occurred at another node, and it may not be possible to predict where that knowledge will be needed. In the case where all events occur at a centralized server, it is easy to identify them in a way that they can be consistently referenced throughout the system and used in system management. In the case where an event only occurs at one point in the system, it is much more difficult to handle the identification and management of events efficiently without excessive messaging, especially when knowledge of the event may only be needed at a limited number of points in the system, or may not be needed at all unless further events occur. Summary of the invention

[0009] In a first aspect, the present disclosure provides a method for managing service events in a distributed computing system, wherein the distributed computing system includes multiple computing nodes capable of performing services using a service process, wherein the method includes, at one computing node among the multiple computing nodes: receiving or creating a service event identified by a combination of a node identifier, a time element, and a local counter value, wherein the local counter value represents the number of service events performed by the service process for a user since the last reset; storing the identified service event in a service process database based on the node identifier and the local counter value; using the service process database to manage service events in the distributed system; and when the service event is no longer valid, removing the service event from the service process database using the time element.

[0010] Using this approach, service events occurring in a distributed computing system can be efficiently identified, and a computing node can establish from which other computing node they originated. The identified structure facilitates direct use in system management and removal of events when they are no longer relevant.

[0011] In an embodiment, the service event includes a cryptographic process. The service event may include the generation of a cryptographic certificate. A local counter may then be used to identify the cryptographic key used for the cryptographic process. These service events may be managed based on the validity period of the cryptographic key.

[0012] The identification structure taught herein is particularly effective for this purpose, since the presence of time information together with the counter information allows efficient coordination with the validity period of the key. The counter can also be reset as the time period changes, thereby allowing smaller counter values ​​to be transmitted.

[0013] In an exemplary context, the method is performed in the same node as the service process that creates the service event. Here, the method also includes determining a service event limit for the user's service process, counting the service events using a local counter, and pausing the service process for the user when the service event limit is exceeded.

[0014] In another exemplary context, the method is performed in a computing node that includes a verification service process for verifying a service event. In the case where the service event includes the generation of a cryptographic proof, the verification service can verify the cryptographic proof. In this case, there can be one or more additional counters associated with the verification service, and there are additional counter limits for the one or more additional counters, and the method also includes pausing the operation of the service process for the user when one of the additional counter limits is exceeded. There can be a replay counter among the additional counters to count attempts to verify the same service event. There can also be a password failure counter to count failures of the verification service process to produce a verification result.

[0015] In an embodiment, the distributed computing system is a transaction processing system, and the service event comprises generation of transaction details for processing in the transaction processing system, and the local counter is a local transaction counter.

[0016] In a second aspect, the present disclosure provides a computing node of a distributed computing system, wherein the computing node comprises at least a programmed processor and a memory, wherein the programmed processor is suitable for executing the method of the first aspect.

[0017] In a third aspect, the present disclosure provides a distributed computing system, comprising a plurality of computing nodes according to the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0019] Figure 1 A conventional system involving multiple clients interacting with a central server is shown;

[0020] Figure 2 Shows the provision of Figure 1 Multiple clients interacting with the same service in a distributed computing architecture with a central server;

[0021] Figure 3 Shown in Figure 1 Methods for counting events in conventional systems;

[0022] Figure 4 Shown in Figure 3 A method for counting and managing events in an arrangement, the method being applied to an embodiment of the present disclosure;

[0023] Figure 5 Schematically illustrates a distributed transaction architecture using a four-party model;

[0024] Figure 6 The diagram is suitable for implementing Figure 5 Elements of complex distributed systems of transaction architecture;

[0025] Figure 7 Schematically shows the Figure 5 and Figure 6 An exemplary system for implementing digital transactions in a transaction architecture;

[0026] Figure 8 schematically illustrates an arrangement of a distributed system for digital enablement of transactions;

[0027] Fig. 9 A more detailed illustration Figure 8 Arrangement of computing nodes;

[0028] Fig.10 Pictured Fig. 9 The elements within the computation node;

[0029] Fig.11 Instructions and Fig. 9 The transaction flow related to the operations performed by the nodes;

[0030] Fig.12 Instructions Figures 9 to 11 In an embodiment of the arrangement, tokenization is used;

[0031] Fig.13 Instructions can be applied to Figure 8 A method of key management for an arrangement;

[0032] Fig.14 An exemplary method of transaction identification related to an embodiment of the present disclosure is illustrated;

[0033] Fig.15 The diagram shows the application Figure 8 A set of exemplary cryptographic mechanisms for digital transactions arranged in

[0034] Fig.16 The diagram shows Fig.13 A global model of key management for each node managed as shown in;

[0035] Fig.17 The diagram shows Fig.13 and Fig.16 A global monitoring model associated with the key management model;

[0036] Fig.18 The diagram shows the use of Fig. 9 and Fig.10An exemplary modified tokenization process for transactions of a traditional use case of a node;

[0037] Fig.19 Diagram showing the key rotation process for a system using traditional use cases;

[0038] Fig. 20 A set of exemplary cryptographic mechanisms for digital transactions using traditional use cases is illustrated;

[0039] Fig.21 Illustration of the use of suitable Fig. 9 and Fig.10 A method to carry local transaction counters using the traditional use case used with nodes.

[0040] Fig. 22 Diagram showing the use of Fig. 9 and Fig.10 Used when using a card verification code (CVC) to deliver a local transaction counter Fig.21 Methods;

[0041] Fig.23 Illustration of the use of suitable Fig. 9 and Fig.10 A method for using the UCAF (Universal Cardholder Authentication Fields) format with other nodes to transmit transaction credential information as part of a transaction;

[0042] Fig.24 An exemplary set of cryptographic mechanisms for digital transactions using the UCAF format is illustrated;

[0043] Fig.25 Illustration of the use of Fig. 9 and Fig.10 A method for using DPD (Digital Payment Data) to transmit transaction credential information together with nodes;

[0044] Fig.26 Provides more detailed instructions on the role of LTC in key usage and credential generation (or verification);

[0045] Fig. 27 Illustrate the role of LTC in resolving system issues such as replay detection, password failures, and retries. DETAILED DESCRIPTION

[0046] Generally speaking, the problem addressed by the present disclosure is Figure 1 and Figure 2 Medium picture. Figure 1A central system is shown that performs functions in response to requests from a very large number of geographically distributed entities. This places strong demands on the central system in terms of processing power, storage, and messaging, and often results in significant delays throughout the system due to bottlenecks and messaging requirements.

[0047] Figure 2 An alternative arrangement is shown in which the role of the central system is broken down so that the same functions are performed by a set of distributed nodes, each with the ability to perform some or all of the functions provided by the central system. The individual nodes should see much lower demand than the central system, and latency can potentially be reduced because entities should be able to interact with nodes that are more local than the central system. However, as discussed generally above, and specifically related to transaction processing systems below, there are significant technical challenges in achieving this benefit.

[0048] Figure 3 Shows Figure 1 A typical method of event processing in a conventional central server-based system. The central server 31 contains a service process 32 that provides services to requesters 33. If it is necessary to identify each instance of a service or the associated service result, a counting process 34 works with the service process to assign a unique identifier each time the service process 32 performs a service for a requester. The unique identifier can be used as a subsequent reference to the service instance or the result of the service instance. Since any further interaction related to the service execution will involve returning to the service process 32 or another process in the central node 31, the unique identifier can be easily used at any time.

[0049] In such Figure 2 In the distributed system shown in , the situation is more complicated. A service may be generated at one of the multiple nodes in the system, and other nodes may need to know and engage the service result. Therefore, embodiments of the present disclosure provide methods for handling such more complex situations. Figure 4 A general example of how this can be achieved in a distributed system 41 comprising a plurality of local nodes 35a, 35b, 35c, 35d is illustrated. In this case, a requester 33 can request a service from one of the local nodes 35a, 35b, 35c, 35d. Each local node 35a is shown here as having its own service process 32a (in the embodiments discussed below, a local node may have a plurality of different services, and may have more than one type of service).

[0050] The service process 32a interacts with a local counter 36a here. The local counter 36a counts the services performed at the local node 35a and provides them with a value unique to the local node 35a. As further described below, the value may be unique over a period of time, and the local counter value is reset after the period - in this case, the local counter value and the indication of the time period are needed to realize local uniqueness. The value is usually not unique in a distributed system - two different local nodes 35a, 35b can use the same local counter value (or even the same local counter value and time period value) to identify different service events. In order to be used as an identifier in the system, the local unique value can be combined with the identification of the local node 35a itself. This can be used to provide a valid unique value in the entire system, and also allows the provider of the identification service.

[0051] This method has many practical uses - for example, a new service request made by a requester 33a to a local node 35b may have identified a previous service result with a specific identifier, which indicates that the service is provided by a local node 35c. This is particularly relevant in the case where a second service uses the result of a first service. As discussed in more detail below in a specific example, this may be applicable when a first service generates a certificate and a second service verifies the certificate - usually this requires that the first service and the second service have access to the same or complementary cryptographic resources. Here, this can result in a message delivery 37 between a local node 35b and a local node 35c about the execution of a second service by the local node 35b. This can be used for service management, such as by allowing the original service result from the first service to be determined to be abused. A local node identifier can be used to establish communication, and a local counter can be used to help determine how a service instance is used. This use can be within a specific time period - for example, between local counter resets. The specific way in which this type of identifier and in particular a local counter element can be used to achieve different functional results is described below. This is described in detail in the context of a trading system, but it should be understood that these are applicable to other functional systems.

[0052] This problem is particularly relevant to transaction processing systems, and in particular to systems for processing digital transactions. In these cases, the local counter mentioned above is a local transaction counter (LTC). The number of digital transactions is growing extremely fast, and there is a need for them to be performed reliably and quickly. Support for these transactions can use transaction processing systems developed for device-based payments using payment cards, and use the protocols of such payment systems, but in practice such transactions have different characteristics from device-based transactions. This will be discussed below, first with reference to the general elements of a transaction processing system, and then in more detail to the infrastructure used to support digital transactions.

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

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

[0055] 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 a bank or any other financial institution that issues a card to cardholder 110. Acquirer 140 provides services for card processing to merchant 120.

[0056] The model also includes a central switch 150 - interactions between issuers 130 and acquirers 140 are routed through the switch 150. The switch 150 enables merchants 120 associated with one particular bank acquirer 140 to accept payment transactions from cardholders 110 associated with different bank issuers 130.

[0057] A typical transaction between entities in the four-party model can be divided into two main stages: authorization and settlement. A cardholder 110 uses their card to initiate the purchase of goods or services from a merchant 120. The card and transaction details are sent to the issuer 130 via the acquirer 140 and the switch 150 to authorize the transaction. The cardholder 110 may have provided verification information in the transaction, and in some cases may need to go through additional verification processes to verify their identity (such as 3-D secure in the case of online transactions). Once the additional verification process is completed, the transaction is authorized.

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

[0059] The transaction details are then routed by the acquirer 140 to the relevant issuer 130 via the switch 150. Upon receiving these transaction details, the issuer 130 provides the settlement funds to the switch 150, which in turn forwards these funds to the merchant 120 via the acquirer 140.

[0060] Separately, the issuer 130 and the cardholder 110 settle the payment amount between them. In return, the merchant 120 pays a service fee to the acquirer 140 for each transaction, and the acquirer 140 pays an interchange fee to the issuer 130 in exchange for the funds settlement.

[0061] In actual implementations of the four-party system model, the roles of a particular party may involve multiple elements acting together. This is often the case in implementations that have evolved beyond contact-based interactions between a customer card and a merchant terminal to digital implementations using proxy or virtual cards on a user computing device such as a smartphone.

[0062] Figure 6 An architecture suitable for interaction between a cardholder and a merchant according to an embodiment of the present disclosure is shown. The figure shows a general architecture for reference, but particularly shows specific elements of the architecture used when a cardholder conducts an online transaction with a merchant server.

[0063] For conventional transactions, the cardholder will use their payment card 6 - or a mobile computing device such as a smart phone 11 suitable for use as a contactless payment device - to conduct transactions with the POS terminal 7 of the merchant 2. However, in embodiments related to the present invention, the cardholder will use his or her computing device - which can be any or all of a cellular phone, tablet, laptop, static personal computer, or any other suitable computing device (a mobile phone or smart phone 11 is shown here) - and other computing devices (such as smart watches or other wearable devices) may also be used - to act as a proxy for the physical payment card 6 or as a virtual payment card that operates only in the digital domain. As described below, the smart phone 11 can achieve this through a mobile payment application and a digital wallet. The smart phone 11 can use it to conduct transactions with the merchant POS terminal 7 using NFC or other contactless technology, or to make payments in association with its wallet service as discussed below. However, embodiments of the present disclosure are particularly concerned with online transactions with merchants, rather than contact or contactless transactions with merchant POS terminals 7. To conduct online transactions, the smartphone 11 can also interact with a merchant server 12 representing the merchant 2 over any suitable network connection, such as the public Internet - the connection to the merchant may be provided by an app or application on the computing device.

[0064] The transaction scheme infrastructure (transaction infrastructure) 5 here not only provides the computing infrastructure required to operate the card scheme and provides transaction routing and other messaging to parties such as acquirers 3 and issuers 4, but also provides wallet services 17 that support digital wallets on cardholder computing devices, and provides an Internet gateway 18 to accept Internet-based transactions for processing by the transaction infrastructure. In other embodiments, the wallet service 17 can 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 can be provided by a third party with an appropriate trust relationship), and the transaction scheme infrastructure provides digital implementation services 16 to support the execution of tokenized digital transactions, as well as interacting with other elements of the system so that transactions are properly executed-this digital implementation service can include other elements, such as token service provision.

[0065] For tokenized transactions, the transaction is validated in the transaction scheme by mapping the cardholder token to their card PAN, checking the token status (to ensure it is within the expiration date or otherwise valid), and any customer verification methods used. This allows the issuer to authorize the transaction in the normal way.

[0066] Figure 7 Elements of a transaction infrastructure supporting digital payments from a mobile device are shown in more detail. The figure shows the applicant's Mastercard Cloud Based Payment (MCBP) architecture as a specific example - this is exemplary and not specific to the present invention, and illustrates how the architecture can be used to support a mobile payment application 215 on a mobile device (such as a smart phone 11) - here the 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 a payment card 6 used by the mobile device 11.

[0067] MasterCard Digital Implementation Service (MDES) 42 performs various functions to support mobile payments and digital transactions. As described above, MDES 42 is exemplary only - for example, other embodiments may use digitization, tokenization and provisioning services associated with other transaction processing infrastructures. The wallet server 17 is not part of MDES 42 - and does not need to exist if, for example, the mobile payment application 215 is not embedded in the digital wallet 41 - but acts as an interface between the mobile device 11 and MDES 42. MDES 42 also mediates tokenized transactions so that they can be processed through a transaction scheme like conventional card transactions. The following functional elements are displayed within MDES 42: Account Implementation System (AES) 43, Credential Management System (CMS) 44, Token Library 45 and Transaction Management System (TMS) 46. These will be briefly described below.

[0068] The Account Implementation System (AES) 43 is used for card digitization and user establishment. It will interact with the mobile payment application (here through the wallet server 17) for card digitization requests, and will populate the token library 45 when tokenizing, and will interact with the CMS 44 to establish a card profile with associated keys for digital use of the card.

[0069] 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 delivery of necessary elements (such as digitized cards and credentials and keys) to the mobile payment application in the form required for use. The system can also interact with the wallet server 17 to manage the mobile payment application.

[0070] The token vault 45 - shown here as being within the MDES 42, but it may be a separate element under separate control - is a repository for token information, including the correspondence between tokens and associated cards. When processing a tokenization transaction, the MDES 42 will reference the token vault 45, and the tokenization of the card will result in the creation of a new entry in the token vault 45.

[0071] A transaction management system (TMS) 46 is used when processing tokenized transactions. If the transaction scheme identifies the transaction as being tokenized, the transaction is routed to the TMS 46, which de-tokenizes the transaction using the token library 45. The de-tokenized transaction is then routed to the issuer (here represented by the financial authorization system 47) for authorization in a conventional manner. The TMS 46 also interacts with the CMS 44 to ensure synchronization related to the cardholder account and credentials.

[0072] The embodiments of the present disclosure are directed to implementing a method for executing Figure 7 Aspects of the system for digital transactions shown in —— especially the management and use of credentials —— can be decentralized. This is done by replacing the central node with a set of decentralized nodes, each of which is capable of credential management, such as Figures 8 to 10 as shown in .

[0073] Figure 8 A decentralized system of computing nodes Nx is shown, each of which is capable of generating G and verifying V credentials. These credentials may be valid for the entire system (unless limited to some nodes due to on-soil regulation, etc.), and are in this case associated with the transactions of a set of users (clients) whose transactions are typically routed to the node by geographical proximity. Nodes provide credential generation G and credential verification V as services to clients, and need to be able to securely generate credentials and securely verify them at least while they are valid. In the architecture shown, the credentials are not stored - they are generated upon request and verified on the fly. As Figure 8 and Fig. 9 As shown in , in addition to credential generation and verification, key management K and monitoring M can be considered as services both local to the node and across the system, and access control AC is usually required to allow access to the services. These aspects will be described in more detail below.

[0074] Elements of suitable computation nodes such as Fig.10 . Node 80 includes at least one network connection 81 to allow communication with clients 90 and other nodes 91 and (in this example) a central node 91a that coordinates activities between one or several nodes. Communications are shown here as being through separate networks to each set of other parties - through 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 may be physically different or may have different security requirements and protocols.

[0075] Node 80 contains a number of 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. Also included within node 80 are a number of hardware security modules 85 (HSMs) suitable for storing cryptographic material and securely performing cryptographic functions. The elements within node 80 are shown here communicating with the aid of a bus 86. Although in this case node 80 is represented as a single data center, this is not required - the "bus" may, for example, include a dedicated network connection between a set of related data centers, which allows them to provide real-time responses so that they appear to be part of an integrated whole to other entities communicating with the node.

[0076] The existing credential management process in payment systems is 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 according to a hierarchical process. An Issuer Master Key (IMK) is associated with a token of a specific scope, and the keys used for the credentials are derived hierarchically (Card Master Key -CMK- from the IMK, and then Session Key -SK- 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 very rapidly compared to device-based interactions, where growth is more aligned with resources.

[0077] In the digital ecosystem, while there is a very rapid growth in demand, there is also generally a more secure environment because the interactions are generally between the merchant system (or payment service provider) and the transaction system through a secure pathway between participants with clear identities. Therefore, when all assets are kept securely in a restricted environment including key management and cryptographic operations, when APIs to access services are exposed, when services are provided in a server context, there are interactions in the device context that may require multiple cryptographic operations for security that can be streamlined.

[0078] While it would seem desirable to scale the transaction system used to perform digital EMV transactions by using a set of distributed servers to generate and verify credentials, this approach was found to be unscalable. The overall level of key generation would not change, but the volume of messaging within the system would increase significantly, as a very large number of tokens would need to be managed and replicated. Since existing EMV key generation methods require custom-made hardware security modules (HSMs) in place of off-the-shelf ones, processing requirements are high and costly, and data storage and, in particular, network latency would become unmanageable issues.

[0079] Embodiments of the present disclosure support this distributed approach by replacing the binding of a token with a specific hierarchically derived key, thereby allowing the first available key from the key stack to be assigned to a tokenized transaction instead. This approach uses flexible and dynamic key management, allowing for a scalable solution. It can be monitored in a way that ensures the security of the distributed architecture without the need to transmit or copy large amounts of sensitive information. This approach can also be performed in a standard HSM using a fully FIPS compliant process - for example, DES and 3DES do not need to be used. This approach is described in more detail below.

[0080] Currently, the device security model is also used for fully digital transactions. This security model involves the Issuer Master Key (IMK) being stored in the transaction system HSM and used to derive the Card Master Key (CMK) from the associated IMK and the card PAN (Primary Account Number). These CMKs are then stored in the device (usually a secure element or alternative technology). When a mobile device is used to generate transaction credentials using a software-based solution, a Session Key (SK) is generated using the associated CMK and the card / device’s ATC (Application Transaction Counter) – this is currently done by e.g. Figure 7 . Currently, all tokens, even for fully digital transactions, are bound to this IMK / CMK / SK derivation. This also applies to transaction credentials generated by the server through the API exposed by the transaction system for remote payment transactions.

[0081] Although the term PAN is used generically below, in the context of digital transactions, it is also appropriate to use the term TUR (Token Unique Reference) to refer to the unique identifier of a card or account. Literally, these terms should be used in the following expected manner to distinguish one from the other:

[0082] ● PAN is a value directly associated with an account - this is the normal (numeric) way of identifying an account - the term FPAN or Funding PAN may be used to indicate a reference to the issuing bank account;

[0083] ●TUR or “Token Unique Reference” is a value that allows a token to be identified without exposing any PAN value. A mechanism exists in the transaction system to determine which PAN is associated with the TUR.

[0084] However, when the term PAN is used below, it should be understood that this is an identifier used in a broad sense that may be associated with an account that identifies it - and thus use of PAN below may include TUR.

[0085] This approach requires a very heavy key management load, which is not suitable for fully digital transactions, as shown below Fig.11 and Fig.12 As discussed. The generation of SK and therefore the application of cryptography (AC - standard mechanism in EMV transactions) requires multiple cryptographic operations, not all of which can be performed by regular off-the-shelf HSMs, so customized HSMs are required. Keys need to be distributed in large quantities throughout the system so that the execution of transactions can be supported wherever transactions occur, and ATC management is complex. It is desirable to use standard HSMs, avoid large-scale key duplication, make keys directly available, and provide a solution that limits the number of overall HSMs (as they usually only support a few thousand keys).

[0086] Much of this security is about providing assurance even when the system endpoint (e.g., at the cardholder device) is potentially compromised. Beyond that, security is limited, e.g. Fig.11 The main purpose of cryptographic functions is to provide assurance - this covers both integrity and authentication of data. The transaction-related data protected by cryptographic data includes the identification of the transaction and the associated token, as well as an indication of any cryptographic processes used and any relevant financial data (as well as any other aspects of the transaction that need to be assured). This is represented by the transaction voucher - this requires the generation of G and subsequent verification of V, these processes are monitored M to ensure overall system integrity and supported by some kind of key management system K.

[0087] In the case of fully digital transactions, these processes take place in a constrained environment where endpoint security is not as much of an issue as it is on the device. Fig.12 As can be seen in , in this domain, the token does not reach any end point of the conventional transaction management system - the cardholder or the issuer. Instead, it operates across the merchant system or payment service provider (PSP) and the transaction solution provider.

[0088] This approach allows the decentralization of credential systems from complex central servers to multiple nodes that provide services. These nodes are typically geographically distributed, but may be extended to multiple data centers (for example, by using cloud infrastructure to enable data sharing within the nodes). These nodes provide services related to credentials, generation services G and verification services V, and define rules for access control to the services. Merchants or PSPs communicate with the generation service G to obtain credentials, which are then used in the standard authorization process, calling the verification service V when the credentials need to be verified. These services have access to the computing infrastructure of the nodes (HSM, databases). Monitoring M and key management K services are also provided - these services can be centrally organized or include a mix of coordination and local functions. All these services and their relationship to each other are described in more detail below.

[0089] Access control to services can be provided in a substantially conventional manner. A set of common controls can be defined for a node, and can be modified locally - for example, to meet local regulatory or other specific security requirements. This approach can easily implement country-specific policies, for example by restricting all business in a particular country to a specific set of nodes. Access control can be performed at more than one level (for example, for individual services, but also for nodes), and there can be specific rules or checks for specific service types. Access control is potentially very granular, and specific solutions can be provided 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 for a given token.

[0090] Fig.13The key management mechanism shown in illustrates how a finite number of keys can be distributed to nodes while providing a deterministic process for picking the keys used to generate credentials. The same process can be used by the verifying entity to determine the key used by the generator so that it can verify any cryptographic material that is part of the credential submitted for verification.

[0091] For each node, both the generation G and verification V services have access to a pool of HSMs. The HSMs contain keys that are each uniquely identified by a set of key identifiers (KeyIds). A KeyId can be a label, a value, a clear unique value (such as a UUID), or anything else with appropriate attributes. These KeyIds are stored in unique identification (identifier) ​​key lists—these key lists provide a list of relationships between identifiers (Ids) and stored keys (KeyIds). The identifier (Id) is determined by a deterministic process in order to establish what key to use, as will be described further below.

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

[0093] Fig.13An exemplary arrangement of a node Ni is illustrated, which has two generation services G that are capable of generating credentials associated with a transaction. At any given point in time, these services G will be required to use a given key list - such as key list A in the first example. This uses yellow and blue keys, so these keys must be loaded into the HSM used by the generation service G. After a period of time has expired, the key rotation process may, for example, force the use of key list B - this uses yellow and blue keys, but also uses green keys, so the green key must be loaded into the relevant HSM (if not already present). The specific key to be used is selected from the key list by a deterministic process, as will be discussed below - this will usually give different results after key rotation, but this is not inevitable (for example, Id=3 or Id=6 will give a blue key before or after rotation). Although the generation service G does not need key list A after key rotation, the verification service V still needs it - they need to access any key list associated with potentially valid credentials. The verification service V must be able to determine exactly which key the generation service G used to generate the credential in order to verify the credential.

[0094] The transaction-related data to be cryptographically protected includes the identification of the token associated with the transaction, but also the identification of the transaction itself. For this purpose, some kind of transaction identifier is required. At each node, the credential generation and verification services have access to a local database that can be used to manage such data. To ensure that transactions are managed efficiently across the system, any transaction credential generation for a given token should be associated with a unique transaction identifier for each transaction. This can be a UUID, but as mentioned earlier, it is challenging to establish a UUID in a distributed system where transaction identification may need to be performed by one of multiple distributed nodes. In an embodiment of the present disclosure, an appropriate identifier structure (such as a cascade of an n-bit node identifier, an e-bit epoch time, and a c-bit local counter) may be used.

[0095] In an embodiment of the present disclosure, the size of the data transmitted in the transaction voucher can be reduced to a few digits by using a local transaction counter. This can simply be stored in the node's local database, and when the local generation service G generates a new token, the local (rather than the global) value is incremented, such as Fig.14 The process shown in the general terms of . The local transaction counter (LTC) can thus contribute to the above-described effective unique identifier structure, where the combination of node identification, time, and the local transaction counter is used to effectively and uniquely identify a transaction. As will be discussed further below, the use of key list rotation using a time-based process allows the LTC value to be reset at the end of a time period without losing these characteristics, while limiting the size of the data required to transmit the LTC value as part of the transaction flow. This and other uses of the local transaction counter are described in further detail below.

[0096] Now refer to Fig.13 An exemplary process for identifying keys for transactions is described. As described above, at any given time, the generation service G has access to a set of keys in the local HSM and uses keys according to its currently active key list. The key list itself is uniquely identified (by Identifier) ​​and contains a list of entries corresponding to the relationship between an identifier (Id) and a stored key (represented by KeyId). In the case of key list A, there are ten entries, and each Id is an integer.

[0097] There will be a deterministic process associated with the key list that determines which key will be associated with a given transaction. This does not need to be the same deterministic process for each key list, but it needs to be used consistently for that key list so that both the generation and verification services will obtain the same results. In order 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 conveniently available and easy to handle. It is not necessary to use the full unique identifier discussed above here - the identifier only needs to be able to determine which key was selected within a given node within a given time period, so a local counter (such as an LTC) is suitable for this purpose. As will be seen below, this allows the selection to be made in a deterministic manner that can be replicated by another party seeking to verify the transaction.

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

[0099] The entire process of key selection using LTC in the embodiment is Fig.14 shown in and still in Fig.26The LTC is part of the transaction-related data and, as we will see below, is used in several ways to determine whether a credential can be generated or is valid for use. The LTC is also used to calculate a value for selecting a key tag (which can, for example, come from a position within a key list). This tag is associated with a specific key (keyId) held in the HSM, and the HSM uses this key in its cryptographic functions to generate a cryptographic result that can then be verified by another party (a verification service in the same node or another node).

[0100] HSM cryptographic functions should be suitable for ensuring data integrity and authentication through credential generation and verification. Cryptographic functions operate on selected transaction data using a key and provide output that does not expose the key. Various alternative cryptographic functions can be used - HMAC is a particularly effective choice, but CMAC, CBC MAC are possible alternatives. The cryptographic function used should be specified in the key list (such as keyList.CryptoFunction) and is also driven by the capabilities of the HSM used for generation and verification. Soil regulation, export of cryptographic material or other security considerations may lead to the selection of a specific cryptographic function.

[0101] Within the transaction data there should be information representing the application password generated during the transaction process. This may be a simplified form of the password - for example, in a traditional transaction this may be provided as a CVC2 field. This is important because the verification service V must have access to all the data used by the generation service G to generate the password - this will include the following:

[0102] Dynamic information transmitted as part of the transaction process;

[0103] Shared information from one of the following:

[0104] replication processes (such as key list management);

[0105] System parameters for specific use cases.

[0106] The standard approaches for different use cases – traditional transactions, UCAF and DPD field transactions – are discussed further below. The traditional transaction use case provides a solution when merchants and / or PSPs can only manage PAN, expiration date and CVC2 as part of the transaction flow and do not have access to recent developments. The UCAF use case aims to leverage the recently introduced universal cardholder authentication field to convey more data as part of the transaction flow. The DPD use case covers the introduction of digital payment data, a container capable of conveying all the data required as part of the transaction flow.

[0107] A complete set of password mechanisms such as Fig.15 Reference Fig.16 Discuss key management. There are two aspects of key management in this model: the management of the keys themselves, including their generation and delivery to the HSM associated with the node, and the management of key lists, including their generation, distribution, activation and deactivation. Key lists are sensitive assets, while keys are considered secret assets - key lists define the keys used for the generation and verification of passwords. When loading the keys into the HSM, the keys require end-to-end security, where wrapping / unwrapping techniques are used to securely transmit the keys. Their use should not be affected by the key list in case an attacker wants to change the content of the key list to change the key selection process. The integrity of the key list is guaranteed by a seal - providing a seal for the key list by the generating party or an associated trusted party will involve a suitable cryptographic process (such as HMAC with a suitable private key or using a digital signature generated, for example, using an asymmetric algorithm (such as RSA, ECC, SM2...)), and the 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. In addition, the key list seal can be used for the generation and verification of passwords to protect credentials.

[0108] Different control models are possible. There may be central control, where a central service generates keys and key lists and distributes them to different nodes. However, there may also be localized control if dedicated processes are required at specific nodes. This may be particularly applicable if there are specific requirements for a specific country - for example, soil regulation or restrictions on the export of cryptographic materials. This may also be applicable if HSM management requires proprietary mechanisms - for example, a specific cloud service provider. This does not need to be node-restricted - it can apply to regional control with a central service within a region (this may be particularly applicable if a specific country has a specific security model to meet local legal requirements). There may also be hybrid or composite models where some key and key list provisioning is central and some is local - there may also be distributed models where distributed peers together take on the role of a central service.

[0109] and Fig.17 The monitoring discussed in this connection can have both local and central aspects. While both local and centralized monitoring are possible, a hybrid approach can be particularly effective in order to provide effective detection of any issues and generate effective responses to offset the risks associated with a fully distributed architecture.

[0110] There are three main categories of monitoring to consider: 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, it is important to effectively monitor the entire distributed system. Risks to consider include attackers abusing the real transaction credentials generated by the generation service G in a node, especially by trying to verify them in multiple verification services in other nodes - this is a problem because the verification service V does not usually see the actions taken by the verification service V in other nodes of the distributed system in real time.

[0111] While monitoring is important to maintain the integrity of the system, it is also important to limit the amount of messaging generated to ensure that the system is scalable and not overloaded by the monitoring process. Several options can be made to ensure an effective monitoring process. One is for the monitoring process M to be fed directly by the credential generation service G. Another is: since any verification service V can verify transaction credentials, provide a common storage for all verification services V at any given node. This allows associated data management local to the monitoring service M to provide an initial layer of defense, especially against replay detection.

[0112] The local monitoring service may then be able to report to other nodes via a central monitoring service (hub and spoke) or directly (peer to peer), thereby reporting to other verification services V as a second layer of defense to prevent abuse of transaction credentials across nodes.

[0113] The validation service itself obviously checks that the transaction credentials are valid, and can cascade to detect any problems (such as validation failures, excessive retries, and invalid transaction data or key list references) - these can be used to suspend tokens across nodes. Additional controls can also be implemented, such as random checks on the verification of key list seals. Another monitoring process is the association between different service types - here generation G and verification V - to detect whether transaction credentials have been lost (due to non-submission, abnormal generation, or other reasons). The use of cryptographic material can be tracked to track that it is used appropriately and that the system is configured appropriately - for example, the number of cryptographic operations using a given stored key can be tracked.

[0114] As mentioned above, one principle to follow for effective monitoring is to provide an effective solution without placing excessive load on distributed systems. This can be done by supporting different levels of information (e.g., monitoring locally where appropriate, and only communicating summaries of local monitoring activities further) and reducing load through data replication and sharing.

[0115] Monitoring may vary from node to node, or from region to region, where specific requirements exist. A specific monitoring process may be used at a given node or in a given region to address soil or personally identifiable information (PII) requirements in a given geographic area.

[0116] The challenge involved is to effectively identify in a transaction how the credentials were generated in order to enable their subsequent verification - in particular, identifying which node generated the credential and which key list was used to complete it, as well as the state of the local transaction counters. This is challenging because transaction data is highly restricted, and in order to provide any such information, it is necessary to change existing electronic transaction protocols (such as ISO 8583) or repurpose existing fields.

[0117] For traditional electronic transaction protocols, fields that could in principle be repurposed are the primary account number (PAN), since some of the digits within the PAN may be implicit in the context of such transactions and could therefore be reused, and the expiration date, some of which may be transmitted in a compressed format as well as CVC2. Six bits could be freed up directly using the expiration date as a carrier, but this is not enough - for any extended system, a node identifier would typically require at least four bits, and one bit may not be enough for a key list reference or transaction counter.

[0118] One approach that can be used is to use a set of specific Bank Information Numbers (BINs) that make up the first six digits in the PAN to support the above implementation - when one of these BINs is detected, special processing can be applied. This may involve associating a token with multiple PAN values. This model is as follows Fig.18 As shown in the figure. The FPAN (Fund Master Account Number - corresponding to the physical card account) - can be mapped to one or more tokens, but specific tokens are associated with specific technologies. The top row shows the conventional tokenization process - the FPAN is associated with a single token. Using the above approach, for the traditional acceptance use case (bottom line), a token can be associated with nine PAN values, but as described below, a one-to-one mapping can still be used for some new formats.

[0119] Therefore, the reuse of transaction fields in the traditional case can be as follows. For PAN, 14 bits can be used to fully identify the token, with 1 bit used for the counter associated with the token for a given number, and 1 bit for the Luhn number (which needs to be retained as a checksum to ensure that a valid number is used). The 6 bits of the expiration date can be reused, with the x bits used to identify the node and the y bits used to reference the node's associated key list. CVC2 provides three bits that can be used for the password.

[0120] For security purposes, it is desirable to change the key list regularly to ensure that the system is secure from attack. It is also important to be able to allow validation of credentials for a period of time after they have been created - the recommended approach is to allow validation of credentials up to 24 hours after creation. If this is combined with a key rotation process that operates every 24-36 hours, this means that while the generation process will only have one active key list for a given node, the validation process will only need to consider two key lists (one currently active for credential generation, and the other active immediately before it). The key to be used is established using a deterministic process based on a transaction counter. This type of binary information (i.e., one or the other) can typically be encoded using one bit of information. Cryptography plays a key role in protecting the integrity of transactions - successfully validating a cryptographic key calculated for a given data set using the correct key confirms that the data originally used for credential generation is authentic. Any failure in the validation process may come from using incorrect cryptographic material and / or corrupted transaction data.

[0121] Fig.19 An exemplary key rotation process for this traditional arrangement is shown in . First, new keys are provided to the HSM as needed - this may be distributed from a central source, or through another key generation process, such as through local key generation. A new key list is then generated - this may involve existing keys and new keys - here, most of the slots in the key list involve existing keys in new positions in the key list (but keys may also remain in the same position in the key list - as shown here for key list positions 2 and 6), but new keys are also used in positions 3, 7 and 8. Again, this may be a central process, one managed by a peer in a distributed network, or a local management. The new key list is distributed to any verification service eligible for verification and a single generation service that uses it to generate. The new key list is then activated in the verification service, and then in the generation service, which automatically deactivates the previously active key list in the generation service - at this point the key rotation process is complete. After 24 hours, the previous key list is then deactivated for the verification service. This approach works with the limited space available in the traditional case - just switching a single bit indicates which key list is used.

[0122] One potential problem is that the number of transactions performed for a given token appears to be limited by the space available to transmit the transaction counter. One solution would be to increase the space available for the transaction counter, but this would correspondingly limit the number of available tokens (since this is the only place the additional bits could come from). Another possibility would be to use a "retry" procedure if verification initially fails to recover a "full counter" value, where that value is larger than the original available space and is stored only as a modulo value. The two approaches could be combined. It is also possible to introduce different rules for different token ranges.

[0123] In each node, each generation (G) and verification (V) service has access to a local database. The generation of any transaction credentials for a given token is associated with a unique transaction identifier for each transaction. As mentioned above, for a given token in a given node, the local transaction counter (LTC) is managed by "G" using a given list of keys associated with a given use case. The same process applies when verifying by "V". This information can be transmitted in the PAN field (digit 15, or digits 14 and 15), as Fig.21 As shown in or Fig. 22 As shown in the use of the CV2 field, where there is a retry flag in the expiration date field, if the LTC is at a higher value, then a "full counter" is generated if necessary. However, it is important to limit the number of passwords that can be generated by G and verified by V for a given token for a given node for a given key list to ensure effective access control - this value "MaxTransactionCounter" can be stored in the key list and protected by the key list sealing lock.

[0124] Fig. 20 The cryptographic process for this conventional case is shown in . In this case, HMAC is chosen as the cryptographic function as this allows the use of a generic HSM while delivering valid functionality. The identification of the token uses the PAN value. The identification of the transaction takes information from the expiration date (ISO 8583 field DE14) - specifically the node identifier and reference, possibly with a retry flag - and from the PAN field which holds a local transaction counter. The identification of the key and the cryptographic method are provided by the local transaction counter (which determines which key is selected from the key list) together with information shared in the key list by the key management system. The various fields defining the transaction can be used as financial data (such as TokenID) for generating cryptographic keys. Fig.18 All of these fields are used to generate a password which is then decimalized and the three least significant digits are used in the CVC2 field.

[0125] Those skilled in the art will recognize that some variations of these protocols may prioritize certain choices or priorities. For example, it may be desirable to find more efficient ways to transfer data, such as avoiding the use of a local transaction counter that retries a process when more data can be transferred during a transaction flow—such as from Fig.21As can be seen in Figure 1, the process shown above allows the transaction counter to use up to two digits of the PAN (and using two digits limits the number of tokens that can be provided) and maintains a reduced password in three CVC2 digits. A different approach is to use only two digits of the CVC2 field in the password instead of three, with the other digit being used to maintain the rightmost digit of the local transaction counter. This can be provided in a more dynamic way by rearranging the three digits into a different order - this can be done by adding a CVC2 encoding table to the key list so that when the key list is used, the encoding table - also protected by the sealing lock - determines the encoding selected to provide the CVC2 field. The code can be selected from any value known to both the G and V services - for example, the Luhn number of the PAN. A new key list can then use an entirely different encoding table, making the process significantly more dynamic.

[0126] This arrangement is Fig. 22 The PAN digits identify the token and also provide the Luhn number, and the Luhn number is used to determine the digit order of the CVC2 field - in this case, option 3 is selected, indicating that the least significant digit and the next least significant digit of the password are in the first two positions, and the least significant digit of the counter is in the third position. This results in both the G and V services being able to derive a CVC2 output.

[0127] If newer versions of the electronic transaction protocol are used, then additional fields can be used to convey more information. For example, where the Universal Cardholder Authentication Field (UCAF) is available (ISO 8583DE48 SE 43), many additional bytes can be used, allowing the compromises used in the legacy case to be avoided. This approach can free up an additional 21 bytes of data to convey data as part of the transaction flow. This is sufficient to allow the full local transaction counter value to be conveyed, thus avoiding the need for any retry mechanism. More cryptographic material can be used - 8 bytes of cryptography instead of 2 or 3 numeric bits. More nodes can be used without node identification becoming an issue due to the limited space available in the transaction data defined in the electronic transaction protocol requirements. Key lists can also be rotated more frequently than 24 hours, as there is space to use more than one bit for key list identification for the authentication service. The available space in the transaction data can be used to provide additional features, for example by supporting merchant locking techniques (where some form of merchant identification is used to effectively tie the transaction to a given merchant), by including additional components in the cryptographic process (such as by using some random element or seed between the generator and the verifier), or by taking additional measures to provide full compliance with any regulatory requirements.

[0128] As from Fig.23As can be seen in Figure 1, using the new layout of the UCAF content (e.g., format 7—this is an identifier of the applicant's proprietary UCAF format) there are 21 bytes available. One byte can be split between the version identifier and the codebook to specify the conditional data used in the cryptogram generation. The full byte can be used to hold a local transaction counter—this means that the generation service G will be able to generate up to 255 cryptograms per key list for a given token for a given node, which should prevent the need to retry the counter and resolve the need for transaction credentials before activating a new key list. Another byte is sufficient for the node identifier data and the key list reference, which leaves a full 10 bytes for the conditional data used in cryptogram generation and / or verification—each use case is associated with a value in the codebook—thus allowing the use of data different from that transmitted in the authorization message (the transmitted data may include unpredictable numbers for transactions, merchant data such as merchant type and card acceptor or acquirer ID code, amount related information...). 8 bytes can be used to truncate the cryptogram, significantly improving security. Fig.24 Indicates how the password process is related to Fig. 20 The differences shown in - PAN, LTC, node identifier and reference can all be easily included, and additional information such as additional transaction fields, codebooks and other conditional data can be included in the generation (or verification) of the cryptogram.

[0129] This approach offers a variety of further possibilities. Supplying additional bits for keylist references allows for twice as frequent keylist rotation. While some requirements remain - such as the need to limit the number of cryptograms generated by service G for a given token for a given node for a given keylist - others are exempted (the presence of a full LTC means that no retry process is required). It should be noted that keylists may be limited to specific use cases - legacy, UCAF or DPD - and this can be used to determine specific limits on transaction counters for a given use case.

[0130] A new format called DPD (Digital Payment Data) will soon be introduced – this will provide even more options, such as Fig.25 As shown in . As described above, the DPD can transmit the UCAF to the credential. In the first option, the generation service can define a unique identifier (such as a UUID) at transaction creation time and add it to the list of data used in the cryptographic process - this allows the transaction credential to be tracked end-to-end independently of the transaction details, providing monitoring and fraud prevention advantages. In the second option, a much larger codebook can be used, as well as extended identification of nodes, storage of more conditional data and use of standard truncated cryptographic used in other transaction flows - as well as UUIDs for the first option.

[0131] The role of the local transaction counter (LTC) in embodiments of the present disclosure will now be described in more detail. As described above, the LTC helps to provide a unique identifier for a transaction. The LTC itself is not unique, but when combined with other values ​​- such as the node identifier and time period identifier as described above, but also other values, such as the key list identifier and PAN / TUR - it can provide a unique identifier, in particular a unique identifier for a transaction performed by a given node with a given key list having a given PAN / TUR. As also described above, the LTC can also be used to provide a deterministic means of selecting a key from a key list for cryptographic generation and verification.

[0132] In addition to these features, LTC can also be used to track various activities related to transactions, and can provide specific benefits in situations where only limited data can be transmitted in the transaction fields (such as the traditional use cases discussed above). This is related to replay detection (verification of transaction credentials submitted for a given LTC value that have already been used for a given node and key list) and tracking failed passwords and retries (where more than one verification attempt is required).

[0133] LTC management is discussed below for all use cases (Legacy - L, UCAF - U, DPD Option 1 - D1; and DPD Option 2 - D2). In the legacy case, as discussed above, the dynamic expiration date field is used to convey additional information related to the LTC - the impact of the dynamic expiration date on the verification process is also discussed below.

[0134] First, the basic operation of the local transaction counter at the generation service G and the verification service V will be discussed.

[0135] Generate Service

[0136] LTC in service performance and in generating the database of service G (db G ) plays a key role in recording service operations in the node. This database is used to track the activity of a given node (N) using a given list of active keys identified using keyList.Identifier. i ) of each LTC value. When a transaction is generated for a given PAN or TUR (hereinafter referred to as PAN / TUR) for the first time, an entry is created in the database. This entry contains only one LTC value and is updated with this given key list in this given node when any subsequent transaction voucher for this PAN / TUR is generated.

[0137] The process of doing this is as follows. First, a default value of LTC is established for the first generated transaction voucher and stored in the database (db G) for the given PAN / TUR as indicated. For any subsequent transaction voucher generation for that PAN / TUR, the counter will be incremented until the PAN / TUR reaches a limit value of LTC. This limit value may be defined in the key list (keyList.Limit.LTC). The transaction voucher generation service G will then stop generating transaction vouchers for that PAN / TUR using that key list until a new key list becomes active for that node.

[0138] Authentication Service

[0139] The credential verification service (V) also uses the database (db V ), the database uses the LTC value of the verified credential. The database stores any given node (N) using a given-active-keylist identified by keyList.Identifier. i ) of LTC values. An entry is created when a transaction credential for a given PAN / TUR is first verified using a given list of keys associated with a given node. v ) is associated with a list of LTC values, a list of counters (Replay, CryptoFailure, and Retry - all default to 0 and incremented by appropriate events, as described below). Any subsequent validation of transaction credentials for that PAN / TUR using a given keylist associated with a given node will result in an updated database entry. When a keylist is deactivated, the keylist used to validate transactions generated by a given node (N) is deactivated when credentials generated using that keylist can no longer be legitimately validated. i ) A database of transaction credentials generated for this key list using keyList.Identifier (db v ) will be deleted. There is a delay between the deactivation of the key list used by the generator and the deactivation of that key list by the validator(s) of the generated transaction credentials. This delay is driven by business rules, allowing, for example, up to 24 hours between the generation of a transaction credential and its valid validation.

[0140] In addition to modifying the entry when the transaction has succeeded, the password verification process, as described further below, will also update the database (db V ) for additional purposes: detecting and tracking replays; tracking password failures; and tracking retry counts.

[0141] The verification process will now be described in more detail, with a particular focus on LTC management issues. In this context, the verification process covers the following:

[0142] ●Service Request Management

[0143] ● Collect and process transaction-related data, including:

[0144] ○Token identification (PAN / TUR)

[0145] ○Transaction identification (using LTC)

[0146] ○ Identification of the key list (using the node information and the identifier of the key list)

[0147] ○ Identification of transaction keys and cryptographic functions

[0148] ○ Any processing of financial or other data

[0149] ●Password verification

[0150] ●Verification of transaction credentials

[0151] ●Processes common to any use case (L, U, D1 and D2)

[0152] ● Specific processes for the selected use case (L, U, D1 or D2)

[0153] ●Report to local monitoring (mV)

[0154] As indicated above, this document focuses only on LTC usage, so other aspects of the authentication process are not described in detail here.

[0155] As described above, the key list may contain a limit value of LTC (keyList.Limit.LTC) to control the number of transaction vouchers that can be generated by the voucher generation service G for a given PAN / TUR using a given key list in a given node in a given time period. This limit value may also be used by the verification process. The key list may also contain additional fields to enable dynamic management of other limits.

[0156] If we consider the list of keys used by:

[0157] Node N i , used to generate transaction vouchers

[0158] Node N i (or any qualifying N j ), used to verify transaction credentials

[0159] The authentication process done by Vx uses a key list to support:

[0160] ●Replay management (keyList.Limit.Replay)

[0161] ○ The value Limit.Replay is used to limit the number of replay attempts before the PAN / TUR can be paused

[0162] ○Counter.Replay is composed of nodes (N i or any matching N j ) is used to track the i )Use with N i The number of replay attempts for verification of transaction credentials generated for a given PAN / TUR associated with a given key list.

[0163] ●Crypto failure management (keyList.Limit.CryptoFailure and keyList.Limit.CryptoFailureReset)

[0164] ○ The value Limit.CryptoFailure is used to limit the number of cryptographic authentication failures before the PAN / TUR can be suspended.

[0165] ○Counter.CryptoFailure is generated by node (N i or any matching N j ) is used to track the i )Use with N i The number of times cryptographic verification of transaction credentials generated for a given PAN / TUR associated with a given key list has failed.

[0166] ○ The value Limit.CryptoFailureReset is a Boolean parameter that determines whether a valid password can be used to reset Counter.CryptoFailure.

[0167] ●Retry management (keyList.Limit.Retry)

[0168] o The value Limit.Retry is used to limit the number of retries before the PAN / TUR can be suspended.

[0169] ○Counter.Retry is composed of nodes (N i or any matching N j ) is used to track the i )Use with N i The number of retries after a cryptographic verification failure of a transaction credential generated for a given PAN / TUR associated with a given key list.

[0170] As will be appreciated by those skilled in the art, suspending the PAN / TUR is one countermeasure that may be used to protect the PAN / TUR from any fraudulent or anomalous use.

[0171] Retry is only used for the legacy (L) use case - this is not used when using a format that allows the full value of the Local Transaction Counter (LTC) to be transmitted (such as UCAF, DPD Option #1 or DPD Option #2). These limits and counters are node specific - they are not consolidated across all nodes. However, it should be noted that information related to these counters can be distributed across all potentially affected nodes using a coordinated monitoring process.

[0172] Each verification process (Vj, Vk, ...) has its own list of LTCs and a counter of each processed PAN / TUR corresponding to the transaction voucher generated by the given node using the given list of keys. Fig. 27 This arrangement is depicted in .

[0173] Fig. 27 An example is given of two generation nodes (Ni and Nx) using their own key lists.

[0174] ●Vj is able to verify the transaction credentials generated by Ni.

[0175] ●Vk is able to verify the transaction credentials generated by Ni and Nx.

[0176] ●Vj and Vk track processed PAN / TUR, managed at keylist / node level

[0177] List of counters and LTC:

[0178] ●Vj stores PAN / TUR related information of the key list corresponding to Ni

[0179] Vk storage:

[0180] ●PAN / TUR related information of the key list corresponding to Ni

[0181] ●PAN / TUR related information of the key list corresponding to Nx

[0182] The deactivation of a keylist triggers the deletion of the stored information. This can be seen as a reset of all counters associated with a given keylist. The verification process actions will now be considered in more detail.

[0183] The result of the validation process reports the following information when validating the password - it should be noted that additional information related to the retry process and dynamic expiration date management is required in traditional use cases.

[0184]

[0185]

[0186] Table 1 - Verification results

[0187] The validation process can use the function SetValidationOutcome() to collect information about the validation of the transaction credentials. This information will be used by the validation service V, but also by the monitoring service (which may be local to the node, coordinated across multiple nodes, or globally, or both). Replay and password failure restrictions are delegated and the management of retries is discussed further below.

[0188] The notification process is used when the associated limit (Limit.Replay, Limit.CryptoFailure or Limit.Retry) is exceeded. This may result in suspension of PAN / TUR.

[0189] The concept of using (STANDARD or SPECIAL) expiration dates is introduced below in the section related to the impact of dynamic expiration dates on the validation process - standard is the default value for the expiration date.

[0190] We will now discuss managing the validation process associated with LTC without retries - this is relevant for all use cases.

[0191] Replay and password failure limits are managed as follows. If PAN / TUR is not suspended, then the following process applies to node N i Verification of the transaction voucher generated. The suspension of PAN / TUR will be communicated to the verification service.

[0192] ●Use “the” LTC value

[0193] ●SetValidationOutcome(replayDetection=NO_REPLAY, retryControl=NO_RETRY)

[0194] Password verification

[0195] ○ Password (Success)

[0196] ■SetValidationOutcome(cryptoValidation=SUCCESS)

[0197] ■LTC is not in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0198] - Add LTC to the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0199] - if Limit.CryptoFailureReset, reset Counter.CryptoFailure[N i ,keyList.Identifier,PAN / TUR]

[0200] ■LTC is already in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0201] -Increment (or create) Counter.Replay[N i ,keyList.Identifier,PAN / TUR]

[0202] -Counter.Replay <Limit.Replay

[0203] ●SetValidationOutcome(replayDetection=REPLAY)

[0204] -Counter.Replay≥Limit.Replay

[0205] ●SetValidationOutcome(replayDetection=REPLAY_EXCEEDED)

[0206] ●Notify fraud management services (may result in suspending PAN / TUR)

[0207] ○Password (failed)

[0208] ■SetValidationOutcome(cryptoValidation=FAILURE)

[0209] ■Increment (or create) Counter.CryptoFailure[N i ,keyList.Identifier,PAN / TUR]

[0210] ■Counter.CryptoFailure≥Limit.CryptoFailure

[0211] -SetValidationOutcome(cryptoValidation=FAILURE_EXCEEDED)

[0212] -Notify fraud management services (may result in suspension of PAN / TUR)

[0213] ■LTC is not in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0214] - Add LTCM to the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0215] ■LTC is already in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0216] -Increment (or create) Counter.Replay[N i ,keyList.Identifier,PAN / TUR]

[0217] -Counter.Replay <Limit.Replay

[0218] ●SetValidationOutcome(replayDetection=REPLAY)

[0219] -Counter.Replay≥Limit.Replay

[0220] ●SetValidationOutcome(replayDetection=REPLAY_EXCEEDED)

[0221] ●Notify fraud management services (may result in suspension of PAN / TUR)

[0222] This process allows limits to be established efficiently and the fraud management service to be notified when limits are exceeded.

[0223] A possible option is to reset the counter for tracking crypto failures already after a crypto success (successful crypto verification). There can be a value -Limit.CryptoFailureReset in the key list for this purpose. Possible alternatives are:

[0224] ● Consider the counters and their associated limits defined for the lifetime of a given list of keys, without any reset [false].

[0225] ● Relax these rules and consider a valid password to be a sufficient condition for a reset [true].

[0226] Restricted delegation for replay and password failure can be achieved as follows. Again, if PAN / TUR is not suspended, then the following process applies to authenticating as node N i The generated transaction credentials. In this case, the verification service V is not performing the replay or password failure check itself according to the associated restrictions, but V is delegating it. The process is as follows:

[0227] ●Use “the” LTC value

[0228] ●SetValidationOutcome(replayDetection=NO_REPLAY, retryControl=NO_RETRY)

[0229] Password verification

[0230] ○ Password (Success)

[0231] ■SetValidationOutcome(cryptoValidation=SUCCESS)

[0232] ■LTC is not in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0233] - Add LTC to the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0234] - if Limit.CryptoFailureReset, reset Counter.CryptoFailure[N i ,keyList.Identifier,PAN / TUR]

[0235] ■LTC is already in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0236] -Increment (or create) Counter.Replay[N i ,keyList.Identifier,PAN / TUR]

[0237] -SetValidationOutcome(replayDetection=REPLAY)

[0238] ○Password (failed)

[0239] ■SetValidationOutcome(cryptoValidation=FAILURE)

[0240] ■Increment (or create) Counter.CryptoFailure[N i ,keyList.Identifier,PAN / TUR]

[0241] ■LTC is not in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0242] - Add LTC to the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0243] ■LTC is already in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0244] -Increment (or create) Counter.Replay[N i ,keyList.Identifier,PAN / TUR]

[0245] -SetValidationOutcome(replayDetection=REPLAY)

[0246] The reset of the counter used to track password failures after a successful password validation is an option defined using the Limit.CryptoFailureReset value from the key list, as described in the section above.

[0247] Another entity will manage the restrictions on Replay and CryptoFailure using the following process, which can override the verification results set by V:

[0248] ●Counter.Replay≥Limit.Replay

[0249] ○SetValidationOutcome(replayDetection=REPLAY_EXCEEDED)

[0250] ○Notify fraud management services (may result in suspension of PAN / TUR)

[0251] ●Counter.CryptoFailure≥Limit.CryptoFailure

[0252] ○SetValidationOutcome(cryptoValidation=FAILURE_EXCEEDED)

[0253] ○Notify fraud management services (may result in suspension of PAN / TUR)

[0254] This allows V to effectively delegate these checks to another entity, such as a fraud management service or any dedicated service that will perform these checks to reduce the load on the validator (V).

[0255] The special considerations for LTC management for the traditional use case will now be discussed. The traditional use case (L) is significantly more complex due to the problems caused by the limited space available to capture LTC and other data, as described above in reference Figures 19 to 22 As shown. UCAF (U) and Digital Payment Data Option #1 (D1) and Option #2 (D2) use cases have more space available - for example, in UCAF, LTC can be transmitted as part of the transaction data (e.g., as 1 byte in format 7, with further space available for conditional data). This avoids various issues that need to be addressed in the legacy use case (such as restoring the full value of the local transaction counter and retrying in case of cryptographic verification failure). In DPD, there is even more space available (2 bytes plus conditional data). Therefore, the content below is generally related to the legacy use case (L), but it is definitely pointed out below that it also applies to UCAF and DPD use cases (such as verification without retry).

[0256] As mentioned earlier, the traditional use case (L) has strict size restrictions on the data that can be transmitted as part of the transaction data, and can only transmit a portion of the LTC value - usually a single digit (C). This means that a recovery process must be adopted to efficiently and reliably recover the LTC data. For the traditional use case, the verification process has two flavors - the "no retry process", as described above and used for all other use cases, and the "retry process" specific to the traditional use case. Starting with a value C, the requirements for each are identified as follows:

[0257] If we consider KLmax as the maximum value of LTC based on the LTC limit defined in the key list (keyList.Limit.LTC) and RF as the retry flag delivered with the expiration date, we have:

[0258] KLmax≤19:C results in an LTC value [no retry – process described above]

[0259] RF=0

[0260] LTC = 0 C

[0261] RF=1

[0262] LTC = 1 C

[0263] ●KLmax>19

[0264] ■RF=0:C results in a LTC value [no retry – process described above]

[0265] LTC = 0 C

[0266] ■RF=1:C leads to one or more candidates for LTC value [retry – process described below]

[0267] ●LTC Candidate=(1 C , 2 C ,…,n C )with n C ≤KLmax

[0268] The logic above assumes that we can trust the identity of the node, the reference to the key list, and the value of the retry flag conveyed with the expiration date.

[0269] It may be challenging for V to recover this information - the impact of dynamic expiration dates on the verification process is described further below.

[0270] Other considerations are generally related to the traditional (L) use case which is complicated by the lack of space available for transmitting LTC data in transactions. There are two main areas of consideration. One is limit management - retry limits can be managed, while replay limits can be managed or delegated in alternative options. Another area of ​​consideration is the use of dynamic expiration dates and its consequences, especially the difficulty of managing month-end, where certain fields that can be effectively reused at other times become important.

[0271] First, consider the retry process, where the verification node V manages the limits of both replay and retry. If PAN / TUR is not suspended, then the following process applies to verifying that iThe generated transaction voucher. V uses the following process to manage replay and retry limits:

[0272] ●SetValidationOutcome(replayDetection=NO_REPLAY, retryControl=NO_RETRY)

[0273] ● Sort the candidate list so that we prioritize those that are not yet stored in the database (dbV) [N i , keyList.Identifier, PAN / TUR] in the LTC list (one or more) candidates.

[0274] Sorting the values ​​is intended to resolve the risk of collisions (i.e., having the same cryptographic value) between candidate lists. Using this prioritization process, we try to avoid reporting a replay (which typically indicates that the transaction has been rejected) when another valid candidate has not yet been used for cryptographic verification.

[0275] ●Use from LTC 1 Started (LTC 1 ,LTC 2 ,…,LTC n ) of LTC for circulation

[0276] ○ Password verification

[0277] ■Password (Success)

[0278] -SetValidationOutcome(cryptoValidation=SUCCESS)

[0279] -LTC is not in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0280] ●Add LTC to the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0281] ● if Limit.CryptoFailureReset, reset

[0282] Counter.CryptoFailure[N i ,keyList.Identifier,PAN / TUR]

[0283] -LTC is already in the database (dbV )[N i ,keyList.Identifier,PAN / TUR]

[0284] ●Increment or (create) Counter.Replay[N i ,keyList.Identifier,PAN / TUR]

[0285] ●Counter.Replay <Limit.Replay

[0286] ■SetValidationOutcome(replayDetection=REPLAY)

[0287] ●Counter.Replay≥Limit.Replay

[0288] ■SetValidationOutcome(replayDetection=REPLAY_EXCEEDED)

[0289] ■Notify fraud management services (may result in suspension of PAN / TUR)

[0290] - Exit the loop

[0291] ■Password (failed)

[0292] -SetValidationOutcome(cryptoValidation=FAILURE)

[0293] -Increment or (create) Counter.Retry[N i ,keyList.Identifier,PAN / TUR]

[0294] -Counter.Retry <Limit.Retry

[0295] ●SetValidationOutcome(retryControl=RETRY)

[0296] -Counter.Retry ≥ Limit.Retry

[0297] ●SetValidationOutcome(retryControl=RETRY_EXCEEDED)

[0298] ●Notify fraud management services (may result in suspension of PAN / TUR)

[0299] ● Exit the loop

[0300] -Any remaining candidate LTC i ?

[0301] ●Available

[0302] ■Use LTC i Continue the cycle (Password Verification)

[0303] ●Not available

[0304] ■ Exit the loop

[0305] This approach allows for efficient management of both replay and retries - with the option to reset replay - enabling escalation when limits are exceeded. It should be noted that "replay" does not apply to crypto failures - Counter_Retry was introduced to limit the number of retries a node will have to process a given PAN / TUR using a given keylist associated with that node. As mentioned previously, resetting the crypto failure counter after a successful crypto validation is an option that can be used and can be defined in the keylist using Limit.CryptoFailureReset.

[0306] The alternative process for delegation replay restriction is as follows:

[0307] ●SetValidationOutcome(replayDetection=NO_REPLAY, retryControl=NO_RETRY)

[0308] ● Sort the candidate list so that we prioritize candidates that are not yet stored in the database (db V )[N i , keyList.Identifier, PAN / TUR] in the LTC list (one or more) candidates.

[0309] Sorting the values ​​is intended to resolve the risk of collisions (i.e., having the same cryptographic value) between candidate lists. Using this prioritization process, we try to avoid reporting a replay (associated with the rejection of a transaction) when another valid candidate has not yet been used for cryptographic verification.

[0310] ●Use from LTC 1 Started (LTC 1 ,LTC 2 ,…,LTC n ) of LTC for circulation

[0311] ○ Password verification

[0312] ■Password (Success)

[0313] -SetValidationOutcome(cryptoValidation=SUCCESS)

[0314] -LTC is not in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0315] ●Add LTC to the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0316] ● if Limit.CryptoFailureReset, reset

[0317] Counter.CryptoFailure[N i ,keyList.Identifier,PAN / TUR]

[0318] -LTC is already in the database (db V )[N i ,keyList.Identifier,PAN / TUR]

[0319] ●Increment or (create) Counter.Replay[N i ,keyList.Identifier,PAN / TUR]

[0320] ●SetValidationOutcome(replayDetection=REPLAY)

[0321] - Exit the loop

[0322] ■Password (failed)

[0323] -SetValidationOutcome(cryptoValidation=FAILURE)

[0324] -Increment or (create) Counter.Retry[N i ,keyList.Identifier,PAN / TUR]

[0325] -Counter.Retry <Limit.Retry

[0326] ●SetValidationOutcome(retryControl=RETRY)

[0327] -Counter.Retry ≥ Limit.Retry

[0328] ●SetValidationOutcome(retryControl=RETRY_EXCEEDED)

[0329] ●Notify fraud management services (may result in suspension of PAN / TUR)

[0330] ● Exit the loop

[0331] -Any remaining candidate LTC i ?

[0332] ●Available

[0333] ■Use LTC i Continue the cycle (Password Verification)

[0334] ●Not available

[0335] ■ Exit the loop

[0336] Other considerations are the same as in the initial process. In the case of delegation, another entity will manage the Replay restrictions using the following process, which can override the verification results set by V:

[0337] ●Counter.Replay≥Limit.Replay

[0338] ○SetValidationOutcome(replayDetection=REPLAY_EXCEEDED)

[0339] ○Notify fraud management services (may result in suspension of PAN / TUR)

[0340] The following discussion involves using a "dynamic expiration date" to convey information in a traditional (L) use case. The expiration date field is used to pass the expiration month to the message using t x The 6-bit value (exp) is transmitted as a reference to the next month value (YYMM) calculated in UTC.

[0341] b6 b5 b4 b3 b2 b1 describe x Key List Reference x Retry flag x x x x Node Identifier

[0342] The working example is as follows:

[0343]

[0344] ●t X (10:30:00AM CST, Wednesday, June 26, 2019) = 03:30:00PM UTC, Wednesday, June 26, 2019

[0345] ●Based on t X Next month (YYMM) (UTC) = 1907

[0346] ●Dynamic expiration date = 1907 "+" 19 = 2102

[0347] The dynamic expiry date is calculated by G as part of the transaction voucher generation for the “L” use case – it is used here because PAN, expiry date and CVC2 are the minimum data sets that the merchant / PSP and its acquirer can handle, so some mechanism is needed to convey the additional necessary information.

[0348] In most cases, the information can be reliably extracted using a simple deterministic process. G knows the time t corresponding to the generation of the transaction voucher G .

[0349] ●Time t G Can be converted to the UTC time zone, which can be used as a reference for the entire system

[0350] ●This converted value can clearly determine the value of "next month"

[0351] The dynamic expiration date is a combination of "next month" and a value corresponding to the above 6-bit information.

[0352] In short, for a given transaction voucher generation, we can set a dynamic expiration date using a deterministic process. one The verification service V follows the same logic, but uses as reference time t corresponding to the verification of the transaction credentials V .

[0353] As will be appreciated by those skilled in the art, the above-described embodiments are exemplary, and those skilled in the art can develop other embodiments that fall within the spirit and scope of the present disclosure based on the principles and exemplary work set forth above.

Claims

1. A method of managing the use of credentials in a distributed computing system, wherein the distributed computing system comprises a plurality of computing nodes, and wherein a first group of computing nodes is adapted to provide a credential generation service, and wherein a second group of computing nodes is adapted to provide a credential verification service, wherein the credential comprises a cryptographic proof, wherein the method comprises: The distributed computing system receives a request to generate credentials for a user account, wherein the request is directed to a first computing node that is one of a first set of computing nodes; the first computing node generating the credential and creating or incrementing a counter value entry for the user account in a first database associated with credential generation at the first computing node; The first computing node provides, in response to the request, the credential and an identification of the first node, a time value used to generate the credential, and a counter value of the counter value entry; The distributed computing system receives a request to verify the credential, wherein the request is directed to a second computing node that is one of a second set of computing nodes; The second computing node verifies the credential and creates or increments at least one further counter value entry in a second database for tracking verification of the credential, wherein the at least one further counter value entry is associated with the first node and the user account. 2 . The method of claim 1 , wherein at least one computing node is a member of both the first group of computing nodes and the second group of computing nodes. The method of claim 2 , wherein the first computing node and the second computing node are the same computing node.

4. A method as claimed in any one of the preceding claims, wherein generating the credential requires use of a cryptographic key among a plurality of cryptographic keys used for credential generation in a distributed computing system, and wherein verifying the credential requires access to the cryptographic key used to generate the credential.

5. The method of claim 4 , wherein the distributed computing system has a plurality of key lists, wherein each key list identifies a set of cryptographic keys, and wherein the key lists are distributed to each of the computing nodes for credential generation and credential verification, wherein at a first node, only a specified one of the key lists is available for credential generation at a given time, the key lists having a validity period for credential generation and a validity period for credential verification.

6. The method of claim 5, wherein after a validity period for credential generation, a new key list becomes valid for credential generation and the counter value is reset.

7. A method as claimed in claim 5 or claim 6, wherein the counter value has a predetermined maximum value, and when the counter value reaches the predetermined maximum value, the first computing node refuses to generate any further credentials for the user account until the counter value is reset.

8. A method as claimed in any one of claims 5 to 7, wherein the counter value is used to determine a cryptographic key from a key list for generating the credential.

9. A method as claimed in any preceding claim, wherein one of the at least one further counter comprises a replay counter to track attempts to replay the use of credentials generated by a given node for a given user account.

10. A method as claimed in any preceding claim, wherein one of the at least one further counter comprises a verification failure counter to track cryptographic failures of verification of credentials generated by a given node for a given user account.

11. A method as claimed in claim 9 or claim 10 as appended to claim 5, wherein the tracking is for credentials generated by a given node for a given user account for a given key list.

12. A method as claimed in any preceding claim when dependent on claim 11, wherein entries of counter values ​​in the second database are deleted when the key list associated with these counter values ​​is no longer valid for verification of the credential.

13. A method as claimed in any preceding claim, wherein each of the further counter values ​​has a predetermined limit and if the predetermined limit is reached, the second computing node refuses to verify any further credentials for the user account.

14. A method as claimed in any preceding claim, wherein the request relates to the performance of a transaction, and wherein credential generation is performed for providing the transaction to be authorised, and wherein credential verification is performed for authorising the transaction.

15. A distributed computing system comprising a plurality of computing nodes, wherein a first group of computing nodes is adapted to provide a credential generation service, and wherein a second group of computing nodes is adapted to provide a credential verification service, wherein the credential comprises a cryptographic proof, wherein the distributed computing system is adapted to perform the method of at least one of claims 1 to 14.

Images