New hybrid method for quantum resistant off-line authentication of a payment device

Abstract

Method for quantum resistant off-line authentication of a payment device by means of a payment terminal, comprising firstly authentication of the payment device using standard public key cryptography authentication and a certificate chain according to the Europay Mastercard Visa (EMV) Public Key Infrastructure (PKI) model, secondly the verification of a Certification Authority (CA) signature using a CA Post Quantum Cryptography (PQC) public key, the verification of the CA signature comprising: - Signing the payment device credentials with a Certification Authority (CA) Post Quantum Cryptography (PQC) private key to obtain a CA signature, - Storing the generated CA signature on the payment device together with the corresponding CA PQC public key identifier, - Transmitting the CA PQC public key to the payment terminal, - Presenting the payment device to a payment terminal, and - Verifying the CA signature by means of the payment terminal using the CA PQC public key.

Description

[0001] NEW HYBRID METHOD FOR QUANTUM RESISTANT OFF-LINE

[0002] AUTHENTICATION OF A PAYMENT DEVICE

[0003] CROSS-REFERENCE TO RELATED APPLICATION

[0004] This application claims priority to, and the benefit of, United Kingdom Patent Application No. 2405231.8, filed on April 12, 2024, the entire contents of which is incorporated herein by reference.

[0005] FIELD OF THE DISCLOSURE

[0006] The present disclosure relates generally to a new hybrid method for quantum resistant off-line authentication of a payment device by means of a payment terminal. The method is particularly useful for allowing authentication of payment device credentials, such as an account identifier or a cryptographic public key, in an off-line manner by means of a first authentication of the payment device using standard public key cryptography authentication and a certificate chain according to the Europay Mastercard Visa (EMV) Public Key Infrastructure (PKI) model, and a second verification of a Certification Authority (CA) signature using a CA Post Quantum Cryptography (PQC) public key.

[0007] BACKGROUND

[0008] Cryptographic digital signature certificate chains protect the authenticity of device level public keys used to verify a signature over the transaction data generated from a device private key. It is possible that quantum computers will be able to counterfeit certificate chains, enabling massive fraud. In particular, a quantum computer attack on the RSA (Rivest-Shamir-Adleman), DSA (Digital Signature Algorithm) or ECC (Elliptic Curve Cryptography) public key certificate chain may be financially viable. In the cryptographic community the prevalent view is that to respond to the quantum computer threat posed to conventional public key algorithms (e.g. RSA / ECC / DSA) that form the security backbone to today’s communications, the industry must foundationally move to adopt post quantum algorithms. The present disclosure provides a quantum resistant method of trusting a constrained device cryptographic public key in an off-line manner without traversing a Post Quantum Cryptography (PQC) cryptographic public key digital signature certificate chain. Cryptographic digital signature certificate chains protect the authenticity of device level public keys, such as chip card based RSA, DSA or ECC, used to verify a signature over the transaction data generated from a device private key. These certificate chains mean that it is typically possible to rely on the trustworthiness of the device public key without resorting or referring to a distant resource, for example over a network, such as traversing a cryptographic public key digital signature certificate chain.

[0009] Resorting or referring to a distant resource will typically incur a communications round trip of more than 500 ms. In some circumstances, such a delay is not desirable or acceptable. One such circumstance is at a transit terminal, such as a terminal at a train or bus station.

[0010] Transit terminals typically see a high volume of consumers passing therethrough in a short time. In many circumstances, it is not possible to increase the number of transit terminals due to a lack of space.

[0011] Accordingly, to avoid an increase in waiting time or the slow-down of traffic during rush hours, it is typically desirable or necessary to avoid the need for a communications round trip of over 500 ms. Contactless transactions, such as those performed using near-field communication (NFC), typically have performance criteria of less than 500 ms and preferably less than 300 ms.

[0012] Payment devices may use a certificate chain to authenticate the payment device credentials when performing local authentication of the transaction data. Quantum computers pose a potential threat on standard public key cryptography like RSA, DSA and ECC used in the EMV public key infrastructure (PKI) model to validate payment transactions off-line.

[0013] One concern is that RSA, DSA and ECC keys can be broken by means of quantum computers in that the private key is retrieved from the public key. Therefore, an alternative or additional method would be required to authenticate the payment device and prove the payment device credentials are genuine.

