Patent Description:
Wireless technologies such as radio-frequency identification (RFID) and near field communication (NFC) are used in a variety of contexts for short range, and typically rapid, interactions between one electronic device and another over a short-range wireless channel. Such arrangements are very widely used for contactless payment from a user device (such as a payment card that can be used as a proximity card, or another payment device such as an NFC-enabled mobile telephone) to a point of sale (POS) terminal.

Contactless payments are generally performed according to contactless EMV specifications (these standards are maintained by EMVCo, and they may be found at emvco. com) - the current version of these specifications is <NUM>, published on <NUM>th March <NUM>. EMV standards generally implement ISO/IEC <NUM>, but ISO/IEC <NUM> is also relevant for contactless cards).

For security and for the convenience of the parties, it is desirable for contactless payment interactions to be performed quickly, typically within <NUM> at most. This may prove challenging if the payment interaction requires significant processing, as may be the case when a complex calculation is required to produce a cryptographic result necessary to make the interaction secure. As security requirements will typically increase over time as new security challenges appear, the complexity of such calculations will typically increase. This may be too challenging to achieve, or to achieve reliably, on a payment device such as a mobile telephone. Additional services - for example, cloud-based cryptography services - have become available, but engaging with such services will generally introduce latency as there may be both a communication lag and a handshake required to ensure secure communication between the service and any device using the service.

Various art addresses approaches to greater and more complex demands on the user computing device. <CIT> relates to a mechanism that allows a cardholder to associate multiple accounts with a payment device, including accounts associated with a "secondary issuer" that is not the card issuer. This mechanism may include the use of application cryptograms generated remotely from the payment device. <CIT> relates to provision of dynamic elements in payment credentials in the context of e-commerce - again, this approach involves remote assistance for the payment device, here from a payment services computer accessed over the public Internet or other suitable network.

It would be desirable to be able to achieve secure wireless interactions between devices reliably at high speed, even in situations where one of the devices has a processing capability that limits its ability to produce cryptographic results at high speed.

The invention is defined by independent claims <NUM>, <NUM> and <NUM>.

In a first aspect, useful for illustration but outside the scope of the claims, the disclosure provides a method for carrying out a wireless transaction between a first computing device and a second computing device for authorisation through a transaction processing system, the method comprising at the first computing device: establishing a secure network connection with a third computing device; initiating the wireless transaction with the second computing device; providing information for performance of a security protocol for the transaction to the third computing device over the secure connection, wherein performance of the security protocol includes determination of a secure result; receiving a dummy secure result from the third computing device; and completing the wireless transaction with the second computing device using the dummy secure result, such that for authorisation of the wireless transaction the dummy secure result can be used to reconcile the wireless transaction with a true secure result for the wireless transaction prepared by the third computing device and provided to the transaction processing system.

This approach has clear benefits in enabling a secure wireless transaction to be performed rapidly. The use of a dummy secure result allows the direct interaction between the first and second computing devices to take place rapidly, meeting any appropriate time threshold (this may be, for example, <NUM> for a contactless transaction using EMV or a similar protocol). The separate preparation of the secure result for reconciliation at the transaction processing system allows a rapid transaction to be performed without compromising security.

In embodiments, the third computing device is an edge server. In such a case, the first computing device and the third computing device may communicate by cellular telecommunications, and the third computing device may be located at the base station of a telecommunications network.

In embodiments, initiation to completion of the transaction may take less than <NUM> seconds.

In embodiments, the wireless transaction may be a contactless payment transaction, and the first computing device may be a consumer computing device and the second computing device may be a point of sale terminal. In such a case, the secure result may be an application cryptogram for the contactless payment transaction. The first computing device may receive variables computed for a digital signature by the third computing device along with the dummy secure result, and may use the computed variables to digitally sign transaction data including the dummy secure result for provision to the second computing device. This digital signature may be an elliptic curve digital signature.

Establishing a secure network connection with the third computing device may comprise establishing a public key encryption scheme for the first computing device certified by a party trusted by the third computing device.

In a second aspect also outside the scope of the claims, the disclosure may provide a computing device comprising a memory and a suitably programmed processor, wherein the computing device is adapted to carry out the method of the first aspect as a first computing device.

Such a computing device may be a mobile telephone. The computing device may have a wallet application installed thereon, and may be programmed to use host card emulation for wireless interaction with a second computing device.

The computing device may comprises a wallet application adapted to carry out the performance of a contactless payment transaction - in such a case, the first computing device may be a consumer computing device and the second computing device may be a point of sale terminal, with the secure result being an application cryptogram for the contactless payment transaction. The first computing device may also receive variables computed for a digital signature by the third computing device along with the dummy secure result, and use the computed variables to digitally sign transaction data including the dummy secure result for provision to the second computing device - this digital signature may be an elliptic curve digital signature.

In a third aspect, the disclosure provides a method to support performance of a contactless payment transaction between a first computing device and a second computing device for authorisation through a transaction processing system, the method comprising at a third computing device supporting the performance of the first computing device: establishing a secure network connection with the first computing device; receiving information for performance of a security protocol for the transaction from the first computing device over the secure connection, wherein performance of the security protocol includes generation of an application cryptogram requiring multiple cryptographic operations; providing a dummy application cryptogram whose value is a random transaction identifier to the first computing device; and obtaining a true application cryptogram for the transaction, and providing the true application cryptogram to a transaction processing system using the dummy application cryptogram as an identifier for the transaction whereby the transaction processing system can reconcile the true application cryptogram with the wireless transaction comprising the dummy application cryptogram provided for authorisation.

In embodiments, the first computing device and the third computing device communicate by cellular telecommunications, and the third computing device is located at the base station of a telecommunications network. In embodiments, a credential for the application cryptogram may be obtained from a distributed cryptographic service for providing credentials for digital transactions. In addition, variables for a digital signature for the contactless payment transaction may be computed, and the computed variables provided along with the dummy application cryptogram to the first computing device to allow the first computing device to digitally sign transaction data. This digital signature may be an elliptic curve digital signature.

In a fourth aspect, the disclosure provides a computing device comprising a memory and a suitably programmed processor, wherein the computing device is adapted to carry out the method of the third aspect as a third computing device.

Such a third computing device may be located at the base station of a telecommunications network, with the first computing device and the third computing device communicating by cellular telecommunications. The computing device may be adapted to obtain a credential for the secure result from a distributed cryptographic service for providing credentials for digital transactions, with the computing device being adapted to access a node of the cryptographic service at the base station.

In a fifth aspect, the disclosure provides a method of verification of transaction details at a transaction processing system, the method comprising: receiving a contactless payment transaction for verification originating from a point of sale terminal for contactless transactions; establishing that an application cryptogramin the transaction is a dummy application cryptogram and not a true application cryptogram; using the dummy application cryptogram as a transaction identifier to identify a message comprising the true application cryptogram received from an online processing system; and verifying the transaction details for the transaction using the true application cryptogram.

Here, verification of the transaction details may comprise verification of a credential provided in the true application cryptogram by using a distributed cryptographic service.

Specific embodiments of the disclosure are now described, by way of example, with reference to the accompanying drawings, of which:.

In general terms, the problem addressed by the disclosure and the solution employed by embodiments of the disclosure is illustrated in <FIG>. A wireless interaction <NUM> is to be carried out between first device <NUM> and second device <NUM> - this wireless interaction <NUM> is intended to be both rapid and secure. For the interaction to be secure, a security protocol needs to be performed between the first device <NUM> and the second device <NUM>, and for purposes where a high level of security is required, this may require significant computational power at both the first device <NUM> and the second device <NUM>. If the first device <NUM> has limited computational power, this may prevent the interaction taking place both securely and rapidly.

