Monitoring in distributed computing systems

Abstract

A method of monitoring a service executing at a computing node is described. The computing node is one of a plurality of computing nodes in a distributed computing system. Each computing node is adapted to execute at least one service for a client. A monitoring process is adapted to monitor execution of a service process. In the method, the monitoring process monitors execution of the service by the service process. The monitoring service then provides monitoring information to a monitoring process of another service process. Suitable computing nodes for executing services are described, as well as a coordinating monitoring service for supporting multiple monitoring services.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit and priority of European Patent Application No. 19206982.1, filed on November 4, 2019. The entire disclosure of the above-cited application is incorporated herein by reference. Technical Field

[0003] This disclosure relates to monitoring in distributed computing systems, and particularly to monitoring in distributed computing systems that perform one or more security processes. Background Technology

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

[0005] In practice, this decentralization can be achieved using a cloud architecture, which typically uses several geographically distributed servers (or data centers) to deliver services to clients. A cloud architecture can be thought of as comprising several nodes—when using a cloud architecture, a node can be an aggregation of several computers and can cover more than one data center with “real-time” connectivity and data sharing within a given node.

[0006] Decentralization itself can be problematic, especially if services need to be provided in a way that extends beyond the server providing the service and the client receiving it. For example, if other clients (or other system nodes) need to refer back to the service-providing node to check if the service has been provided or how it has been provided, or if the central system needs to understand how the service is provided or the expected operation of the distributed server nodes, new bottlenecks may emerge at the central server, replacing the original bottlenecks. The total amount of messages transmitted in the system may increase, and network latency may become a serious problem.

[0007] This is especially critical when a service involves security (and therefore requires assurance that it is executed securely throughout the system) and when it involves providing services over short timeframes. Both of these issues apply to transaction systems—where transactions must be authorized within a short period and it must be ensured that they have been executed legitimately—but also to other technical contexts.

[0008] Executing activities securely in such a distributed environment is challenging because malicious actors could potentially exploit the possibility of performing actions in multiple ways and from several locations. The aim is to address this challenge without resorting to methods that would significantly diminish the benefits of using a distributed environment. Summary of the Invention

[0009] In a first aspect, this disclosure provides a method for monitoring a service executed at a computing node, wherein the computing node is one of a plurality of computing nodes in a distributed computing system, each computing node being adapted to execute at least one service for a client, wherein a monitoring process is adapted to monitor the execution of the service process, the method comprising: monitoring the service process in response to expected operations of the service; and providing monitoring information to another service process.

[0010] Using this peer-to-peer communication method involving monitoring processes requires exchanging less monitoring information and allows for faster information exchange. This allows for an effective balance between practical processing requirements and security requirements.

[0011] In some cases, the monitoring process provides monitoring information directly after the service process is completed. In other cases, the monitoring process provides monitoring information after receiving monitoring information from another service process. As discussed below, the embodiments are particularly relevant to complementary services, in which one service may play one role and another service may play another role.

[0012] In some embodiments, monitoring information is provided to a monitoring process in another computing node. In some embodiments, multiple service processes exist in a computing node, and monitoring information is provided to one of the monitoring processes in that computing node. In some cases, monitoring information may be provided to multiple monitoring processes.

[0013] In an embodiment, the monitoring process has a monitoring process database, wherein the monitoring process can update the monitoring process database during the monitoring service process.

[0014] In embodiments, the service process includes a first service process for performing a first service and a second service process for performing a second service, wherein the first and second service processes are complementary. In this way, embodiments of this disclosure are particularly relevant to the provision of complementary services by distributed networks. In some cases, a computing node may contain multiple service processes, and these service processes may include a first service process, a second service process, or both. The first service process may include the generation of credentials, and the second service process may include the verification of credentials. Credentials are provided herein as cryptographic proof, and verification is a determination of the validity of that cryptographic proof. This is particularly useful in the context of payment systems. In a payment system, credentials can be generated on behalf of payment device users to indicate that they have authorized the use of the payment device to make payments to merchants. Verification is then required on behalf of the merchant or the merchant's acquiring bank to determine that the transaction is legitimate and authorized by the payment device user.

[0015] In one such scenario, the service process can be a second service process, and the method includes providing monitoring information to a monitoring process of the first service process that generates the credential. Here, the monitoring process can also receive a monitoring information response from the monitoring process of the first service process that generates the credential. Upon receiving the monitoring information response, the monitoring process can update the service process. This can be used to indicate many different situations. The monitoring information response may indicate that the credential is invalid. This could be because the credential was never generated. This could be caused by a guessing attack by the party requesting the verification service—for example, it could be that a merchant (or one in a merchant consortium) attempts to obtain payment for a fraudulent transaction by generating a false payment credential. Alternatively, the monitoring information response may indicate that the credential cannot be used for legitimate purposes—this could be because the credential has already been used, and in the case of a payment, a rogue user might attempt to execute the same payment twice.

[0016] In another such scenario, the service process may be a first service process, and the method may include providing monitoring information to a monitoring process of a second service process for verifying credentials. Then, in response to the verification monitoring information received from the monitoring process of the second service process for verifying credentials, the monitoring information may be provided as a monitoring information response. Here, upon receiving the verification monitoring information, the monitoring process may determine whether the credential has already been used, and if so, indicate this in the monitoring information. Upon receiving the verification monitoring information, the monitoring process may determine whether the credential can be used legitimately, and if not, indicate this in the monitoring information.

[0017] As discussed in more detail below, this architecture prevents many potential system abuses. It also addresses faults such as data corruption that leads to the misidentification of credentials. It can also be used to establish proper system use within appropriate timeframes, such as the validity period of encryption keys used during service.

[0018] In this embodiment, the monitoring process is also adapted to provide update messages to update the service processes it monitors. In addition to the peer-to-peer "horizontal" paths between monitoring services, there also exists a "vertical" path between the monitoring process and the service process itself. Typically, the monitoring process provides update messages after providing monitoring information. The service process may have an associated service process database, which it updates upon receiving an update message from the monitoring process.

[0019] In embodiments, the monitoring process is also adapted to provide escalation messages to or receive action messages from a collaborative monitoring process associated with multiple service processes. The monitoring process may provide the escalation message after providing monitoring information. After providing the escalation message, the monitoring process may receive action messages from the collaborative monitoring process for updating. Upon receiving such an action message, the monitoring process may update the service processes. This method is particularly useful when the impact is broader than that between two related complementary services.

[0020] In a second aspect, this disclosure provides a method for monitoring services executed in a distributed computing system, wherein the distributed computing system includes multiple computing nodes, each computing node being adapted to execute at least one service for a client, wherein the service is executed by service processes having associated monitoring processes, wherein the method is executed by a collaborative monitoring service, the method comprising: receiving an escalation message from one of the monitoring processes; determining, based on the escalation message, whether action needs to be taken at one or more service processes in one or more computing nodes; and if action needs to be taken, sending an action message to the monitoring process of the affected service process. The monitoring process can then update its service processes as needed.

[0021] These service processes may include a first service process for performing a first service and a second service process for performing a second service, which are complementary. The first service process may include credential generation, and the second service process may include credential verification. Here, action messages may indicate to multiple second service monitoring processes that a credential has been used. Action messages may be used to update these multiple service processes via the monitoring processes: an identified user of the distributed computing system is no longer permitted to use one or more of these services.

[0022] In a third aspect, this disclosure provides a computing node suitable for performing at least one service, wherein the computing node is one of a plurality of computing nodes in a distributed computing system, each computing node being adapted to perform at least one service for a client, wherein a monitoring process is adapted to monitor the service process performing the process, the computing node comprising: a service process adapted to perform the service in response to a client request; and a monitoring process adapted to monitor the service process for expected operation of the service and adapted to provide monitoring information to another service process.

[0023] The monitoring process can be adapted to provide monitoring information directly after the service process is completed. Alternatively, the monitoring process can be adapted to provide monitoring information after receiving monitoring information from another service process.

[0024] This monitoring information can be provided to a monitoring process in another compute node. In some cases, a compute node may include multiple service processes, and also a monitoring process for each service process. Such a monitoring process can be adapted to provide monitoring information to the monitoring process in the compute node. The monitoring information can be provided to multiple monitoring processes.

[0025] The compute node may also include a monitoring process database associated with the monitoring process, wherein the monitoring process is adapted to update the monitoring process database during the monitoring service process.

[0026] In an embodiment, the service process may include a first service process for performing a first service and a second service process for performing a second service, wherein the first and second service processes are complementary. A computing node may include multiple service processes, and these service processes may include the first service process, the second service process, or both. The first service process may include credential generation, and the second service process may include credential verification.

[0027] When the service process is a second service process, the monitoring process can be applied to provide monitoring information to the monitoring process of the first service process that generates the credential. Such a monitoring process can also be applied to receive monitoring information responses from the monitoring process of the first service process that generates the credential.

[0028] When the service process is the first service process, the monitoring process can provide monitoring information to the monitoring process of the second service process for verifying credentials. Such a monitoring process can also be adapted to provide monitoring information response in response to verification monitoring information received from the monitoring process of the second service process for verifying credentials.

[0029] The monitoring process can also be adapted to provide update messages to update the service processes it monitors. Such a monitoring process can be adapted to provide update messages after providing monitoring information. The compute node includes a service process database associated with the service processes, wherein the service processes are adapted to update the service process database upon receiving update messages from the monitoring process.

[0030] The monitoring process can also be adapted to provide escalation messages to or receive action messages from a collaborative monitoring process associated with multiple service processes. Such a monitoring process can be adapted to provide escalation messages after providing monitoring information. After providing escalation messages, the monitoring process can also be adapted to receive action messages from the collaborative monitoring process for updates. Upon receiving an action message, the monitoring process can also be adapted to update the service processes.

[0031] In a fourth aspect, this disclosure provides a distributed computing system for providing services to clients, the system comprising a plurality of computing nodes as identified in a third aspect of this disclosure, wherein each computing node is adapted to perform at least one service for a client. Attached Figure Description

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

[0033] Figure 1 Multiple clients interacting with the central server are shown;

[0034] Figure 2 The diagram illustrates multiple clients interacting with a distributed computing architecture that provides... Figure 1 The same service as the central server;

[0035] Figure 3 As shown Figure 2 The operation of the distributed system is shown, in which distributed nodes create and verify proofs;

[0036] Figure 4 An embodiment according to this disclosure is shown in Figure 3 Methods of monitoring in the layout

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

[0038] Figure 6 The diagram illustrates the implementation. Figure 5 The elements of a complex distributed system in terms of transaction architecture;

[0039] Figure 7 The illustration shows the use of in Figure 5 and Figure 6 An exemplary system for implementing digital transactions within a transaction architecture;

[0040] Figure 8 The diagram schematically illustrates the layout of a distributed system for the digital realization of transactions;

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

[0042] Figure 10 The diagram shows... Figure 9 Components within a computing node;

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

[0044] Figure 12 Instructions in Figures 9 to 11 The use of tokenization in the implementation examples of the layout;

[0045] Figure 13 Indicates the key management method used in the embodiments of this disclosure;

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

[0047] Figure 15 The illustrations depict a set of exemplary encryption mechanisms for digital transactions in embodiments of this disclosure;

[0048] Figure 16 The diagram illustrates the global model of key management, where the various modes are as follows: Figure 13 Manage as shown;

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

[0050] Figure 18 An embodiment of the present disclosure is shown for use with, such as Figure 8 The elements of a monitoring system used in a distributed system are shown.

[0051] Figure 19 The multi-layer model is shown. Figure 18 The surveillance system;

[0052] Figure 20a It is an indication that involves Figure 18 A block flowchart illustrating the monitoring-related communication between the two nodes in the setup, and Figure 20b The diagram shows... Figure 20a The various action types shown;

[0053] Figure 21a It shows Figure 20a The interaction flow of the generation service G in the layout and Figure 21b It shows Figure 20a The interaction flow of the verification service V in the layout, and Figure 21c The interactive flow in response to distributed actions from the collaborative monitoring service M is illustrated.

