Data management and encryption in distributed computing systems

Abstract

Methods of providing a secure service at a computing node are described. The secure service is for a requestor external to the computing node. The following steps occur at the computing node. A service request is received from the requestor. The service request includes a request to generate a credential. The credential is then generated and service related information is obtained. The credential and the service related information are encrypted using an encryption process to form an encrypted message portion. A service identifying clear message portion is also created and a message including the clear message portion and the encrypted message portion is sent to the requestor. Methods of verifying the credential using such a message, and methods of confirming the integrity of the service related information held in such a message are also described, as are computing devices adapted to perform one or more of these methods.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of UK Patent Application No. 2013340.1, filed on 26 August 2020, the contents of which are incorporated herein by reference for all purposes. Technical Field

[0003] This disclosure relates to data management and encryption in distributed computing systems, and in particular, to distributed computing systems that perform one or more secure processes. Background Technology

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

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

[0006] Decentralization itself can be problematic, especially when it's necessary to provide services in this way, as the supply of services can exceed the capacity of the servers providing the services and the clients receiving them. For example, if other clients (or other system nodes) need to trace back to the service-providing node to check if or how the service has been provided, or if the central system needs to know how the service has been provided or the expected operation of the distributed server nodes, then new bottlenecks may emerge on the central server, replacing previous bottlenecks. The total amount of messages transmitted in the system may increase, and network latency may become a serious problem.

[0007] This is particularly critical when services are related to security (and therefore require assurance that they have been securely executed throughout the system) and when they relate to the provisioning of services within short time frames. Both of these issues apply to transaction systems—where transactions need to be authorized within a short period and it is necessary to ensure that transactions have been legitimately executed—but also to other technical contexts.

[0008] Services such as transaction authorization may require completion within short timeframes, but may also necessitate the secure and reliable storage of service instance-related data into the future. With an exceptionally large number of service instances, the secure storage of service instance records proves extremely burdensome. The desired approach to this problem is to identify past service instances and use the data associated with those instances to support future service activities, all while maintaining data security without placing excessive demands on system resources. Summary of the Invention

[0009] In a first aspect, this disclosure provides a method for providing a security service at a computing node to a requester outside the computing node, the method comprising, at the computing node: receiving a service request from the requester, wherein the service request includes a request to generate credentials; generating credentials; obtaining service-related information and using an encryption process to encrypt the credentials and service-related information to form an encrypted message portion; creating a service identification plaintext message portion; and sending a message including the plaintext message portion and the encrypted message portion to the requester.

[0010] The encryption process may include block ciphers.

[0011] The credentials themselves can be generated using a cryptographic process. In this case, a sharing mechanism can be used to provide keys for both the first encryption process and the cryptographic process. The key validity period for the key used in the encryption process can then be longer than the key validity period for the key used in the cryptographic process. The cryptographic process can then include a key hashing algorithm. A suitable pair of algorithms can then be selected for both processes: for example, the encryption process and the cryptographic process can each include the SM4 and SM3 algorithms, respectively. More generally, encryption can use any cipher from a wide range of ciphers (such as AES CBC, SM4CBC), and the cryptographic process can use a wide range of key hashing message authentication codes (such as HMAC-SHA256, HMAC-SM3, or any other process suitable for generating message authentication codes or signatures).

[0012] Security services may include providing credentials for transactions to allow authorization upon verification of those credentials. The unencrypted message portion may then include information to identify the transaction—it may also include instructions on how the transaction should be processed. The encrypted message portion may include transaction data as well as credentials. The transaction data may include account data and transaction details, where the transaction details are suitable for verifying the validity of the account data independently of credential verification. The account data may include at least an indication of the primary account number and expiration date. These transaction details may include one or more of a merchant identifier, transaction amount, and strong customer authentication flags.

[0013] In a second aspect, this disclosure provides a method for providing security services at a computing node to a requester outside the computing node, the method comprising, at the computing node: receiving a service request from the requester, wherein the service request includes a request to verify credentials, wherein the service request includes a message containing credentials, wherein the message includes a plaintext message portion containing service identification information and an encrypted portion containing credentials and service-related information; performing a decryption process using the service identification information to decrypt the encrypted portion of the message; and further using the service identification information to verify the credentials.

[0014] The decryption process may include block ciphers. A cryptographic process can be used to generate credentials, and this process may include hash algorithms.

[0015] Security services may include verifying transaction credentials to authorize the transaction. The unencrypted message portion may include information to identify the transaction—it may also include instructions on how to process the transaction. The encrypted message portion may include transaction data as well as credentials.

[0016] In a third aspect, this disclosure provides a method for providing security services at a computing node to a requester outside the computing node, the method comprising, at the computing node: receiving a service request from the requester, wherein the service request includes a request to confirm the integrity of service-related information, wherein the message includes a plaintext message portion containing service identification information and an encrypted portion containing service-related information; performing a decryption process using the service identification information to decrypt the encrypted portion of the message to provide the service-related information; and further using a first portion of the service-related information to confirm the integrity of a second portion of the service-related information, wherein the first portion of the service-related information is provided in the service request.

