Security model for distributed computing systems

Abstract

A method for a computing node to provide cryptographic keys in response to service requests, the method comprising: establishing a key list, wherein the key list comprises key identifiers for a plurality of keys; receiving a service request and identifying that a key is required in response to the service request; and allocating one of the key identifiers using a deterministic process dependent on data associated with the service request and thereby allocating the key associated with said one of the key identifiers to the service request. A suitably configured computing node is also described.

Description

[0001] Cross-references to related applications

[0002] This application is based on and claims the benefit and priority of European patent application No. 19178579.9 filed on 5 June 2019 and European patent application No. 19178583.1 filed on 5 June 2019, the contents of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] This disclosure relates to the management of credentials and security models used in distributed computing systems. Specifically, this disclosure relates to distributed systems with a very large number of clients that require credentials to be associated with the use of the system. Background Technology

[0004] There are many technical challenges in providing services to a very large number of clients using a centralized system, especially when these clients are geographically dispersed. It is logical to consider distributed systems that allow the relevant services to be provided by a set of geographically distributed servers, rather than by a central server or data center.

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

[0006] Decentralization itself can be problematic, especially when it's necessary to provide services in this way, as the supply of services can exceed the capacity of the servers providing the services and the clients receiving them. For example, if other clients (or other system nodes) need to trace back to the service-providing node to check if or how the service was provided, or if the central system needs to know how the service was provided or the performance of the distributed server nodes, new bottlenecks may emerge on the central server, replacing previous 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 the service is security-related (and therefore must be securely executed throughout the system) and when it involves providing the service over a short period of time. Both of these issues apply to transaction systems—where transactions must be authorized within a short timeframe and it must be ensured that they have been legally executed—but also to other technological scenarios. Summary of the Invention

[0008] In a first aspect, this disclosure provides a method for a computing node to provide a cryptographic key in response to a service request, the method comprising: establishing a key list, wherein the key list includes key identifiers of a plurality of keys; receiving a service request and identifying a required key in response to the service request; and allocating one of the key identifiers using a deterministic process based on data associated with the service request, and thus allocating a key associated with said one of the key identifiers to the service request.

[0009] This approach provides a highly efficient and scalable method for assigning keys to cryptographic processes. Using a deterministic process in this way makes it easy to determine which key was used in a given situation.

[0010] A compute node can be one of multiple nodes in a distributed computing system, and service requests can be received from clients within the distributed computing system. This client can be a subset of the clients in the distributed computing system associated with the compute node.

[0011] Service requests can be associated with credential management—specifically, with credential generation or verification. Credentials can be associated with transactions executed by the client providing the service request. Data associated with a service request may include a transaction identifier, which may be based on a local transaction counter.

[0012] The key list includes unique identifiers. Deterministic processes can be identified within the key list. The key list can be cryptographically sealed using a key list sealing lock.

[0013] Key lists can have expiration dates. When an expiration date arrives, it can be replaced by another key list. This other key list can be provided by a central service located far from the compute nodes, or it can be generated locally or provided by peer nodes. In the case of credentials, the expiration date can be related to the generation of the credential, but not to the verification of the generated credential.

[0014] The cryptographic method used to employ the key can be identified in the key list—one possibility being HMAC. Information from the key list serves as input to the cryptographic process, and as a way to bind the process's output to the key list. In an embodiment, the cryptographic process delivers cryptographic proofs on the compute node, information from the service request, a transaction identifier, and information from the key list.

[0015] In a second aspect, this disclosure provides a computing node adapted to provide a cryptographic key in response to a service request according to the method of the first aspect. The computing node may include one or more hardware security modules therein for storing the cryptographic key. Attached Figure Description

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

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

[0018] Figure 2 It shows the provision of and Figure 1 A distributed computing architecture that provides the same services to multiple clients within a central server;

[0019] Figure 3 This schematically illustrates a distributed transaction system architecture using a four-party model;