[0014] In the prior art, solutions are proposed to deal with the above- mentioned problem, such as a PKI model relying on public key Post Quantum Cryptography (PQC). However, this solution is considered computationally and monetarily expensive as it requires a complete hardware and software change of the payment environment. This means that new devices should replace both existing payment devices and existing payment terminals. For instance, if PQC resists attacks using classical and quantum computers, current algorithms used in those models require an order of magnitude faster contactless communication and crucially more powerful payment devices.

[0015] Technical limitations linked to solutions suggested in the prior art comprise, among others, the fact that the currently suggested post quantum algorithms use large public keys that require much larger public key certificates to be stored in the payment device and to be transmitted to the terminal. As an indication, these public keys use kilobytes rather than kilobits or even less when ECC is used.

[0016] Related to this problem, the PQC signatures needed for these systems is also larger in a similar ratio and therefore require more computational power and more memory on the payment device; the most critical aspect being the side channel resistance of the PQC signature generation, when possible.

[0017] Further, the known PQC algorithms are still not mature enough to ensure security alone, nor are standards finalised yet. For instance, several suggested PQC algorithms have suffered from classical attacks in the past number of years.

[0018] In view of the observations above, aspects of the present disclosure seek to provide an off-line transaction validation method that does not require the change of payment devices or payment terminals, but only requires software modification to the payment terminals.

[0019] In most protocols today, RSA / ECC / DSA perform two separate tasks: (1) attestation to some fact e.g. “1234567” is a valid bank account number including the attached credentials like the account public key; and (2) validation of a claim to be a given entity, e.g. “I claim to be card “1234567” and I can prove it with an active challenge and response protocol”. According to received wisdom (“Principle A”), for a protocol to be post-quantum secure then RSA / ECC / DSA must be replaced with new quantum resistant algorithms for both of these tasks. A refinement to this basic migration principle (“Principle A+”) is based on the following logic. As of today, the post quantum algorithms being deployed are immature as regards the amount of academic scrutiny they have faced, and insurance should be taken against the risk that they may not actually resist classical attack never mind quantum attack. Consequently, as partial mitigation, post quantum algorithms should not be applied alone but one of ECC / RSA / DSA should additionally and in parallel be used, since the latter are confidently believed to be resistant to classical attacks. This approach is often referred to in the community as “hybrid”. In short, known hybrid approaches involve delivering tasks (1) and (2) using full duplication: post quantum algorithm and RSA / ECC / DSA in parallel (this is “Principle A+”, extending “Principle A”).

[0020] The present application challenges the received wisdom (“Principle A” and “Principle A+”) by providing a new type of hybridisation mechanism, which for example avoids transistor count increase on chip cards in particular, to maintain security in the face of a quantum adversary.

[0021] SUMMARY

[0022] According to a first aspect the disclosure relates to a method for quantum resistant off-line authentication of a payment device by means of a payment terminal, comprising firstly authentication of the payment device using standard public key cryptography authentication and a certificate chain according to the Europay Mastercard Visa (EMV) Public Key Infrastructure (PKI) model, secondly the verification of a Certification Authority (CA) signature using a CA Post Quantum Cryptography (PQC) public key, the verification of the CA signature comprising:

[0023] - Signing the payment device credentials with a Certification Authority (CA) Post Quantum Cryptography (PQC) private key to obtain a CA signature,

[0024] - Storing the generated CA signature on the payment device together with the corresponding CA PQC public key identifier,

[0025] - Transmitting the CA PQC public key to the payment terminal,

[0026] - Presenting the payment device to a payment terminal, and

[0027] - Verifying the CA signature by means of the payment terminal using the CA PQC public key.

[0028] According to the disclosure, additional quantum resistant authentication is provided by a CA signature of the payment device credentials stored in the data storage of the payment device. The CA signature verification is performed by the payment terminal using the CA PQC public key stored in a payment terminal.

[0029] The technical effect provided by this solution is that the additional quantum resistant authentication that is provided only needs the generation and verification of the CA signature. This verification of the CA signature means that only the payment device credentials are authenticated. This verification does not require a full certification chain. Moreover, no change to existing payment devices and terminals is required. The only change needed is an update to the software of the used network terminals. The new hybridisation concept disclosed herein is as follows: use of post quantum algorithms only for task (1) and use of RSA / ECC / DSA only for task (2). This new hybridisation concept adds a post quantum authentication of account credentials (task (1)) used to validate a terminal transaction (task (2)). Rather than being a mere duplication of a conventional protocol using post quantum algorithms, the new type of hybridisation disclosed herein overcomes shortcomings of existing solutions, does not require localisation and is not multiplicative.