[0017] The decryption process may include block ciphers. The encrypted portion may also include credentials.

[0018] Security services may include providing transaction-related data to a party authorized to receive such data. The unencrypted message portion may include information to identify the transaction—it may also include instructions on how to process the transaction. The encrypted message portion may include transaction data. This transaction data may include account data and transaction details, where the transaction details are suitable for verifying the validity of the account data. The account data may then include at least an indication of the primary account number and the expiration date. The transaction details may then include one or more of a merchant identifier, transaction amount, and strong customer authentication flags.

[0019] In a fourth aspect, this disclosure provides a computing device including a processor and a memory and adapted to send and receive messages, wherein the processor is programmed to perform the methods of the first, second, or third aspects of this disclosure, or any combination thereof, with the aid of the memory. Attached Figure Description

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

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

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

[0023] Figure 3 It shows things like Figure 2 The operation of the distributed system shown in the diagram includes distributed nodes creating and verifying proofs;

[0024] Figure 4 An embodiment according to this disclosure is shown in Figure 3 The arrangement provides a method for adding an encryption layer;

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

[0026] Figure 6 The diagram illustrates what is suitable for implementation. Figure 5 The elements of a complex distributed system in the transaction system architecture;

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

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

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

[0030] Figure 10 The diagram shows... Figure 9 Elements within a compute node;

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

[0032] Figure 12 Instructions in Figures 9 to 11 The implementation of the arrangement uses tokenization;

[0033] Figure 13 Instructions in Figures 8 to 12 The key management method used in the layout;

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

[0035] Figure 15 The diagram illustrates the use of Figures 8 to 14 A set of exemplary cryptographic mechanisms for digital transactions in the setup;

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

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

[0038] Figure 18 Examples of embodiments according to this disclosure are shown as follows. Figure 9 The management of the second encryption layer in the node shown;

[0039] Figure 19 The use of encryption and decryption is shown in Figure 9 nodes and Figure 18 How do the nodes change?

[0040] Figure 20 The relationship between transaction data and cryptographic materials is illustrated in embodiments of this disclosure;

[0041] Figure 21 The encryption and decryption processes used in embodiments of this disclosure are illustrated;

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

[0043] Figure 23 The diagram illustrates the use of, for example Figure 22 The UCAF format digital transaction is illustrated with a set of exemplary cryptographic mechanisms.

[0044] Figure 24 The diagram illustrates the use of suitable and Figure 18 The UCAF format, used by nodes together, is a method for transmitting transaction credential information as part of a transaction;

[0045] Figure 25 The diagram illustrates the use of Figure 19The execution of the initial transaction in the modification process shown;

[0046] Figure 26 The diagram illustrates the use of Figure 19 The modification process shown accesses the mapping information before verification; and

[0047] Figure 27 The diagram illustrates the use of Figure 19 The modification process shown accesses mapping information for subsequent transactions. Detailed Implementation

[0048] Generally speaking, the context of this disclosure is... Figures 1 to 3 The diagram in the middle is shown. Figure 1 This illustrates a central system responding to requests from a large number of geographically distributed entities. This places heavy demands on the central system in terms of processing power, storage, and messaging, often resulting in significant system load due to bottlenecks and messaging requirements. In addition to network latency issues caused by travel time, other problems arise when requests originate from geographically distant requesters communicating with the centralized system.

[0049] Figure 2 An alternative arrangement is illustrated, in which the role of the central system is replicated, with the same functionality performed by a set of distributed nodes, each capable of performing some or all of the functions provided by the central system. Individual nodes should see significantly lower demand than the central system, and network latency is potentially reduced because entities should be able to interact with more local nodes than the central system. However, as discussed generally above and in the specific context of transaction processing systems below, realizing this benefit presents significant technical challenges—in particular, with direct replication, all the same information needs to be distributed to all nodes replicating the centralized system, often making the overall situation worse rather than better.

[0050] There are specific difficulties when a second user of the system needs to be certain that the action taken by the first user is legitimate. Figure 1 In this case, it's relatively simple—because the service is executed centrally and the central system has all the information, there usually won't be a problem if the user trusts the central system. Figure 2In a scenario where a first user might be interacting with one node and a second user might be interacting with another node, the same level of confidence cannot be achieved unless all necessary information is maintained and properly synchronized across all nodes (which would cause the decomposition points to fail when replicating a centralized system). If the product of the first service performed by the first user is valuable information—such as a payment proof made by the first user that will be used by a second user to complete a transaction—then the risk of system failure or compromise due to, for example, multiple second users using the proof at multiple nodes to complete the relevant transaction needs to be addressed.

[0051] Generally speaking, this situation is as follows: Figure 3 As shown in the diagram. First user 51 requests execution of first service 53—in this case, creating proof of an event such as a payment from a specific account—and second user 52 requests verification of the proof of that event from second service 54, for example, to determine if the payment was validly made. First user 51 has already invoked first service 53 at first node 55. Second user typically cannot choose where to invoke second service 54—this could be a matter of geographical or other administrative factors—specifically, it may be impossible to invoke second service 54 at first node 55 (although this is a possibility). In practice, second service 54 will then be invoked at another node 56a, 56b, 56c with sufficient information to implement the verification process. Typically, this will involve accessing a set of public cryptographic keys and the minimum set of information required to regenerate the proof or otherwise determine its correctness—as discussed below, in embodiments, a limited set of keys may be used. The situation where such proofs, or objects claiming to be such proofs, are presented to one or more second services at one or more nodes needs to be addressed so that such systems can operate reliably and securely.