The architecture shown in <FIG> supports a wireless interaction <NUM> which is both rapid and secure. The first device <NUM> is here supported by a third device <NUM> with which the first device <NUM> has some form of networked connection - the third device <NUM> has sufficient computational power to complete security protocol results.

In the architecture shown here, the wireless interaction <NUM> involves the delivery of a secure result to the second device <NUM>, with the secure result being provided over communication channel <NUM> to a verification system <NUM>. Here, there is a further pathway to the verification system <NUM> from the third device <NUM>. The third device <NUM> enables the rapid interaction in two ways. First of all, it provides a dummy secure result <NUM> to the first device <NUM>, with the dummy secure result <NUM> being communicated in the wireless interaction <NUM> to the second device <NUM>. This dummy secure result is not the actual secure result required by the verification system <NUM>, but it has the form of the secure result and so will be accepted as formally correct by the security protocol, allowing the dummy secure result <NUM> to be sent for verification over pathway <NUM> between the second device <NUM> and the verification system <NUM>. Such a dummy secure result <NUM> can be generated very rapidly by the third device <NUM> - it may be that much of the dummy secure result <NUM> can even be precomputed - allowing the wireless interaction <NUM> to be extremely rapid.

The dummy secure result <NUM> of course would not be verified by the verification system <NUM>. It may, however, be used as an interaction identifier which can be used to recognise the true secure result for the interaction. This true secure result <NUM> is generated by the third device <NUM> (this does not need to be within the duration of the wireless interaction <NUM> itself). The third device <NUM> then sends both the true secure result <NUM> (as the interaction secure result) and the dummy secure result <NUM> (as an interaction identifier) to the verification system <NUM> over a suitable channel <NUM>. A reconciliation system <NUM> within the verification system <NUM> recognises the dummy secure result <NUM> as a dummy secure result and looks for a matching interaction identifier. When this is received from the third device <NUM> the true secure result <NUM> is treated by the verification system <NUM> as the secure result for the wireless interaction <NUM> for verification purposes.

While this approach can be applied to a variety of wireless interactions that need to be very rapid - for example, for secure access control or smart ticketing - it is particularly appropriate for contactless payment, where in many contexts interaction duration of <NUM> or less is required, and the level of security required may be significant (particularly for higher value transactions). In this case, the wireless interaction <NUM> may be a short-range wireless "tap and go" interaction, using a technology such as NFC. This approach is particularly appropriate where the second device <NUM> is a POS terminal of some kind but the first device <NUM> is a mobile telephone handset - this may not have sufficient computational power available for high-speed generation of a necessary secure result. However, such a telephone handset may be able to make a secure connection to a third device <NUM> with much greater computational power, such as an edge server accessible as part of a <NUM> communication system. In this case, the edge server may be used to perform the function of generating both the dummy secure result <NUM> and the true secure result <NUM>, communicating the dummy secure result <NUM> back to the first device <NUM> for use in the wireless interaction <NUM>, and also communicating the true secure result <NUM> with the dummy secure result <NUM> as identifier to the verification system <NUM> (with the initial part of the suitable channel <NUM> being a <NUM> connection to the edge server).

Embodiments will be described in more detail in the context of a transaction scheme. A suitable transaction scheme and infrastructure will first be described in more detail. <FIG> is a block diagram of a typical four-party model or four-party payment transaction scheme. The diagram illustrates the entities present in the model and 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 (adopted by the present applicant). For the purposes of this document, the four-party model is described in further detail below.

The four-party model may be used as a basis for the transaction network. For each transaction, the model comprises four entity types: cardholder <NUM>, merchant <NUM>, issuer <NUM> and acquirer <NUM>. In this model, the cardholder <NUM> purchases goods or services from the merchant <NUM>. The issuer <NUM> is the bank or any other financial institution that issued the card to the cardholder <NUM>. The acquirer <NUM> provides services for card processing to the merchant <NUM>.

The model also comprises a central switch <NUM> - interactions between the issuer <NUM> and the acquirer <NUM> are routed via the switch <NUM>. The switch <NUM> enables a merchant <NUM> associated with one particular bank acquirer <NUM> to accept payment transactions from a cardholder <NUM> associated with a different bank issuer <NUM>.

A typical transaction between the entities in the four-party model can be divided into two main stages: authorisation and settlement. The cardholder <NUM> initiates a purchase of a good or service from the merchant <NUM> using their card. Details of the card and the transaction are sent to the issuer <NUM> via the acquirer <NUM> and the switch <NUM> to authorise the transaction. The cardholder <NUM> may have provided verification information in the transaction, and in some circumstances may be required to undergo an additional verification process to verify their identity (such as <NUM>-D Secure in the case of a remote transaction). Once the additional verification process is complete the transaction is authorized.

On completion of the transaction between the cardholder <NUM> and the merchant <NUM>, the transaction details are submitted by the merchant <NUM> to the acquirer <NUM> for settlement.

The transaction details are then routed to the relevant issuer <NUM> by the acquirer <NUM> via the switch <NUM>. Upon receipt of these transaction details, the issuer <NUM> provides the settlement funds to the switch <NUM>, which in turn forwards these funds to the merchant <NUM> via the acquirer <NUM>.

Separately, the issuer <NUM> and the cardholder <NUM> settle the payment amount between them. In return, a service fee is paid to the acquirer <NUM> by the merchant <NUM> for each transaction, and an interchange fee is paid to the issuer <NUM> by the acquirer <NUM> in return for the settlement of funds.

In practical implementations of a four-party system model, the roles of a specific party may involve multiple elements acting together. This is typically the case in implementations that have developed beyond a contact-based interaction between a customer card and a merchant terminal to digital implementations using proxy or virtual cards on user computing devices such as a smart phone.

<FIG> shows an architecture appropriate for interaction between a cardholder and a merchant. This Figure shows a general-purpose architecture for reference, but it shows elements of an architecture used when a cardholder carries out a remote transaction with a merchant server.

For a conventional transaction, a cardholder <NUM> will use their payment card <NUM> - or a mobile computing device such as smartphone <NUM> adapted for use as a contactless payment device - to transact with a POS terminal <NUM> of a merchant <NUM>. However, in embodiments relevant to the present disclosure, the cardholder will use his 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 <NUM> is shown) - and other computing devices such as a smart watch or other wearable device may also be used) - to act either as a proxy for a physical payment card <NUM> or as a virtual payment card operating only in a digital domain. The smartphone <NUM> may achieve this with a mobile payment application and a digital wallet, as described below. The smart phone <NUM> can use this to transact with a merchant POS terminal <NUM> using NFC or another contactless technology, or to make a payment in association with its wallet service as discussed below. To make a remote transaction, the smartphone <NUM> may also be able to interact with a merchant server <NUM> representing the merchant <NUM> over any appropriate network connection, such as the public internet - the connection to the merchant may be provided by an app or application on the computing device.

