Security model for distributed computing system

Abstract

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 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 using a deterministic process from data associated with the service request to allocate one of the key identifiers and hence the key associated with said one of the key identifiers to the service request. A suitably configured computing node is also described.

Description

FIELD OF DISCLOSUREThe present disclosure relates to management of credentials and to asecurity model for use in a distributed computing system. The disclosure isparticularly relevant to a distributed system that has a very large number of clientsthat require credentials associated with use of the system.BACKGROUND TO DISCLOSUREThere are multiple technical challenges with requiring a centralizedsystem to provide services to a very large number of clients, particularly when theseare widely geographically distributed. It is logical to consider distributing the systemso that the relevant services can be provided by a set of geographically distributedservers, rather than one central server or data centre.In practice, such decentralisation may use a cloud architecture, whichwill typically use a number of geographically distributed servers - or data centres - todeliver services to clients. The cloud architecture may be considered as comprising anumber of nodes - when using a cloud architecture, a node may be an aggregation of anumber of computers, and may cover more than one data centre with "real-time"connectivity and data sharing within a given node.Decentralisation may itself be problematic, particularly if it isnecessary for services to be provided in such a way that provision of the service hasconsequences beyond the server providing the service and the client receiving it. If,for example, other clients (or other system nodes) need to refer back to the serviceproviding node to check on whether, or how, the service has been provided, or if it isnecessary for a central system to have knowledge of how the service has beenprovided or of performance of the distributed server node, then new bottlenecks mayappear in place of the former bottleneck at the central server, the overall quantity ofmessaging in the system may increase, and network latency can become a seriousissue.This is particular serious when the service relates to security (so it isnecessary to be confident that it has been securely performed across the wholesystem) and when it relates to provisi on of a service over a short time frame. Bothissues apply to transaction systems - it is necessary for transactions to be authorisedover short time periods, and it is necessary to ensure that they have been performedlegitimately - but apply to other technical contexts as well.SUMMARY OF DISCLOSUREIn a first aspect, the disclosure provides a method for a computingnode to provide a cryptographic key in response to a service request, the methodcomprising: establishing a key list, wherein the key list comprises key identifiers for aplurality of keys; receiving a service request and identifying that a key is required inresponse to the service request; and using a deterministic process from data associatedwith the service request to allocate one of the key identifiers and hence the keyassociated with said one of the key identifiers to the service request.This approach provides an exceptionally efficient and scalable methodfor allocating a key to a cryptographic process. The use of a deterministic process inthis way makes it easy to establish which key has been used in a particular case.The computing node may be one of a plurality of nodes of a distributedcomputing system, and the service request may be received from a client within thedistributed computing system. This client may be one of a subset of clients of thedistributed computing system associated with the computing node.The service request may relate to management of credentials - it mayrelate generation or validation of credentials. The credential may relate to atransaction performed by a client providing the service request. The data associatedwith the service request may comprise a transaction identifier, which may be based ona local transaction counter.The key list comprises a unique identifier. The deterministic processmay be identified in the key list. The key list may be cryptographically sealed with akey list seal.The key list may have a period of validity. The key list may bereplaced with another key list when the period of validity expires. This other key listmay be provided by a central service remote from the computing node, or may begenerated locally or provided by a peer node. In the case of credentials, the period ofvalidity may relate to generation of a credential but not to validation of a generatedcredential.A cryptographic method for using the key may be identified in the keylist - one possibility would be HMAC. Information from the key list is used as aninput to the cryptographic process, as a way of binding the output of the process to thekey list. In embodiments, the cryptographic process is delivering a cryptographicproof on the computing node, information from the service request, transactionidentification and information from the key list.In a second aspect, the disclosure provides a computing node adaptedto provide a cryptographic key in response to a service request in accordance with themethod of the first aspect. This computing node may comprise one or more hardwaresecurity modules in which the cryptographic keys are stored.DESCRIPTION OF SPECIFIC EMBODIMENTSSpecific embodiments of the disclosure are now described, by way ofexample, with reference to the accompanying drawings, of which:Figure 1 shows multiple clients interacting with a central server;Figure 2 shows multiple clients interacting with a distributedcomputing architecture providing the same services as the central server of Figure 1;Figure 3 shows schematically a distributed transaction architectureusing a four party model;Figure 4 illustrates elements of a complex distributed system adaptedto implement the transaction architecture of Figure 3;Figure 5 shows schematically an exemplary system for enabling digitaltransactions in the transaction architecture of Figures 3 and 4;Figure 6 illustrates schematically an arrangement for a distributedsystem for digital enablement of transactions;Figure 7 illustrates a computing node of the arrangement of Figure 6 inmore detail;Figure 8 illustrates elements within the computing node of Figure 7;Figure 9 indicates transaction flow in relation to operations performedby the node of Figure 7;Figure 10 indicates use of tokenisation in an embodiment of thearrangement of Figures 7 to 9;Figure 11 indicates an approach to key management used inembodiments of the disclosure;Figure 12 illustrates an exemplary approach to transactionidentification;Figure 13 illustrates an exemplary set of cryptographic mechanisms foruse for digitised transactions in embodiments of the disclosure;Figure 14 illustrates a global model of key management withindividual modes managed as shown in Figure 11;Figure 15 illustrates a global model of monitoring associated with thekey management model of Figures 11 and 14;Figure 16 illustrates an exemplary modified tokenisation process fortransactions using a legacy use case with the nodes of Figures 7 and 8;Figure 17 illustrates a key rotation process for a system using a legacyuse case;Figure 18 illustrates an exemplary set of cryptographic mechanisms foruse for digitised transactions using a legacy use case;Figure 19 illustrates an approach to carry a local transaction counterusing a legacy use case suitable for use with the nodes of Figures 7 and 8;Figure 20 illustrates using the approach of Figure 19 in delivery of alocal transaction counter using the Card Verification Code (CVC) for use with thenodes of Figures 7 and 8;Figure 21 illustrates an approach to carry transaction credentialsinformation as part of a transaction using a UCAF (Universal CardholderAuthentication Field) format suitable for use with the nodes of Figures 7 and 8;Figure 22 illustrates an exemplary set of cryptographic mechanisms foruse for digitised transactions using a UCAF format; andFigure 23 illustrates an approach to carry transaction credentialsinformation using DPD (Digital Payment Data) for use with the nodes of Figures 7and 8.In general terms, the problem addressed by the disclosure is illustratedin Figures 1 and 2. Figure 1 shows a central system performing functions in responseto requests from a very large number of geographically distributed entities. Thisplaces intense demand on the central system in relation to processing capability,storage and mess aging, and will typically lead to significant latency in the systemoverall because of bottlenecks and messaging requirements.Figure 2 shows an alternative arrangement in which the role of thecentral system is disaggregated so that the same functions are performed by adistributed set of nodes, each with the capability to perform some or all of thefunctions provided by the central system. Individual nodes should see a significantlylower demand than the central system, and as entities should be able to interact with amore local node than the central system, there is potential to reduce latency.However, as discussed above in general terms, and below with specific relevance to atransaction processing system, there are significant technical challenges in achievingthis benefit.This issue is particularly relevant to transaction processing systems,and in particular to systems for handling digital transactions. The number of digitaltransactions is increasing extremely rapidly, and it is necessary for them to executereliably and rapidly. Support of these transactions can use transaction processingsystems developed for device based payments using payment cards and use theprotocols of such payment systems, but in practice such transactions have a differentcharacter from device-based transactions. This is discussed below, first by referenceto the general elements of a transaction processing system, and then by a moredetailed discussion of the infrastructure used to support digital transactions.Figure 3 is a block diagram of a typical four-party model or four-partypayment transaction scheme. The diagram illustrates the entities present in the modeland the interactions occurring between entities operating in a card scheme.Normally, card schemes - payment networks linked to payment cards- are based on one of two models: a three-party model or a four-party model (adoptedby the present applicant). For the purposes of this document, the four-party model isdescribed in further detail below.The four-party model may be used as a basis for the transactionnetwork. For each transaction, the model comprises four entity types: cardholder 110,merchant 120, issuer 130 and acquirer 140. In this model, the cardholder 110purchases goods or services from the merchant 120. The issuer 130 is the bank or anyother financial institution that issued the card to the cardholder 110. The acquirer 140provides services for card processing to the merchant 120.The model also comprises a central switch 150 - interactions betweenthe issuer 130 and the acquirer 140 are routed via the switch 150. The switch 150enables a merchant 120 associated with one particular bank acquirer 140 to acceptpayment transactions from a cardholder 110 associated with a different bank issuer130.A typical transaction between the entities in the four-party model canbe divided into two main stages: authorisation and settlement. The cardholder 110initiates a purchase of a good or service from the merchant 120 using their card.Details of the card and the transaction are sent to the issuer 130 via the acquirer 140and the switch 150 to authorise the transaction. The cardholder 110 may haveprovided verification information in the transaction, and in some circumstances maybe required to undergo an additional verification process to verify their identity (suchas 3-D Secure in the case of an online transaction). Once the additional verificationprocess is complete the transaction is authorised.On completion of the transaction between the cardholder 110 and themerchant 120, the transaction details are submitted by the merchant 120 to theacquirer 140 for settlement.The transaction details are then routed to the relevant issuer 130 by theacquirer 140 via the switch 150. Upon receipt of these transaction details, the issuer130 provides the settlement funds to the switch 150, which in turn forwards thesefunds to the merchant 120 via the acquirer 140.Separately, the issuer 130 and the cardholder 110 settle the paymentamount between them. In return, a service fee is paid to the acquirer 140 by themerchant 120 for each transaction, and an interchange fee is paid to the issuer 130 bythe acquirer 140 in return for the settlement of funds.In practical implementations of a four-party system model, the roles ofa specific party may involve multiple elements acting together. This is typically thecase in implementations that have developed beyond a contact-based interactionbetween a customer card and a merchant terminal to digital implementations usingproxy or virtual cards on user computing devices such as a smart phone.Figure 4 shows an architecture according to an embodiment of thedisclosure appropriate for interaction between a cardholder and a merchant. ThisFigure shows a general purpose architecture for reference, but shows in particularelements of an architecture used when a cardholder carries out an online transactionwith a merchant server.For a conventional transaction, a cardholder will use their paymentcard 6 - or a mobile computing device such as smartphone 11 adapted for use as acontactless payment device - to transact with a POS terminal 7 of a merchant 2.However, in embodiments relevant to the present invention, the cardholder will usehis or her computing device - which may be any or all of a cellular telephone handset,a tablet, a laptop, a static personal computer or any other suitable computing device(here cellular telephone handset or smartphone 11 is shown) - and other computingdevices such as a smart watch or other wearable device may also be used) - to acteither as a proxy for a physical payment card 6 or as a virtual payment card operatingonly in a digital domain. The smartphone 11 may achieve this with a mobile paymentapplication and a digital wallet, as described below. The smart phone 11 can use thisto transact with a merchant POS terminal 7 using NFC or another contactlesstechnology, or to make a payment in association with its wallet service as discussedbelow. However, online transactions with a merchant are of particular interest inconnection with embodiments of the disclosure, rather than contact or contactlesstransactions with a merchant POS terminal 7. To make an online transaction, thesmartphone 11 may also be able to interact with a merchant server 12 representing themerchant 2 over any appropriate network connection, such as the public internet - theconnection to the merchant may be provided by an app or application on thecomputing device.The transaction scheme infrastructure (transaction infrastructure) 5here provides not only the computing infrastructure necessary to operate the cardscheme and provide routing of transactions and other messaging to parties such as theacquirer 3 and the issuer 4, but also a wallet service 17 to support a digital wallet onthe cardholder computing device, and an internet gateway 18 to accept internet basedtransactions for processing by the transaction infrastructure. In other embodiments,the wallet service 17 may be provided similarly by a third party with an appropriatetrust relationship with the transaction scheme provider. To support tokenisation, atoken service provider 19 is present (again, this is shown as part of transactioninfrastructure 5 but may be provided by a third party with appropriate trustrelationships), and the tr ansaction scheme infrastructure provides a digital enablementservice 16 to support the performance of tokenised digital transactions, and to interactwith other elements of the system to allow transactions to be performed correctly -this digital enablement service may include other elements, such as token serviceprovision.For a tokenised transaction, the transaction is validated in thetransaction scheme by mapping the cardholder token to their card PAN, checking thestatus of the token (to ensure that it is in date and otherwise valid) and any customerverification approach used. This allows the issuer to authorise the transaction in thenormal manner.Figure 5 shows elements of a transaction infrastructure to supportdigitised payments from a mobile device in more detail. This Figure shows as aspecific example the applicant's Mastercard Cloud Based Payment (MCBP)architecture - this is exemplary rather than specific to the invention, and illustrateshow the architecture is used to support a mobile payment application 215 on a mobiledevice (such as smartphone 11) - here the mobile payment application 215 is shownas contained within a wallet application or digital wallet 41. Such a digital wallet 41may communicate with a wallet server 17 to allow management of the mobilepayment application, and it also can be used to request digitization of a payment card6 to be used by the mobile device 11.The Mastercard Digital Enablement Service (MDES) 42 performs avariety of functions to support mobile payments and digitized transactions. Asindicated above, the MDES 42 is exemplary only - other embodiments may usedigitisation, tokenisation and provisioning services associated with other transactionprocessing infrastructures, for example. The wallet server 17 is not a part of theMDES 42 - and need not be present, for example if the mobile payment application215 is not embedded within a digital wallet 41 - but acts as an interface between themobile device 11 and the MDES 42. The MDES 42 also mediates tokenisedtransactions so that they can be processed through the transaction scheme as forconventional card transactions. The following functional elements shown within theMDES 42: the Account Enablement System (AES) 43, the Credentials ManagementSystem (CMS) 44, the Token Vault 45, and the Transaction Management System(TMS) 46. These will be described briefly below.The Account Enablement System (AES) 43 is used in card digitisationand user establishment. It will interact with the mobile payment application (herethrough the wallet server 17) for card digitisation requests, and will populate theToken Vault 45 on tokenisation and wil interact with the CMS 44 to establish a cardprofile with associated keys for digital use of the card.The Credentials Management System (CMS) 44 supports managementof cardholder credentials, and is a key system within the MDES 42. The core system441 manages synchronisation with the transaction system as a whole throughinteraction with the TMS 46 and manages the channel to the AES 43. The dedicatedsystem 442 provides delivery of necessary elements to the mobile paymentapplication such as the digitized card and credentials and keys in the form needed foruse. This system may also interact with the wallet server 17 for management of themobile payment application.The Token Vault 45 - which is shown here as within the MDES 42,but which may be a separate element under separate control - is the repository fortoken information including the correspondence between a token and the associatedcard. In processing tokenised transactions, the MDES 42 will reference the TokenVault 45, and tokenisation of a card will result in creation of a new entry in the TokenVault 45.Transaction Management System (TMS) 46 is used when processingtokenised transactions. If a transaction is identified by the transaction scheme asbeing tokenised, it is routed to the TMS 46 which detokenises the transaction by usingthe Token Vault 45. The detokenised transaction is then routed to the issuer (hererepresented by Financial Authorisation System 47) for authorisation in theconventional manner. The TMS 46 also interacts with the CMS 44 to ensuresynchronisation in relation to the cardholder account and credentials.Embodiments of the disclosure are directed to enabling aspects of asystem for the performance of a digitized transaction as shown in Figure 5 - and inparticular the management of credentials - to be decentralized. This is done byreplacing a central node with a decentralized set of nodes each capable of credentialmanagement, as is shown in Figures 6 to 8.Figure 6 shows a decentralised system of computing nodes Nx, eachcapable of both generating G and validating V credentials. These credentials can bevalid a cross the whole system (unless restricted to some nodes as result of on-soilregulation or the like), and in this case are associated with transactions for a set ofusers (clients) whose transactions are routed to that node, typically throughgeographic proximity. Nodes provide credential generation G and credentialvalidation V as services to clients, and need to be able to generate the credentialssecurely and validate them securely while they are valid at least. In the architectureshown, credentials are not stored - they are generated on request and validated on thefly. As Figures 6 and 7 show, in addition to credential generation and validation, keymanagement K and monitoring M can be considered as services both locally at a nodeand across the system, and access control AC will typically be required to allowaccess to a service. These aspects will all be described in more detail below.Elements of a suitable computing node are shown in Figure 8. Thenode 80 comprises at least one networking connection 81 to allow communication toclients 90 and other nodes 91 as well as (in this example) a central node 91a.Communication is shown here as being through separate networks to each set of otherparties - through a first network cloud 92 for connection to clients, and a secondnetwork cloud 92a for connection to other nodes within the distributed system. Thisreflects that these networks may be physically different, or may have differentsecurity requirements and protocols.The node 80 contains a plurality of conventional servers 83 (which willcontain their own processors and memories - not shown - along with othercomponents as would normally be found in a server) and a memory 84 containing acentral database. Also comprised within the node 80 are a plurality of hardwaresecurity modules 85 (HSMs), adapted to hold cryptographic material and to performcryptographic functions securely. Here elements within the node 80 are showncommunicating by means of a bus 86. While the node 80 in this case is represented asa single data centre, this is not required - the "bus" may be, for example, comprise adedicated network connection between a group of related data centres that allowsthem to provide a real-time response such that they will appear to other entitiescommunicating with the node to be part of an integrated whole.Existing procedures for credential management in payment systems arecentralized - any request to create or validate credentials results in a query to acentralized syst em. For a payment system implementing EMV standards, credentialsare generated using keys derived according to a hierarchical process. Issuer MasterKeys (IMK) are associated with a specific range of tokens, and keys for use forcredentials are derived hierarchically (Card Master Keys - CMK - from IMK, andthen Session Keys - SK - from CMK). This approach is used for devices, such asphysical cards, but is also used for digital transactions. The number of digitaltransactions is increasing extremely rapidly, as opposed to device based interactionswhere the growth is more consistent with resources.In the digital ecosystem, while there is very rapidly increasing demand,there is also generally a more secure environment, as the interaction is typicallybetween merchant systems (or payment service providers) and the transaction systemover secure pathways between well-identified participants. There are thusinteractions that may require multiple cryptographic operations for security in adevice context that can be streamlined when delivering services in a server contextwhen exposing API to access the services while keeping all the assets secure in aconstrained environment including key management and cryptographic operations.While it may appear desirable to scale a transaction system forperforming digital EMV transactions by using a set of distributed servers to generateand validate credentials, it is found that this approach does not scale. The overalllevel of key generation would not be changed, but the amount of messaging within thesystem would be very greatly increased, as an extremely large number of tokenswould need to be managed, and replicated. Processing would be demanding and alsoextremely expensive, as existing EMV key generation approaches require customisedrather than off-the-shelf Hardware Security Modules (HSMs), and data storage andparticularly network latency would become impossible to manage problems.Embodiments of the disclosure support this distributed approach byreplacing the binding of a token to a specific hierarchically derived key, allowinginstead the first available key from a stack of keys to be allocated to a tokenizedtransaction. This approach, using flexible and dynamic key management, allows for ascalable solution. Monitoring can be carried out in such a way as to ensure that thedistributed architecture is secure without requiring the transmission or replication oflarge quantities of sensitive information. This approach can also be carried out in astandard HSM using fully FIPS compliant processes - for example, DES and 3DESneed not be used. This approach is described in more detail below.At present, the device security model is also used for fully digitaltransactions. This security model involves Issuer Master Keys (IMKs) being stored inthe transaction system HSMs and used to derive Card Master Keys (CMKs) from therelevant IMK and a card PAN (Primary Account Number). These CMKs are thenstored in a device (typically a Secure Element or substitute technology). When usingsoftware-based solutions to generate transaction credentials using a mobile device, aSession Key (SK) is generated using the relevant CMK and an ATC (ApplicationTransaction Counter) for the card / device - this is currently generated by theCredentials Management System (CMS) as shown in Figure 5. At present, all tokens,even for fully digital transactions, are bound to this IMK / CMK / SK derivation. Thisalso applies for transaction credentials generated by server through API exposed bythe transaction system for remote payment transactions.This approach requires a very heavy management load for keys, whichis not appropriate for fully digital transactions, as is discussed below with reference toFigures 9 and 10. Generation of SKs, and hence Application Cryptograms (AC - astandard mechanism in EMV transactions) requires multiple cryptographic operations,not all of which can be carried out by a conventional off the shelf HSM, so bespokeHSMs are required. Massive distribution of keys across the system is required so thatperformance of a transaction can be supported wherever it occurs and ATCmanagement is complex. It would be desirable to use standard HSMs, avoid massivekey replication while having keys directly available for use, and to be able to providea solution that limits the number of HSMs overall (as these typically support only afew thousand keys).Much of this security is to provide assurance of security even if there isthe possibility of compromise at a system endpoint (for example, at the cardholderdevice). Aside from this, security has a limited role, as shown in Figure 9. The mainpurpose of the cryptographic function is to provide a guarantee - this covers bothintegrity of the data and authentication. The transaction related data protected by acryptographic data includes identification of a transaction and the associated token,along with an indication of any cryptographic processes used and any relevantfinancial data (along with any other aspect of the transaction that needs to beguaranteed). This is represented by a transaction credential - this needs to begenerated G and subsequently va lidated V, with these processes being monitored M toensure overall system integrity and supported by a key management system K ofsome kind.In the case of a fully digital transaction, these processes take place in aconstrained environment where endpoint security is not an issue in the same way aswith devices. As can be seen from Figure 10, in this domain the token does not reacheither of the endpoints of the conventional transaction management system - thecardholder or the issuer. Instead, it operates across a merchant system or a paymentservice provider (PSP) and transaction scheme provider. .This approach allows for decentralisation of the credential system froma complex central server into a number of nodes providing services. These nodes willtypically be geographically distributed, but may extend over a number of data centres(for example, by use of a cloud infrastructure to achieve data sharing within a node).These nodes provide services - in relation to credentials, a generation service G and avalidation service V - with defined rules for access control to the services. Themerchant or PSP communicates with the generation service G to obtain credentials,which are then used in a standard authorisation process, with the validating service Vbeing called upon where necessary to validate the credential. These services haveaccess to the computing infrastructure (HSMs, databases) of a node. Monitoring Mand key management K services are also provided - these may be centrally organisedor comprise a mix of central and local functionality. All these services and theirinterrelationship are described in greater detail below.Access control to services can be provided in an essentiallyconventional manner. A general set of controls can be defined for a node, with thepossibility of local modification - for example, to meet local regulatory or otherspecific security requirements. This approach makes it easy to implement countryspecificpolicies, for example, by constraining all traffic for a particular country to aparticular set of nodes. Access control can be performed at more than one level (forexample, for individual services, but also for a node), and there may be specific rulesor checks for specific service types. Access control is potentially very granular, andmay provide specific solutions in a versatile way - for example, it could be used toallow a given merchant to perform a maximum number of transaction credentialgeneration operations during a defined time for a given token.The key management mechanism shown in Figure 11 illustrates how alimited number of keys can be allocated to a node while providing a deterministicprocess in order to pick a key to generate credentials. The same process can be usedby a validation entity to determine the key that was used by the generator so that itcan validate any cryptographic material that is part of the credentials submitted forvalidation.For each node, the generation G and validation V services have accessto a pool of HSMs. The HSMs contain keys that are each uniquely identified by a setof key identifiers (KeyId). KeyId may be a label, a value, an explicitly unique valuesuch as a UUID, or anything else with appropriate properties. These KeyIds arestored in uniquely identified (Identifier) key lists - these key lists provide a list ofrelationships between an identifier (Id) and a stored key (KeyId). The identifiers (Id)are what will be determined by the deterministic process in order to establish whatkey is to be used, as will be described further below.The integrity of each key list is guaranteed using a seal (Seal) - if thekey lists are provisioned from a central location, this may be applied by a trusted partyassociated with that central location. Several other distribution models can besupported using for example a trusted party being a local functionality instead of acentral location. A node will typically have a number of key lists available, but withonly one active for generating credentials (G) at a given time - it will howevergenerally be necessary for the validation service (V) to be able to access any key listthat may be associated with a credential that is still valid. Key rotation in thisapproach is extremely straightforward - it may simply involve replacement of theactive key list with another key list. It is however very straightforward to tell whichKeyId is needed to validate a credential - it will be determined fully by the nodeidentifier and the reference of the key list. That information is part of the credentialand is used as input to the deterministic process to pick a key from a list of keys.Figure 11 illustrates an exemplary arrangement for Node Ni, which hastwo generation services G able to generate credentials associated with transactions.At any given point in time, these services G will be required to use a given key list -say Key List A in the first instance. This uses the yellow 111 and blue 112 keys, sothese keys must be loaded in the HSMs used by the generation services G. After theexpiry of a period of time, the key rotation process may for example mandate the useof Key List B - this uses yellow 111 and blue 112 keys, but also the green 113 key, sothe green 113 key must be loaded in the relevant HSMs if not already present. Thespecific key to be used is selected from the key list by the deterministic process, aswill be discussed below - this will typically give a different result after key rotation,but this is not inevitably the case (for example, Id=2 or Id=6 would give the blue 112key before or after rotation). While the generation services G do not need Key List Aafter key rotation, the validation services V still do - they require access to any keylist that relates to a potentially valid credential. The validation services V must beable to establish exactly which key was used to generate a credential by the generationservices G in order to validate a credential.The transaction related data to be protected cryptographically includesidentification of the token associated with the transaction, but also identification ofthe transaction itself. For this, some kind of transaction identifier is required. At eachnode, the credential generation and validation services have access to a local databasewhich can be used to manage such data. To ensure that transactions are managedeffectively across the system, any generation of transaction credentials for a giventoken should be associated with a unique transaction identifier for each transaction.This may be a UUID or any appropriate identifier structure (such as a concatenationof an n bit node identifier, an e bit epoch time, and a c bit local counter).The size of data to be carried in transaction credentials could howeverbe reduced to a few digits by use of a local transaction counter. This could simply bestored in the local database of a node and the local (rather than a global) valueincremented when a local generation service G generates a new token, a processshown in general terms in Figure 12.An exemplary process for identifying a key to use for a transaction willnow be described with reference to Figure 11. As indicated, at any given time ageneration service G has access to a set of keys in local HSMs, and uses keys inaccordance with its currently active key list. This key list is itself uniquely identified(by Identifier) and contains a list of entries which correspond to relationships betweenan identifier (Id) and a stored key, represented by KeyId. In the case of Key List A,there are ten entries, and each Id is a single integer.There will be a deterministic process associated with a key list todetermine which key will be associated with a given transaction. It need not be thesame deterministic process for every key list, but it needs to be used consistently forthat key list so that both generation and validation services will achieve the sameresult. To provide this association, the deterministic process should operate oninformation identifying the transaction, such as some kind of transaction identifier -in this case, the local transaction counter (LTC) is a particularly effective choice asthis is conveniently available and easy to process.There are many choices available for a function, but the simplestchoice is a MOD operation - for example here, Id = LTC MOD 10 would beappropriate to provide a deterministic result which could point to any of the availablevalues of Id. Any validation service V with access to the transaction counter value intransaction data (or any counter derived from that value) can then determine thelogical key identifier that was used by the generation service G that generated thecredential and access the correct stored key without any trial and error mechanism.Associating the deterministic process function (referred to below askeyList.GetIdFunction) to the attributes of a key list in this way allows a scalablesolution that can accept any number of logical key identifiers for a given key list.The HSM cryptographic function should be appropriate to ensure dataintegrity and authentication through credential generation and validation. Thecryptographic function operates on the chosen transaction data, using the key, andprovides an output which does not expose the key. Various alternative cryptographicfunctions could be used - HMAC is a particularly effective choice, but CMAC, CBCMAC are among possible alternatives. The cryptographic function used should bespecified in the key list (as keyList.CryptoFunction) and is also driven by thecapabilities of the HSMs used for generation and validation. On-soil regulations,cryptographic material export or other security considerations may lead to the choiceof specific cryptographic functions.Within the transaction data, there should be information representativeof the application cryptogram generated during the transaction process. This may be areduced form of the cryptogram - for example, in legacy environments (such asMagnetic Stripe or eCommerce) not able to carry any Digital Secure Remote Payment(DSRP) data (using EMV or UCAF field) this may be provided as the CVC2 field.This is significant as a validation service V must be able to access all the data used bya generation service G to generate a cryptogram - this will include the following:dynamic information carried as part of the transaction flow;shared information from one of the following:replicated processes (such as management of the key lists);system parameters for particular use cases.Standard approaches for difference use cases - legacy transaction,UCAF and DPD field transactions - are discussed further below. Legacy transactionuse cases provide a solution when the Merchant and / or the PSP are only able tomanage PAN, Expiry Date and CVC2 as part of the transaction flow, and do not haveaccess to more recent developments. The UCAF use case aims to leverage the morerecently introduced Universal Cardholder Authentication Field to carry more data aspart of the transaction flow. The DPD use case covers the introduction of DigitalPayment Data, a container able to carry all the data needed as part of the transactionflow.A full set of cryptographic mechanisms is shown in Figure 13. Keymanagement is discussed with reference to Figure 14. There are two aspects to keymanagement in this model: management of the keys themselves, including theirgeneration and delivery to the HSMs associated with the nodes, and management ofthe key lists, including their generation, distribution, activation and deactivation. Thekey lists are sensitive assets while keys are considered as secret assets - the key listsdefine the keys to be used for generation and validation of cryptograms. Keys requireend to end security with secure transport of the keys using wrapping / unwrappingtechniques when loading the keys in HSMs. Their use should not be compromised bythe key lists in case an attacker would like to change the content of a key list in orderto alter the key selection process. The integrity of key lists is guaranteed by the seals- a seal is provided for a key list by the generating party or an associated trustedparty, will involve a suitable cryptographic process (such as HMAC with anappropriate dedicated key or using for example a digital signature generated usingasymmetric algorithms such as RSA, ECC, SM2…), and has the effect that anyrelevant part of the system can have confidence that the key list was generated by anappropriate party and has not been modified. In addition the key list seals can be usedin the generation and validation of cryptograms to secure the credentials.Different control models are possible. There may be centralizedcontrol, with a central service generating keys and key lists, and distributing these tothe different nodes. There however a lso may be localised control if dedicatedprocesses are required at a particular node. This may in particular apply if there arespecific requirements for a particular country - for example, on-soil regulations orrestrictions on export of cryptographic material. This may also apply if there is aproprietary mechanism needed for HMS management - for example, with a particularcloud service provider. This need not be node-limited - it could apply to regionalcontrol with a central service within a region (this may be particularly appropriatewhere there is a specific security model for a particular country to meet local legalrequirements). There may also be a hybrid or composite model, in which some keyand key list provisioning is central, whereas some is local - there may also be adistributed model in which distributed peers together assume the role of a centralservice.Monitoring, which is discussed with relevance to Figure 15, may haveboth local and central aspects. While both local and centralized monitoring arepossible, a hybrid approach may be particularly effective in order both to provideeffective detection of any issue and to produce reaction effective to counter risksassociated with a fully distributed architecture.There are three main categories of monitoring to be considered:integrity of the distributed system; generation of transaction credentials; andvalidation of transaction credentials. As transaction credentials may be generated orvalidated anywhere, it is important to have effective monitoring across the wholedistributed system. Risks to be considered include misuse by an attacker of genuinetransaction credentials generated by a generation service G in a node, in particular byan attempt to validate in multiple validation services in other nodes - this is an issueas a validation service V would typically not have real-time sight of actions taken byvalidation services V in other nodes of the distributed system.While monitoring is important to maintain the integrity of the system,it is also important to limit the amount of messaging that results to ensure that thesystem is scalable and will not be overloaded by the monitoring process. A number ofchoices can be made to ensure an effective monitoring process. One is for themonitoring process M to be fed directly by the credential generation services G.Another is, that as any validation service V can validate transaction credentials, tohave mutualised storage for all validation services V at any given node. This allowsassociated data management of the monitoring service M locally to provide an initiallayer of defence, particularly against replay detection.A local monitoring service may then be able to report via a centralmonitoring service (hub and spoke) or directly (peer to peer) to other nodes and henceto other validation services V as a second layer of defence to counter misuse oftransaction credentials across nodes.Validation services themselves obviously check whether transactioncredentials are valid, and can cascade detection of any issues (such as a validationfailure, excessive retries, and invalid transaction data or key list references) - thesecan be used to suspend a token across nodes. Additional controls, such as makingrandom checks on validation of key list seals, can also be performed. Anothermonitoring process is correlation between different service types - here, generation Gand validation V - to detect whether transaction credentials have been lost (by nonsubmission,abnormal generation, or otherwise). The use of cryptographic materialmay be followed to track that it is being appropriately used and that the system isappropriately configured - for example, the number of cryptographic operations usinga given stored key may be tracked.As indicated above, one principle to be followed in effectivemonitoring is to provide an effective solution without an excessive load on thedistributed system. This can be done by supporting different levels of information(for example, local monitoring where appropriate, with only digests of localmonitoring activity communicated further) and reduction of load with data replicationand sharing.Monitoring may be different from node to node, or from region toregion, where there are specific requirements. Specific monitoring processes may beused at a given node or in a given region to address on-soil or personally identifiableinformation (PII) requirements in a given geography.A challenge involved is in effectively identifying in a transaction howcredentials have been generated in order to enable their subsequent validation - inparticular, identification of which node generated the credential and which key listwas used to do it, and the state of the local transaction counter. This is challenging, astransaction data is highly constrained, and to provide any of this information it will benecessary to change existing electronic transactions protocols (such as ISO 8583) orto repurpose existing fields.For legacy electronic transactions protocols, fields that could inprinciple be repurposed are Primary Account Number (PAN), as some digits withinthe PAN may be implicit in the context of a transaction of this type and can be reusedas a result, Expiry Date, where some information can be carried in a condensedformat, and CVC2. Six bits could be released straightforwardly using the expiry dateas a carrier, but this would not be sufficient - a node identifier would typically need atleast four bits for any extended system, and one bit would probably not be sufficientfor either a key list reference or a transaction counter.One approach that could be used is to use a specific set of BankInformation Numbers (BINs), which form the first six digits in a PAN, to support theimplementation described above - when one of these BINs is detected, specialhandling can be employed. This can involve associating a token with a number ofPAN values. This model is shown in Figure 16. An FPAN (Funding PrimaryAccount Number - corresponding to a physical card account) - may be mapped toone or more tokens, but a specific token is associated with a particular technology.The top line shows a conventional tokenization process - an FPAN is associated withsingle token. Where the approach described above is used, the token may beassociated with nine PAN values for a legacy EMV use case (bottom line), though aswill be described below, for certain new formats a one to one mapping may still beused.Reuse of transaction fields in the legacy case can thus be as follows.For PAN, 14 digits can be used for full identification of the token, with 1 digit for thecounter associated to the token for a given number, and one to the Luhn number(which needs to be retained as a checksum to ensure valid numbers are used). The 6bits of the expiry date can be repurposed with x bits used to identify the node and ybits used to refer to the relevant key list for that node. CVC2 provides three digitswhich can be used for the cryptogram.For security, it is desirable to change key lists on a regular basis toensure system security against attacks. It is also important to be able to allowvalidation of credentials for a period after they have been created - a suggestedapproach is to allow validation of credentials for up to 24 hours after creation. If thisis combi ned with a key rotation process that operates every 24-36 hours, this meansthat while the generation process will only ever have one active key list for a givennode, the validation process will only need to consider two key lists (the one currentlyactive for credential generation and the one active immediately before it). Using theestablished deterministic process based on the transaction counter thus establishes thekey to be used. This type of binary information (i.e. one or the other) can be typicallycoded using one bit of information. The cryptogram plays a key role in protecting theintegrity of the transaction - successful validation of a cryptogram computed over agiven set of data using a correct key confirms that data originally used in credentialgeneration is genuine. Any failure in the validation process can come from the use ofwrong cryptographic material and / or corrupted transaction data.An exemplary key rotation process for this legacy arrangement isshown in Figure 17. First of all, new keys are provided to the HSMs as needed - thismay be by distribution from a central source, or by another key generation process,for example by local key generation. A new key list is then generated - this mayinvolve existing keys and new keys - here, most slots in the key list involve existingkeys in new positions in the key lists (though it may also be possible for a key toremain in the same position in a key list - as shown here for key list positions 2 and6), though a new key has also been used in positions 3, 7 and 8. Again, this may be acentral process, one managed by peers in a distributed network, or one managedlocally. The new key list is distributed to any validation service eligible to validateand to the single generation service that is to use it to generate. The new key list isthen activated in the validation services, and then activated in the generation service,which automatically deactivates the previously active key list in that generationservice - the key rotation process is complete at this point. After 24 hours, theprevious key list is then deactivated for the validation services. This approach workswell with the limited space available for legacy cases - a single bit can just be toggledto indicate which key list is used.One potential issue is that the number of transactions carried out for agiven token appears limited by the space available to carry the transaction counter.One solution is to increase the space available for the transaction counter, but this willcorrespondingly limit the number of tokens available (as this is the only place wherethe additional bit can c ome from). Another possibility would be for a "retry" processto be used if validation has originally failed to recover a "full counter" value wherethis was greater than the original space available and has only been stored as amodulo value. These two approaches can be combined. It may also be possible tointroduce different rules for different token ranges.In each node, each generation (G) and validation (V) service has accessto a local database. Any generation of transaction credentials for a given token isassociated to a unique transaction identifier for each transaction. A local transactioncounter (LTC) is managed by "G" for a given token in a given node. The sameprocess applies at the time of validation by "V". This information is carried in thePAN field (digit 15, or digits 14 and 15) with a retry flag in the expiry date field, witha "full counter" generated if necessary if LTC is at a higher value. It is howeverimportant to set a limit on the number of cryptograms that can be generated by G andvalidated by V for a given token for a given node for a given key list to ensureeffective access control - this value "MaxTransactionCounter" may be stored in thekey list and protected by the key list seal.Cryptographic processes for this legacy case are shown in Figure 18. Inthis case, HMAC is chosen as the cryptographic function as this allow the use ofgeneral purpose HSMs while delivering effective functionality. Identification of thetoken uses the PAN value. Identification of the transaction takes information from theexpiry date (EMV field DE14) - specifically the node identifier and the reference,possibly also with a retry flag - and from the PAN field, which holds the counter.Identification of the key and the cryptographic method is provided from the counter(which establishes which key is chosen from the key list) together with informationshared by the key management system in the key lists. A variety of fields defining thetransaction may be used as financial data to be used to generate the cryptogram (asshown in Figure 18), with all these fields used to generate the cryptogram, which isthen decimalised and the three least significant digits used in the CVC2 field.As the skilled person will appreciate, some variation to these protocolsis possible to prioritise certain choices or priorities. For example, it may beconsidered desirable to find a more effective way to carry data such as the LocalTransaction Counter which did not require the use of a retry process - as can be seenfrom Figure 19, the process shown above allows the use of at most two digits of thePAN for the transaction counter (and the use of two digits limits the number of tokensthat can be provided), with a reduced cryptogram held in the three CVC digits. Adifferent approach would be by using only two digits, rather than three, of the CVCfield from the cryptogram, with the other digit used for holding the rightmost digit ofthe Local Transaction Counter. This could be provided in a more dynamic fashion byrearranging the three digits into a different order - this could be done by adding aCVC coding table to the key list, so that when the key list is used the coding table -also protected by the seal - determines the coding to be selected for providing theCVC2 field. The code may be selected by any value known by both the G and Vservices - for example, the Luhn number of the PAN. A new key list may then use acompletely different coding table, making the process significantly dynamic.This arrangement is shown in Figure 20. The PAN digits identify thetoken and also provide a Luhn number, and the Luhn number is used to determine theordering of digits for the CVC field - in this case, option 3 is chosen, indicating theleast significant digit and next least significant digit of the cryptogram in the first twoplaces, with the least significant digit of the counter in the third place. This results ina CVC output that can be derived by both the G and V services.If more recent versions of electronic transaction protocol are used, thenthere are other fields available which may be used to carry more information. Forexample, where the Universal Cardholder Authentication Field (UCAF) is available, anumber of additional digits are usable, which allow compromises used in the legacycase to be avoided. This approach may liberate a further 21 bytes of data to carry dataas part of the transaction flow. This is sufficient to allow a full local transactioncounter value to be carried, avoiding the need for any retry mechanism. Morecryptographic material can be used - 8 bytes of cryptogram, rather than 2 or 3 digits,A larger number of nodes can be used without node identification becoming aproblematic issue because of limited available space in transaction data as defined inelectronic transaction protocol requirements. It may also be possible to rotate keylists more frequently than 24 hours, as there is the space to use more than one bit forkey list identification for validation services. Additional features can be deliveredleveraging the available space in transaction data, for example by supportingmerchant locking techniques (when the transaction is effectively bound to a givenmerchant using some form of merchant identification), by including additionalcomponents in the cryptographic process such as by using some random element orseed between the generator and the validator, or by taking additional measures toprovide full compliance with any regulatory requirements.As can be seen from Figure 21, using a new layout for the content ofUCAF (e.g. Format 7) there are 21 bytes available. One byte can be split between aversion identifier and a codebook to specify conditional data used in cryptogramgeneration. A full byte can be used to hold the Local Transaction Counter - thismeans that a generation service G will be able to generate up to 255 cryptograms perkey list for a given node for a given token, which should prevent the need for a retrycounter and address the need of transaction credentials before a new key list isactivated. A further byte is sufficient for node identifier data and a key list reference,which leaves a full 10 bytes for conditional data to be used in cryptogram generationand / or validation - with each use case associated with a value in the codebook -allowing use of different data than that carried in the authorisation message (datacarried can include an unpredictable number used for the transaction, merchant datasuch as merchant type and card acceptor or acquiring institution ID codes, amountrelated information…). 8 bytes can be used for a truncated cryptogram, thussignificantly increasing security. Figure 22 indicates how the cryptographic processesdiffer from what is shown in Figure 18 - the PAN, LTC, Node Identifier andReference can all easily be included, and additional information can be provided inthe encrypted data, such as additional transaction fields, the codebook and otherconditional data.This approach offers various further possibilities. The provision of anadditional bit for key list reference allows for twice as frequent key list rotation.While some requirements remain - such as the need to limit the number ofcryptograms generated by a service G for a given token for a given node for a givenkey list - others are waived (the presence of the full LTC means that there is no needfor any retry process). It should be noted that a key list may be restricted to aparticular use case - legacy, UCAF or DPD - and this may be used to determine thespecific limit for the transaction counter for the assigned use case.A new format called DPD (Digital Payment Data) is to be introducedshortly - this would provide even further options, as shown in Figure 23. DPD couldcarry the UCAF to credentials as de scribed above. In the first option, a uniqueidentifier (such as a UUID) could be defined by a generation service at the time oftransaction creation, and added to the list of data used in the cryptographic process -this allows transaction credentials to be tracked end-to-end independently oftransaction details providing monitoring and fraud prevention benefits. In the secondoption, a much larger codebook can be used, along with extended identification ofnodes, storage of more conditional data and use of a standard truncated cryptogram asused in other transaction flow - along with a UUID as for the first option.As the skilled person will appreciate, the embodiments describedabove are exemplary, and further embodiments falling within the spirit and scope ofthe disclosure may be developed by the skilled person working from the principlesand examples set out above.