[0030] According to an embodiment of the disclosure, the step of storing of the generated CA signature and the CA PQC public key identifier comprises:

[0031] - Presenting, the payment device to a bank terminal operated by or on behalf of the issuer of the payment device,

[0032] - Interrogating the payment device to determine if the payment device stores a CA signature and the CA PQC public key identifier, and in case the payment device does not store such a CA signature and the CA PQC public key identifier:

[0033] - Requesting, by the bank terminal, a Certification Authority (CA) to generate a CA signature,

[0034] - Generating, by the Certification Authority (CA), the CA signature, using the CA PQC private key,

[0035] - Receiving, by the bank terminal, the CA signature and the corresponding CA PQC public key identifier, and,

[0036] - Storing, by the bank terminal, the generated CA signature together with the corresponding CA PQC public key identifier on the payment device.

[0037] According to an embodiment of the disclosure, the payment device is stored in or with an issuer application present on an electronic device and wherein the step of storing the generated CA signature together with the corresponding CA PQC public key identifier on the payment device comprises:

[0038] - Storing the generated CA signature together with the corresponding CA PQC public key identifier in the payment device online, via said issuer application.

[0039] According to an embodiment of the disclosure, the method further comprises the steps of:

[0040] - Providing, by the Certification Authority (CA) the corresponding CA PQC public key, and

[0041] - Storing the CA PQC public key on the payment device, the method further comprising the step of: - Transmitting the CA PQC public key to the payment terminal by means of the payment device.

[0042] According to an embodiment of the disclosure the CA PQC public key is transmitted to the payment terminal by means of a short-distance communication protocol.

[0043] According to an embodiment of the disclosure, the payment terminal is connected to a network and wherein the CA PQC public key is transmitted to the payment terminal by means of said network.

[0044] According to an embodiment of the disclosure, the method further comprises, prior to authentication of the payment device:

[0045] - Determining that the device identifier is present on a deny list; and

[0046] - Rejecting the payment device.

[0047] According to an embodiment of the disclosure, the method is carried out by a payment terminal, the payment device is an NFC enabled device, the receiving and extracting of data is carried out via NFC, and the method is initiated by bringing the NFC enabled device within an NFC operational distance of an NFC transceiver of the payment terminal, wherein the method further comprises the step of:

[0048] - Approving payment via the payment terminal following the validation of the transaction.

[0049] According to an alternative solution, wherein the method is carried out by a payment terminal, the payment device is a contact enabled payment device, the receiving and extracting of data is carried out via contact between the payment terminal and the payment device, and the method is initiated by bringing the contact enabled payment device in contact with the payment terminal, wherein the method further comprises the step of:

[0050] - Approving payment via the payment terminal following the validation of the transaction.

[0051] According to an embodiment of the disclosure, the payment terminal is connected to a network host, the method further comprising:

[0052] - Obtaining, by the payment terminal, the CA PQC public key identifier from the payment device, and in case the terminal does not have the CA PQC public key,

[0053] - Requesting, by the payment terminal, the CA PQC public key from the network host. According to an embodiment of the invention, the payment terminal is a gate of a transit network and wherein approving payment comprises allowing access to said transit network.

[0054] According to a second aspect of the present disclosure, the disclosure relates to a data processing system associated with a physical terminal, the system comprising a processor configured to perform the methods disclosed herein.

[0055] According to a third aspect of the present disclosure, the disclosure relates to a computer program product comprising instructions which, when the program is executed by a computer associated with a physical terminal, cause the computer to carry out the methods disclosed herein.

[0056] According to a fourth aspect of the present disclosure, the disclosure relates to a computer-readable storage medium associated with a physical terminal, the medium comprising instructions which, when executed by a computer, cause the computer to carry out the methods disclosed herein.

[0057] According to a further aspect of the disclosure there is provided a method for authentication of a payment device by a payment terminal, the method comprising: authenticating the payment device using standard public key cryptography authentication; and verifying a Certificate Authority (CA) signature using a CA Post Quantum Cryptography (PQC) public key.

[0058] In examples, the method is a method for offline authentication of the payment device.

[0059] In examples, the payment terminal authenticates the payment device.

[0060] In examples, authenticating the payment device comprises using a certificate chain, for example a certificate chain according to the Europay Mastercard Visa (EMV) Public Key Infrastructure (PKI) model.

[0061] In examples, authenticating the payment device using standard public key cryptography authentication comprises using only standard public key cryptography authentication to authenticate the payment device.