The transaction scheme infrastructure (transaction infrastructure) <NUM> here provides not only the computing infrastructure necessary to operate the card scheme and provide routing of transactions and other messaging to parties such as the acquirer <NUM> and the issuer <NUM>, but also a wallet service <NUM> to support a digital wallet on the cardholder computing device, and an internet gateway <NUM> to accept internet-based transactions for processing by the transaction infrastructure. This internet gateway <NUM> may be provided by a payment service provider, and in some arrangements the merchant <NUM> may interact with an internet gateway rather than directly with the acquirer. In other embodiments, the wallet service <NUM> may be provided similarly by a third party with an appropriate trust relationship with the transaction scheme provider. To support tokenization, a token service provider <NUM> is present (again, this is shown as part of transaction infrastructure <NUM> but may be provided by a third party with appropriate trust relationships), and the transaction scheme infrastructure provides a digital enablement service <NUM> to support the performance of tokenized digital transactions, and to interact with other elements of the system to allow transactions to be performed correctly - this digital enablement service may include other elements, such as token service provision.

For a tokenized transaction, the transaction is validated in the transaction scheme by mapping the cardholder token to their card PAN, checking the status of the token (to ensure that it is in date and otherwise valid) and any customer verification approach used. This allows the issuer to authorise the transaction in the normal manner.

<FIG> shows elements of a transaction infrastructure to support digitized payments from a mobile device in more detail. This Figure shows as a specific example the applicant's Mastercard Cloud-Based Payment (MCBP) architecture-this illustrates how the architecture is used to support a mobile payment application <NUM> on a mobile device (such as smartphone <NUM>) - here the mobile payment application <NUM> is shown as contained within a wallet application or digital wallet <NUM>. Such a digital wallet <NUM> may communicate with a wallet server <NUM> to allow management of the mobile payment application, and it also can be used to request digitization of a payment card <NUM> to be used by the mobile device <NUM>(whereby the digitized payment card is stored in / associated with the digital wallet <NUM>).

The Mastercard Digital Enablement Service (MDES) <NUM> performs a variety of functions to support mobile payments and digitized transactions. As indicated above, the MDES <NUM> is exemplary only - other embodiments may use digitization, tokenization and provisioning services associated with other transaction processing infrastructures, for example. The wallet server <NUM> is not a part of the MDES <NUM> - and need not be present, for example if the mobile payment application <NUM> is not embedded within a digital wallet <NUM> - but acts as an interface between the mobile device <NUM> and the MDES <NUM>. The MDES <NUM> also mediates tokenized transactions so that they can be processed through the transaction scheme as for conventional card transactions. The following functional elements shown within the MDES <NUM>: the Account Enablement System (AES) <NUM>, the Credentials Management System (CMS) <NUM>, the Token Vault <NUM>, and the Transaction Management System (TMS) <NUM>. These will be described briefly below.

The Account Enablement System (AES) <NUM> is used in card digitisation and user establishment. It will interact with the mobile payment application (here through the wallet server <NUM>) for card digitisation requests and will populate the Token Vault <NUM> on tokenization and will interact with the CMS <NUM> to establish a card profile with associated keys for digital use of the card.

The Credentials Management System (CMS) <NUM> supports management of cardholder credentials and is a key system within the MDES <NUM>. The core system <NUM> manages synchronisation with the transaction system as a whole through interaction with the TMS <NUM> and manages the channel to the AES <NUM>. The dedicated system <NUM> provides delivery of necessary elements to the mobile payment application such as the digitized card and credentials and keys in the form needed for use. This system may also interact with the wallet server <NUM> for management of the mobile payment application.

The Token Vault <NUM> - which is shown here as within the MDES <NUM>, but which may be a separate element under separate control - is the repository for token information including the correspondence between a token and the associated card. In processing tokenized transactions, the MDES <NUM> will reference the Token Vault <NUM>, and tokenization of a card will result in creation of a new entry in the Token Vault <NUM>.

Transaction Management System (TMS) <NUM> is used when processing tokenized transactions. If a transaction is identified by the transaction scheme as being tokenized, it is routed to the TMS <NUM> which detokenizes the transaction by using the Token Vault <NUM>. The detokenized transaction is then routed to the issuer (here represented by Financial Authorisation System <NUM>) for authorisation in the conventional manner. The TMS <NUM> also interacts with the CMS <NUM> to ensure synchronisation in relation to the cardholder account and credentials.

Embodiments of the present disclosure relate particularly to contactless transactions and their digitization, and to implementation in <NUM> networks. Relevant features of <NUM> networks will now be described with reference to <FIG>, and an existing approach to digitization of contactless transactions will then be described with reference to <FIG>.

<FIG> shows a cellular communications network in which user equipment <NUM> (typically such "user equipment" is a mobile telephone handset, but the term is the generic one for the end stage device of such a network) connects to a radio area network <NUM>, and through the radio area network <NUM> to the core network <NUM> of the telecommunications system provider. This approach is generally used for any radio access technology (such as GSM, UMTS and LTE), but <NUM> is distinguished by its support for multi-access edge computing (MEC). This provides a distributed computing environment for application and service hosting close to cellular subscribers for extremely rapid response. This may be achieved by using an MEC application server <NUM>, typically integrated with the radio area network <NUM> for example by deployment at the base station. The MEC application server <NUM> can be used to host applications to provide services to customers - an MEC application server is typically a multitenancy run-time and hosting environment and while the hardware may be considered part of the cellular telecommunications network, third party services may be hosted on this hardware for interaction with user equipment.

<FIG> illustrates cryptographic processes - specifically, the cryptographic payment proof computation - for an exemplary contactless transaction. This consists of the combination of results from two cryptographic primitives: the generation <NUM> of an application cryptogram (AC), and the production <NUM> of a digital signature (DS).

The application cryptogram is generated using an appropriate algorithm, typically a block cipher such asAES or SM4 in CBC mode. This operates on transaction data using a session key that is unique per transaction (the payment application has access to an application transaction counter - ATC - controlled by the payment device on behalf of the issuer) per active device (associated with a token PAN). The transaction data, which is provided by the terminal, includes an unpredictable number (UN). When received in the payment processing system for authorisation via the terminal and the PSP/Acquirer, the TMS (as described in <FIG> above) verifies it to counter transaction counterfeit attempts such as replay attacks - the TMS has the information used to provide the session key and is able to recompute it.

The digital signature is constructed using a digital signature algorithm such as ECDSA or SM2. This operates on the AC and on account information (the token and the expiry date) - this provides proof for the contactless terminal that the digital card is authentic. This is an active protection against other forms of attack (such as edge device attacks, which aim to substitute the AC with a fake value).

More than one type of contactless flow is possible. For example, there may be a "fast flow" and a "slow flow" that apply in different circumstances. For a non-local card, it may be desirable to implement a full transaction flow (implementing this in EMV, the cryptographic proof may be provided in response to a First Generate AC command). In use, this may require the user to "tap and hold" the payment device for a longer period of time - for example, a few seconds - to allow the whole protocol to be carried out when the payment device and the terminal are in proximity to each other.

For a local card where it is desirable for the transaction to be rapid - for example, at a ticket gate to a rail system during rush hour- a "fast flow" may be implemented. In this case the return of the cryptographic proof may take place earlier during the Get Processing Options command. These transactions are designed to take place in a fraction of a second - typically no more than <NUM> between the terminal connecting with the payment device and the provision of the final signed response to the terminal. This may require the computation of the cryptographic proof to take place in <NUM> or less.