[0054] Figure 22 The diagram illustrates the transaction and monitoring process for generating service G;

[0055] Figure 23 The diagram illustrates the transaction and monitoring process of the verification service V;

[0056] Figure 24 The monitoring process for detecting replay attacks is illustrated;

[0057] Figure 25 The monitoring process for preventing replay attacks involving multiple nodes is illustrated.

[0058] Figure 26 The diagram shows the response process indicating that a double-spending fraud has been attempted;

[0059] Figure 27 Instructions were made to use a surveillance system to detect and communicate replay fraud;

[0060] Figures 28 to 30 This involves using surveillance systems to detect and signal different types of speculative attacks; among which Figure 28 Related to incorrect guessing; Figure 29 This relates to guessing attempts made by individual merchants (or PSPs); and Figure 30 Related to speculative attempts by dishonest merchants (or PSP alliances); and

[0061] Figure 31 This shows another monitoring process that is executed at the end of the time period. Detailed Implementation

[0062] Generally speaking, the problems addressed by this disclosure are Figures 1 to 3 As shown in the image. Figure 1 This illustrates a central system that performs functions in response to requests from a large number of geographically distributed entities. This places heavy demands on the central system in terms of processing power, storage, and messaging, and typically results in a significant overall load on the system due to bottlenecks and messaging requirements. This is in addition to network latency issues caused by travel time when requests originate from geographically distant requesters communicating with the centralized system.

[0063] Figure 2 An alternative arrangement is illustrated, in which the role of the central system is replicated 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. Individual nodes should see significantly lower requirements than the central system, and network latency is potentially reduced because entities should be able to interact with nodes that are more local than the central system. However, as discussed broadly above and specifically below regarding transaction processing systems, there are significant technical challenges in realizing these benefits—specifically, direct replication would be required to distribute all the same information to all nodes replicating the centralized system, generally making the overall situation worse rather than better.

[0064] There are particular difficulties when a second user of a system needs to be certain that the actions taken by the first user are legitimate. Figure 1In this case, it's relatively simple—because the service is centrally executed and the central system has all the information, so if the user trusts the central system, then there's usually no problem. Figure 2 In situations where a first user might be interacting with one node while a second user is interacting with another, the same level of confidence cannot be achieved unless all necessary information is consistently and properly synchronized across all nodes (which would disrupt disaggregation points when replicating a centralized system). If the output of the first service performed by the first user is valuable information—such as a proof that the second user will use the first user's payment when completing a transaction—then it is necessary to address the risk of system failures or compromises, for example, due to multiple second users using the proof at multiple nodes to complete related transactions.

[0065] Usually, in Figure 3 The following illustrates this scenario. First user 1 requests execution of first service 3—in this case, creating proof of an event such as a payment from a specific account—and second user 2 requests verification of that proof, for example, to determine if a payment was validly made from second service 4. First user 1 has already invoked first service 3 at first node 5. Second user will typically have no choice in where to invoke second service 4—this could be a matter of geographical or other administrative factors—specifically, it may be impossible to invoke second service 4 at first node 5 (although this is a possibility). In practice, second service 4 will be invoked at another node 6a, 6b, 6c, which has sufficient information to implement the verification process. Typically, this will involve accessing a public cryptographic key set and the minimum set of information required to regenerate the proof or otherwise determine that the proof is correct—as discussed below, a limited key set may be used in embodiments. There is a need to address situations where such proofs or claims of being the object of such proofs are provided to one or more second services at one or more nodes for such systems to operate reliably and securely.

[0066] This disclosure teaches how to address these situations using appropriate monitoring systems. Monitoring systems according to embodiments of this disclosure... Figure 4 As shown, it is extended by including a monitoring system. Figure 3 The system is arranged such that each service in a node, such as the first service 3 and the second service 4, has an associated monitoring service (such as the first service monitoring service 31 and the second service monitoring service 41). This monitoring service interacts directly with its associated service using appropriate messaging, performs monitoring as the service is executed, and provides the associated service with the information required for the correct current or future service delivery, including information received from other parts of the distributed system.

[0067] Each monitoring service has at least two further communication paths. One is a peer-to-peer (horizontal) communication path 7, used to communicate with monitoring services in other nodes using inter-node messages, so that information that can be immediately identified as relevant to other services can be sent to those monitoring services. It should be noted that although this peer-to-peer (horizontal) communication path is shown as an inter-node path, it can also be effectively run within a single node if multiple services are provided within that node (i.e., if processes 4 and 41 adjacent to processes 3 and 31 will run in node 5)—in which case the peer-to-peer (horizontal) communication path between 41 and 31 is provided as an in-node message or path. The terms "in-node" and "within-node" are used interchangeably here to refer to messages sent within the same physical or logical node, although the term "within-node" will generally be used below. This path is particularly effective for direct communication between the monitoring service that verifies the proof and the monitoring service that has created the proof.

[0068] The second communication path is path 8 between each local monitoring service 31, 41 and the collaborative monitoring service—which may be provided, for example, as a central monitoring service 9. This helps support the escalation process, which assesses potential errors or threats that the local monitoring services cannot directly identify, and communicates actions to the affected nodes or services within those nodes to address the threat and mitigate any associated residual security risks when such issues have been detected and a distributed response is required.

[0069] The arrangement shown here has a third communication path for vertical communication between services 3, 4 and their monitoring processes 31, 41. This is used here for message passing between services 3, 4 and their monitoring processes 31, 41 to monitor the expected operation of the services. In the arrangement described here, message passing is used for this purpose, but in other architectures, it is conceivable that monitoring can be achieved through measurement without an explicit message passing step. However, this third communication path is crucial for conveying information... from Monitoring processes 31 and 41 provide valuable feedback; services 3 and 4 are also valuable.

[0070] This architecture effectively allows both the first and second services to operate without latency, while enabling effective monitoring through peer-to-peer interaction between a monitoring process exchanging first-type information and a remote collaborative monitoring system receiving second-type information. The first-type information can be used to provide rapid updates, which can address issues such as coordinated attacks, while the second-type information can be used to ensure sufficient understanding of events across the entire system to prevent other types of attacks. This approach supports effective monitoring across distributed systems, but information exchange is limited to those necessary for maintaining an effective and secure system.

[0071] The timing of messaging within an extended system is crucial. There are three timing types for messaging: real-time; near real-time; and post-service. Real-time messaging is instantaneous. Near real-time messaging may not be instantaneous—real-time messaging takes precedence—but it is fast and can be completed during relevant extended system events, allowing monitoring information to be received while multiple secondary services are used in parallel. Post-service messaging is less urgent and is used for reconciliation and system changes to eliminate identified vulnerabilities.

[0072] Here, the messaging and processing involved in providing services to users occur in real time, making such services a fully real-time process. Local monitoring and associated communications (such as peer-to-peer messaging between monitoring services) typically occur in near real-time, so the speed of service delivery is not affected, but the response is fast enough to resolve threats within a sufficiently short timescale. Often, this near real-time communication is fast enough that it occurs within the same timeframe as, and often before, the broader processes associated with the use of a second service, and frequently before those processes complete, thus making this approach effective against attacks or problems occurring at multiple points in the system. Collaborative monitoring and other communications involving collaborative monitoring services typically do not need to be immediate and can be performed after the associated services have completed. This approach therefore allows for an effective response to threats in distributed service delivery systems without compromising the operation of the service delivery itself.

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

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

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

[0076] 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 cards to cardholder 110. Acquiring party 140 provides card processing services to merchant 120.

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

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

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

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

[0081] Specifically, issuer 130 and cardholder 110 settle payment amounts between themselves. In return, merchant 120 pays a service fee to acquirer 140 for each transaction, and acquirer 140 pays exchange fees to issuer 130 in return for fund settlement.

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

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

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

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

[0086] For tokenized transactions, the transaction scheme verifies the transaction by mapping the cardholder's token to their card PAN, checking the token's status (to ensure it is up-to-date or valid), and using any customer verification methods employed. This allows the issuer to authorize transactions in the normal manner.

[0087] Figure 7 The elements of the transaction infrastructure supporting digital payments from mobile devices are illustrated in more detail. The diagram, as a concrete example, shows the applicant's Mastercard Cloud-Based Payments (MCBP) architecture—which is exemplary and not specific to this disclosure—and illustrates how this architecture can be used to support a mobile payment application 215 on a mobile device (such as smartphone 11)—here, 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 the payment card 6 to be used by the mobile device 11.

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

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

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

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

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

[0093] The embodiments of this disclosure are intended for use in performing, such as Figure 7 The various aspects of the digital transaction system shown—especially the management of credentials—can be decentralized. This is accomplished by replacing the central node with a set of decentralized nodes, each capable of credential management, such as... Figures 8 to 10 As shown.

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

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

[0096] Node 80 includes multiple conventional servers 83 (each containing its own processor and memory—not shown—and other components typically found in servers) and memory 84 containing a central database. Node 80 also includes multiple hardware security modules 85 (HSMs) adapted to store encrypted material in the form of keys required to perform encryption functions and securely execute them. Here, the elements within node 80 are shown communicating via bus 86. While node 80 is represented as a single data center in this case, this is not necessary—for example, the “bus” could include a dedicated network connection between a set of related data centers, allowing the related data centers to provide real-time responses so that they appear as part of an integrated whole to other entities communicating with the node.

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

[0098] In the digital ecosystem, while there is rapidly growing demand, there is also often a more secure environment because interactions typically occur between merchant systems (or payment service providers) and transaction systems via secure paths between clearly identified participants. Therefore, interactions in the device context may require multiple cryptographic operations to ensure security. These operations can be streamlined when exposing APIs to access services and when delivering services in the server context, while maintaining the security of all assets within a constrained environment that includes key management and cryptographic operations.

[0099] While scaling trading systems for executing digital EMV transactions might seem desirable by using a set of distributed servers to generate and verify credentials, this approach has proven unscalable. The overall level of key generation will remain unchanged, but the amount of messaging within the system will increase dramatically due to the need to manage and replicate an extremely large number of tokens. Since existing EMV key generation methods require custom rather than off-the-shelf Hardware Security Modules (HSMs), processing will be demanding and extremely expensive, and data storage, especially network latency, will become unmanageable issues.

[0100] This distributed approach is supported by replacing token bindings with specific hierarchical derived keys, thereby allowing the first available key from the key stack to be assigned to a tokenized transaction. This approach, using flexible and dynamic key management, allows for scalable solutions. Monitoring can be conducted to ensure the distributed architecture is secure without the need to transfer or replicate large amounts of sensitive information. The approach can also be implemented in standard HSMs using fully FIPS-compliant procedures—for example, without the need for DES and 3DES. The approach is described in more detail below.

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

[0102] This method requires an extremely heavy key management workload, which is unsuitable for fully digital transactions, as shown in the reference below. Figure 11 and Figure 12 The generation of SK and therefore the application cipher (AC—the standard mechanism in EMV transactions) requires multiple cryptographic operations, not all of which can be performed by a traditional off-the-shelf HSM, thus requiring a custom HSM. This necessitates the large-scale distribution of keys throughout the system to support transaction execution regardless of where transactions occur, and ATC management is complex. The following would be preferable: using a standard HSM that makes keys readily available while avoiding extensive key duplication, and providing a solution that limits the total number of HSMs (since these typically only support a few thousand keys).