[0062] In examples, the payment terminal verifies the CA signature.

[0063] In examples, the method comprises obtaining a CA signature.

[0064] In examples, the method comprises signing the payment device credentials with a Certification Authority (CA) Post Quantum Cryptography (PQC) private key to obtain a CA signature. In examples, the method comprises storing the generated CA signature on the payment device.

[0065] In examples, the method comprises storing the CA PQC public key identifier on the payment device.

[0066] In examples, the method comprises transmitting the CA PQC public key to the payment terminal

[0067] In examples, the method comprises presenting the payment device to a payment terminal.

[0068] In examples, the method comprises verifying the CA signature by means of the payment terminal using the CA PQC public key.

[0069] In examples, verifying the Certificate Authority (CA) signature comprises using a CA Post Quantum Cryptography (PQC) public key only.

[0070] In examples, verifying the Certificate Authority (CA) signature does not involve using standard public key cryptography authentication.

[0071] It will be appreciated that any features described herein as being suitable for incorporation into one or more aspects or embodiments of the present disclosure are intended to be generalizable across any and all aspects and embodiments of the present disclosure. Other aspects of the present disclosure can be understood by those skilled in the art in light of the description, the claims, and the drawings of the present disclosure. The foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the claims.

[0072] BRIEF DESCRIPTION OF THE DRAWINGS

[0073] The disclosure will be further described with reference to examples depicted in the accompanying figures in which:

[0074] Figure l is a flow chart of the method according to the present disclosure;

[0075] Figure 2 is a diagram showing the steps of requesting, by the bank terminal, the CA signature to the Certification Authority (CA), and storing, by the bank terminal, the generated CA signature together with the corresponding CA PQC public key identifier on the payment device; and

[0076] Figures 3 and 4 are diagrams showing the steps of presenting a payment device at a network terminal. DETAILED DESCRIPTION

[0077] The following description presents particular examples and, together with the drawings, serves to explain principles of the disclosure. However, the scope of the disclosure is not intended to be limited to the precise details of the examples, since variations will be apparent to a skilled person and are deemed to be covered by the description. Terms for components used herein should be given a broad interpretation that also encompasses equivalent functions and features. In some cases, alternative terms for structural features may be provided but such terms are not intended to be exhaustive.

[0078] Descriptive terms should also be given the broadest possible interpretation; e.g. the term "comprising" as used in this specification means "consisting at least in part of' such that interpreting each statement in this specification that includes the term "comprising", features other than that or those prefaced by the term may also be present. Related terms such as "comprise" and "comprises" are to be interpreted in the same manner.

[0079] The description herein refers to examples with particular combinations of features, however, it is envisaged that further combinations and cross-combinations of compatible features between embodiments will be possible. Indeed, isolated features may function independently from other features and not necessarily require implementation as a complete combination.

[0080] In the disclosure, the term CA signature is used. This term refers to a signature, which relates to the payment device credentials and which is obtained by means of a Certification Authority (CA) Post Quantum Cryptography (PQC) private key.

[0081] In the description, reference is made to standard public key cryptography. With this term reference is made to known cryptography technology that is used for the authentication of payment devices, such as RSA, DSA and ECC.

[0082] The main objective of the disclosure is to provide a method, which after a first local authentication using standard cryptography authentication, such as the verification of the ECC public key certificate chain, allows for additional authentication of a payment device, while using the existing functionality of payment devices and payment terminals. Thus, the introduction of the solution according to the disclosure does not require an amendment to the existing payment infrastructure. The term ‘hybrid’ is used to underline the fact that the authentication comprises a first and a second step.

[0083] Figure l is a flowchart of the method according to the disclosure.

[0084] According to Figure 1, the new hybrid method for quantum resistant off-line authentication of a payment device by means of a payment terminal according to the disclosure comprises a first step 110 wherein the payment device is authenticated using standard public key cryptography authentication and a certificate chain according to the Europay Mastercard Visa (EMV) Public Key Infrastructure (PKI) model.

[0085] In a second step 120, the CA signature is verified using CA PQC public key.

[0086] The generation of the CA signature comprises a step 130 wherein the payment device credentials are signed with a Certification Authority (CA) Post Quantum Cryptography (PQC) private key to obtain a CA signature.

[0087] In a further step 140, the method comprises storing the generated CA signature on the payment device together with the corresponding CA PQC public key identifier.