[0052] This disclosure teaches development based on this method, such as Figure 4 As shown in the diagram, the first user 51 requests the execution of the first service 53 as before, but the output of the first service 53 is now provided to the third service 57 for further processing—in this case, the event proof provided by the first service 53 is encrypted. In the illustrated case, both the first service 53 and the third service 57 are shown as part of a larger node process 60. This node process 60 also provides additional information 61 here, along with the event proof from the first service 53, both of which are encrypted by the third service 53 in a public envelope. The encrypted output of the third service 57 is again provided to the first user 51—as discussed further below, this can be part of a message containing the encrypted output as an encrypted portion and the unencrypted portion also provided by the node process 60. The unencrypted portion can be used to identify the service instance, where the event proof and other sensitive data are kept in the encrypted portion. This can then be shared with the second user 52.

[0053] The second user 52 obtains the proof verification as before, with the change that before calling the second service 54 at another node 56a, 56b, 56c, the fourth service 58 must be called to restore the proof for the second service 54 to verify.

[0054] In an embodiment, verification may have only a short window—e.g., 24 hours. The encryption and decryption timeframes may be much longer because information about the service event may not be needed long after verification, or verification may still be possible. During this period, transaction verification may no longer be needed, but the recovery of additional information 61 may be strongly desired. This can be done by identifying the relevant transaction—e.g., by using the unencrypted portion of the message described earlier—and using that information to obtain decryption. Here, the third user 59 needs to establish this additional information—which can be done separately from the fourth service 58 without invoking the second service 54, and the relevant node process 60 returns the additional information. The fourth service 58 can even be used to establish this additional information before verification occurs (or if verification never occurs).

[0055] All processes can use the same key identification process, but as indicated, encryption and decryption may operate over a much longer time span, thus different key rotation strategies may be employed. Different algorithms may be needed for generation / verification (potentially involving hashes with large or variable data inputs) and for encryption / decryption (potentially involving block ciphers).

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

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

[0058] Typically, 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 applicant). For the purposes of this document, the four-party model is described in more detail below.

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

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

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

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

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

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

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

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

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

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

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

[0070] Figure 7 The elements of the transaction infrastructure supporting digital payments from mobile devices are illustrated in more detail. The figure shows the applicant's Mastercard Cloud Based Payment (MCBP) architecture as a specific example—this is exemplary and not specific to the invention—and illustrates how this architecture can be used to support a mobile payment application 215 on a mobile device (such as smartphone 11)—here, mobile payment application 215 is shown as being contained within a wallet application or digital wallet 41. Such a digital wallet 41 can communicate with a wallet server 17 to allow management of the mobile payment application, and it can also be used to request the digitization of payment card 6 used by mobile device 11.

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

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

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

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

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

[0076] The applicant's earlier European patent application No. 19178579.9 describes the implementation for performing, as Figure 7 The methods for various aspects of the digital transaction system illustrated—particularly the management of credentials—are decentralized, and the contents of this application are incorporated herein by reference to the extent permitted by applicable law. This is accomplished by replacing the central node with a set of decentralized nodes, each capable of credential management, such as... Figures 8 to 10 As shown in the image.

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

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

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

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

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

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

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

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

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