Claims

1. 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 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 using a deterministic process from data associated with the service request to allocate one of the key identifiers and hence the key associated with said one of the key identifiers to the service request.

2. The method of claim 1, wherein the computing node is one of a plurality of nodes of a distributed computing system.

3. The method of claim 2, wherein the service request is received from a client within the distributed computing system.

4. The method of claim 3, wherein the client is one of a subset of clients of the distributed computing system associated with the computing node.

5. The method of claim 4, wherein the service request relates to the generation or validation of a credential.

6. The method of claim 5, wherein the credential relates to a transaction performed by a client providing the service request.

7. The method of claim 6, wherein the data associated with the service request comprises a transaction identifier.

8. The method of claim 7, wherein the transaction identifier is based on a local transaction counter.

9. The method of any preceding claim, wherein the key list comprises a unique identifier.

10. The method of any preceding claim, wherein the deterministic process for key and cryptographic operation selection is identified in the key list.

11. The method of any preceding claim, wherein the key list is cryptographically sealed with a key list seal.

12. The method of any preceding claim, wherein the key list has a period of validity.

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

14. The method of claim 13, wherein another key list is provided by a central service remote from the computing node, provided by a peer node or generated locally.

15. The method of any of claims 13 to 14 where dependent on claim 5, wherein the period of validity relates to generation of a credential but not to validation of a generated credential.

16. The method of any preceding claim, wherein a cryptographic method for using the key is identified in the key list.

17. The method of claim 16, wherein the cryptographic process is delivering a cryptographic proof on the computing node, information from the service request, transaction identification and information from the key list.

18. A computing node adapted to provide a cryptographic key in response to a service request in accordance with the method of any of claims 1 to 17.