[0088] In a next step 150, the CA PQC public key is transmitted to the payment terminal.

[0089] In a further step 160, the payment device is presented to a payment terminal.

[0090] In yet a further step 170, the CA signature is verified by means of the payment terminal using the CA PQC public key.

[0091] It should be noted that steps 110 - 170 are presented in a certain order and the numbering of the steps suggests that the steps are performed consecutively. It should be clear that it is possible to change the order of the steps without changing the overall technical effect of the solution according to the disclosure.

[0092] The technical effect of the solution of the method presented in Figure 1 is that the additional authentication is obtained by storing a CA signature of the payment device credentials in the data storage of the payment device. The payment device does not need any physical modification to allow the storage of this CA signature. In other words, existing payment devices can be used in the method according to the disclosure. The CA signature verification is performed by the payment terminals. To allow these payment terminals to perform these tasks, the terminals only need a software update. This confirms the above-mentioned statement that the method according to the disclosure does not require the replacement of existing payment terminals.

[0093] According to the disclosure, the additional authentication of a payment device comprises the use of a post quantum public key cryptography (PQC) to perform an additional authentication of the payment device credentials such as the payment device PAN and ECC public key, which are already authenticated by an RSA / DSA / ECC certificate chain, according to the EMV PKI model.

[0094] The payment devices are, for instance, bank cards issued by an issuer bank. These existing bank cards comprise a memory, which support data storage and which can store additional data during their life cycle.

[0095] If the quantum computing threat becomes imminent, the issuer bank can decide to store the mentioned CA signatures of the payment device credentials on the existing payment devices when these payment devices are presented at a bank terminal or an ATM. Alternatively, if the payment device is stored in or with an issuer application on a connected device, such as a mobile telephone, the issuer bank can decide to store the CA signature on the payment device online via said issuer application.

[0096] The CA signature is generated by the certification authority (CA) using its CA PQC private key and transmitted to the issuer bank with the corresponding CA PQC public key identifier when requested. The CA PQC private / public key pair can be brand agnostic, which would mean that the same key pair is used for all payment systems. In that case, a single trusted entity, such as an EMV server, generates the CA signatures for all the issuers.

[0097] The CA signature is stored post issuance in the data storage of the payment device together with the corresponding CA PQC public key identifier. This is possible since existing payment devices have sufficient memory to store the additional data. To allow this post issuance storage of the CA signature, no physical change to payment devices is required. However, in the payment environment, the payment terminals that are used and that support off-line transactions must be adapted to be able to verify the CA signature newly stored in the payment device. Figure 2 schematically shows the communication between different entities in the payment environment which are used to store a CA signature on a payment device 10. As shown in Figure 2, the payment device 10 is presented at a bank terminal 20 and performs a C-8 transaction based on ECC as specified by EMV.

[0098] After this initial presentation of the payment device 10, the bank terminal 20 firstly verifies the ECC public key certificate chain. This means that the first verification is completed using standard public key cryptography authentication and a certification chain according to the Europay Mastercard Visa (EMV) Public Key Infrastructure (PKI) model.

[0099] Subsequently the presence of a CA signature is verified. Where the bank terminal 20 determines that the payment device 10 does not have a CA signature, the bank terminal 20 will send a request to the issuer bank 30 to obtain such a CA signature. The issuer bank 30 will verify the request and, once approved, will forward the request to the Certification Authority (CA) 40.

[0100] The CA 40 will generate the requested CA signature and will forward this to the issuer bank 30 together with the corresponding CA PQC public key identifier.

[0101] Subsequently, the issuer bank 30 will forward the CA signature and the corresponding CA PQC public key identifier to the bank terminal 20.

[0102] Finally, the bank terminal 20 will store the CA signature on the payment device 10 together with the corresponding CA PQC public key identifier.

[0103] The procedure according to Figure 2, allows for the deployment of the CA signatures to payment devices 10, post issuance of said payment devices.

[0104] It is noted that according to an alternative embodiment, the payment device is stored in or with an issuer application present on an electronic device. In that case, the step of storing the generated CA signature together with the corresponding CA PQC public key identifier on the payment device comprises storing of the generated CA signature together with the corresponding CA PQC public key identifier in the payment device online, via said issuer application. The issuer application is, for instance, a wallet application on an electronic device, such as a mobile telephone.

[0105] According to this alternative, the generated CA signature together with the corresponding CA PQC public key identifier can be stored in or with an issuer application at any appropriate time. This means that the storing does not interfere and / or slow down any communication between a payment terminal and the payment device.