<FIG> indicates an appropriate architecture for a payment device comprising a "digital card" hosted on a user computing device such as a mobile telephone handset <NUM>. Some implementations of such digital cards use a physical secure element (SE) - ApplePay is an example of this - but the embodiment described here uses a software solution (such as is used in, for example, devices running an Android operating system). The user device here has a Rich Execution Environment (REE) <NUM> in which applications generally run, and a Host Card Emulator (HCE) within it to provide digital wallet functionality. Host Card Emulation is widely used on Android architectures to support such functionality and to allow NFC based interaction between devices. This allows secure card hosting without reliance on a physical secure element (which is in most architectures impractical, as the only physical secure element is a SIM under the control of the Mobile Network Operator without effective access by other parties). In this case, there is a wallet application <NUM> in the REE (termed here the "Go Shopping" or GoS application in examples) which includes one or more mobile payment applications <NUM> (MPA) to provide payment functionality. Such an application may provide online shopping capability, or a blended online and bricks-and-mortar experience, but this is not considered further here - the present disclosure relates to face-to-face contactless payment at a point-of-sale (POS) terminal <NUM>.

As shown in <FIG>, the Go Shopping application comprises the following elements:.

As described above, an exemplary digital transaction technology using tokenization is the applicant's MCBP, described in <FIG> above. Examples that follow will be described in the context of MCBP, though the technical solutions described are relevant to other digital transaction architectures. The following features of MCBP are relevant to implementation here:.

Interaction between these elements in performing a transaction according to a "fast" flow is shown at a high level in <FIG>, with pre- and in-transaction flows shown in <FIG> and <FIG> respectively. As shown in <FIG>, when communication is established between the user device <NUM> and the terminal <NUM>, a command (using an ISO <NUM> standard) is sent from the terminal <NUM> to the client - the transaction details are provided from the terminal to the device in this way. This command is received by the Go Shopping wallet application <NUM>, which makes a request (which may be under any appropriate protocol - typically this will be through a proprietary API) to the MPA <NUM> to perform the necessary cryptographic functions (AC and DS generation). The MPA <NUM> will previously been provisioned with keys for this purpose through MCBP <NUM>, and it will have stored these in the LDE. The MPA will then retrieve a set of these previously stored keys by making a request to the LDE <NUM>, and it will use these to compute the AC and to provide the dynamic digital signature. These are provided to the Go Shopping wallet <NUM>, and hence to the terminal <NUM> using an ISO <NUM> command response.

Such a flow is shown in detail in <FIG> and <FIG>. <FIG> shows the pre-transaction flow in which secret session keys for AC computation by the MPA are loaded into the LDE from the CMS-D. When the session keys available to the MPA are exhausted <NUM> (possibly instead of complete exhaustion this step could be triggered with one or two keys left) the MPA begins the replenishment process. The MPA communicates with the wallet application which establishes <NUM> a secure channel over an internet connection with the CMS-D - this channel is secure and there is mutual authentication. The wallet application then requests <NUM> a number of keys, providing the current ATC and the tokenPAN for the tokenised card. These keys are then derived <NUM> by the CMS-D and loaded <NUM> to the wallet application over the secure channel. The keys are then loaded <NUM> by the wallet application to the MPA, and stored <NUM> in encrypted form in the LDE. On confirmation that the loading is successful <NUM>, the secure channel is closed <NUM>, ending the replenishment phase.

In the transaction phase as shown in <FIG>, the transaction is started by the consumer opening or otherwise activating the wallet application and bringing the payment device into proximity <NUM> with the terminal to establish communication and begin the contactless transaction. As is normal for an EMV contactless transaction (the terminology used throughout this paragraph is standard EMV terminology), the first step is to establish a PPSE (Proximity Payment System Environment) for the transaction - this is initiated <NUM> by the terminal, with a SELECT PPSE command sent <NUM> to the wallet application and communicated <NUM> to the MPA, which retrieves <NUM> its template (FCI - File Control Information - template) for such a transaction and provides <NUM> this to the wallet application. The wallet application notes <NUM> that there will be no card selection process by the consumer - as this is a rapid contactless transaction that needs to operate according to established defaults - and provides <NUM> a list of payment applications by application identifier (AID) to the terminal, with the "fast flow" application heading the list. The application list is prioritised <NUM> by the terminal, and here it is assumed that fast flow is selected and this is communicated <NUM> to the wallet application, and hence <NUM> to the MPA. The MPA then retrieves <NUM> the FCI template and establishes what information is needed from the terminal and in what form and provides <NUM> this to the wallet application as a Processing Data Objects List (PDOL), which is sent <NUM> to the terminal. The terminal prepares <NUM> this information for a Get Processing Options (GPO) command with the information needed by the MPA to prepare an AC - this will include the transaction data and a random number and potentially other information. The GPO command is sent <NUM> to the wallet application and on <NUM> to the MPA, which identifies the requested algorithm specified and retrieves the necessary key <NUM>, then computes the AC and further produces the dynamic signature <NUM> as indicated above, with the dynamic signature comprising the AC being sent <NUM> to the wallet application. The wallet application compiles <NUM> and sends <NUM> a response to the GPO command to the terminal, which then sends an authorization request <NUM> in the standard manner for an EMV transaction.

The approach set out above uses existing technological arrangements, and has certain drawbacks. One is the reliance on the LDE as the secure element (both for symmetric and private keys, but also for local authenticator linked sensitive data such as a reference PIN or biometric) - there is some risk, particularly if prolonged access to the device is obtained, of a reverse engineering attack. The digital payment system is also constrained: the TMS (Transaction Management System) may be limited in the number of transactions that can be processed as processing requires access to a centralized token vault; the CMS-D may not be effectively scalable, particularly if there are a large number of devices to provision which are also geographically dispersed; and the key derivation approach of EMV can lead to the creation of a very large number of keys which will not all be used effectively.

As noted above, existing "fast" arrangements rely on pre-provisioning of the payment device with secret keys so that contactless operation need not rely on any external connection. In a <NUM> environment, however, the availability of fast local edge servers allows "external" computation with very low latency. Embodiments of the present disclosure exploit this aspect of a <NUM> architecture to realise new models of contactless interaction which can meet timing requirements without needing to make operational compromises of the kind indicated above. This may be paired with a decentralized version of the digitized payment infrastructure of <FIG> such as is described in the applicant's earlier <CIT>, for example. This decentralized scheme, termed NODES, is described in further detail below, but is briefly referenced in the immediately following discussion of transaction flows that can be achieved using a <NUM> computational architecture.

<FIG> shows how the contactless transaction process and architecture of <FIG> may be enhanced in a <NUM> computational and communications architecture. The contactless interaction between the payment device <NUM> and the terminal <NUM> follows the same ISO <NUM> approach as before, mediated by the wallet contactless application <NUM>, but there is now another route which the mobile payment application <NUM> can take to support rapid computation other than simply rely on resources preloaded into the LDE <NUM> - it can use a path (here mediated through the wallet internet application <NUM>) to access an edge service provider <NUM> to provide computing services. This edge service provider may, for example, be implemented in an MEC application server provided as part of the <NUM> infrastructure. Cryptographic services for the edge service provider may be provided by a cryptographic service provider <NUM>. This may, for example, be a node of a NODES system as described further below. This may again be located within the <NUM> infrastructure (and possibly also implemented by a MEC application server, even the same MEC application server as for the computation), but may be a separate computing entity with a secure channel to the edge service provider <NUM>. Where both edge service provider <NUM> and the cryptographic service provider <NUM> are located in the edge, rather than in the cloud, there is the possibility of sufficiently rapid AC calculation to meet "fast flow" requirements while not needing to rely on what is present or pre-loaded in the payment device itself.

The NODES infrastructure has been described in earlier cases - for example, the applicant's earlier <CIT> and <CIT> - as an approach to enabling aspects of a system for the performance of a digitized transaction - and in particular the management of credentials - to be decentralised. This is done by replacing a central node with a decentralised set of nodes each capable of credential management, as is shown in <FIG>.