[0086] Much of this security is provided through appropriate preventative mechanisms, even when the system endpoint (e.g., at the cardholder's device) is potentially vulnerable to attack. Beyond this, the role of security is limited, such as... Figure 11 As shown in the diagram. The primary purpose of cryptographic functions is to provide guarantees—covering both authentication and data integrity. Transaction-related data protected by cryptographic data includes the transaction's identifier and associated token, as well as instructions for any cryptographic processes used and any related financial data (and any other aspects of the transaction requiring guarantees). This is represented by transaction credentials—which require the generation of G and subsequent verification of V, processes monitored by M to ensure overall system integrity and supported by some kind of key management system K. This disclosure relates to methods for monitoring that effectively address the consequences of erroneous or malicious actions through appropriate detection, messaging, and responses—as will be described—which occur largely separately from the actual execution of the transaction.

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

[0088] This approach allows the credentialing system to be decentralized from a complex central server to multiple nodes providing services. These nodes will typically be geographically distributed but may extend to multiple data centers (e.g., by using cloud infrastructure to enable data sharing within nodes). These nodes provide services—related to credentials, generation service G, and verification service V—along with defined rules for access control of those services. Merchants or PSPs communicate with generation service G to obtain credentials, which are then used in a standard authorization process performed through the payment system's payment network, invoking verification service V when credentials need to be verified. These services have access to the nodes' computing infrastructure (HSM, database). Monitoring service M and key management service K are also provided—these services can be centrally organized or include a hybrid of central and local functions.

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

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

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

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

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

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

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

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

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

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

[0099] HSM cryptographic functions should be suitable for ensuring data integrity and authentication through credential generation and verification. The cryptographic function operates on selected transaction data using a key and provides an output that does not expose the key. Various alternative cryptographic functions can be used—HMAC is a particularly effective choice with several options regarding hash functions, but CMAC and CBC MAC are possible alternatives that don't even discuss solutions using asymmetric cryptography. The cryptographic function used should be specified in the key list (e.g., keyList.CryptoFunction) and is also driven by the capabilities of the HSM used for generation and verification. Domestic regulations, export of cryptographic materials, or other security considerations may lead to the selection of a particular cryptographic function.

[0100] Within the transaction data, there should be information indicating the application password generated during the transaction process. This could be a simplified form of the password—for example, in a traditional EMV transaction, this could be provided as a CVC2 field. This is important because the verification service V must be able to access all the data used by the generation service G to generate the password—this would include the following:

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

[0102] Shared information from one of the following:

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

[0104] System parameters for a specific use case.

[0105] Different methods can be used for different transaction information formats—traditional transactions, UCAF, and DPD field transactions. The traditional transaction use case provides a solution when merchants and / or PSPs can only manage PAN, expiry date, and CVC2 as part of the transaction process and lack access to recent developments. The UCAF use case aims to leverage the universal cardholder authentication field to transmit more data as part of the transaction process. The DPD use case covers recently introduced digital payment data, which is a container capable of transmitting all the data required as part of the transaction process. As described below, additional capabilities of formats such as UCAF can support the additional capabilities provided by embodiments of this disclosure.

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

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

[0108] Figure 17 Monitoring is illustrated in general terms. Here, monitoring complements security measures taken directly within the service to prevent fraud or abuse (such as the service's fundamental purpose—generating credentials using passwords and performing subsequent verification). This monitoring aims to detect security anomalies associated with transactions—which can then trigger appropriate response mechanisms to contain any security risks and identify any attackers. In principle, this can be both local and centralized. A hybrid approach has been found to be particularly effective, providing both efficient detection of any issues and efficient responses to the risks associated with a fully distributed architecture.

[0109] Monitoring such a system involves addressing three categories of issues: the integrity of the distributed system; the generation of transaction credentials; and the verification of transaction credentials. Since transaction credentials can be generated or verified anywhere, effective monitoring of the entire distributed system is crucial. An exemplary risk is that attackers abuse genuine transaction credentials generated by the generation service G in a node, particularly by attempting verification in multiple verification services on other nodes—a problem if the verification service V lacks effective visibility into the actions taken by the verification service V on other nodes in the distributed system.

[0110] While monitoring is important for maintaining system integrity, it is also important to limit the amount of messaging generated to ensure system scalability and prevent overloading of the monitoring process. Therefore, it is expected that messaging from nodes will be limited to those truly necessary to resolve threats, and that nodes will store information locally to allow for effective use of monitoring results.

[0111] In embodiments of this disclosure, the method is modified by adding an additional encryption layer to allow credentials to be protected for an extended period—the additional transaction-related information can also be included in a public encrypted envelope accompanying the credentials. This extended period may be much longer than the period after the credentials are generated and can be verified. This additional encryption layer allows for the secure and efficient storage of transaction credentials so that they and other transaction-related information can be used in the future, such as establishing links between new and previous transactions (e.g., in processing refunds or subsequent transactions following pre-authorization). When credentials are provided after generation, they may be provided in a message containing both encrypted and unencrypted portions. The encrypted portion may contain the credentials and other sensitive transaction data. The unencrypted portion may contain information that allows the transaction to be identified and enables nodes in the system to decrypt the encrypted envelope. Appropriate data formats for providing such messages will be discussed further below.

[0112] Therefore, in addition to providing credential generation (G) and credential verification (V) to clients as services, two additional services are provided: encryption service (E) and decryption service (D). Other features remain largely the same as before—key management (K) and monitoring (M) can again be considered as services local to the node and across the system, and typically require access control (not shown) to allow access to these services. Encryption and decryption services require additional key management activities, but as discussed below, this strategy will differ due to the different time spans involved.

[0113] As previously described, node 80 can be provided as a single server or as multiple conventional servers (which will contain their own processors and memory—not shown—and other components as typically found in servers). Node 80 can access multiple hardware security modules 85 (HSMs) adapted to hold cryptographic material in the form of keys required to execute cryptographic functions and to securely execute cryptographic functions, as well as access data storage device 84.

[0114] Encryption service E is suitable for encrypting data including credentials after the credentials are generated. For example... Figure 19 As shown, decryption service D is used to decrypt such encrypted data to allow credentials to be verified and to allow the use of transaction information at later times when necessary, typically when further transactions are required. While only credential verification is needed once to execute a transaction, the identification and referencing of transaction data elements may occur multiple times; therefore, the keys used in encryption and decryption need to remain available for a long period. As will be further described below, encryption and decryption are independent of the verification process, and decryption can be performed many times after (or even before) verification. Figure 19 It can also be seen that the credential generation (G) and verification (V) services have one set of keys, and the encryption (E) and decryption (D) services have another set of keys. As will be further described below, these can be rotated using a similar mechanism, but within different time frames.

[0115] The general method of key identification and use employed in generating credentials (in this case, passwords) can also be used for encryption, but with a much slower-changing set of different keys. The key selection method used for generation is generally outlined earlier in this specification and... Figure 20 The following is a summary. Transaction-related data is established, including the Local Transaction Counter (LTC) value established at the node. The LTC is used as input to a function ID, which is used to select a tag. This tag is associated with a key—keyid—in the relevant HSM. The HSM uses this key to generate a cipher for manipulating the related data (in this case, specific transaction data).

[0116] This method can be used not only to select the key used to generate credentials—the transaction key—but also to select the key used to encrypt data—the encryption key. The same steps can be used—the local transaction counter can again be used to calculate the encid function (which can even be the same id function used for credential generation—but can be different in other embodiments), and this is used to select the key tag. Here, the key tag refers to a key from a different key list—the encryption key list, not the transaction key list. The key indicated by the tag in the relevant HSM is used to encrypt the data itself.

[0117] While the same architecture is reused across all levels of encryption, there are differences in the use of the transaction key list and the encryption key list. Transaction key list key references have a finite lifespan (e.g., 24 hours) and are rotated periodically. Therefore, the keys themselves are frequently changed. The transaction key list is identified by a combination of a node identifier and transaction key list references. Encryption key list key references are selected to have a much longer lifespan (potentially months or years). Given this long lifespan, encryption keys may be used extensively, but because pseudo-random elements are included as part of the data encrypted using that key, any associated security risks from repeatedly using the same encryption key for data protection are reduced. The encryption key list is identified by a combination of a node identifier and encryption key list references.

[0118] A cryptographic key list is a long-term asset. It contains key list identifiers and node identifiers, and will have various attributes to indicate its origin (timestamps of creation, activation, and deactivation dates, format version information) and its purpose (identification of the function used for cryptographic operations, an orphanage flag indicating whether multiple nodes can be used for decryption), as well as the key tags themselves and the key list seal for integrity maintenance.

[0119] Different algorithms are commonly used for generation / verification and for encryption / decryption. Generation and verification in the above embodiments involve generating output from large amounts of data (and potentially in different formats)—a key hash function is typically appropriate here—and verification involves recreating the same hash and comparing it to the supplied value. For encryption / decryption, the original input needs to be recovered from the encrypted data through a decryption process; therefore, block ciphers are a logical choice.

[0120] Therefore, the key list sealing lock can be used for further purposes in the embodiments, such as... Figure 21 As shown in the diagram. If a block cipher is used for encryption—in the case shown, a block cipher in CBC mode—then an initialization vector (IV) is required for each encryption operation. A particularly efficient option is to define the IV using a key list seal—in this embodiment, this is a 16-byte value, where 16 bytes of data will also be encrypted. The key list seal is a static value of a given key list (used as a pseudo-random element), and as referenced above. Figure 20 The key is determined as described above. The decryption process is then performed in reverse. A list of relevant encryption keys is identified, revealing the key list seal, and a key is established for encryption using the same method described earlier. Therefore, the decrypted data can be reconstructed.

[0121] While block ciphers are typically used for encryption and decryption here, different algorithm choices are possible. One possibility is to use a widely supported cipher, such as AES; another option is to use the SM4 block cipher, which may be preferred in a particular geographic region to meet specific requirements regarding the choice of cryptographic primitives. In the embodiments described here, either choice can be made—this can be indicated by appropriate references in the information associated with the transaction. For example, reference 3 might be associated with AES, in which case the encryption and decryption process can be identified as follows:

[0122] encryptCryptoXAes128Cbc()

[0123] decryptCryptoXAes128Cbc()

[0124] Reference 13 may be related to the SM4 block cipher, in which case the encryption and decryption process can be identified as follows:

[0125] encryptCryptoXSm4Cbc()

[0126] decryptCryptoXSm4Cbc()

[0127] Similarly, matching selections can be made for credential generation and verification, which is typically performed using a key hash function because the output will be a constrained size, much smaller than the given value. The functions referenced in 3 and 13 could now be SHA-256 key hash and SM3 key hash respectively—for reference 3, the generation and verification process is identified as follows:

[0128] generateCryptoXHmacSha256()

[0129] validateCryptoXHmacSha256()

[0130] For reference 13, the generation and verification process is identified as follows:

[0131] generateCryptoXHmacSm3()

[0132] validateCryptoXHmacSm3()

[0133] As discussed above, although the same method is used to identify and select keys, the key rotation methods differ greatly due to different use cases—generation and verification require relatively rapid key changes (24-hour time spans) but allow for significant key eviction, while encryption and decryption allow for much longer key validity periods and may expect to completely avoid key eviction.

[0134] This can be achieved by using a longer key list reference for the encryption key list (e.g., 4 bits) instead of the transaction key list (identified as 2 bits above) and a much longer validity period (months or years instead of 24 hours) for the encryption key list instead of the transaction key list. Therefore, a transaction key list reference can have a maximum of four values ​​and will cycle very regularly, while a transaction key list reference can have a maximum of sixteen values ​​and may not need to cycle at all.

[0135] As described in the applicant's earlier European patent application, number 19178579.9, the latest version of the electronic transaction protocol can be used to transmit more information than the earlier protocol. Several additional digital digits can be used where the Universal Cardholder Authentication Field (UCAF) is available. Using this method, such as Figure 22 As shown, the complete local transaction counter value can be transmitted, and more cryptographic material can be used—8 bytes of cipher instead of the 2 or 3 bits used in older protocols. More nodes can be used without node identification becoming an issue due to the limited available space in the transaction data as defined in electronic transaction protocol requirements. The key list can also be rotated more frequently than 24 hours because there is space to use more than one bit for key list identification of the verification service. The available space in the transaction data can be utilized to deliver additional features, such as by supporting merchant locking technology (effectively binding transactions to a given merchant using some form of merchant identifier), by including additional components in the cryptographic process (such as using some pseudo-random element or variable content between the generator and validator), or by taking additional measures to provide full compliance with any regulatory requirements.

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

[0137] In embodiments of this disclosure, a new structure of UCAF can be used, thereby employing a new format, UCAF format 8. This is in Figure 24 As shown below. This includes an encrypted portion 241 and an unencrypted portion 242. The encrypted portion 241 contains credentials (passwords) and certain transaction data, which allows certain elements to be kept in encrypted form only. The unencrypted portion 242 allows identification of the transaction and its origin. This is described in more detail below.

[0138] The unencrypted portion 241 contains 4 bytes of information, including the version, node (and node-related information), transaction, and specific merchant information. Version information 2411 is a 4-bit field, allowing for multiple version formats. Node-related information includes a 6-bit node identifier 2412 and key list references associated with the node—as previously mentioned, these include a 2-bit transaction key list reference 2413 and a 4-bit encryption key list reference 2414. The transaction itself is identified by a 1-byte Local Transaction Counter (LTC) 2415. As mentioned above, this information is sufficient to allow the node to perform verification by regenerating credentials / passwords (if permitted). The merchant bound to the token is provided by a merchant ID hash divided between the 1-byte unencrypted portion 2416 and the 1-byte encrypted portion 2421.

[0139] Encryption allows other transaction information to be stored in encrypted form but made available upon future decryption, enabling transactions to be mapped to the PAN (Primary Account) without maintaining a dedicated mapping database—other important information, such as the PAN Serial Number (PSN), can be stored in this way. The encrypted data 242 comprises 16 bytes of data, the first byte of which is the encrypted portion 2421 of the Merchant ID hash as described above. The cipher 2422 constitutes the next 22 bits of the encrypted data. One bit is used as the SCA flag 2423 to indicate whether strong customer authentication is used for the transaction. Another 23 bits are used to approximate the transaction amount 2424—these can be encoded as follows:

[0140] Number of reconstructions = A * 2 B

[0141] A is used for the leftmost 18 bits, and B is used for the rightmost 5 bits. The next 74 bits are related to card information 2425. This includes the PAN (63 bits) and PSN (4 bits), which can be provided in full. 7 bits are used to transmit the expiration date information—therefore, this needs to be a partial expiration date, which can be obtained as follows:

[0142] The standard expiration date is encoded using 4 digits – YYMM

[0143] • Constraints on the number of bits allow it to be encoded as 11 bits (typically in MMYY format).

[0144] Use MM-1 (i.e., January = 00, February = 01, ... December = 11).

[0145] Following "о" is "YY".

[0146] Use values ​​between 0000 and 1199 (00000000000b and 10010101111b).

[0147] This can be shortened to 7 bits by ignoring the first year's digits and reconstructing it.

[0148] Use OMMM-1 as before

[0149] о Use only Y Y In Y

[0150] Use values ​​between 000 and 119 (0000000b and 1110111b).

[0151] • The recipient can use Y Determine Y Y The Y in MM is used to reconstruct the complete expiration date.

[0152] In this way, transaction information can be efficiently provided to include key information in encrypted form. This method is highly advantageous because it supports the binding between tokens and their corresponding PANs without using standard mapping services—which would impose a huge computational and storage burden on users with extremely high transaction volumes. This transaction information can also be used as a way to examine decrypted data without verifying the password, as will be described further below.

[0153] The specific process of generating (and verifying) credentials using the methods described above will now be described in more detail.

[0154] The password generation here involves using a key hash function to produce 22 bits from the transaction data—two hash options are presented: SHA-256 and SM3. An exemplary procedure for each is as follows:

[0155] 3:generateCryptoXHmacSha256()

[0156] The 22-bit password is generated as follows:

[0157] 1. Create a JSON object that conforms to the password (input) pattern.

[0158] 2. Prepare the input data using JSON content converted to hexadecimal format (ASCII), and remove all padding and delimiters.

[0159] 3. Based on ISO / IEC 9797-2 MAC algorithm 2 (HMAC), SHA256 (ISO / IEC 10118-3) is used to truncate the data to 16 bytes (leftmost), and a MAC is generated on the input data.

[0160] 4. Take the leftmost 22 bits of the result and use them as the response.

[0161] 13:generateCrytoXHmacSm3()

[0162] The 22-bit password is generated as follows:

[0163] 1. Create a JSON object that conforms to the password (input) pattern.

[0164] 2. Prepare the input data using JSON content converted to hexadecimal format (ASCII), and remove all padding and delimiters.

[0165] 3. Based on ISO / IEC 9797-2 MAC algorithm 2 (HMAC), SM3 (ISO / IEC 10118-3) is used to truncate the data to 16 bytes (leftmost), and a MAC is generated on the input data.

[0166] 4. Take the leftmost 22 bits of the result and use them as the response.

[0167] The verification process complements the generation process.

[0168] 3:validateCryptoXHmacSha256()

[0169] The 22-bit password is verified as follows:

[0170] 1. Create a JSON object that conforms to the password (input) pattern.

[0171] 2. Prepare the input data using JSON content converted to hexadecimal format (ASCII), and remove all padding and delimiters.

[0172] 3. Based on ISO / IEC 9797-2 MAC algorithm 2 (HMAC), SHA256 (ISO / IEC 10118-3) is used to truncate the data to 16 bytes (leftmost), and a MAC is generated on the input data.

[0173] 4. Take the leftmost 22 bits of the result and use them as the generated value.

[0174] 5. Compare the generated value with the value supplied for verification.

[0175] 6. Set the response to true or false based on the comparison result.

[0176] 13:validateCryptoXHmacSm3()

[0177] The 22-bit password is verified as follows:

[0178] 1. Create a JSON object that conforms to the password (input) pattern.

[0179] 2. Prepare the input data using JSON content converted to hexadecimal format (ASCII), and remove all padding and delimiters.

[0180] 3. Based on ISO / IEC 9797-2 MAC algorithm 2 (HMAC), SM3 (ISO / IEC 10118-3) is used to truncate the data to 16 bytes (leftmost), and a MAC is generated on the input data.

[0181] 4. Take the leftmost 22 bits of the result and use them as the generated value.

[0182] 5. Compare the generated value with the value supplied for verification.

[0183] 6. Set the response to true or false based on the comparison result.

[0184] As mentioned above, the data in the encrypted portion can be used for verification to provide, for example, confidence in the correlation between later and earlier transactions, without requiring password verification. (Reference) Figure 25 The use of credential generation and transaction verification is described, and Figure 26 and Figure 27 This disclosure illustrates how embodiments of the present disclosure can be used to provide assurances about other transaction elements when verification of credentials has not yet occurred or may no longer be possible.

[0185] To execute transactions involving the generation and verification of credentials, the process is as follows: Figure 25 As shown in the diagram. Transactions are executed by the merchant or by a payment service provider (PSP) on behalf of the merchant. Transactions are digital, therefore the architecture shown here is used for execution. Associated with transactions is that customers typically have a primary account (PAN), but digital transactions are usually tokenized, and the account PAN is replaced by a token uniquely referenced (TUR) and its associated proxy PAN value. The token is mapped to an account represented by at least the PAN and PSN.

[0186] Once the transaction details are established, the merchant or PSP will invoke the transaction infrastructure (the system of multiple service-providing nodes is referred to as NODES – this term will be used below) to generate transaction credentials. The token and its mapping information, along with the transaction data, are provided to the node, which in turn provides them to the generation service to generate the credentials. This credential is then encrypted along with other transaction data to form an encrypted portion, and the transaction information containing this encrypted portion is provided along with some unencrypted transaction information in the UCAF 8 data format described above. For example... Figure 25 As shown, the token itself is used to generate the password, and the generated password (which is associated with the token in the password field) and the information used to establish the mapping from the token to account data (such as PAN and PSN) are located in the encrypted section. UCAF 8 format transaction data is returned to the merchant / PSP.

[0187] Merchants or PSPs can store this UCAF 8 format information (including the password (associated with the token) and encrypted mapping information). In doing so, the merchant / PSP does not store the customer's account information in plaintext—this account information is only kept in encrypted form. When a transaction is now submitted online for processing by the merchant / PSP, it needs to be verified by a payment solution provider (such as this applicant). Again, this verification is performed by invoking the NODES service by first establishing a decryption key using the unencrypted information, and then using that decryption key to decrypt the encrypted portion of the UCAF 8 information. This decryption reveals the credential, and it can be seen that sufficient information can be obtained to allow the credential to be verified by using the method described above.

[0188] Although the transaction was completed in this way, from Figure 25 It is clear that the merchant / PSP can still call the decryption service to gain access to encrypted information—this is usually mapping information for tokens used in connection with the relevant transaction.

[0189] During the verification phase, the merchant / PSP can use the result of the verification process as confirmation of the integrity of the mapping information stored with it in the encrypted portion of the UCAF 8 data. This verification process can only occur once and can only be performed while the associated list of transaction keys is still active. As mentioned above, it is desirable to be able to establish the integrity of the mapping information independently of the verification process, for example, for subsequent transactions—and in some cases, it may even be desirable to do so before verification occurs.

[0190] As from Figure 24As can be seen, additional information is available for checking the decrypted data without verifying the password: the merchant ID hash (split between the unencrypted and encrypted portions); the SCA flag; and the approximate transaction amount. The merchant ID, SCA flag, and approximate amount together constitute a portion of the overall transaction data, referred to here as "partial transaction data." If the merchant / PSP itself stores partial transaction data at the time of the transaction, it can include this partial transaction information in the call when it invokes the decryption service to retrieve mapping information from the UCAF 8 data. The decryption service can then calculate the merchant ID hash based on the merchant ID and the approximate amount based on the call and LTC (which can be determined from the unencrypted portion of the UCAF 8 data), decrypt the encrypted data, and check the calculated and supplied information against the merchant ID hash, SCA flag, and approximate amount derived or partially derived from the UCAF 8 encrypted data to return mapping information with integrity confirmation (or an error in case the check fails).

[0191] This process does not depend on verification in any way, so it can occur before or after verification (even long after). Figure 26 The instruction to decrypt before verification is required only if the credentials have been generated and UCAF 8 data has been created, and the merchant / PSP has stored it along with some transaction data.

[0192] Figure 27 This provides more detailed instructions for the "follow-up" transaction process. At this point, the relevant transaction has been verified, so the encrypted portion only protects the mapping information—but the merchant has information about the "old" transaction and the associated "old" UCAF 8 data. However, this can be used to decrypt the encrypted portion of the old UCAF 8 data to reveal the mapping information, and this mapping information can be applied to the "new" transaction if intended as a follow-up to the "old" transaction. Account details, along with any new elements of the transaction data, are used for the new transaction—this generates new UCAF 8 data, in which the mapping data is encrypted again.

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

Claims

1. A method for providing security services at a compute node to a requester outside the compute node, the method comprising at the compute node: Receive a service request from the requester, wherein the service request includes a request to generate credentials for a transaction to allow the transaction to be authorized upon verification of the credentials; Generate credentials using a cryptographic process; Obtain service-related information, including transaction data, and use an encryption process to encrypt credentials and service-related information to form an encrypted message portion; Create a service to identify the plaintext message portion; as well as Send a message to the requester, including both plaintext and encrypted parts.

2. The method of claim 1, wherein the encryption process includes block cipher.

3. The method of claim 1, wherein the sharing mechanism is used to provide keys for the encryption and cryptographic processes.

4. The method of claim 3, wherein the key validity period of the key used for the encryption process is longer than the key validity period of the key used for the cryptographic process.

5. The method of claim 3 or claim 4, wherein the cryptographic process includes a key hashing algorithm.

6. The method of claim 1, wherein the unencrypted message portion includes information for identifying how to process the transaction.

7. The method of claim 1, wherein the transaction data includes account data and transaction details, wherein the transaction details are adapted to check the validity of the account data independently of credential verification.

8. The method of claim 7, wherein the account data includes at least an indication of the primary account number and the expiration date, and wherein the transaction details include one or more of a merchant identifier, a transaction amount, and a strong customer authentication mark.

9. A method for providing security services at a compute node to a requester outside the compute node, the method comprising at the compute node: Receive a service request from a requester, wherein the service request includes a request to verify credentials for a transaction to allow the transaction to be authorized, wherein the credentials are generated using a cryptographic process, wherein the service request includes a message containing the credentials, wherein the message includes a plaintext message portion containing service identification information and an encrypted portion containing the credentials and service-related information, wherein the service-related information includes transaction data; The service identification information is used to perform the decryption process to decrypt the encrypted portion of the message; and The service identification information is then used to verify the credentials, and the verification result is provided for authorization of the transaction.

10. The method of claim 9, wherein the decryption process includes block cipher.

11. The method of claim 9, wherein the cryptographic process includes a key hashing algorithm.

12. The method of claim 9, wherein the unencrypted message portion includes information for identifying how to process the transaction.

13. A method for providing security services at a compute node to a requester outside the compute node, the method comprising at the compute node: Receive a service request from the requesting party, wherein the service request includes a request to confirm the integrity of the transaction, wherein a cryptographic process is used to generate credentials for the transaction, and wherein the service request includes a message containing the credentials. The message includes a plaintext message portion containing service identification information and an encrypted portion containing service-related information. The service identification information includes some transaction data, and the service-related information includes transaction data. The service identification information is used to perform a decryption process to decrypt the encrypted portion of the message in order to provide service-related information, including transaction data. as well as The transaction data is matched with partial transaction data to confirm the integrity of the transaction.

14. The method of claim 13, wherein the decryption process includes block cipher.

15. The method of claim 13 or claim 14, wherein the security service includes providing transaction-related data to a party entitled to receive such data.

16. The method of claim 15, wherein the unencrypted message portion includes information for identifying how to process the transaction.

17. The method of claim 14, wherein the transaction data includes account data and transaction details, wherein the transaction details are adapted to verify the validity of the account data.

18. The method of claim 17, wherein the account data includes at least an indication of the primary account number and the expiration date, and wherein the transaction details include one or more of a merchant identifier, a transaction amount, and a strong customer authentication mark.

19. A computing device comprising a processor and a memory and adapted to send and receive messages, wherein the processor is programmed to perform the method as described in any one of claims 1 to 18 with the aid of the memory.

Images