[0106] According to an embodiment of the invention, the storing of the generated CA signature together with the corresponding CA PQC public key identifier on a physical payment device is executed in two subsequent steps. In a first step, the generated CA signature together with the corresponding CA PQC public key identifier are stored in or with an issuer application present on an electronic device. In a second, subsequent step, the electronic device and the physical payment device, such as a credit card, are brought near to each other. In this manner the generated CA signature together with the corresponding CA PQC public key identifier can be transferred from the electronic device to the physical payment device. This embodiment allows the transfer of the generated CA signature together with the corresponding CA PQC public key identifier to the physical payment device, via the electronic device at any appropriate time. This means that the storing does not interfere and / or slow down any communication between a payment terminal and the payment device.

[0107] Figure 3 is a schematic diagram of the use of a payment device 10 in a transit network. The transit network will comprise, for example, a number of network terminals or gates 50. This network terminal 50 is typically a gate or barrier at a train station. Other transit specific systems, such as those present on bus or tram networks, are also envisaged. It should be noted that in Figure 3 only one network terminal 50 is shown. In practice, a transit network will comprise a large number of network terminals 50, which all work in a similar manner.

[0108] It will be appreciated that the physical terminal represented in Figure 3 as network terminal 50 may be any physical terminal and is not limited to the context of transit network. The physical terminal may be an area, a bay, a device, or any other physical structure with which a consumer may momentarily engage before proceeding onwards. The physical terminal may include a display, input means, a memory, a moveable barrier, and / or any other desired or necessary physical components. The physical terminal may prevent or restrict a consumer from passing therethrough unless one or more conditions are met, such as the consumer being in possession of a valid ticket or providing payment credentials. The physical terminal may be operated by an operator, such as a train operating company. Accordingly, the operator may be a party responsible for the running of the physical terminal and thus may be responsible for carrying out actions in relation to the physical terminal.

[0109] In the example according to Figure 3, the network terminal 50 may comprise a fixed barrier and a moveable barrier portion. The fixed barrier portion may be a post or any other suitable fixed structure. The moveable barrier portion will be configured to be moveable relative to the fixed barrier portion between a blocking position and an access position. With the moveable barrier portion in the blocking position, the network terminal 50 is arranged to prevent a consumer from passing therethrough. With the moveable barrier portion in the access position, the network terminal 50 is arranged to allow a consumer to pass therethrough.

[0110] The network terminal 50 will include a processor and an associated memory. The processor is configured to control operation of the network terminal 50, such as opening of the gate by, for instance, controlling a motor to move the moveable barrier portion from the blocking position and the access position.

[0111] The processor will typically be connected to an NFC transceiver. This NFC transceiver may be arranged to continuously or continually search for an NFC enabled device, such as a payment device 10. When a consumer brings an NFC enabled device 10 within range of the NFC transceiver, the processor may interrogate a memory of the payment device 10.

[0112] Alternatively, the communication between the network terminal 50 and the payment device is established after physical contact between the network terminal 50 and the payment device 10.

[0113] The memory of the payment device 10 is arranged to store the device credentials. The network terminal 50 will be able to read the memory of the payment device 10. As such, the gate 50 may be able to read device credentials. The device credentials may be related to or include any data unique to or associated with the payment device 10. For example, the device credentials may be or include an account identifier, a cryptographic public key, a device identifier and / or any other data.

[0114] The communication and exchange of information and the order wherein the information is exchanged between the payment device 10 and the network terminal 50 is shown in detail in Figure 3.

[0115] The payment device 10 is presented to a network terminal 50, which operates as a payment terminal. Typically, the payment device 10 communicates with the network terminal 50 using a short distance communication protocol, such as NFC. Firstly, the gate 50 verifies the ECC public key certificate chain and secondly the CA signature using the CA PQC public key. It is noted that this authentication does not require traversing a second CA PQC public key certificate chain. A payment device 10 without the CA signature or with an invalid CA signature can be rejected in off-line environments.

[0116] Therefore, the method according to the disclosure neither requires the payment device 10 to generate a PQC signature in real time at the gate 50 nor to store a PQC public key certificate chain. It will be clear that the method according to the disclosure can use the advantages linked to post quantum algorithms like MAYO or HAWK, because of the use of a relatively small public key, in the order of 1 kbytes, and signature, in the order of 400 bytes, which can be stored in the payment device 10.