[0103] Much of this security is guaranteed through appropriate preventative mechanisms, even in the event of a potential threat at the system endpoint (e.g., at the cardholder's device). In addition, such as... Figure 11 As shown, the role of security is limited. The primary purpose of encryption is to provide guarantees—this encompasses both data integrity and authentication. Transaction-related data protected by encryption includes the transaction's identifier and associated token, as well as instructions on any encryption processes used and any related financial data (and any other aspects of the transaction requiring guarantees). This is represented by transaction credentials—which need to be generated G and subsequently verified V, processes monitored M to ensure overall system integrity and supported by some kind of key management system K. This disclosure relates to a monitoring method that effectively addresses the consequences of erroneous or malicious actions through appropriate detection, messaging, and responses—as will be described—largely separate from the actual execution of the transaction.

[0104] In the context of fully digital transactions, these processes occur in a restricted environment where, in the same manner as on a device, endpoint security is not an issue. (As from...) Figure 12 As can be seen, in this domain, the token does not reach either endpoint of a traditional transaction management system—the cardholder or the issuer. Instead, it operates across merchant systems or payment service providers (PSPs) and transaction solution providers.

[0105] This method allows the credentialing system to be decentralized from a complex central server to multiple nodes providing services. These nodes are typically geographically distributed but may extend to multiple data centers (e.g., by using cloud infrastructure to enable data sharing within nodes). These nodes provide services—associated with credentials, generation service G, and verification service V—with defined rules for access control over these services. Merchants or PSPs communicate with generation service G to obtain credentials, which are then used in a standard authorization process performed on the payment system's payment network, where verification service V is invoked as needed to verify the credentials. These services have access to the nodes' computing infrastructure (HSM, database). Monitoring service M and key management service K are also provided—these services can be centrally organized or contain a hybrid of central and local functions.

[0106] Access control for services can be provided in a largely traditional manner. A set of generic controls can be defined for nodes, with the possibility of local modifications—for example, to meet local regulations or other specific security requirements. This approach makes it easy to implement localization strategies, for example, by restricting all traffic from a particular country to a specific set of nodes or by taking regionally or market-specific actions. Access control can be enforced at more than one level (e.g., for individual services and also for nodes), and there may be specific rules or checks for specific service types. Access control can be very granular and can provide specific solutions in a variety of ways—for example, it can be used to allow a given merchant to perform a maximum number of transaction credential generation operations within a defined time for a given token.

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

[0108] For each node, the GenerateG and VerifyV services can access a pool of HSMs. The HSM contains keys, each uniquely identified by a set of key identifiers (KeyIds). KeyIds can be tags, values, explicitly unique values ​​(such as UUIDs), or anything else with appropriate attributes. These KeyIds are stored in uniquely identified (identifier) ​​key lists—lists that provide a hierarchy of relationships between identifiers (Ids) and stored keys (KeyIds). The identifiers (Ids) are determined by a deterministic process to determine which key to use, as will be further described below.

[0109] Seals are used to ensure the integrity of each key list—if the key list is provided from a central location, this can be applied by a trusted party associated with that central location. Several other distribution models can be supported, for example, by using a trusted party as a local function rather than a central location. A node will typically have many available key lists, but only one active at any given time for generating credentials (G)—however, the verification service (V) will usually need to be able to access any key list that might be associated with a still valid credential. Key rotation in this approach is extremely simple—it may simply involve replacing the active key list with another key list. However, determining which KeyId is needed to verify the credential is very straightforward—it will be determined entirely by the node identifier and the reference to the key list. This information is part of the credential and serves as input to the deterministic process of selecting a key from the key list.

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

[0111] Transaction-related data to be encrypted includes the identifier of the token associated with the transaction, as well as the identifier of the transaction itself. For this, some kind of transaction identifier is required. At each node, the credential generation and verification service can access a local database that can be used to manage such data. To ensure efficient transaction management throughout the system, any generation of transaction credentials for a given token should be associated with a unique transaction identifier for each transaction. This could be a UUID or any suitable identifier structure (such as a cascade of an n-bit node identifier, an e-bit epoch time, and a c-bit local counter).

[0112] However, by using a local transaction counter, the size of the data carried in the transaction credential can be reduced to a few digits. This can be simply stored in the node's local database, and the local (rather than global) value increases when the local generation service G generates a new transaction credential for the token. Figure 14 The process is summarized in the text.

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

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

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

[0116] HSM encryption functions should be suitable for ensuring data integrity and authentication through credential generation and verification. The encryption function operates on selected transaction data using a key and provides an output that does not expose that key. Various alternative encryption functions can be used—HMAC is a particularly effective choice with several options regarding hash functions, but CMAC, CBCMAC, and even solutions using asymmetric encryption are not discussed. The encryption function used should be specified in the key list (specified as keyList.CryptoFunction) and is also driven by the capabilities of the HSM used for generation and verification. Local regulations, export of encrypted materials, or other security considerations may lead to the selection of a specific encryption function.

[0117] Within the transaction data, there should be information representing the application password generated during the transaction process. This might be a simplified form of the password—for example, in a traditional EMV transaction, this might 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:

[0118] Dynamic information carried as part of the transaction flow;

[0119] Shared information from one of the following:

[0120] The copying process (such as key list management);

[0121] System parameters for a specific use case.

[0122] The standard approaches for different use cases—traditional transactions, UCAF, and DPD field transactions—are discussed further below. The traditional transaction use case offers a solution when merchants and / or PSPs can only manage PAN, expiry date, and CVC2 as part of the transaction flow and cannot access the latest developments. The UCAF use case aims to leverage the recently introduced Universal Cardholder Authentication Field to carry more data as part of the transaction flow. The DPD use case encompasses digital payment data, i.e., the introduction of a container capable of carrying all the data needed as part of the transaction flow.

[0123] Figure 15 The document illustrates a complete encryption mechanism. (Reference) Figure 16Key management is discussed. Key management in this model has two aspects: the management of the keys themselves, including their generation and delivery to the HSM associated with the node; and the management of the key list, including its generation, distribution, activation, and deactivation. The key list is a sensitive asset, while the keys are considered secret assets—the key list defines the keys to be used to generate and verify ciphers. When keys are loaded into the HSM, end-to-end security is ensured through the secure transmission of keys using wrapping / unwrapping techniques. The use of keys should not be compromised if an attacker wants to alter the contents of the key list to change the key selection process. A seal guarantees the integrity of the key list—the seal provided by the generating party or an associated trusted party involves appropriate encryption processes (such as HMAC with a suitable private key or, for example, digital signatures generated using asymmetric algorithms such as RSA, ECC, SM2, etc.) and has the effect that any relevant part of the system can be confident that the key list was generated by the appropriate party and has not been modified. Furthermore, the key list seal can be used for cipher generation and verification to protect credentials.

[0124] Different control models are possible. Centralized control may exist, where a central service generates keys and key lists and distributes them to different nodes. However, local control may also exist if specific nodes require dedicated processes. This may be particularly suitable if a particular country has specific requirements, such as local regulations or restrictions on the export of cryptographic materials. This may also be suitable if HMS management requires proprietary mechanisms (e.g., in the case of a specific cloud service provider). This does not need to be node-restricted—it can be applied to regional control with a central service within a region (which may be particularly suitable if a specific security model exists in a particular country to meet local legal requirements). Hybrid or composite models may also exist, where one key and key list provision is central and another is local—a distributed model may also exist, where distributed peers collectively assume the role of the central service.

[0125] Figure 17 The text outlines monitoring in general. Here, monitoring complements security actions taken directly within the service to prevent fraud or abuse (such as the service's fundamental purpose—generating credentials using passwords and having subsequent verification). Such monitoring aims to detect security anomalies associated with transactions—which can then trigger appropriate response mechanisms to mitigate any security risks and identify any attackers. In principle, this can involve both local and central aspects. A hybrid approach is particularly effective in providing both effective detection of any issues and generating effective responses to the risks associated with a fully distributed architecture.

[0126] In such a system, there are three categories of problems that need to be addressed through monitoring: the integrity of the distributed system; the generation of transaction credentials; and the verification of transaction credentials. Since transaction credentials can be generated or verified anywhere, effective monitoring across the entire distributed system is crucial. An exemplary risk is that attackers abuse genuine transaction credentials generated by the generation service G in a node, particularly by attempting verification in multiple verification services on other nodes—this would be problematic if the verification service V lacks effective visibility into the actions taken by the verification service V on other nodes of the distributed system.

[0127] While monitoring is important for maintaining system integrity, it is also crucial to limit the volume of messages generated to ensure system scalability and prevent overloading of the monitoring process. Therefore, it is necessary to restrict off-node messaging to only those truly needed to address threats, and for nodes to store information locally to allow for effective use of monitoring results.

[0128] The methods and architectures for monitoring based on these principles will now be described in more detail. After describing the architecture as a whole, we will describe how to use this architecture to monitor different types of events. Following that, we will describe the use of monitoring in detecting and preventing various attacks.

[0129] Now refer to Figure 18 and Figure 19 The monitoring architecture is described, and the interactions between system elements are described in later sections. This description defines the system elements and their actions, enabling technicians to implement them without unnecessarily restricting message passing or information storage—it provides a complete description of the functional requirements and core principles related to monitoring according to embodiments of this disclosure.

[0130] For convenience, in the remainder of this document, elements most appropriately labeled [G], [V], [m], and [M] will be referred to as G, V, mG or mV and M. This also applies to [k] and [K]. For example, G1,V2… means “G in node 1, V in node 2…”. The same notation is used when referring to Vj or Vk, where Vj is the verification process in node Nj and Vk is the verification process in node Nk. Any G, mG, V, mV… can have multiple instances for a given node. This applies to M or any other entity.

[0131] In addition to monitoring activities related to the management (generation and verification) of transaction credentials, auditing activities to ensure system integrity should also be considered—these will cover access control, communication layers between involved entities, and the management of the HSM (Hardware Security Module). However, such auditing activities can be conducted in a basic, traditional manner, and will not be discussed in more detail here.

[0132] Figure 18 The monitoring architecture used in embodiments of this disclosure is illustrated. At the top level are shown traditional transaction system elements involved in the process of generating and verifying transaction credentials—merchant (or payment service provider in the case of online transactions) 161, acquirer 162, and transaction scheme provider 163. The next layer involves distributed nodes, specifically the basic process of node 164—generation service G 165 and verification service V 166—where multiple verification services are shown, indicating that credentials generated by generation service G can be verified by various verification services Vj, Vk. In this case, node 164 contains only the generation service, and the verification services are in other nodes (not explicitly identified). Alternative nodes (164a) are also shown in shaded areas as an alternative possibility—in which case both generation service G and verification service V are located in the same node. Generation service G can access local database 1651, and verification services can access local database 1661. Node 164 also contains a local monitoring service mG 167 with a local database 1671 for monitoring generation service 165, and a local monitoring service mV 168 with a local database 1681 for monitoring verification service 166. It can be seen that there is interaction and messaging between the local monitoring services and the services they are monitoring, and between services themselves—here, messaging between the local generation service monitoring mG and the local verification service monitoring mV is shown (typically inter-node messaging). If a global monitoring service M 169 is needed, a further level is required—usually this is the result of some kind of upgrade. The global monitoring service 169 can communicate with both types of local monitoring services 167 and 168. If it is necessary to cascade actions to each node (in... Figure 18 If the message is represented as a distributed action, it can originate from the global monitoring service M and be cascaded to each production service G and verification service V through its local monitoring services mG and mV.

[0133] It should be noted that this architecture is a specific example of a more general architecture for monitoring service processes that can execute on one of multiple nodes in a distributed computing system. As will be described, this architecture effectively allows service processes (in this particular architecture, credential generation and credential verification are both service processes, each executed for the client) to occur without latency, while allowing for effective monitoring through peer-to-peer interaction between monitoring processes exchanging first-type information and remote collaborative monitoring systems receiving second-type information. The first-type information can be used to provide rapid updates that can address, for example, collaborative attacks, while the second-type information can be used to ensure sufficient understanding of events across the entire system to prevent other types of attacks from taking place.

[0134] Figure 17The layout is shown, with levels clearly marked. The top layer 171 involves only regular transaction scheme entities. The second and third layers both exist within the nodes—the second layer 172 is the service layer and the third layer 173 is the monitoring layer. The fourth layer 174 consists of a global monitoring service and the messaging associated with that service.

[0135] Now we will describe it in more detail. Figure 18 and Figure 19 The entities and interactions shown in the image.

[0136] Figure 18 and Figure 19 middle not yet Key management is explicitly stated, but for completeness, its basic principles are presented here. Monitoring of key management activities is considered a specific process associated with system auditing. Key management monitoring provides the following assurances: cryptographic material is ready for use and is properly erased or archived (using a managed service) when it is no longer needed to support the generation and verification of transaction credentials. Key management monitoring also addresses the management of key lists through the creation, distribution, activation, and deactivation.

[0137] Typically, both local surveillance (mG and mV) and central or collaborative surveillance (M) will be aware of key management activities, but will be separate from key management surveillance. In the illustrated arrangement, the local surveillance processes will not access the HSM containing the transaction keys, so these processes will not be able to invoke the HSM encryption process (and therefore will not be able to generate or verify credentials as needed). Collaborative surveillance M may be able to do this in the embodiment, preferably through a specific interface determined by the key management process.

[0138] The verification process V running in node Nj can verify transaction credentials from a given set of generation processes G running in that node and other nodes {Ni, Nj, Nk…}. As discussed above, each generation process G (from which the verification process V can verify transaction credentials) has an associated key list (KLi, KLs, KLref...) shared with the verification process V, where KLi is the key list identifier, KLs is the key list stamp, and KLref is the key list reference.

[0139] from Figure 18 It can be seen that the following "vertical" process interactions exist within the node:

[0140] • G interacts with the local monitoring generation process (mG).

[0141] • V interacts with the local monitoring and verification process (mV).

[0142] from Figure 18It can also be seen that there is a "horizontal" process interaction. Such an interaction can be established between the local monitoring and verification process mVj located in node Nj and the following:

[0143] • The local monitoring generation process mGj in the same node Nj.

[0144] • For any local monitoring generation process mGi, mGk... (in nodes Ni, Nk...), mVj can access the key list for each mGx (x = i, k...).

[0145] Figure 18 The same interaction is shown in mVk located in node Nk. This peer-to-peer communication between monitoring processes allows for the rapid transfer of critical information between monitoring processes (and thus between associated service processes via vertical communication between monitoring processes and service processes) without affecting the services themselves, as will be further described below.

[0146] Any local monitoring process mG / mV, whether or not it is associated with a G or V process within a node, can interact with the collaborative monitoring process M. This collaborative monitoring process M typically does not link directly to a node, but rather bridges the gap between local monitoring processes across multiple nodes. It also provides a final response manager, which can be used to target one, several, or all nodes to make necessary changes (e.g., tweaking the system to respond to known threats).

[0147] Such a monitoring process (local or collaborative) may require the temporary storage of sensitive data, such as passwords or inputs used for transaction credential generation and / or verification.

[0148] It can be seen that there are multiple message types that different entities can use.

[0149] The credential generation and verification service (G / V) can communicate with the associated monitoring process (mG / mV) within the same node using a pair of vertical node-internal messages, as shown below:

[0150] • G / V invokes local monitoring mG / mV respectively through monitoring messages within the node.

[0151] • mG / mV can request actions from G / V respectively using action messages within the node.

[0152] Two local monitoring processes, mV and mG, within the same node can communicate with each other using a pair of horizontal intra-node messages, as follows:

[0153] • mV calls mG through an internal node report message.

[0154] • mG can request a response from mV using an intra-node response message.

[0155] Two local monitoring processes, mV and mG, located on two different nodes, can communicate using inter-node messages, i.e.:

[0156] mV calls mG through inter-node reporting messages.

[0157] • mG can use inter-node response messages to determine its response to mV.

[0158] Under certain conditions, a local monitoring generation process (mG) or a local monitoring verification process (mV) in any node can invoke a collaborative monitoring process (M) via an upgrade message. After a risk management decision, M can trigger one or more distributed action messages to one or more local monitoring processes (mG / mV) in any node to ensure the system is fully aware of the necessary changes.

[0159] In the described system, the timing of messaging within the extended system is crucial. There are three timing types for messaging: real-time; near real-time; and post-transaction. Real-time messaging is instantaneous. Near real-time messaging may not be instantaneous—real-time messaging takes precedence—but it is fast and typically completes during relevant extended system events, such as transaction authorization. Post-transaction messaging is less urgent and is used for reconciliation and system changes to eliminate identified vulnerabilities. In the described embodiment, the timing for a specific message is as follows:

[0160] • Real-time G / V management:

[0161] o Pseudo-random P' freshness, where

[0162] □P=(KLi,KLs),(RF,C),LTC,UN,UUID…

[0163] □P'=(RF,C),LTC,UN,UUID...where P' represents P that does not have (KLi,KLs) information.

[0164] o Password generation / verification (as part of transaction credential generation / verification).

[0165] o The option to postpone password verification based on the risk-based analysis (RBA) principle.

[0166] • Intra-node monitoring messages (using P' as needed) are sent in real time from G to mG and from V to mV. The local monitoring process (mG / mV) is expected to have access to KLi and KLs information.

[0167] • Inter-node reporting messages are sent from each mV to mG in near real-time to trigger the aggregation of pseudo-random P' values.

[0168] • Following the report message initiated by mV, a near real-time response message is sent from mG to mV via inter-node response messages, requesting an immediate horizontal action on the mV caller.

[0169] • Intra-node monitoring messages are processed in near real-time by the destination local monitoring process, and the database is updated appropriately, and intra-node action messages are sent to the vertical caller in near real-time.

[0170] • The collaborative monitoring process (M) is initiated after a transaction based on an upgrade message triggered by one or more local monitoring processes (mG / mV). Again, the collaborative monitoring process (M) is expected to have access to KLi and KLs information.

[0171] • Collaborative surveillance (M) can send distributed actions to one or more local surveillance processes (mG / mV) in the event of a major threat.

[0172] about Figure 18 and Figure 19 As can be seen, message passing between Layer 1 and Layer 2 (the main transaction scheme entities and the generation and verification services), within Layer 1 and Layer 2, and from Layer 1 and Layer 2 is typically sent in real time, enabling generation and verification to be fully real-time processes. Local monitoring and other communications within Layer 3 are usually performed in near real-time, so transaction speed is not affected, but the response is fast enough to resolve threats in a sufficiently short time. Typically, this near real-time communication is fast enough that it occurs within the same timeframe as the associated transaction system process (in this case, often the authorization of the transaction)—often before such a process completes—making the approach effective against attacks or issues occurring at multiple points in the system. Collaborative monitoring and other communications involving Layer 4 do not need to be instantaneous and can occur post-transaction.

[0173] The interactions between entities involved in the monitoring will now be described with reference to different system events. First, the basic scenario of credentials being generated by the generation service G and verified by the verification service V (on the same node or different nodes) will be discussed. Both the generation service G and the verification service V can report to the collaborative monitoring service M.

[0174] The primary transaction system event is that G executes a cipher to generate payment proof for the transaction. G then delivers the transaction credential to the party that requested it (merchant or PSP). These transaction credentials are provided to V (received from the acquirer via the payment network) as part of the transaction process. V verifies the cipher and determines whether the transaction credential has been verified. These actions can be embedded in other layers of transaction activity, but these are not relevant to this disclosure.

[0175] exist Figure 20a and Figure 20bThe main monitoring processes are shown in the diagram—these are supplementary to the main service processes based on password generation / verification as described above. Figure 18 The diagram illustrates the actions of vertical flow within a processing node (and to clients and collaborative monitoring services on that node) and horizontal flow between processing nodes. Figure 18 b provides the key for the action type shown. Typically, the monitoring process is based on the detection of security anomalies and the triggering of appropriate actions for anomaly reporting and security maintenance responses. These appropriate actions have a vertical flow within the processing node (and to clients and collaborative monitoring services to the node) and a horizontal flow between processing nodes. In addition to processes performed by any component (as described in the two paragraphs above), the vertical process includes monitoring and escalation of a collaborative monitoring service M (by a monitoring service associated with a generation or verification service) that may provide distributed actions to multiple nodes, with each service responding by providing actions from the monitoring service to its associated services. Horizontally, there will be inter-service (which may be intra-node or inter-node) reporting, typically regarding verification operations, as well as inter-service responses (which may be in response to reports).

[0176] In addition to this basic functional interaction, both G and V participate in complementary monitoring processes to increase trust in the decisions made by the distributed system.

[0177] G's surveillance activities are as follows:

[0178] 1 G generates a transaction certificate based on the request (from the merchant or PSP).

[0179] 2 G->mG: After returning the transaction credentials to the requester, G uses intra-node monitoring messages to notify its local monitoring generation process (mG).

[0180] 3 mG processes the received information—this could come from two different sources.

[0181] a)(vertical) G->mG, involving the result of the transaction certificate generation service for G.

[0182] b)(Horizontal) mV->mG: Reporting of the results of mV performing the transaction credential verification service of V - this may be an intra-node or inter-node report, depending on the verification service V that performed the verification.

[0183] 4 mG processing may result in the sending of one or more of the following messages:

[0184] a) (Horizontal) mG->mV: This will typically be a response to a message received from mV regarding the verification process, and involves mG notifying mV of a possible reaction to change a part of the state / result of the verification process. Again, this can be intra-node or inter-node, depending on the location of the relevant verification service V.

[0185] b)(Vertical Up) mG->G: mG may require G in the same node to perform intra-node actions to change the transaction certificate generation service status and the data in the corresponding database.