[0020] Figure 4 The diagram illustrates what is suitable for implementation. Figure 3 The elements of a complex distributed system in the transaction system architecture;

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

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

[0023] Figure 7 A more detailed illustration is provided. Figure 6 The arrangement of computational nodes;

[0024] Figure 8 The diagram shows... Figure 7 Elements within a compute node;

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

[0026] Figure 10 Instructions in Figures 7 to 9 The implementation of the arrangement uses tokenization;

[0027] Figure 11 Indicates the key management method used in the embodiments of this disclosure;

[0028] Figure 12 An exemplary method for transaction identification is illustrated;

[0029] Figure 13 The illustrations depict a set of exemplary cryptographic mechanisms for digital transactions in embodiments of this disclosure;

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

[0031] Figure 15 The diagram illustrates the relationship with Figure 11 and Figure 14 The key management model is associated with a global monitoring model;

[0032] Figure 16 The illustration shows the use of having Figure 7 and Figure 8 An exemplary modification of the tokenization process for transactions in traditional use cases of nodes;

[0033] Figure 17 The diagram illustrates the key rotation process in a system using traditional use cases;

[0034] Figure 18 The illustration shows a set of exemplary cryptographic mechanisms for digital transactions using traditional use cases;

[0035] Figure 19 The diagram illustrates the use of suitable and Figure 7 and Figure 8 The traditional use case method of using nodes together to carry local transaction counters;

[0036] Figure 20 The diagram illustrates the use of and Figure 7 and Figure 8 The nodes use Card Verification Code (CVC) together to deliver local transaction counters. Figure 19 Methods;

[0037] Figure 21 The diagram illustrates the use of suitable and Figure 7 and Figure 8 The method of using the UCAF (Universal Cardholder Authentication Field) format together with nodes to transmit transaction credential information as part of a transaction;

[0038] Figure 22 The diagram illustrates a set of exemplary cryptographic mechanisms used for digital transactions using the UCAF format; and

[0039] Figure 23 The diagram illustrates the use of... Figure 7 and Figure 8 The method of using DPD (Digital Payment Data) with nodes to transmit transaction credential information. Detailed Implementation

[0040] Generally speaking, the problem addressed by this disclosure is Figure 1 and Figure 2 The diagram in the middle is shown. Figure 1 This illustrates a central system that performs functions in response to requests from a very large number of geographically distributed entities. This places heavy demands on the central system in terms of processing power, storage, and messaging, and often results in significant latency across the entire system due to bottlenecks and messaging requirements.

[0041] Figure 2 An alternative arrangement is illustrated, in which the role of the central system is decomposed, allowing a set of distributed nodes to perform the same functions, each node having the capability to perform some or all of the functions provided by the central system. Each node should see significantly lower demands than the central system, and latency can potentially be reduced because entities should be able to interact with nodes that are more local than the central system. However, as discussed generally above, and in the specific context of transaction processing systems below, there are significant technical challenges in realizing these benefits.

[0042] This issue is particularly relevant to transaction processing systems, especially those used to process digital transactions. The volume of digital transactions is growing extremely rapidly, necessitating their reliable and fast execution. While these transactions can be supported using transaction processing systems developed for device-based payments using payment cards, and employing the protocols of such payment systems, these transactions actually differ from device-based transactions in many ways. This will be discussed below, first referring to the general elements of a transaction processing system, and then discussing in more detail the infrastructure used to support digital transactions.

[0043] Figure 3 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.

[0044] Typically, card schemes—payment networks associated with 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.

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

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

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

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

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

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

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

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

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

[0054] The transaction infrastructure (transaction infrastructure) 5 here provides not only the computing infrastructure required for the card scheme and transaction routing and other messaging to parties such as acquirer 3 and issuer 4, but also wallet service 17 supporting digital wallets on the cardholder's computing device, and internet gateway 18 to accept internet-based transactions for processing by the transaction infrastructure. In other embodiments, wallet service 17 may be similarly provided by a third party with appropriate trust relationships with the transaction scheme 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 appropriate trust relationships), and the transaction infrastructure provides digital implementation service 16 to support the execution of tokenized digital transactions and to interact with other elements of the system to ensure that transactions are executed correctly—this digital implementation service may include other elements such as token service provisioning.

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