[0117] As shown in Figure 3, the network terminal 50 is able to read the CA signature and the CA PQC public key identifier.

[0118] In case the network terminal 50 does not have the CA PQC public key, the network terminal 50 demands to receive the CA PQC public key from the network host 60 using the CA PQC public key identifier. Once the CA PQC public key is received, the network terminal 50 can validate the CA signature and approve the payment device 10 and thereby authorise the payment of the payment device 10. In the described example of a transit system, this means, for instance, that the network terminal 50 can allow, after validation of the CA signature, a user to get access to a transit network.

[0119] After such off-line authentication, the payment can be completed using a deferred online authorisation. This step is executed using an online connection between the network host 60 and the issuer 30.

[0120] It is possible that the CA PQC public key is transmitted to the network terminal 50 by means of the payment device 10, for instance, using NFC communication. If the CA PQC public key is transmitted by the payment device 10 and is not known by the network terminal 50 or by the network to which the network terminal 50 is connected, the network terminal 50 requests a real time online authorisation to authenticate the payment device 10. This is shown in Figure 4.

[0121] According to Figure 4, after the network terminal 50 has read the CA PQC public key, the gate 50 connects with the host 60 to request online authorisation of the payment device 10. If this authorisation is successful, the CA PQC public key is considered as genuine and can be trusted. In most cases, off-line terminals, such as network terminal 50, are indeed connected, but off-line authentication is preferred to meet performance issues. However, if the online authorisation failed, the CA PQC public key is rejected and the payment device 10 can be denied.

[0122] Instead of providing the CA PQC public key to the network terminal 50 by means of the payment device 10, the CA PQC public key can be transmitted to the network terminal 50 by means of said network, since the network terminal 50 is connected to a network.

[0123] Irrespective of whether CA PQC public key is provided by the payment device 10 or out of band by the network, the trusted CA PQC public key is stored with its identifier in the network terminal 50. Once the CA PQC identifier is known by the network terminal 50, it does not need to read the CA PQC public key from the payment device 10 nor to perform a real time online authorisation.

[0124] As long as the CA PQC public key is trusted by the network terminal 50, all the following transactions are validated off-line, the payment device 10 credentials being all considered as genuine including the ECC public key used to establish the C-8 transaction secure channel, between the payment device 10 and the network terminal 50, and sign the transaction.

[0125] As shown in Figures 3 and 4, all off-line transactions are followed by a deferred online authorisation that will complete the payment. If the online authorisation fails, the identifier of the payment device is eventually stored in a deny list of the network host.

[0126] As will be understood from the above, the method according to the disclosure gives the certification authority with the possibility to revoke a doubtful PQC algorithm and use a new PQC algorithm which is more trusted and / or more performant than an earlier version. This flexibility is available for the certification authority, since the diffusion of the new PQC algorithm can be processed post issuance of the individual payment devices 10. A new CA signature is then stored in the payment device 10 when presented at a bank terminal 20, ATM or online via the issuer application, in place of the old CA signature.

[0127] In case a new CA PQC public key is provided to the network out of band, the old CA PQC public key stored in the payment device 10 can no longer be used. All payment devices 10 with a revoked CA signature can then be rejected. The method can further comprise, prior to authentication of the payment device: determining that the device identifier is present on a deny list; and rejecting the payment device.

[0128] In addition to the method described above, the disclosure also relates to a data processing system associated with a physical terminal, the system comprising a processor configured to perform the method according to the disclosure.

[0129] The disclosure further relates to a computer program product comprising instructions which, when the program is executed by a computer associated with a physical terminal, cause the computer to carry out the method according to the disclosure.

[0130] The disclosure also refers to computer-readable storage medium associated with a physical terminal, the medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to the disclosure.

[0131] With reference to the description, it is noted that one of the advantages of the described new hybrid method is that the solution can be prepared as a safety and therefore will be ready to deploy whenever the threat of quantum computer, as described above, becomes imminent.

[0132] The solution according to the description can be deployed after the emission of payment devices or, alternatively, can be added as standard feature to a new generation of payment devices.

[0133] With reference to the description above, it is noted that the above described new hybrid method has provided an improvement of an EMV payment platform. Alternatively, the new hybrid method according to the description can provide a more general and global solution in the form of a common protocol to improve payment systems.

[0134] The description provided herein may be directed to specific implementations. It should be understood that the discussion provided herein is provided for the purpose of enabling a person with ordinary skill in the art to make and use any subject matter defined herein by the subject matter of the claims.