[0186] c)(Vertical Downward) mG->M: mG determines that it needs to be upgraded to the collaborative monitoring process (M).

[0187] 5M can respond to upgrade messages to make confirmation / correction decisions related to the verification of executed transaction credentials, and then correct the behavior of any G / V / mG / mV processes by sending distributed action messages to mG / mV.

[0188] V's surveillance activities

[0189] 1V receives the transaction credentials generated by G and verifies them as part of the transaction processing.

[0190] 2 V->mV: V sends an intra-node monitoring message to notify its local monitoring verification process (mV).

[0191] The received information is processed at 3 mV – this could come from two different sources:

[0192] a)(vertical)V->mV, the result of the transaction credential verification service involving V.

[0193] b) (Horizontal) mG->mV, related to any response required for monitoring the generation process (mG). This could be an intra-node or inter-node message, depending on the relative positions of G and V.

[0194] 4 mV processing may result in sending one of the following messages:

[0195] a) (Horizontal) mV->mG: mV sends a report message to mG, allowing mG to make decisions based on verification process information. Again, this could be an inter-node or intra-node message, depending on the positions of G and V.

[0196] b)(Vertical Up) mV->V: mV may require V in the same node to perform intra-node actions to change the transaction credential verification service status and the data in the corresponding database.

[0197] c)(Vertical Downward) mV->M: mV indicates that it needs to be upgraded to the collaborative monitoring process (M).

[0198] 5M can respond to upgrade messages to make confirmation / correction decisions related to the verification of executed transaction credentials, and then correct the behavior of any G / V / mG / mV processes by sending distributed action messages to mG / mV.

[0199] These basic principles apply to more complex use cases. The next consideration is the flow when there are two different verification services (V1 and V2 in this case). Both V1 and V2 are capable of verifying credentials generated by G because both have access to the list of keys used by G. In this use case, G generates transaction credentials that can be verified by multiple verification services V, which do not interact directly with each other but instead exchange level reports and reaction messages with G.