<FIG> shows a decentralised system of computing nodes Nx, each capable of both generating G and validating V credentials. These credentials can be valid across the whole system (unless restricted to some nodes as result of on-soil regulation or the like), and in this case are associated with transactions for a set of users (clients) whose transactions are routed to that node, typically through geographic proximity. Nodes provide credential generation G and credential validation V as services to clients, and they need to be able to generate the credentials securely and validate them securely while they are valid at least. In the context of the present disclosure, it can be assumed that one of these nodes is located in the edge of a <NUM> system, so that it can provided credential generation and validation services to clients accessing a <NUM> network through that edge. In the architecture shown, credentials are not stored - they are generated on request and validated on the fly. As <FIG> and <FIG> show, in addition to credential generation and validation, key management K and monitoring M can be considered as services both locally at a node and across the system, and access control AC (note that this is not the same abbreviation as for discussion of transaction flows, where AC will refer to Application Cryptogram) will typically be required to allow access to a service. These aspects will all be described in more detail below.

Elements of a suitable computing node are shown in <FIG>. The node <NUM> comprises at least one networking connection <NUM> to allow communication to clients <NUM> and other nodes <NUM> as well as (in this example) a central node 91a. Communication is shown here as being through separate networks to each set of other parties - through a first network cloud <NUM> for connection to clients (in embodiments of the disclosure, this may be simply the <NUM> connection to clients connected to that edge), and a second network cloud 92a for connection to other nodes within the distributed system. This reflects that these networks may be physically different, or that they may have different security requirements and protocols.

The node <NUM> may generally be implemented by one or more conventional servers <NUM> (which will contain their own processors and memories - not shown - along with other components as would normally be found in a server) and a memory <NUM> containing a central database. Also comprised within the node <NUM> are a plurality of hardware security modules <NUM> (HSMs), adapted to hold cryptographic material in the form of keys needed to perform cryptographic functions and to perform cryptographic functions securely. Here elements within the node <NUM> are shown communicating by means of a bus <NUM>. While the node <NUM> in this case is represented as a single data centre, this is not required - the "bus" may be, for example, comprise a dedicated network connection between a group of related data centres that allows them to provide a real-time response such that they will appear to other entities communicating with the node to be part of an integrated whole.

Existing procedures for credential management in payment systems are centralised - any request to create or validate credentials results in a query to a centralised system.

For a payment system implementing EMV standards, credentials are generated using keys derived according to a hierarchical process. Issuer Master Keys (IMK) are associated with a specific range of tokens, and keys for use for credentials are derived hierarchically (Card Master Keys - CMK - from IMK, and then Session Keys - SK - from CMK). This approach is used for devices, such as physical cards, but is also used for digital transactions. The number of digital transactions is increasing extremely rapidly, as opposed to device-based interactions where 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 typically between merchant systems (or payment service providers) and the transaction system over secure pathways between well-identified participants. This also applies to operations taking place within the <NUM> infrastructure. There are thus interactions that may require multiple cryptographic operations for security in a device context that can be streamlined when delivering services in a server context when exposing API to access the services while keeping all the assets secure in a constrained environment including key management and cryptographic operations.

As can be seen, NODES provides a distributed system for generation and validation of credentials - however, care is needed in design to ensure that any benefits in distribution of computation are not offset by vastly increased messaging to ensure system-wide operation (including generation of credentials at one node and validation and another). Existing EMV key generation processes would lead to propagation of large numbers of keys and associated messaging. In NODES, however, the distributed approach is supported by replacing the binding of a token to a specific hierarchically derived key, allowing instead the first available key from a stack of keys to be allocated to a tokenized transaction. This approach, using flexible and dynamic key management, allows for a scalable solution. Monitoring can be carried out in such a way as to ensure that the distributed architecture is secure without requiring the transmission or replication of large quantities of sensitive information. This approach can also be carried out in a standard HSM using fully FIPS compliant processes - for example, DES and 3DES need not be used. This approach is described in more detail below.

As noted above, the current EMV security model for digital transactions uses a security model as illustrated in <FIG>. This security model involves Issuer Master Keys (IMKs) being stored in the transaction system HSMs and used to derive Card Master Keys (CMKs) from the relevant IMK and a card PAN (Primary Account Number). These CMKs are then stored in a device (typically a Secure Element or substitute technology). When using software-based solutions to generate transaction credentials using a mobile device, a Session Key (SK) is generated using the relevant CMK and an ATC (Application Transaction Counter) for the card/device - this is currently generated by the Credentials Management System (CMS) as shown in <FIG>. In such a model, all tokens, even for fully digital transactions, are bound to this IMK/CMK/SK derivation. This also applies for transaction credentials generated by server through API exposed by the transaction system for remote payment transactions.

This approach requires a very heavy management load for keys, which is not appropriate for fully digital transactions, as is discussed below with reference to <FIG> and <FIG>. Generation of SKs, and hence Application Cryptograms, requires multiple cryptographic operations, not all of which can be carried out by a conventional off the shelf HSM, so bespoke HSMs are required. Massive distribution of keys across the system is required so that performance of a transaction can be supported wherever it occurs, and ATC management is complex. It would be desirable to use standard HSMs, avoid massive key replication while having keys directly available for use, and to be able to provide a solution that limits the number of HSMs overall (as these typically support only a few thousand keys).

Much of this security is to provide assurance by appropriate prevention mechanisms even if there is the possibility of compromise at a system endpoint (for example, at the cardholder device). Aside from this, security has a limited role, as shown in <FIG>. The main purpose of the cryptographic function is to provide a guarantee - this covers both integrity of the data and authentication. The transaction related data protected by a cryptographic data includes identification of a transaction and the associated token, along with an indication of any cryptographic processes used and any relevant financial data (along with any other aspect of the transaction that needs to be guaranteed). This is represented by a transaction credential - this needs to be generated G and subsequently validated V, with these processes being monitored M to ensure overall system integrity and supported by a key management system K of some kind. The present disclosure relates to an approach to monitoring which is effective to address the consequences of erroneous or malicious action by appropriate detection, messaging and reaction - as will be described, this largely takes place separately from the actual performance of a transaction.

This approach allows for decentralisation of the credential system from a complex central server into a number of nodes providing services. These nodes will typically 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 a validation service V - with defined rules for access control to the services. The merchant or PSP communicates with the generation service G to obtain credentials, which are then used in a standard authorisation process carried out over the payment network of the payment system, with the validating service V being called upon where necessary to validate the credential. These services have access to the computing infrastructure (HSMs, databases) of a node. Monitoring M and key management K services are also provided - these may be centrally organised or comprise a mix of central and local functionality.

Access control to services can be provided in an essentially conventional manner. A general set of controls can be defined for a node, with the possibility of local modification - for example, to meet local regulatory or other specific security requirements. This approach makes it easy to implement localised policies, for example, by constraining all traffic for a particular country to a particular set of nodes, or by taking other region- or market-specific actions. Access control can be performed at more than one level (for example, for individual services, but also for a node), and there may be specific rules or checks for specific service types. Access control is potentially very granular and may provide specific solutions in a versatile way - for example, it could be used to allow a given merchant to perform a maximum number of transaction credential generation operations during a defined time for a given token.

The key management mechanism shown in <FIG> illustrates how a limited number of keys can be allocated to a node while providing a deterministic process in order to pick a key to generate credentials. The same process can be used by a validation entity to determine the key that was used by the generator so that it can validate any cryptographic material that is part of the credentials submitted for validation.