[0056] Figure 5The elements of the transaction infrastructure supporting digital payments from mobile devices are illustrated in more detail. The figure shows the applicant's Mastercard Cloud Based Payment (MCBP) architecture as a specific example—this is exemplary and not specific to the invention—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 payment card 6 used by mobile device 11.

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

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

[0059] The Credential Management System (CMS) 44 supports the management of cardholder credentials and is the key system within the MDES 42. The core system 441 manages synchronization with the entire transaction system through interaction with the TMS 46 and manages the channel to the AES 43. The dedicated system 442 provides the necessary elements (such as digitized 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.

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

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

[0062] The embodiments of this disclosure are for implementing functions such as Figure 5 The various aspects of the digital transaction system illustrated—particularly 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 6 to 8 As shown in the image.

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

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

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

[0066] 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 according to a hierarchical process. An issuer master key (IMK) is associated with a specific range of tokens, and the keys used for credentials are derived hierarchically (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 much more rapidly than device-based interactions, where growth is more aligned with resources.

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

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

[0069] This disclosure supports this distributed approach by allowing the allocation of the first available key from the key stack to tokenized transactions, replacing the token binding with a key derived from a specific hierarchy. This approach uses flexible and dynamic key management, allowing for scalable solutions. Monitoring can be performed in a way that ensures the security of the distributed architecture without transmitting or copying large amounts of sensitive information. This approach can also be implemented in standard HSMs using fully FIPS-compliant processes—for example, without the need for DES and 3DES. This approach is described in more detail below.

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

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

[0072] Much of this security is provided even when the system endpoint (e.g., at the cardholder's device) is potentially vulnerable to attack. Beyond that, the role of security is limited, such as... Figure 9 As shown in the diagram. The primary purpose of cryptographic functions is to provide guarantees—this covers both data integrity and authentication. Transaction-related data protected by cryptographic data includes the transaction's identifier and associated token, as well as instructions for any cryptographic processes used and any related financial data (and any other aspects of the transaction requiring guarantees). This is represented by transaction credentials—which require the generation of G and subsequent verification of V, processes monitored by M to ensure overall system integrity and supported by some kind of key management system K.

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

[0074] This approach allows the credentialing system to be distributed from a complex central server to multiple nodes providing the 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 related to credentials, generation service G, and verification service V, and define rules for access control to these services. Merchants or PSPs communicate with generation service G to obtain credentials, which are then used in standard authorization processes, and verification service V is invoked when credentials need to be verified. These services have access to the node's computing infrastructure (HSM, database). Monitoring service M and key management service K are also provided—these services can be centrally organized or include a hybrid of central and local functions. All these services and their interrelationships are described in more detail below.

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

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

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

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

[0079] Figure 11The diagram illustrates an exemplary arrangement of node Ni, which has two generation services G capable of generating credentials associated with transactions. At any given point in time, these services G will need to use a given list of keys—such as key list A in the first instance. This uses yellow 111 and blue 112 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 111 and blue 112 keys, but also green 113 keys, so green 113 keys must be loaded into the relevant HSM (if they do not already exist). The specific key to be used is selected from the key list through a deterministic process, as will be discussed below—this often yields different results after key rotation, but it is not inevitable (e.g., Id=2 or Id=6 will give blue 112 keys before or after rotation). While generation service G does not need key list A after key rotation, verification services V still do—they need access to any list of keys associated with potentially valid credentials. The verification service V must be able to determine exactly which key the generation service G uses to generate the credentials in order to verify the credentials.

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

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

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

[0083] A deterministic process will be associated with a key list to determine which key will be associated with a given transaction. For each key list, the deterministic process does not need to be the same, but it needs to be consistently applied to that key list so that both the generation and verification services will obtain the same results. 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.

[0084] There are many options available for the function, but the simplest is the MOD operation—for example, here, Id = LTCMOD 10 would be suitable for providing a deterministic result that can point to any available Id value. Any verification service V with access to a transaction counter value (or any counter derived from that value) in the transaction data can then determine the logical key identifier used by the generation service G, which generates credentials and accesses the correctly stored key, without any trial-and-error mechanism. Associating a deterministic 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.

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

[0086] Within the transaction data, there should be information indicating the application password generated during the transaction process. This could be a simplified form of the password—for example, in traditional environments (such as magnetic stripe or eCommerce) where no Digital Secure Remote Payment (DSRP) data can be transmitted (using EMV or UCAF fields), this could be provided as a CVC2 field. This is important because the verification service V must be able to access all the data used by the generation service G to generate the password—this will include the following:

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

[0088] Shared information from one of the following:

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

[0090] System parameters for a specific use case.

[0091] The standard approaches for different use cases—traditional transactions, UCAF, and DPD field transactions—will be 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 process and lack access to recent developments. The UCAF use case aims to leverage the recently introduced Universal Cardholder Authentication field to deliver more data as part of the transaction process. The DPD use case covers the introduction of digital payment data, a container capable of delivering all the data needed as part of the transaction process.

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

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

[0094] and Figure 15 The monitoring discussed can be both local and centralized. While both local and centralized monitoring are possible, a hybrid approach can be particularly effective in providing efficient detection of any issues and generating effective responses to offset the risks associated with a fully distributed architecture.

[0095] There are three main categories of monitoring to consider: the integrity of the distributed system; the generation of transaction credentials; and the verification of transaction credentials. Since transaction credentials can be generated or verified anywhere, effective monitoring of the entire distributed system is crucial. Risks to consider include attackers abusing genuine transaction credentials generated by the generation service G on a node, particularly attempting verification in multiple verification services on other nodes—this is problematic because verification services V typically do not monitor the actions taken by verification services V on other nodes of the distributed system in real time.

[0096] 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. Several options exist to ensure an effective monitoring process. One is for a monitoring process M directly fed by the credential generation service G. Another is to provide a shared storage for all verification services V at any given node, since any verification service V can verify transaction credentials. This allows for local associated data management by the monitoring service M to provide an initial layer of defense, particularly against replay detection.

[0097] Then, the local monitoring service can report to other nodes via the central monitoring service (hub and spoke) or directly (peer to peer), thereby reporting to other verification services V as a second layer of defense to prevent cross-node abuse of transaction credentials.

[0098] The verification service itself obviously checks the validity of transaction credentials and can cascade to detect any issues (such as verification failures, excessive retries, and invalid transaction data or key list references)—these can be used to suspend tokens across nodes. Additional controls can also be performed, such as random checks on the verification of key list locks. Another monitoring process is the correlation between different service types—here, generation (G) and verification (V)—to detect if transaction credentials have been lost (due to non-commit, anomalous generation, or other reasons). The use of cryptographic material can be tracked to ensure it is used appropriately and the system is properly configured—for example, the number of cryptographic operations performed using a given stored key can be tracked.

[0099] As mentioned above, a principle of effective monitoring is to provide efficient solutions without placing excessive load on the distributed system. This can be achieved by supporting different levels of information (e.g., local monitoring where appropriate, with only a summary of local monitoring activities further communicated) and by reducing the load through data replication and sharing.

[0100] Monitoring may vary from node to node or from region to region, with specific requirements. Specific monitoring processes can be used at a given node or in a given region to address soil or personally identifiable information (PII) requirements in a given geographic area.

[0101] The challenge lies in effectively identifying how credentials are generated within a transaction in order to enable their subsequent verification—specifically, identifying which node generated the credentials and which key list was used to accomplish it, as well as the status of the local transaction counter. This is challenging because transaction data is highly restricted, and to provide any such information, it is necessary to modify existing electronic transaction protocols (such as ISO 8583) or reuse existing fields.

[0102] For traditional electronic transaction protocols, the field that can be reused in principle is the Master Account (PAN), because some numeric bits within the PAN may be implicit in the context of such transactions and therefore can be reused, as well as the expiration date. Some of this information can be transmitted in a compressed format as well as CVC2. The expiration date can be used as a carrier to directly release six bits, but this is not sufficient—for any extended system, the node identifier typically requires at least four bits, and one bit may not be enough for key list references or transaction counters.

[0103] One approach could be to use a specific set of Bank Information Numbers (BINs) that form the first six digits of the PAN to support the implementation described above—special processing can be applied when one of these BINs is detected. This might involve associating the token with multiple PAN values. The model is as follows: Figure 16As shown in the diagram, an FPAN (Funds Master Account – corresponding to a physical card account) can be mapped to one or more tokens, but a specific token is associated with a specific technology. The top row illustrates the standard tokenization process – an FPAN is associated with a single token. Using the methods described above, for traditional EMV use cases (bottom line), a token can be associated with nine PAN values; however, as described below, for some newer formats, a one-to-one mapping can still be used.

[0104] Therefore, the reuse of transaction fields in the traditional context can be as follows. For PANs, 14 bits can be used to fully identify the token, with 1 bit used for a counter associated with the token of a given number and 1 bit used for the Luhn number (which needs to be reserved for checksum to ensure the use of a valid number). The 6 bits for the expiration date can be reused, with x bits used to identify the node and y bits used to reference the list of related keys for that node. CVC2 provides three bits that can be used for the cryptography.

[0105] For security, it is desirable to change the key list periodically to ensure the system is protected against attacks. It is also important to allow verification of credentials for a period of time after creation—the recommended approach is to allow verification of credentials within a maximum of 24 hours of creation. If this is combined with a key rotation process that operates every 24-36 hours, this means that while the generation process will have only one active key list for a given node, the verification process will only need to consider two key lists (one currently active for credential generation, and the other immediately preceding it). A deterministic process based on transaction counters is used to establish the keys to be used. This type of binary information (i.e., one or the other) can typically be encoded using a single bit of information. Cryptography plays a crucial role in protecting transaction integrity—successful verification confirms that the cryptographic evidence computed using the correct key against a given dataset is authentic, verifying that the data initially used for credential generation is genuine. Any failures in the verification process can stem from the use of incorrect cryptographic material and / or corrupted transaction data.

[0106] Figure 17The diagram illustrates an exemplary key rotation process for this traditional arrangement. First, new keys are provided to the HSM as needed—this could be done by distribution from a central source or by another key generation process, such as local key generation. Then, a new key list is generated—this could involve both existing and new keys. Here, most slots in the key list involve existing keys in new positions in the key list (but keys may also remain in the same positions in the key list—as shown here for positions 2 and 6), but new keys are also used in positions 3, 7, and 8. Again, this could be a central process, one managed by peers in a distributed network, or a local one. The new key list is distributed to any authentication service eligible for authentication, as well as the single generation service that uses it to generate the keys. The new key list is then activated in the authentication service, and then in the generation service, which automatically deactivates the previously active key list in that generation service—at which point the key rotation process is complete. After 24 hours, the previous key list is then deactivated for the authentication service. This approach is suitable for the limited space available in traditional cases—only a single bit needs to be switched to indicate which key list was used.

[0107] A potential problem is that the number of transactions executed for a given token appears to be limited by the space available for transmitting the transaction counter. One solution is to increase the available space for the transaction counter, but this would correspondingly limit the number of tokens available (since this is the only place the additional bits could possibly come from). Another possibility would be to use a "retry" process if verification initially fails to recover the "full counter" value, which is greater than the original available space and is only stored as a modulo value. These two methods can be combined. Different rules can also be introduced for different token ranges.

[0108] Within each node, each generation (G) and verification (V) service has access to the local database. The generation of any transaction credential for a given token is associated with a unique transaction identifier for each transaction. For a given token in a given node, the local transaction counter (LTC) is managed by "G". The same process applies when verifying by "V". This information is transmitted in the PAN field (15 numeric bits, or 14 and 15 numeric bits), where a retry flag is included in the expiration date field, and a "full counter" is generated if the LTC is high, if necessary. However, it is important to limit the number of ciphers that can be generated by G and verified by V for a given token on a given key list on a given node to ensure effective access control—this value, "MaxTransactionCounter", can be stored in the key list and protected by a key list seal lock.

[0109] Figure 18The diagram illustrates the cryptographic process for this traditional scenario. In this case, HMAC is chosen as the cryptographic function because it allows the use of a generic HSM while delivering a valid function. The token is identified using a PAN value. The transaction identifier derives information from the expiration date (EMV field DE14)—specifically, the node identifier and reference, possibly also with a retry flag—and from the PAN field of the retention counter. The key identifier and cryptographic method are provided by a counter (which determines which key to select from the key list) along with information shared in the key list by the key management system. Various fields defining the transaction can be used as financial data for generating the cryptography (such as…). Figure 18 As shown in the diagram, all these fields are used to generate a password, which is then decimalized and used in the CVC2 field with three least significant digits.

[0110] Those skilled in the art will recognize that some variations of these protocols may prioritize certain options or priorities. For example, it may be desirable to find more efficient ways to transmit data, such as local transaction counters that do not require the use of retry procedures—as from... Figure 19 As can be seen, the process shown above allows the transaction counter to use at most two bits of the PAN (and using two bits limits the number of tokens that can be provided), while maintaining a reduced cipher in the three CVC bits. A different approach is to use only two bits of the CVC field in the cipher instead of three, with the other bit used to hold the rightmost bit of the local transaction counter. This can be provided in a more dynamic way by rearranging the three bits in a different order—this can be done by adding a CVC encoding table to the key list, such that when the key list is used, the encoding table—also protected by the seal lock—determines the encoding chosen to provide the CVC2 field. The code can be chosen from any value known to both the G and V services—for example, the Luhn number of the PAN. The new key list can then use a completely different encoding table, making the process significantly dynamic.

[0111] This arrangement is like Figure 20 As shown in the diagram. The PAN digit identifier token also provides a Luhn number, which is used to determine the digit order of the CVC field—in this case, selecting option 3 indicates the least significant digits of the password in the first two positions and the second least significant digit in the second least significant digit position, with the least significant digit of the counter in the third position. This results in both the G and V services being able to export the CVC output.

[0112] If a newer version of the electronic transaction protocol is used, additional fields can be used to transmit more information. For example, where the Universal Cardholder Authentication Field (UCAF) is available, many additional bits can be used, allowing for the avoidance of compromises used in traditional cases. This approach frees up an additional 21 bytes of data to transmit as part of the transaction process. This is sufficient to allow the transmission of the full local transaction counter value, thus avoiding the need for any retry mechanisms. More cryptographic material can be used—an 8-byte cipher instead of 2 or 3 bits. More nodes can be used without node identification becoming an issue due to the limited available space in the transaction data as defined in the electronic transaction protocol requirements. Key lists can also be rotated more frequently than 24 hours, as there is room to use more than one bit for key list identification of the verification service. Additional features can be provided using the available space in the transaction data, such as by supporting merchant-locked technology (effectively binding a transaction to a given merchant using some form of merchant identifier), by including additional components in the cryptographic process (such as by using some random element or seed between the generator and validator), or by taking additional measures to provide full compliance with any regulatory requirements.

[0113] As from Figure 21 As can be seen, the new layout using UCAF content (e.g., format 7) has 21 bytes available. One byte can be split between the version identifier and the codebook to specify conditional data used in password generation. The full byte can be used to maintain a local transaction counter—meaning the generation service G will be able to generate up to 255 passwords per key list for a given token on a given node. This should prevent the need to retry the counter and resolve transaction credentials before activating a new key list. Another byte is sufficient for the node identifier data and key list references, leaving a full 10 bytes for conditional data used in password generation and / or verification—each use case associated with a value in the codebook—allowing for the use of data different from that transmitted in the authorization message (which may include unpredictable numbers used for transactions, merchant data such as merchant type and card acceptor or acquiring institution ID code, amount-related information, etc.). Eight bytes can be used to truncate the password, significantly improving security. Figure 22 Instructions on how the cryptographic process is related to Figure 18 The differences shown—PAN, LTC, node identifiers, and references—can all be easily included, and additional information such as additional transaction fields, codebooks, and other conditional data can be provided in the encrypted data.

[0114] This approach offers a variety of further possibilities. Feeding additional bits to the key list references allows for twice the frequency of key list rotation. While some requirements remain—such as limiting the number of ciphers generated by service G for a given key list for a given token on a given node—other requirements are waived (the existence of full LTC means no retry process is needed). It should be noted that the key list may be limited to specific use cases—traditional, UCAF, or DPD—and this can be used to determine specific limits for the transaction counters of a given use case.

[0115] A new format called DPD (Digital Payment Data) will soon be introduced—this will even offer more options, such as Figure 23 As shown in the diagram. As described above, DPD can transmit UCAF to credentials. In the first option, the generation service can define a unique identifier (such as a UUID) at transaction creation time and add it to the list of data used in the cipher process—this allows transaction credentials to be tracked end-to-end independently of transaction details, providing monitoring and fraud prevention advantages. In the second option, a much larger codebook can be used, along with extended identifiers for nodes, storage of more conditional data, and the use of standard truncated ciphers as used in other transaction processes—along with the UUID used in the first option.

[0116] As those skilled in the art will recognize, the above embodiments are exemplary, and those skilled in the art can develop further embodiments falling within the spirit and scope of this disclosure by working based on the principles and examples set forth above.

Claims

1. A method for a computing node to provide a cryptographic key in response to a service request, the method comprising: Establish a key list, wherein the key list includes key identifiers for multiple keys; Receive service requests related to transactions and identify that a key is required to perform a service in response to the service request; as well as A deterministic process for key selection is used, based on operating the deterministic process on the transaction identifier that identifies the transaction, to allocate a key identifier from the key identifiers, and thus the key associated with the key identifier from the key identifiers is used in performing the service in response to the service request; as well as Upon receiving another service request related to another transaction, the same deterministic process is used to allocate a key identifier from the same key identifiers in the same key list, and thus the key associated with the key identifier in the key identifiers is used to perform the other service in response to the other service request; The transaction identifier identifying the transaction is based on a local transaction counter; and A compute node is one of many nodes in a distributed computing system. Service requests are received from clients within the distributed computing system, and each client is a subset of the clients in the distributed computing system associated with a compute node.

2. The method of claim 1, wherein the service request is related to the generation or verification of credentials.

3. The method of claim 2, wherein the credential is associated with a transaction executed by the client that requested the service.

4. The method of any one of claims 1 to 3, wherein the key list includes unique identifiers.

5. The method of any one of claims 1 to 3, wherein a deterministic process for selecting keys and cryptographic operations is identified in the key list.

6. The method of any one of claims 1 to 3, wherein the key list is cryptographically sealed with a key list sealing lock.

7. The method of claim 2, wherein the key list has an expiration date.

8. The method of claim 7, further comprising replacing the key list with another key list when the validity period expires.

9. The method of claim 8, wherein another key list is provided by a central service located away from the computing node, provided by a peer node, or generated locally.

10. The method of claim 8 or 9, wherein the validity period is related to the generation of the credential, but not to the verification of the generated credential.

11. The method of any one of claims 1 to 3, wherein a cryptographic method for using the key is identified in a key list.

12. The method of claim 11, wherein the cryptographic process delivers cryptographic proofs on the computing node, information from the service request, transaction identifiers, and information from the key list.

13. A computing node adapted to provide a cryptographic key in response to a service request as described in any one of claims 1 to 12.

Images