[0200] In this use case, the processing and messaging provided by verification services V1 and V2 are exactly the same as those provided by verification service V in the original example. The process at the monitoring generation service mG will differ slightly. mG needs to integrate responses from the non-interactive monitoring verification services mV1 and mV2. The effect of this integration, particularly related to the range of pseudo-random numbers (P') reported by each verification entity V1 and V2, is to allow mG to determine whether any of these pseudo-random numbers has been used by more than one verifier, an indication of potential fraud. Such detection can be escalated to the collaborative monitoring service M, and distributed action messages can be sent to mG, mV1, and mV2 to allow determination of how processing should be stopped or controlled to prevent potential fraud.

[0201] The next complex use case involves two generation services, G1 and G2, and a single verification service, V, verifying transaction credentials from the two generation services. These two generation services, G1 and G2, do not communicate with each other and each uses different key lists. V must therefore know both key lists and use the appropriate key list based on the generation service that generated the given credential.

[0202] In this scenario, both mG1 and mG2 will precisely act as the generation monitoring service mG in the original example. However, the monitoring of the verification service is different. The verification monitoring service mV must be able to send intra-node and inter-node reporting messages to each relevant generation monitoring service, and also be able to receive reaction messages from both generation monitoring services. Since G1 and G2 use different key lists, the transaction credential generation action performed by one G (G1 or G2) is completely independent of the transaction credential generation action performed by the other G, and therefore their corresponding lists of pseudo-random numbers (P') and local transaction counters (LTC) are completely independent of each other.

[0203] In this scenario, the detection of malicious actions needs to be handled by the collaborative monitoring service M. If malicious behavior identified in a transaction with credentials generated by one service and verified by V could affect V's verification of credentials generated by other generating services, the collaborative monitoring service M can instruct both mG1 and mG2 to perform distributed actions. This is a practical issue because an attacker who succeeds in an attack related to a specific card or token (PAN / TUR) in the (V<->G1) interaction might also use it in the (V<->G2) interaction. Using M effectively prevents malicious processing from affecting both generating services (G1 and G2) in the event that one of them is compromised.

[0204] When considering a process with two generation services (G1 and G2 in this case) and two verification services (V1 and V3 in this case), these two complex scenarios can be combined. In this case, collaborative monitoring M is necessary to support the actions of all parties. If an appropriate problem is detected and escalated, M can determine a set of distributed actions for mG1, mG2, mV1, and mV3 so that any malicious behavior discovered in any (Vy<->Gx) interaction is immediately communicated to any other affected party to contain the attack.

[0205] The interaction flow will be described in more detail below, starting with considering... Figure 20a All the basic cases shown. In Figure 21a and Figure 21b The interaction flows of the generation service G and the verification service V are illustrated separately. These flows show the temporal sequence of the different interactions and indications of the processing logic at each step, but do not provide a complete description of each message (this is not necessary for this discussion, as technicians will be able to provide an implementation of messaging based on this discussion without excessive effort). It should be noted that in some cases, the normal flow may be paused, and the content provided in messaging may differ (e.g., it may be limited to critical details when the system load is very heavy). It should be noted that the basic principle here is to separate the monitoring flow from the transaction flow as much as possible, where mG and mV provide the only points of interaction with their associated services regarding monitoring, both to completely separate the monitoring actions processed in the flow from the transaction flow, and to communicate necessary actions from other nodes or from the cooperating monitoring service M to the associated services.

[0206] Figure 21aThe diagram illustrates the interaction flow of the generation service G. The broader generation process is considered to be an extension of the actual credential generation by G, which then sends a vertically downward intra-node monitoring message (G->mG) containing the results of the cryptographic service activity and a complete trace of the execution of its local generation monitoring (mG) process. mG stores this trace (including transaction-related information) and updates its state in its database. mG also processes this information, which may trigger two distinct vertical interactions.

[0207] - Vertical upward interaction with processing node G may occur (mG->G). This may involve notifying G whether a transaction is complete (G does not wait for any response from mG when delivering transaction credentials to its clients) or may involve corrective actions, such as suspending tokens or blocking merchants (or PSPs) that trigger crypto-service requests if malicious activity is suspected. G ends the interaction flow by completing the processing required by mG.

[0208] - If an escalation to Collaborative Surveillance M is required, a vertical downward interaction (mG->M) will occur. This may simply be a completion instruction, but it could also prompt Collaborative Surveillance M to conduct further investigations into suspicious situations. In this case, M will take action based on the merged information described further below.

[0209] Figure 21b The interaction flow of verification service V verifying credentials generated by generation service G is illustrated. As previously stated, the monitoring operation does not interfere with the transaction flow—the verification action occurs first, followed by a vertically downward intra-node monitoring message (V->mV) sent to its local monitoring verification (mV) process. This contains information related to password verification, as shown in Table 1 below.

[0210]

[0211]

[0212] Table 1 - Information reported by Authentication Service V when verifying passwords

[0213] This information relates to password verification and LTC management—other checks may be performed during the verification process, but these are not directly related to this disclosure and will not be discussed further here.

[0214] The processing performed by mV may produce three different interaction streams:

[0215] - Horizontal Interaction: mV sends intra-node or inter-node reporting messages (mV->mG) to the corresponding local monitoring generation (mG) process in the node executing the cryptographic service G. This interaction and related processing are described in more detail below. mV can identify the relevant mG using the node identifier in the transaction data. In contrast, mG does not know which verification services V can verify the transaction credentials generated by G, so mG relies on the collaborative monitoring M to access all mVs, and mG can react to reporting messages from a given mV.

[0216] - Vertical upward interaction: mV sends an intra-node action message (mV->V) to its own password verification service V to correct or adjust the verification result to a final "continue processing / reject" state. V can perform this correction / adjustment process and send the final result to the issuer.

[0217] - Vertical Downward Interaction: If the transaction credential verification result requires notification of the processing result to other participants in the system, mV sends an escalation message (mV->M) to the Collaborative Monitoring (M). In this case, M will take action based on the merged information as further described below.

[0218] Horizontal interactions will now be considered in more detail. The generation service monitors mG to receive report messages within or between nodes, processes the received information, and assesses risks. Three further interaction flows may arise through communication with the following system elements:

[0219] - Using G–G notifications via an in-node action (mG->G), the action indicates whether cryptographic services should continue to be provided for the token in question, or whether such services should be suspended. The same in-node action message can convey other “extended” actions to G, such as suspending access to the merchant’s (or PSP’s) transaction credential generation service.

[0220] - mV-mV is notified via intra-node or inter-node reaction messages (mG->mV), which can be used to support the final decision on "continue processing / reject" for transaction credentials. mV continues the same vertical upward interaction with V (mV->V), and the vertical downward interaction with M as described above (mV->M).

[0221] - With the help of M-M, which provides an upgrade message notification, M combines it with other information and determines whether further action is needed.

[0222] Upon receiving an upgrade message from either or both of mG and mV, the collaborative monitoring service M executes the upgrade process. This may result in three further interaction flows, involving M sending distributed action messages to:

[0223] - Local monitoring only of the generation (mG) process: M->mG

[0224] - Local monitoring verification (mV) process only: M->mV

[0225] Both -mG and mV: M->mG,mV

[0226] Conversely, the local monitoring process performs its analysis and may identify three further interaction flows, thereby sending intra-node action messages to G-only, V-only, or both—this process occurs within... Figure 21c As shown in the image.

[0227] According to Figure 21a and Figure 21b The described transaction process will refer to the above. Figure 21a and Figure 21b The described method can be directly applied to the more complex use cases mentioned above (one G and two V, two Gs and one V, two Gs and two V).

[0228] from Figure 22 and Figure 23 It can be seen that there is a separation between real-time processing and near real-time monitoring. Figure 22 and Figure 23 The transaction and monitoring process for the generation service G and the verification service V is illustrated.

[0229] Figure 22 This describes the transaction and monitoring process for a successfully completed transaction credential generation service action requested by a legitimate merchant (or PSP). This scenario covers a completely vertical flow between G and mG, without any escalation to the collaborative monitoring process M.

[0230] The credential generation process occurs in real time. During process initialization, in this scenario, for P' = xx...xx, Cr = yy...yy, the transaction for MID (where P' is the challenge, Cr is the password, and MID (or PSP) is the merchant identifier) ​​will not have any trace of credential generation in the mG transaction database (mGTRX DB). The credential generation process is as follows:

[0231] 1. The merchant (or PSP) is identified using the MID, and then the merchant (or PSP) is established as a valid subscriber to the transaction credential generation service, sending a service request to the G process in the nearest node (let's assume it's Ni). This service request should contain PAN / TUR information. Here, PAN specifies the primary account—the regular primary identifier of the transaction card. In the case of tokenized digital transactions, it's more logical to refer to the token rather than the card. For this context, the term TUR (Token Unique Reference) is used as the unique identifier of the token.

[0232] 2. After the node's access control mechanism verifies the MID's permissions for the service, it grants access permissions and passes the service request to G.

[0233] 3. Based on the acceptance pattern, G will generate a fresh challenge P' = xx…xx (using the next LTC value) and will compute the corresponding cipher (Cr) for the acceptance conditions (e.g., amount, time / date): Cr = yy...yy. Acceptance patterns here may include Legacy (L), UCAF (U), and DPD (D1 and D2), where the DPD pattern has available options #1 and #2.

[0234] 4. The generation process will respond to the transaction credential service request with a triple (P' = xx…xx, Cr = yy…yy, MID). Note that if the PSP is processing more than one merchant, the MID can be provided in the response, and each merchant will use its own MID.

[0235] 5. Upon receiving the transaction voucher, the merchant (or PSP) will immediately forward the transaction voucher to the acquiring party in the case of a non-deferred transaction (direct purchase), or store the transaction voucher for later sending in the case of a deferred transaction (such as payment for transportation services, where the transaction is established at the time of booking).

[0236] In contrast, the monitoring actions occur in near real-time, after the generation service G has provided credentials. The monitoring actions are as follows:

[0237] 6.G uses intra-node monitoring messages to notify its local monitoring process mG of the completion of the transaction certificate generation service in near real-time. The intra-node monitoring message sends a triple (P' = xx…xx, Cr = yy…yy, MID).

[0238] 7. The local monitoring process mG receives the trace executed by the current service and checks it against all records collected for the PAN / TUR within this node during the period (the lifecycle of the key list), using (KLi, KLs) as parameters for the current key list. If such a record does not exist, it will be stored as a new record in mGTRX DB. mG will also maintain a counter in mGTRX DB for the execution instance of the transaction credential generation service, denoted as CtrTrxG. This counter will increment with any successful report of the transaction credential generation service execution. This counter can be used to support the period-end balance monitoring process—EoPBALANCE (see below). Figure 31 (To be discussed further).

[0239] The location of the verification service V is roughly the same. Figure 23This describes the transaction and monitoring process for a successfully completed transaction credential verification service action requested by a legitimate merchant (or PSP). This scenario covers a completely vertical flow between V and mV, without any escalation to the collaborative monitoring process M.

[0240] As before, the verification service V performs its actions in real time. The initialization process is the same as the generation service—there is no trace of the verification service's transaction credential verification service for transactions with P' = xx...xx, Cr = yy...yy, and MID (where P' is the challenge, Cr is the password, and MID is the merchant (or PSP) identifier) ​​in the mV transaction database (mVTRX DB). Furthermore, there is no trace of the challenge P' in the LTC database associated with V (VLTC DB). The real-time verification actions are as follows:

[0241] 1. The merchant (or PSP) MID uses the transaction certificate returned by the generation service after the service request for the generation process of the G certificate to legally submit the transaction P'=xx...xx,Cr=yy...yy,MID to the acquiring party.

[0242] 2. Vj receives the transaction credential and checks whether P' is already in its VLTC DB for PAN / TUR (for a given Ni, KLi). If not, Vj inserts it to prevent replay attacks. Afterward, Vj performs the following processing:

[0243] It uses the associated key list KLi to retrieve the identity (GId) of G.

[0244] It verifies the cipher for P' = xx...xx with values ​​yy…yy (i.e., for traditional use cases, recalculates and compares) Cr. Note that KLi and KL (not present in P') are also part of the encryption process and must be available.

[0245] It uses the value received as a password in the transaction certificate generated by G (the received yy…yy) to perform password verification on its result (the recalculated yy…yy).

[0246] It sets the results in the validation result (VO) vector as follows:

[0247] o cryptoValidation = SUCCESS (No password validation failure for this PAN / TUR: recalculated yy…yy = received yy…yy).

[0248] o replayDetection = NO_REPLAY (For PAN / TUR on this Ni with this KLi, P' is not in its list).

[0249] o retryControl = NO_RETRY (This field is only populated for accept mode "L", and will remain NO_RETRY for other accept modes).

[0250] o expiryDate = STANDARD (no end-of-month issues).

[0251] • When verification is successful, V will return "Continue Processing" from the transaction credential verification service to the authorization system (and thus to the issuer).

[0252] • By sending KL.Isolation from its associated key list, Vj reports whether it is the only node capable of verifying transaction credentials generated by G, or whether there are other Vk (k≠j) capable of verifying transaction credentials generated by G. (In this monitoring scenario, we assume Vj is the only verification node capable of verifying transaction credentials generated by G. In this case, KL.Isolation = TRUE. This means that mVj does not need to upgrade to M to mark P' for use in Vj's transaction credential verification, because this isolation means that collaborative monitoring does not need to act as a broadcast service to notify other Vs of P's use.)

[0253] As before, verification monitoring occurs after the verification result has been returned, and the following steps happen in near real-time:

[0254] 3. Vj uses intra-node monitoring messages to notify its local monitoring process mVj of the completion of the transaction credential verification service in near real-time. This intra-node monitoring message will send the tracking {GId,P'=xx…xx,Cr=yy…yy,VO} to mVj.

[0255] 4. mVj receives the trace of transaction credential verification and performs the following processing:

[0256] It stores the trace {GId,P'=xx…xx,Cr=yy…yy,VO} in its transaction database mVTRX DB.

[0257] It checks whether there are other verification processes besides Vj that can verify the transaction credentials generated by G:

[0258] If KL.Isolation = TRUE, then mVj does not need to be upgraded to M to query cross-node activity.

[0259] If KL.Isolation = FALSE, then mVj will be upgraded to M, which has already interacted with the multi-validator generation process. This will trigger the M flag to use the current LTC across nodes.

[0260] • mVj will also maintain a counter in the mVTRX DB for the execution of the transaction credential verification service, denoted as CtrTrxV. This counter will increment with any successful report of the transaction credential verification service and can be used to support the period-end balance monitoring process – EoPBALANCE (see below). Figure 31 (To be discussed further).

[0261] The use of this monitoring structure will now be considered in light of many different potential vulnerabilities.

[0262] Figure 24 The monitoring process for detecting replay attacks (attempts to resubmit already verified credentials) is shown. This may result in the suspension of a merchant's or PSP's access to the transaction credential generation service. The relevant initialization states of the process are as follows:

[0263] The transaction database (mGTRX DB) of mG has a generation tracking of transactions with P' = xx...xx, Cr = yy...yy, MID.

[0264] The VLTC database (VLTC DB) of b V has no trace of challenges to P' = xx...xx for PAN / TUR (for a given Ni, KLi) – this assumes that an attacker could potentially clean up the database.

[0265] The c mV transaction database (mVTRX DB) has a verification track of transactions with P' = xx...xx, Cr = yy...yy, MID.

[0266] The steps of the process are as follows, and the following steps correspond to Figure 24 The numbering steps in the process.

[0267] 1. The merchant (or PSP) MID uses the generation service to submit the transaction P' = xx...xx,Cr = yy...yy,MID to the acquirer based on the transaction credentials previously returned after the service request to the G process.

[0268] 2. Vj receives the transaction credential and checks whether P' already exists in its VLTC DB for PAN / TUR (for a given Ni, KLi). If not, Vj inserts it to prevent replay attacks—here it is assumed that P' does not yet exist due to the attacker's actions. Afterward, Vj performs the following processing (with... Figure 23 (The situations are exactly the same):

[0269] It uses the associated key list KLi to retrieve the identity (GId) of G.

[0270] It verifies the cipher for P' = xx...xx with values ​​yy…yy (i.e., for traditional use cases, recalculates and compares) Cr. Note that KLi and KL (not present in P') are also part of the encryption process and must be available.

[0271] It uses the value received as a password in the transaction certificate generated by G (the received yy…yy) to perform password verification on its result (the recalculated yy…yy).

[0272] It sets the results in the validation result (VO) vector as follows:

[0273] o cryptoValidation = SUCCESS (No password validation failure for this PAN / TUR: recalculated yy…yy = received yy…yy).

[0274] o replayDetection = NO_REPLAY (For PAN / TUR on this Ni with this KLi, P' is not in its list).

[0275] o retryControl = NO_RETRY (This field is only populated for accept mode "L", and will remain NO_RETRY for other accept modes).

[0276] o expiryDate = STANDARD (no end-of-month issues).

[0277] • When verification is successful, V will return "Continue Processing" from the transaction credential verification service to the authorization system (and thus to the issuer).

[0278] • By sending KL.Isolation from its associated key list, Vj reports whether it is the only node capable of verifying transaction credentials generated by G, or whether there are other Vk (k≠j) that can verify transaction credentials generated by G. (In this monitoring scenario, we assume that Vj is the only verification node capable of verifying transaction credentials generated by G. In this case, KL.Isolation = TRUE. This means that mVj does not need to upgrade to M to mark P' for use in Vj's transaction credential verification, because this isolation means that collaborative monitoring does not need to act as a broadcast service to notify other Vs of P's use.)

[0279] 3. Vj uses intra-node monitoring messages to notify its local monitoring process mVj of the completion of the transaction credential verification service in near real-time. This intra-node monitoring message will send the tracking {GId,P'=xx…xx,Cr=yy…yy,VO} to mVj.

[0280] 4. mVj receives the trace of transaction credential verification and performs the following processing:

[0281] ·it Detected The payment proof conflict occurs because its transaction database, mVTRX DB, already contains the trace {GId, P' = xx...xx, Cr = yy...yy, VO}. Given the separation between service provision and monitoring, this database is not easily vulnerable to attack.

[0282] It checks if there are other verification processes besides Vj that can verify the transaction credentials generated by G. Since KL.Isolation=TRUE, mVj does not need to be upgraded to M to query across nodes because there are no other verification paths.

[0283] 5. mVk prepares intra-node or inter-node reporting messages to indicate that a replay attack using P'=xx...xx,Cr=yy...yy,MID has occurred, and submits it to the relevant mG.

[0284] 6. Upon receiving the message, mG marks the transaction as a “replay attack” in the mGTRX DB and keeps it available outside the key list interval (archiving it) for use in the dispute resolution process.

[0285] 7.mG uses intra-node action messages to notify the access control system that it is necessary to block merchants (or PSPs) with MIDs from accessing the generation service until the dispute is resolved.

[0286] 8. Access control systems block merchants (or PSPs) from accessing services by adding MIDs to their access control list blacklists.

[0287] 9. The access control mechanism can also send outbound APIs to merchants (or PSPs) to inform them to suspend their subscription to the transaction credential generation service.

[0288] Figure 25 The monitoring process for preventing replay attacks involving multiple nodes—referred to herein as double-spending attacks—is illustrated. This can be prevented through a near real-time post-transaction process that prevents the double-spending of valid payment messages in two scenarios: multi-acquiring merchant (or PSP) attacks; and multi-node acquiring merchant (or PSP) attacks. In either case, the attacker expects two or more transactions executed using the same payment message to be authorized because the same valid payment message will be processed on multiple nodes, and their databases (especially the VLTC DB) may not be effectively synchronized.

[0289] - In the case of a multi-acquiring merchant (or PSP) attack, the attacker may expect the transaction credential verification service to use the node closest to the acquiring party that gave the payment message, which may be different for acquiring parties in different regions (e.g., one in the United States and another in Europe).

[0290] - For attacks targeting merchants (or PSPs) with multiple acquiring nodes, an attacker might, for example, attempt to exploit the acquiring party's strategy to send transactions to two different nodes, each charging different service fees to its merchant (or PSP) based on the time of day. This could be a characteristic of distributed payment systems that distribute transaction processing based on node load. For instance, the acquiring party could use one node for daytime transactions and another for nighttime transactions.

[0291] The following characteristics of the system can be assumed:

[0292] • G generates transaction credentials for any accepted scenario.

[0293] • G is assigned a list of keys that indicates that multiple validators can inspect its transaction credentials, so KL.Isolation = FALSE (G does not work with a single validator, but with more than one validator in a distributed network).

[0294] The length of the generated password Cr = yy…yy depends on the receiving pattern, and its range may be:

[0295] o Decimal value based on HMAC cipher (two digits D2D1) – in the case of using CVC to carry counter information (C) and cipher (D2D1) “L” acceptance.

[0296] o An 8-byte truncated cipher consisting of the leftmost 8 bytes of the HMAC cipher—in the case of “U” and “D1” acceptance (DPD option #1).

[0297] o A 16-byte truncated cipher consisting of the leftmost 16 bytes of the 32 bytes of the HMAC cipher – in the case of “D2” acceptance (DPD option #2).

[0298] • The transaction credential service is invoked by the merchant (or PSP) with MerchantID=MID.

[0299] As mentioned above, the transaction credentials generated by G can be verified by a set of two validators (Vj or Vk).

[0300] • Vj can be in the same node as G, or in a different node.

[0301] • Vj verifies the transaction credentials generated by G, which have a P' = xx…xx of appropriate length depending on the acceptance type. Note that KLi and KL (not present in P') are also part of the encryption process and must be available.

[0302] • Vj is used as part of the transaction credential verification process to verify the password:

[0303] o Password verification passes without any encryption failure: cryptoValidation = SUCCESS. Therefore, Vj inserts P' = xx…xx in its VLTC DB for PAN / TUR (for a given Ni, KLi).

[0304] o Do not mark replay attempts: replayDetection = NO_REPLAY.

[0305] o Do not retry during password verification: retryControl = NO_RETRY.

[0306] o does not verify on the last day of the month: expiryDate = STANDARD.

[0307] The steps of the process are as follows, and the following steps correspond to Figure 25 The numbering steps in the process.

[0308] 1.G performs the following operations:

[0309] • Calculate the password Cr = yy…yy and return it as part of a transaction credential with an appropriate length depending on the acceptance type in the transaction credential generation service response to the merchant (or PSP), and then send it to the transaction system via the acquirer.

[0310] • This is used to compose the intra-node monitoring message sent to mG, thereby passing P' = xx…xx, Cr = yy…yy as parameters, and the identifier MID of the merchant (or PSP) that initiated the service request.

[0311] 2. mG receives monitoring messages {P'=xx…xx,Cr=yy…yy,MID} from G and stores them in its mGTRX DB as a trace of transactions.

[0312] 3. Vj receives the transaction certificate and performs the following processing:

[0313] It checks that for PAN / TUR (for a given Ni, KLi), P' is not in its VLTC DB, meaning that Vj is unaware of any replay attempts for that payment message.

[0314] It uses the associated key list KLi to retrieve the identity GId of G.

[0315] It uses the values ​​yy…yy against P' = xx…xx to verify the password (i.e., for the traditional use case, recalculate and compare) Cr. Note that KLi and KL (which do not exist in P') are also part of the encryption process and must be available.

[0316] It uses the value received as a password in the transaction certificate generated by G (the received yy…yy) to perform cryptographic verification on its result (the recalculated yy…yy).

[0317] It appropriately sets the results in the validation result (VO) vector as follows:

[0318] o cryptoValidation = SUCCESS (No password validation failure for this PAN / TUR: recalculated yy…yy = received yy…yy).

[0319] o replayDetection = NO_REPLAY (For PAN / TUR on this Ni with this KLi, P' is not in its list).

[0320] o retryControl = NO_RETRY (This field is only populated for accept mode "L", and will remain NO_RETRY for other accept types).

[0321] o expiryDate = STANDARD (no end-of-month issues).

[0322] When verification is successful, V will return "Continue processing" as the output of the transaction credential verification service to the authorization system (by uploading it back to the issuer).

[0323] By sending KL.Isolation from its associated key list, Vj also reports whether it is the only node capable of verifying transaction credentials generated by G, or whether there are other Vk (k≠j) capable of verifying transaction credentials generated by G. In this monitoring scenario, we assume Vj is in the list of verification nodes with other verification nodes (e.g., Vk) capable of verifying transaction credentials generated by G. In this case, KL.Isolation = FALSE. This means that mVj needs to upgrade to M to mark P' as used (by Vj) in the transaction credential verification process. The co-monitoring M will then broadcast that P' has been used to any other verification service V capable of verifying the credential, resulting in P' not being used to verify other payment messages.

[0324] 4. mVj receives the transaction certificate and performs the following processing:

[0325] It stores the trace {GId,P'=xx…xx,Cr=yy…yy,VO} in its transaction database mVTRX DB.

[0326] It checks whether there are other verification processes besides Vj that can verify the transaction credentials generated by G:

[0327] If KL.Isolation = TRUE, then mVj does not need to be upgraded to M for cross-node queries.

[0328] If KL.Isolation = FALSE, then mVj will be promoted to M, which is interacting with the multi-validator generation process. This will trigger M to mark across nodes that the current LTC / P' was used by another validator node.

[0329] 5. In this case, since KL.Isolation = FALSE, M is notified via an upgrade message of the verified challenge P' and the verification result (VO) corresponding to the verification of the transaction certificate generated by G (identified by GId).

[0330] 6. Upon receiving this message, M will perform the following monitoring actions:

[0331] • Check the list of nodes that can verify transaction credentials, denoted as validatingNodes{Vj,Vk,...}. From this list, it retrieves that Vk is also a node that can verify transaction credentials generated by G (identified by GId).

[0332] • Prepare one or more distributed action messages, corresponding to the number of nodes in the validatingNodes list, excluding the nodes that just validated the transaction credentials. This message will include the challenge P' = xx…xx used and the identifier of the node performing the validation, etc.

[0333] 7. In this example, there is only one node Nk and its local verification monitoring process mVk, to which a distributed action message needs to be sent to notify it of the use of P' = xx…xx.

[0334] 8. Upon receiving this message, mVk will, in turn, notify Vk of the use of P'.

[0335] 9. Vk will check whether P' is already in its VLTC DB for PAN / TUR (for a given Ni, KLi), and if not, Vk will insert P' to prevent replay attacks.

[0336] By taking these steps, the monitoring process enables the system to identify replay attacks not only at a single node, but also those involving multiple nodes. The response process then changes as needed.

[0337] The following provides the response procedures to be executed when a double-spending attack (a replay attack on multiple nodes) is detected, for the following two scenarios:

[0338] • A G, but verified by separate Vj and Vk. In this case, the near real-time action of the collaborative monitoring M adds P' to the VLTC DB of Vk because PAN / TUR (for a given Ni, KLi) determines that the value has been used by Vk (step 9 in the previous section).

[0339] • Single G and V – In this case, the process is triggered by V verifying the transaction credentials without the intervention of coordinating monitoring M. Upon verification, V sees that P' has already been used because it is marked in its VLTC DB as being used for PAN / TUR (for a given Ni, KLi).

[0340] The near real-time protection against double-spending attacks described in the previous paragraph can prevent most fraudulent attempts. However, if an attacker has the potential to submit P' in transaction credential verification before monitoring allows node Vk to know about P', then the preventative efforts made by Vj will be ineffective. Therefore, an extended process is needed that includes signaling a response to detected double-spending fraud. For the case of one G and two Vs, in Figure 26 The extended process is illustrated below. While full prevention is possible if the steps shown above have already allowed Vk to know about earlier expenditures, the attack can be contained if it is determined in step 9 that P' has been used.

[0341] 10. Vk notifies mVk via an intra-node monitoring message that P' = xx…xx has been used as a payment message because it exists in its VLTC DB for PAN / TUR (for a given Ni, KLi).

[0342] 11.mVk prepares a double-spending intra-node / inter-node report message for payment messages of P'=xx…xx and submits it to mG.

[0343] 12. Upon receiving the message, mG marks the transaction as "double-spending" in the mGTRX database and keeps it available outside the key list interval (archiving it) for use in subsequent dispute resolution processes.

[0344] 13.mG notifies the access control system via intra-node action messages that it is necessary to block merchants (or PSPs) with MIDs from accessing the service until the dispute resolution process is resolved.

[0345] 14. Access control systems block merchants (or PSPs) from accessing services by adding MIDs to their access control list blacklists.

[0346] Here, the primary purpose of mVk is to notify G that the merchant (or PSP) can be blacklisted, thus ceasing the generation of transaction credentials that could be abused. This blocking decision can be made upon the first detection of a replay, or when the number of replays exceeds the limit defined in the associated key list.

[0347] mVk can also escalate detected issues to collaborative monitoring M. Here, the goal is for M to distribute information to all mVs (and associated Vs using intra-node messaging) if this is necessary to stop verification of all transaction credentials that are part of a transaction from that MID—which is in Figure 26 Not explicitly shown in the document. If a merchant (or PSP) is using more than one node to generate transaction credentials, the same method can be used to communicate the list to mG (cascading to the relevant G).

[0348] Figure 27 The instruction is to use a monitoring system to detect and communicate replay fraud between associated G and V – in this case, a replay attack attempted by a merchant (or PSP) against a single node Vj that verifies transaction credentials generated by G.

[0349] The steps of the process are as follows, and the following steps correspond to Figure 27 The numbering steps in the process.

[0350] 1.G performs the following operations:

[0351] • Calculate the password Cr = yy…yy and return it as part of a transaction credential with an appropriate length depending on the acceptance type in the transaction credential generation service response to the merchant (or PSP), and then send it to the transaction system via the acquirer.

[0352] • This is used to compose the intra-node monitoring message sent to mG, thereby passing P' = xx…xx, Cr = yy…yy as parameters, and the identifier MID of the merchant (or PSP) that initiated the service request.

[0353] 2. mG receives monitoring messages {P'=xx…xx,Cr=yy…yy,MID} from G and stores them in its mGTRX DB as a trace of transactions.

[0354] 3. Vj receives the transaction credentials from the merchant (or PSP) and attempts to add P' to the list of already used challenges, but finds that for PAN / TUR (for a given Ni, KLi), the value of P' is already in its VLTC DB—indicating that a replay has already occurred. Vj performs transaction credential verification, and in this example, we show the case where the number of replays exceeds the limit defined in the key list (KLi).

[0355] 4. Vj sends an intra-node monitoring message to mVj for the P'=xx…xx,Cr=yy…yy,GId,KL.Isolation indication and VO. The VO is filled with the REPLAY_EXCEEDED replay detection indication.

[0356] 5.mVj verifies the KL.Isolation instruction; if it is true, it signals the merchant (or PSP) to detect a replay attack without escalating to M.

[0357] 6.mVj sends intra-node / inter-node report messages indicating a “replay attack” against the challenge P’=xx…xx.

[0358] 7.mG marks transactions as “replays” in its mGTRX DB so that they can be archived for use in any further dispute resolution process.

[0359] 8.mG will notify the access control system via in-node action messages that it is necessary to block merchants (or PSPs) with MIDs from accessing the transaction credential generation service until the dispute resolution process is resolved.

[0360] 9. Access control systems block merchants (or PSPs) from accessing services by adding the MID to their access control list blacklist.

[0361] Figures 28 to 30 This involves using surveillance systems to detect and signal different types of speculative attacks. Figure 28 This involves situations where there is no malicious intent but only a processing error introduced by the receiving infrastructure; Figure 29 This involves guessing attempts made by a single merchant (or PSP); and Figure 30 An attempt to speculate involving an alliance of dishonest merchants (or PSPs).

[0362] exist Figure 28 In this case, a processing error in the merchant's (or PSP's) acceptance infrastructure has resulted in an incorrect value in the transaction certificate. The following assumption is made:

[0363] • G is for a guessable acceptance case (e.g., the traditional acceptance case "L", where the generated password is D2D1 = yy (two digits)) to perform transaction credential generation.

[0364] Merchants (or PSPs) with MerchantID=MID request transaction credential generation service.

[0365] The transaction credentials generated by G can be verified by Vj on the same node or different nodes.

[0366] • Vj verifies the transaction certificate generated by G using LTC=8. V inserts LTC=8 into its VLTC DB for PAN / TUR (for a given Ni, KLi).

[0367] • Vj is used as part of the transaction credential verification to verify the password, where D2D1 = xx (≠ yy):

[0368] o Vj failed password verification and indeed exceeded the allowed number of failures: cryptoValidation = FAILURE_EXCEEDED.

[0369] o Vj does not mark replay attempts: replayDetection = NO_REPLAY.

[0370] o Vj does not retry during cryptographic verification (because LTC≤19): retryControl=NO_RETRY.

[0371] Described below Figure 28 The monitoring and response process is shown.

[0372] 1.G performs the following operations:

[0373] • Calculate the password Cr = yy…yy and return it as part of a transaction credential with an appropriate length depending on the acceptance type in the transaction credential generation service response to the merchant (or PSP), and then send it to the transaction system via the acquirer.

[0374] • This is used to compose the intra-node monitoring message sent to mG, thereby passing P' = xx…xx, Cr = yy…yy as parameters, and the identifier MID of the merchant (or PSP) that initiated the service request.

[0375] 2. mG receives the intra-node monitoring message {P'=xx…xx,Cr=yy…yy,MID} from G and stores it in its mGTRX DB as a trace of the transaction.

[0376] 3. Vj receives the transaction certificate and performs the following processing:

[0377] • For LTC=8 verification cipher (i.e., for the traditional use case, recalculate and compare) D2D1, its value is yy.

[0378] It uses the value (xx) received from G as D2D1 to perform cryptographic verification on its result (yy).

[0379] It appropriately sets the results in the validation result (VO) vector as follows:

[0380] o cryptoValidation = FAILURE_EXCEEDED(yy ≠ xx and the password validation attempts exceeded the limit, because it is assumed that the acceptance error persists).

[0381] o replayDetection = NO_REPLAY (For PAN / TUR on this Ni with this KLi, LTC=8 is not in its VLTC DB).

[0382] o retryControl=NO_RETRY(LTC≤19).

[0383] o expiryDate = STANDARD (no end-of-month issue).

[0384] Since the verification has failed, Vj will return a "reject" as the transaction credential verification service result to the authorization system (and thus to the issuer).

[0385] • Vj reports to the monitoring layer by sending KL.Isolation whether Vj is the sole node verifying transaction credentials generated by G, or whether there are other Vk (k≠j) that can verify G's transaction credentials. In this monitoring scenario, we assume that Vj is the sole verifier of G's transaction credentials because KL.Isolation = TRUE. This means that mVj does not need to upgrade to M to find out whether other nodes in the network have used the same LTC (as we have shown in the previous section on challenging P').

[0386] • Vj forms the monitoring messages within the node, and it sends the received transaction credentials—namely {LTC=8,D2D1=xx,VO,KL.Isolation}—to mVj.

[0387] 4. mVj receives the message and performs the following processing:

[0388] It stores the trace {LTC=8,D2D1=xx,VO} in its transaction database mVTRX DB.

[0389] It checks whether there are other verification processes besides Vj that can verify the transaction credentials generated by G:

[0390] If KL.Isolation = TRUE, then mVj does not need to be upgraded to M to resolve cross-node double-spending.

[0391] If KL.Isolation = FALSE, then mVj upgrades to M, having already interacted with the multi-validator generation process. This will trigger M to cross-node verification to determine if the current LTC has been used by another validator node. In this case, since KL.Isolation = TRUE, M is not involved, and mVj does not send an upgrade message.

[0392] Conversely, mVj forms intra-node / inter-node reporting messages to notify mGV of the encryption failure detected by V at LTC=8. For this purpose, the reporting message carries the LTC value itself, the value of the cipher D2D1 received by V (i.e., xx), and the verification result (VO) vector.

[0393] 5. mG verifies the VO and detects VO.cryptoValidation="FAILURE_EXCEEDED". mG infers that it must check the merchant (or PSP) MID for possible guessing attacks. Therefore, mG performs the following steps:

[0394] • Check in its mGTRX DB whether it has recorded the generation of a transaction certificate with LTC=8.

[0395] • If a corresponding record exists:

[0396] o checks whether the D2D1 value (xx) received from mVj is indeed different from the value (yy) generated by G (and tracked in mG).

[0397] o identifies the merchant (or PSP) that submitted the transaction that triggered the transaction credential verification service. After receiving the D2D1=yy value in the transaction credential generation service response from G, the merchant (or PSP) is expected to send it as is to the acquirer. If the password received by Vj in the transaction credential is different (i.e., xx), we can assume that a change has occurred at the merchant / PSP / acquirer level.

[0398] If VO.cryptoValidation = FAILURE_EXCEEDED, this means that the merchant's (or PSP's) infrastructure is corrupted and has been performing multiple (persistent) errors. The merchant (or PSP) should then be blacklisted by the access control list (ACL) managed by the access control mechanism associated with G until it repairs its infrastructure to function properly.

[0399] Otherwise, if VO.cryptoValidation="FAILURE", the merchant (or PSP) will usually be tolerated, as this is likely a one-off or immediately correctable issue rather than a system failure.

[0400] 6. If blacklisting is required, mG will create an in-node action for G's access control logic to block the merchant (or PSP) MID until it has upgraded / corrected its infrastructure.

[0401] 7. Upon receiving this action message, the access control mechanism can add the MID to the access control list blacklist to temporarily prohibit the merchant (or PSP) from accessing the transaction credential generation service.

[0402] 8. The access control mechanism can also send outbound APIs to the merchant (or PSP) to indicate that service is interrupted until the infrastructure failure is resolved.

[0403] Figure 29 The monitoring and signaling flow is shown in a scenario where the merchant is malicious, rather than facing an infrastructure failure. This monitoring flow is designed to curb the threat of merchants (or PSPs) introducing fraudulent transactions into the system. For these transactions:

[0404] • G did not generate a valid transaction certificate.

[0405] Merchants (or PSPs) attempt to guess the password value contained in the transaction credentials in an attempt to create and cash out counterfeit payment transactions.

[0406] exist Figure 29 The process is illustrated below, with the following steps:

[0407] 1. The attacker performs the following:

[0408] • Guess the password D2D1 = xx and send it as part of the transaction flow via the acquirer to the transaction scheme. In this case, the value is an incorrect guess because G will generate a password value yy for the corresponding LTC (as part of the transaction certificate generation), where yy ≠ xx.

[0409] • G did not receive a transaction credential generation service request from the merchant (or PSP) MID.

[0410] • No intra-node monitoring messages were sent from G to mG.

[0411] 2. mG did not receive any intra-node monitoring messages from G and did not store any transaction traces {LTC=8,D2D1=xx,MID} in its mGTRX DB.

[0412] 3. Vj execution processing and in Figure 26 The processing performed at the same steps in the same case is slightly modified because the MID received from the acquirer must be further passed to mVj in the intra-node monitoring message. The remaining processing performed by Vj remains unchanged.

[0413] 4. In the sense that the MID received from mVj must be further passed to mG in a report message within or between nodes, the processing performed by mVj is different from... Figure 26 The situation has been slightly modified compared to the previous version.

[0414] 5. mG verifies the VO and detects VO.cryptoValidation = "FAILURE_EXCEEDED" (assuming here it's not the merchant's (or PSP's) first guessing attempt on this PAN / TUR on this LTC, and the attacker is acting alone and not in league with / colluding with other merchants or PSPs). mG infers it must check the merchant's (or PSP's) MID for suspicion of a guessing attack. To do this, mG performs the following steps:

[0415] • Check in its mGTRX DB whether the generation of a transaction certificate with LTC=8 has been recorded.

[0416] • No corresponding record exists:

[0417] o Store the evidence of the guessed attack traces in mGTRX DB {LTC=8,D2D1=xx,VO,MID}.

[0418] Use MID to identify merchants (or PSPs) that introduce rogue payment messages.

[0419] If VO.cryptoValidation = FAILURE_EXCEEDED, this means that the merchant (or PSP) has performed multiple rogue transaction attempts. The merchant (or PSP) should be added to the Access Control List (ACL) managed by the access control mechanism associated with G until an audit clarification is triggered by the acquiring party or the transaction scheme.

[0420] Otherwise, if VO.cryptoValidation = "FAILURE", then mG should look for other speculative attack traces (see below). Figure 28 Condition).

[0421] 6.mG creates in-node action messages for G's access control logic to block merchants (or PSPs) MIDs suspected of "guessing attacks" until auditing and appropriate corrective action are taken.

[0422] 7. Upon receiving the action message within the node, the access control mechanism adds the MID to the access control list blacklist to temporarily prohibit the merchant (or PSP) from accessing the service.

[0423] 8. The access control mechanism can also send outbound APIs to merchants (or PSPs) to suggest service interruptions until a fraud and risk management audit has been conducted.

[0424] Figure 30 The scenario illustrates surveillance in the event of a collusion between dishonest merchants (or PSPs) engaging in guessing attempts. In this surveillance scenario, we are attempting to uncover collusion between two (or more) dishonest merchants (or PSPs). In this collusion, the total number of guesses on the password (contained in the transaction credential) is limited to only one or two—this way, the cryptoValidation validation result remains at the "FAILURE" level, but is not marked as cryptoValidation=FAILURE_EXCEEDED in Vj's ValidationOutcome to avoid blacklisting during access control. This allows attempts to continue searching for the correct guess without suspending the merchant's access to the transaction credential verification service (as part of transaction processing), which could be combined with suspending their access to the transaction credential generation service.

[0425] Monitoring Stream and Figure 27 They are almost identical, but with the following differences:

[0426] In step 3, the VO reports VO.cryptoValidation = FAILURE (instead of FAILURE_EXCEEDED).

[0427] In step 5, if VO.cryptoValidation = FAILURE, then the following processing is performed:

[0428] • Search in mGTRX DB for another rogue transaction from a different merchant (or PSP) (who is believed to have colluded with the merchant in the transaction) for the same LTC {LTC=8,D2D1=zz,VO,colludingMID(colludingMID)}.

[0429] If found, both merchants (or PSPs) will be blacklisted as MID and colludingMID for attempting a collusive attack.

[0430] • Maintain tracking of current rogue transactions marked as collusion, i.e., {LTC=8,D2D1=xx,VO,MID,collusion}, for further auditing of merchants (or PSPs) attempting to guess the attack.

[0431] Otherwise (i.e., no other fraudulent transactions with LTC=8 were found for another merchant (or PSP)) the process continues without escalation.

[0432] Figure 31This illustrates the further monitoring procedures to be performed at the end of the validity period of a specific key list. This allows for the evaluation of statistics related to the generation and verification of transaction credentials for PAN / TUR (or a list of PAN / TUR) at the end of the key list's validity period. The aim is to identify any discrepancies in the counters that may reveal attempts to abuse the system (generating [CtrTrxG] to verify [CtrTrxVj, CtrTrxVk…]).

[0433] Figure 29 The monitoring process shown is as follows:

[0434] At the end of the time period, each node—whether generating or verifying—provides an intra-node monitoring message to its corresponding monitoring processes mG, mVj, mVk, thereby (respectively) indicating the list of challenges P' it has at the end of the time period for the given key list.

[0435] Upon receiving this information, 2.j and 2.k check their respective mGTRX DB, VTRX DB Vj, and VTRX DB Vk to retrieve information related to the generator node's successful transaction credential generation counter (CtrTrxG) and successful transaction credential verification counter (for which the verification result indicates that the encryption verification did not fail and there is no replay indication, denoted as CtrTrxVj, CtrTrxVk, etc.).

[0436] 3.j, 3.k Nodes that verify transaction credentials generated from a generator will report a counter (CtrTrxV) of their verified transaction credentials and a list of challenges used (VLTCList(V)). In this regard, each Vj, Vk will send intra-node / inter-node reporting messages, thereby reporting to each verifying node (in... Figure 29 The example shown has only two, namely: Vj and Vk) indicate both CtrTrxVj and VLTCList(Vj).

[0437] 4. After receiving the aforementioned information from all verification nodes, mG will execute two balancing equations:

[0438] • Check that CtrTrxG≥(CtrTrxVj+CtrTrxVk+....).

[0439] • Check that the intersection of any two VLTCList(Vj) and VLTCList(Vk) is empty (this means there are no double-spending attempts), where j≠k.

[0440] 5.j,5.k If both of the above equations are verified, then mG will send intra-node / inter-node response messages, thereby indicating to each verified node the closure of the PAN / TUR balance.

[0441] Therefore, each node will remove all transactions that have been balanced for that PAN / TUR from its corresponding transaction database, as those will be undisputed.

[0442] 7. If any balance equation is not verified, the upgrade will be forwarded from mG to Cooperative Monitoring M for this PAN / TUR.

[0443] 8,8.j,8.k M will coordinate the distribution of actions during its term to block PAN / TUR and store the corresponding disputed transactions in the mVTRXDB of each validator node Vj, Vk...

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

Claims

1. A method for monitoring services executed at a computing node, wherein the computing node is one of a plurality of computing nodes in a distributed computing system, each computing node being adapted to execute at least one service for a client, wherein each service has an associated monitoring process adapted to monitor the execution of the service process, wherein, The service process includes a first service process for performing a first service and a second service process for performing a second service, wherein the first and second service processes are complementary. The first service process includes the generation of credentials, and the second service process includes the verification of credentials. The method includes a monitoring process. To monitor the service process in accordance with the intended use of the service; and The monitoring information is provided to the monitoring process used in another service process. Among these features, surveillance enables the prevention of credential fraud or abuse.

2. The method as described in claim 1, wherein, The monitoring process provides the monitoring information directly after the service process is completed.

3. The method as described in claim 1, wherein, The monitoring process provides monitoring information after receiving monitoring information from another service process.

4. The method as claimed in any of the preceding claims, wherein, The monitoring process has a monitoring process database, wherein the monitoring process updates the monitoring process database while monitoring the service process.

5. The method of claim 1, wherein, The service process monitored by the monitoring process is a second service process, and the method includes providing monitoring information to the monitoring process of the first service process that generates the credential.

6. The method of claim 5, wherein, The monitoring process also receives monitoring information responses from the monitoring process of the first service process that generated the credentials.

7. The method of claim 6, wherein, Upon receiving the monitoring information response, the monitoring process updates the service process being monitored by the monitoring process.

8. The method of claim 6 or claim 7, wherein, The monitoring information response indicates that the credential is invalid or that the credential was never generated and cannot be used for legitimate purposes.

9. The method of claim 1, wherein, The service process monitored by the monitoring process is a first service process, and the method includes providing monitoring information to the monitoring process of a second service process that verifies the credentials.

10. The method of claim 9, wherein, In response to verification monitoring information received from the monitoring process of the second service process that verifies the credentials, monitoring information is provided as a monitoring information response.

11. The method of claim 10, wherein, Upon receiving the verification monitoring information, the monitoring process either determines whether the credential has been used, and if so, indicates this in the monitoring information, or determines whether the credential can be used for legitimate purposes, and if not, indicates this in the monitoring information.

12. The method according to any one of claims 1-3, wherein, The monitoring process is also adapted to provide update messages to update the service processes monitored by the monitoring process.

13. The method of claim 12, wherein, The service process monitored by the monitoring process has an associated service process database, wherein the service process monitored by the monitoring process updates the service process database when an update message is received from the monitoring process.

14. The method according to any one of claims 1-3, wherein, The monitoring process is also adapted to provide escalation messages to a collaborative monitoring process associated with multiple service processes or to receive action messages from the collaborative monitoring process.

15. The method of claim 14, wherein, After providing an upgrade message, the monitoring process receives an action message from the collaborative monitoring process to update itself, and upon receiving the action message, the monitoring process updates the service process being monitored by the monitoring process.

16. A method for monitoring services executing in a distributed computing system, wherein, The distributed computing system includes multiple computing nodes, each adapted to perform at least one service for a client. The service is performed by a service process with an associated monitoring procedure. Each service process includes a first service process for performing a first service and a second service process for performing a second service, wherein the first and second service processes are complementary. The first service process includes credential generation, and the second service process includes credential verification. The method is performed by a collaborative monitoring service, and the method includes: Receive escalation messages from one of the monitoring processes; Based on the upgrade message, determine whether action needs to be taken at one or more service processes on one or more compute nodes; and If action is required, an action message is sent to the monitoring process of the affected service process. Among these features, surveillance enables the prevention of credential fraud or abuse.

17. The method of claim 16, wherein the action message indicates to a plurality of second service monitoring processes that the credentials have been used.

18. The method of claim 16 or claim 17, wherein, The action message indicates to multiple service procedures that the identified user of the distributed computing system is no longer allowed to use one or more of the services.

Images