For each node, the generation G and validation V services have access to a pool of HSMs. The HSMs contain keys that are each uniquely identified by a set of key identifiers (Keyld). Keyld may be a label, a value, an explicitly unique value such as a UUID, or anything else with appropriate properties. These Keyld values are stored in uniquely identified (Identifier) key lists - these key lists provide a list of relationships between an identifier (Id) and a stored key (Keyld). The identifiers (Id) are what will be determined by the deterministic process in order to establish what key is to be used, as will be described further below.

The integrity of each key list Is guaranteed using a seal (Seal) - if the key lists are provisioned from a central location, this may be applied by a trusted party associated with that central location. Several other distribution models can be supported using for example a trusted party being a local functionality instead of a central location. A node will typically have a number of key lists available, but with only one active for generating credentials (G) at a given time - it will however generally be necessary for the validation service (V) to be able to access any key list that may be associated with a credential that is still valid. Key rotation in this approach is extremely straightforward - it may simply involve replacement of the active key list with another key list. It is however very straightforward to tell which Keyld is needed to validate a credential - it will be determined fully by the node identifier and the reference of the key list. That information is part of the credential and is used as input to the deterministic process to pick a key from a list of keys.

<FIG> illustrates an exemplary arrangement for Node Ni, which has two 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 and blue keys, so these keys must be loaded in the HSMs used by the generation services G. After the expiry of a period of time, the key rotation process may for example mandate the use of Key List B - this uses yellow and blue keys, but also the green key, so the green key must be loaded in the relevant HSMs if not already present. The specific key to be used is selected from the key list by a deterministic process- this will typically give a different result after key rotation, but this is not inevitably the case (for example, ld=<NUM> or Id=<NUM> would give the blue key before or after rotation). While the generation services G do not need Key List A after key rotation, the validation services V still do - they require access to any key list that relates to a potentially valid credential. The validation services V must be able to establish exactly which key was used to generate a credential by the generation services G in order to validate a credential.