[0135] It is intended that the subject matter of the claims should not be limited to the implementations and illustrations provided herein, but include modified forms of those implementations including portions of implementations and combinations of elements of different implementations in accordance with the claims. It should be appreciated that in the development of any such implementation, as in any engineering or design project, numerous implementation-specific decisions should be made to achieve a developer’s specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort may be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having benefit of this disclosure.

Claims

CLAIMS1. A method for quantum resistant off-line authentication of a payment device by means of a payment terminal, comprising firstly authentication of the payment device using standard public key cryptography authentication and a certificate chain according to the Europay Mastercard Visa (EMV) Public Key Infrastructure (PKI) model, secondly the verification of a Certification Authority (CA) signature using a CA Post Quantum Cryptography (PQC) public key, the verification of the CA signature comprising:- Signing the payment device credentials with a CA PQC private key to obtain a CA signature,- Storing the generated CA signature on the payment device together with the corresponding CA PQC public key identifier,- Transmitting the CA PQC public key to the payment terminal,- Presenting the payment device to a payment terminal, and- Verifying the CA signature by means of the payment terminal using the CA PQC public key.

2. Method according to claim 1, wherein the step of storing of the generated CA signature and the CA PQC public key identifier comprises:- Presenting the payment device to a bank terminal operated by or on behalf of the issuer of the payment device,- Interrogating the payment device to determine if the payment device stores a CA signature and the CA PQC public key identifier, and in case the payment device does not store such a CA signature and the CA PQC public key identifier:- Requesting, by the bank terminal, a Certification Authority (CA) to generate a CA signature,- Generating, by the Certification Authority (CA), the CA signature using the CA PQC private key,- Receiving, by the bank terminal, the CA signature and the corresponding CA PQC public key identifier, and- Storing, by the bank terminal, the generated CA signature together with the corresponding CA PQC public key identifier on the payment device.

3. Method according to claim 1, wherein the payment device is stored in or with an issuer application present on an electronic device and wherein the step of storing the generated CA signature together with the corresponding CA PQC public key identifier on the payment device comprises:- Storing the generated CA signature together with the corresponding CA PQC public key identifier in the payment device having been obtained online, via said issuer application.

4. Method according to claim 1, 2 or 3, comprising the steps of:- Providing, by the Certification Authority (CA) the corresponding CA PQC public key, and - Storing the CA PQC public key on the payment device, the method further comprising the step of:- Transmitting the CA PQC public key to the payment terminal by means of the payment device.

5. Method according to claim 4, wherein the CA PQC public key is transmitted to the payment terminal by means of a short-distance communication protocol.

6. Method according to claim 1, 2 or 3, wherein the payment terminal is connected to a network and wherein the CA PQC public key is transmitted to the payment terminal by means of said network.

7. Method according to any of the preceding claims, further comprising, prior to authentication of the payment device:- Determining that the device identifier is present on a deny list; and- Rejecting the payment device.

8. Method according to any of the preceding claims, wherein the method is carried out by a payment terminal, the payment device is an NFC enabled device, the receiving and extracting of data is carried out via NFC, and the method is initiated by bringing the NFC enabled device within an NFC operational distance of an NFC transceiver of the payment terminal, wherein the method further comprises the step of:- Approving payment via the payment terminal following the validation of the transaction.

9. Method according to any of the claims 1-7, wherein the method is carried out by a payment terminal, the payment device is a contact enabled payment device, the receiving and extracting of data is carried out via contact between the payment terminal and the payment device, and the method is initiated by bringing the contact enabled payment device in contact with the payment terminal, wherein the method further comprises the step of:- Approving payment via the payment terminal following the validation of the transaction.

10. Method according to claim 8 or 9, wherein the payment terminal is connected to a network host, the method further comprising:- Obtaining, by the payment terminal, the CA PQC public key identifier from the payment device, and in case the terminal does not have the CA PQC public key,- Requesting, by the payment terminal, the CA PQC public key from the network host.

11. Method according to claim 8, 9 or 10, wherein the payment terminal is a gate of a transit network and wherein approving payment comprises allowing access to said transit network.

12. A data processing system associated with a physical terminal, the system comprising a processor configured to perform the method according to any of the preceding claims.

13. A computer program product comprising instructions which, when the program is executed by a computer associated with a physical terminal, cause the computer to carry out the method according to any of claims 1 to 11.

14. A computer-readable storage medium associated with a physical terminal, the medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any of claims 1 to 11.

Images