The transaction related data to be protected cryptographically includes identification of the token associated with the transaction, but also identification of the transaction itself. For this, some kind of transaction identifier is required. At each node, the credential generation and validation services have access to a local database which can be used to manage such data. To ensure that transactions are managed effectively across the system, any generation of transaction credentials for a given token should be associated with a unique transaction identifier for each transaction. This may be a UUID or any appropriate identifier structure (such as a concatenation of 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 however be reduced to a few digits by use of a local transaction counter. This could simply be stored in the local database of a node and the local (rather than a global) value incremented when a local generation service G generates new transaction credentials for a token, a process shown in general terms in <FIG>.

An exemplary process for identifying a key to use for a transaction will now be described with reference to <FIG>. As indicated, at any given time a generation service G has access to a set of keys in local HSMs and uses keys in accordance 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 between an identifier (Id) and a stored key, represented by KeyId. In the case of Key List A, there are ten entries, and each Id is a single integer.

There will be a deterministic process associated with a key list to determine which key will be associated with a given transaction (as illustrated in <FIG>). It need not be the same deterministic process for every key list, but it needs to be used consistently for that key list so that both generation and validation services will achieve the same result. To provide this association, the deterministic process should operate on information identifying the transaction, such as some kind of transaction identifier - in this case, the local transaction counter (LTC) is a particularly effective choice as this is conveniently available and easy to process. Note also that in the context of the token described in embodiments of the disclosure, it is LTC - rather than an ATC, as for a payment application - that is used as the "counter" value carried in the transaction data.

There are many choices available for a function, but the simplest choice is a MOD operation - for example here, Id = LTC MOD <NUM> would be appropriate to provide a deterministic result which could point to any of the available values of Id. Any validation service V with access to the transaction counter value in transaction data (or any counter derived from that value) can then determine the logical key identifier that was used by the generation service G that generated the credential and access the correct stored key without any trial-and-error mechanism. Associating the deterministic process function (referred to below as keyList. GetldFunction, or Getld) to the attributes of a key list in this way allows a scalable solution that can accept any number of logical key identifiers for a given key list.

The HSM cryptographic function should be appropriate to ensure data integrity and authentication through credential generation and validation. The cryptographic function operates on the chosen transaction data, using the key, and provides an output which does not expose the key. Various alternative cryptographic functions could be used - HMAC is a particularly effective choice with several options regarding the hashing function, but CMAC, CBC MAC are among possible alternatives not even talking about solutions using asymmetric cryptography. The cryptographic function used should be specified in the key list (as keyList. CryptoFunction) and is also driven by the capabilities of the HSMs used for generation and validation. On-soil regulations, cryptographic material export or other security considerations may lead to the choice of specific cryptographic functions.

Within the transaction data, there should be information representative of the application cryptogram generated during the transaction process. This may be a reduced form of the cryptogram - for example, in legacy EMV transactions 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 by a generation service G to generate a cryptogram - this will include the following:.

A full set of cryptographic mechanisms is shown in <FIG>. Key management is discussed with reference to <FIG>. There are two aspects to key management in this model: management of the keys themselves, including their generation and delivery to the HSMs associated with the nodes, and management of the key lists, including their generation, distribution, activation and deactivation. The key lists are sensitive assets while keys are considered as secret assets - the key lists define the keys to be used for generation and validation of cryptograms. Keys require end to end security with secure transport of the keys using wrapping/unwrapping techniques when loading the keys in HSMs. Their use should not be compromised by the key lists in case an attacker would like to change the content of a key list in order to 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 trusted party, will involve a suitable cryptographic process (such as HMAC with an appropriate dedicated key or using for example a digital signature generated using asymmetric algorithms such as RSA, ECC, SM2. ), and has the effect that any relevant part of the system can have confidence that the key list was generated by an appropriate party and has not been modified. In addition, the key list seals can be used in the generation and validation of cryptograms to secure the credentials.

Different control models are possible. There may be centralised control, with a central service generating keys and key lists, and distributing these to the different nodes. There however also may be localised control if dedicated processes are required at a particular node. This may in particular apply if there are specific requirements for a particular country - for example, on-soil regulations or restrictions on export of cryptographic material. This may also apply if there is a proprietary mechanism needed for HSM management - for example, with a particular cloud service provider. This need not be node-limited - it could apply to regional control with a central service within a region (this may be particularly appropriate where there is a specific security model for a particular country to meet local legal requirements). There may also be a hybrid or composite model, in which some key and key list provisioning is central, whereas some is local - there may also be a distributed model in which distributed peers together assume the role of a central service.

Monitoring is shown in general terms in <FIG>. Here, monitoring is complementary to security actions taken directly in a service to prevent fraud or misuse (such as the basic purpose of the service - generation of a credential using a cryptogram with subsequent validation). Such monitoring aims to detect security anomalies associated with a transaction - it can then trigger appropriate reaction mechanisms to contain any security risk and identify any attacker. In principle, this may have both local and central aspects. It is found that a hybrid approach is particularly effective in order both to provide effective detection of any issue and to produce reaction effective to counter risks associated with a fully distributed architecture.

There are three types of issue to be addressed by monitoring in such a system: integrity of the distributed system; generation of transaction credentials; and validation of transaction credentials. As transaction credentials may be generated or validated anywhere, it is important to have effective monitoring across the whole distributed system. An exemplary risk is that of misuse by an attacker of genuine transaction credentials generated by a generation service G in a node, in particular by an attempt to validate in multiple validation services in other nodes - this would be an issue if a validation service V did not have effective visibility of actions taken by validation 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 the system is scalable and will not be overloaded by the monitoring process. It is therefore desirable for messaging out of nodes to be limited to that genuinely necessary to address threats and for nodes to store information locally to allow effective use of the results of monitoring.

Using a <NUM> architecture with edge servers able to provide rapidly accessible computation and (using a NODES distributed cryptographic service system) cryptographic services, a different transaction flow is possible which avoids the drawbacks of existing approaches while still meeting "fast flow" requirements. This uses the split path approach of <FIG> and is illustrated in <FIG>.

As for the <FIG> case, there are two paths involved in the transaction - the "conventional" transaction path <NUM> between the user device <NUM> and the terminal <NUM>, ending with an authorization request sent by the terminal <NUM>, and an "additional" path accessed over a <NUM> connection <NUM> from the user device <NUM> to an edge server <NUM> with access to a local node <NUM> of a distributed cryptographic service network. As for the <FIG> case, this involves the creation of a dummy result <NUM> (specifically, a dummy AC) at the edge server <NUM> which is fed back to the user device <NUM> for use in the "conventional" transaction, and hence forwarded by the terminal <NUM> seeking authorization of the transaction. The dummy result <NUM> is not used for authorization of the transaction, but it is recognized by the token management system <NUM> of the transaction processing system <NUM> as a dummy result and instead used as an identifier to recognise the real AC <NUM> produced by the edge server <NUM>. In the case shown here, certain functionality of the edge server <NUM> is provided by particular functional modules - an access point module <NUM> provides the point of communication with the mobile device <NUM> and assembles the response to be made to the mobile payment application <NUM>; interaction with the credential service node <NUM> is provided by a digital contactless transaction server module <NUM>; whereas cryptographic results needed at the edge server are provided by a cryptography as a service module <NUM>. While these are all shown as modules of a separate server here, they may instead be, or be a part of, discrete servers (for example, servers interacting locally at the <NUM> base station). While the local node <NUM> of the distributed cryptographic service network is shown here as a separate computing device, in other embodiments this may form a part of the edge server <NUM>.

The stages of this process are illustrated with respect to <FIG> and also <FIG>. The first stage involves initiation of the transaction and establishment of the two-path process. After a consumer selects <NUM> the wallet application <NUM> at their device, the wallet application <NUM> will initiate <NUM> and establish <NUM> a secure session with the local edge service access point <NUM> - this is in place when the contactless transaction begins <NUM> by the consumer <NUM> bringing the device into proximity with the terminal <NUM>. The transaction continues in the normal way for an EMV contactless transaction - the terminal <NUM> prepares <NUM> to establish a PPSE and issues <NUM> a SELECT PPSE command to the wallet application <NUM> through its contactless interface <NUM>, and the flow then continues in essentially the same manner as in <FIG>. The SELECT PPSE command is communicated <NUM> to the MPA <NUM>, which retrieves <NUM> its template (FCI - File Control Information - template) for such a transaction and provides <NUM> this to the wallet application. The wallet application <NUM> notes <NUM> that there will be no card selection process by the consumer as this is a rapid contactless transaction and provides <NUM> a list of payment applications by application identifier (AID) to the terminal <NUM>, with the "fast flow" application heading the list. The application list is prioritised <NUM> by the terminal <NUM>, and it is again assumed that fast flow is selected, and this is communicated <NUM> to the wallet application <NUM>, and hence <NUM> to the MPA <NUM>. The MPA <NUM> then retrieves <NUM> the FCI template and establishes what information is needed from the terminal <NUM> and in what form and provides <NUM> this to the wallet application <NUM> as a Processing Data Objects List (PDOL), which is sent <NUM> to the terminal <NUM>. The terminal <NUM> then forms <NUM> a Get Processing Options command which includes all necessary transaction and transaction-related data for processing by or for the MPA <NUM>. This contains transaction data including any information necessary to prepare an AC (such as the unpredictable number). This information will also allow the MPA to geolocate the transaction, and there may be particular algorithmic usage requirements associated with geolocation. The wallet application <NUM> advises <NUM> the MPA <NUM>, which provides <NUM> to the wallet application any information needed for the transaction including any encrypted information from the LDE <NUM> - here, this will be the ATC value, identification of the algorithm to be used, the token, and the associated issuer application data (stored as encryptedPanlAD in the LDE). The wallet application provides <NUM> transaction data received from the terminal <NUM> and sends <NUM> this with the processing information received from the MPA <NUM> to the edge server <NUM> via the access point <NUM> through the secure session. The edge server <NUM> then generates <NUM> a random transaction ID (transactionld) for use in both processing paths. This transactionld is a random <NUM>-byte value, which as described before is used as both an identifier and a dummy AC value.

The "additional" path is illustrated in <FIG> - this path uses NODES for credential generation and closely mirrors the NODES process used for online digital transaction described in <CIT>. This process will be relatively rapid, but it is not constrained by the "fast flow" constraints on time of contact between payment device <NUM> and terminal <NUM>, as this path does not return to the payment device <NUM>. Firstly, the edge server at the access point <NUM> requests <NUM> a suitably configured module or server <NUM> - here described as "DXD F2F Service", where DXD describes a tokenisation architecture and F2F indicates that the service relates to face-to-face contactless transactions - to produce the "real" AC using NODES. The DXD F2F service <NUM> interacts with the NODES service via a local node <NUM>, firstly requesting <NUM> decryption of the encryptedPanlAD, which allows PAN information (such as PAN, PSN, expiry date. ) to be established <NUM> and provided <NUM> to the DXD F2F service <NUM>. The DXD F2F service <NUM> may use geolocation to determine MerchantlD for the transaction, and there may be additional transaction information collected at this point (for example, a Strong Cardholder Authenticator flag may be received from the MPA <NUM>). The DXD F2F service <NUM> then provides <NUM> transaction information in the appropriate form for credential generation (here, this is as a UCAF v0. <NUM> template as will be described further below with reference to <FIG>). The NODES node <NUM> generates <NUM> a credential as has been described above for NODES, and this is provided to <NUM> and used at the DXD F2F service <NUM> to create <NUM> an AC for providing to a Payment Service Provider (PSP) <NUM> for the merchant - security is provided by the NODES-generated credential, token information for switching/routing, and transactionID for matching. This cryptogram is provided <NUM> to the PSP <NUM>, which provides <NUM> this information to the DXD Transaction Management System <NUM> for reconciliation.

The "conventional" path - in terms of routing, but not in terms of information provided - is shown in <FIG>. The edge server <NUM> interacts with a local cryptographic service <NUM> in providing the transactionld (as a dummy AC) and parameters required for digital signature. Rather than relying on the limited computational power of the payment device <NUM>, much more powerful edge server computing can be used, without a communication lag, to perform the more complex parts of the digital signature calculation. The Transactionld, when generated, is stored <NUM> as the "dummy" AC, The rest of the cryptographic elements needed to perform the digital signature can now be produced, with the edge server <NUM> using local cryptographic resources (here described as Edge Server CaaS <NUM> - Cryptography as a Service) to produce results with rapid processing and minimal communication latency. The edge server requests <NUM> a (k,k-<NUM>,XR) triple from the CaaS <NUM> - while this may be computed directly, for even greater speed this may simply be taken from a buffer of pre-computed pair values. k is generated at random, and (ANS X9. <NUM> provides details) XR is computed <NUM> on EC(ECDSA,k) as (XR, YR) = kG, where G is the EC generator. XR is further converted to an integer j. The k,k-<NUM>,XR) triple is provided <NUM> to the edge server, which determines <NUM> the message to be signed by the MPA, which includes this dummy AC. The edge server requests <NUM> a hash e (using SHA-<NUM>, for example) to be made <NUM> of this message by SaaS, which returns <NUM> this value. The edge server <NUM> can then compute <NUM> the final pre-computable parameter, r, where <MAT> and provides <NUM> the message to be signed and the pre-computed parameters (k, k-<NUM>, XR, e, r) to the wallet application <NUM>, and hence <NUM> to the MPA <NUM>. The secure channel can close <NUM> at this point. Little time has elapsed at this point as the communication pathway between the payment device <NUM> and the edge server <NUM> has minimal latency and the edge server <NUM> and the CaaS resource <NUM> are computationally powerful. The MPA <NUM> determines <NUM> the algorithm to be used for digital signature (in the example shown here, this will be AES128 as this is the cryptographic suite that has been used earlier in the example) and will retrieve the relevant private key from the LDE <NUM>. This is then used to compute <NUM> the dynamic signature over the message including the "dummy" AC, and this dynamic signature is provided <NUM> to the wallet application <NUM>, which uses it to prepare <NUM> a GPO command response which is sent <NUM> to the terminal - this is the last point at which contact is needed, so defining the end point of the time limit for the "fast flow" process. As for conventional EMV, the terminal <NUM> submits <NUM> an authorisation request to authorise the transaction - the signed message comprises token information and normal transaction data as well as the transactionld (as the AC) which will subsequently be used for reconciliation. The message is here received by the PSP <NUM> for the merchant, which routes <NUM> the message using the token information to the DXD TMS <NUM> for processing. The DXD TMS <NUM> (specifically, the TDS) determines that the "dummy" AC is not a real AC, but a transaction identifier, and it uses the transaction identifier to match <NUM> the information received from the two paths - in practice, the matching may be achieved using a transactionld and Merchantld pair as Merchantld will also be provided over both routes. The TMS <NUM> can establish from the "dummy" AC path the authenticity of the signing key stored by MPA, and as such that the transaction is genuine and not a fake, while retrieving the real cryptogram on the transaction data necessary for authorisation and clearing from the edge server path. The real AC can be validated <NUM>, again using the NODES architecture as described in <CIT>, and the transaction reassembled and provided <NUM> to the issuer for authorisation in the conventional manner, at which point the transaction behaves exactly as a conventional EMV contactless transaction.

For completeness, further discussion of transaction handling for digital transactions using NODES, and the application of this transaction handling model to embodiments of this disclosure, are illustrated in <FIG> and <FIG>, and a discussion of how secure tunnelling between the edge server and the user device may be achieved is illustrated in <FIG>.

<FIG> illustrates the formation of a UCAFv0. <NUM> - UCAF (Universal Cardholder Authentication Field) is a standard for collecting online transaction information - appropriate for use in present embodiments in which a NODES arrangement is used for credential generation and validation and in which the SM suite of cryptographic algorithms is used. Use of UCAF in the context of NODES is discussed in more detail in <CIT> (which uses UCAFv0. <NUM>, but employs similar principles to that shown here) and also in the applicant's subsequent <CIT> (which shows use of UCAFv0.

The top part <NUM> shows generation of the application cryptogram using an SHA-<NUM> keyed hash. Transaction data <NUM>, including the LTC <NUM>, and transaction processing information <NUM> are hashed using a key Kji derived through NODES key selection to produce a <NUM> bit transaction cryptogram. This, along with various of the transaction data (and a checksum SHA-<NUM> hash <NUM>) is provided to an AES128 block cipher <NUM> operating in CBC mode which forms an encrypted part of the UCAFv0. <NUM> (effectively a MAC). An unencrypted header <NUM> is also provided - this provides necessary information for routing of the transaction (such as a node identifier) and information necessary to begin processing of the transaction for validation of the credential, for example.

The full routing of the "additional path" into the payment network is shown in <FIG>. As previously noted, the edge server <NUM> of the access point connects to a NODES node <NUM>, which interacts with the wider NODES network <NUM> (described here as "NODES CLOUD"), which enables the transaction information to be provided for authorisation in the network, here via a PSP <NUM>. This will be routed to the acquirer <NUM> and through the transaction infrastructure <NUM> in the normal way, with transaction information available for routing being such as to direct it to the DXD transaction processing system <NUM>, where, as previously described, reconciliation with the "fast flow" contactless transaction performed with a dummy AC will be carried out. The credential for the actual AC will however be validated using the NODES network <NUM>, and the necessary transaction information to allow authorisation is provided to the issuer <NUM>. Once authorised, authorisation information follows a conventional path for an EMV transaction and is not explicitly shown here.

Secure tunnelling will now be described in more detail with reference to <FIG> shows the establishment of temporary secure tunnelling between the user device (specifically the wallet application, and hence the MPA, and the edge server). There will also be a permanent secure channel between the edge server and the local instance of the NODES network. This may be implemented through any appropriate key establishment mechanisms () and will not be described further here.

The secure tunnelling approach shown in <FIG> has three phases. The first phase <NUM> is an initial set-up phase, which will take place at initial system set-up. The wallet application <NUM> makes a certification request <NUM> to a certification authority server <NUM>, which with its response <NUM> provides the basis for certified public key encryption at the edge server <NUM>.

The second phase <NUM> involves initialisation of the secure tunnel when needed - this will be initiated at the wallet application <NUM> and will typically be started by the user activating the wallet application, which will generally take place seconds before the actual transaction. The first stage is authentication <NUM> of the device (optionally this may also involve authentication of the user) and if this is successful (for example by the edge server <NUM> determining <NUM> that the or each certificate is legitimate), this is followed by session key generation <NUM> with session keys encrypted and sent <NUM> to the wallet application <NUM> in encrypted form using the public key encryption already established. These session keys are then decrypted <NUM> at the wallet application <NUM>. The third phase <NUM> is the secure tunnelling itself. In this phase, the wallet application <NUM> acts as a client and presents data to be transmitted for processing after encryption <NUM> and MAC generation <NUM> using the session keys. The edge server <NUM>, acting as the server in this server/client relationship, verifies the MAC <NUM> and decrypts <NUM> the data to perform <NUM> the outsourced computation, with the result being encrypted <NUM> and a further MAC generated <NUM> before the result is sent back to the wallet application <NUM>, with MAC verification <NUM> and decryption of the result <NUM> at the wallet application <NUM> following. These steps may be repeated <NUM> as necessary until the "additional path" requires no further interaction between the wallet application <NUM> and the edge server <NUM>, at which point the secure tunnel will be closed.

Claim 1:
A method to support performance of a contactless payment transaction between a first computing device (<NUM>) and a second computing device (<NUM>) for authorisation through a transaction processing system (<NUM>), the method comprising at a third computing device (<NUM>) supporting the performance of the first computing device (<NUM>):
establishing a secure network connection with the first computing device (<NUM>);
receiving information for performance of a security protocol for the transaction from the first computing device (<NUM>) over the secure connection, wherein performance of the security protocol includes generation of an application cryptogram requiring multiple cryptographic operations;
providing a dummy application cryptogram (<NUM>) whose value is a random transaction identifier to the first computing device (<NUM>); and
obtaining a true application cryptogram (<NUM>) for the transaction, and providing the true application cryptogram (<NUM>) to the transaction processing system (<NUM>) using the dummy application cryptogram (<NUM>) as an identifier for the transaction whereby the transaction processing system (<NUM>) can reconcile the true application cryptogram (<NUM>) with the transaction comprising the dummy application cryptogram (<NUM>) provided for authorisation.