CROSS REFERENCE TO RELATED APPLICATION

This applica tion claims the benefit of United Kingdom Patent Application No. 2106783.0, which was filed on May 12, 2021, the entire contents of which are hereby incorporated by reference for all purposes.

TECHNICAL FIELD

The present disclosure relates to secure channel establishment. In particular, the present disclosure relates to a computer-implemented method and corresponding computing device for establishing a communication channel for exchanging messages securely between an initiator device and an endpoint device using an intermediary server.

BACKGROUND

A secure connection between two entities can provide protection against eavesdropping and tampering of communications. As an example, a Transport Layer Security (TLS) protocol connection enables communications between two entities to be encrypted to reduce eavesdropping and tampering.

A TLS protocol connection typically requires additional certificate exchanges, as well as additional public key cryptography signing operations, e.g. RSA or. Elliptic Curve cryptography. Furthermore, in peer-to-peer connections, the same certification authority is required for both entities for the TLS protocol to be set up.

In payment systems, TLS protocols can be used to enable communications between a merchant payment terminal and a merchant gateway to be encrypted. A payment system typically uses an EMV payment card, which is a particular example of a transaction device, to perform a payment transaction. The EMV payment card normally contains secure information in a chip to support performance of a transaction. In order to initiate a payment transaction, the EMV payment card can interact with a nierehanfs payment terminal through EMV channels, by inserting the payment card into a card reader at the payment terminal and reading the card data from the chip. Alternatively, card data can be read from the payment card in a contactless manner, namely by bringing the payment card into proximity with a contactless card reader at the payment terminal. Existing security features of EMV payment cards allow the payment terminal to authenticate the cardholder and the payment card as well as the issuer to authorise the transaction.

A problem with EMV payment cards is that they have limited capabilities in terms of interoperability, interactivity and personalised sendces. EMV payment cards can be digitalised in a mobile device, such that card data can. be read from the mobile device instead of the EMV payment card itself; nevertheless, the vast majority of payment transactions are performed using physical payment car ds.

The present disclosure has been devised to mitigate or overcome at least some of the above-mentioned problems.

SUMMARY OF THE. DISCLOSURE

According to a first aspect of the present disclosure, there is provided a computer-implemented method for establishing a communication channel for exchanging messages securely between an initiator device and an endpoint device using an intermediary server, wherein the initiator device is hr communication with the intermediary server vi a a first session encrypted according to a cryptographic protocol, and the endpoint device is in communication with the intermediary server via a second session encrypted according to a cryptographic protocol, and wherein the method is per formed at the initiator device. The method comprises sending, to the intermediary server, a request for a handover token (HT) via the first session encrypted according to a cryptographic protocol, wherein the handover token (HI) comprises data that has been generated at the endpoint device and is configured to be used in setting up the communication channel between the initiator device and the endpoint device; receiving, from fire intermediary server, fire handover token (HT) via the first session encrypted according to a cryptographic protocol; and establishing, using the handover token (HT), the communication channel between the initiator device and the endpoint device.

Preferably, the first session encrypted according to a cryptographic protocol is a first TLS session, and the second session encrypted according to a cryptographic protocol is a second TLS session . TLS is an example of a secure cryptographic protocol. Alternative secure cryptographic protocols may be used instead of the fir st TLS session and second TLS session.

The present disclosure relates to establishing a secure communication channel between an initiator device and an endpoint device. Establishment of the secure communication channel as claimed inthe present disclosure provides the following advantages.

Fewer operations are required to establish the secure communication channel. For example, the method of the present disclosure does nor require any additional certificate exchanges. In addition, no additional public key cryptography signing operations are requir ed and the number of cryptographic operations required are thus reduced. Furthermore, the present disclosure does not require the same certification authority for the initiator device and the endpoint device.

Once the secure communication channel is established, the initiator device and the endpoint device can connect in a secure manner. The secure communication channel provides the ability to perform secure wireless services. The services can also be accessed via a wired connection. It also ensur es user privacy during the wireless service, A further advantage is that it provides integrity and conditional confidentiality' of data exchanged between the initiator device and the endpoint device.

The mobile wallet of a mobile device is also able to manage wireless payments, value-added services, e.g, tipping, charity, loyalty and cloud services, e.g. storing and managing receipts or instant financing. The secure communication channel is available alongside the security of the EM V infrastructure, for example EMV payment cards and merchant card readers. Typically, a mobile wallet in a mobile device does not share any context with the EMV payment card that initiates a payment transaction. The present disclosure provides significant security a dvantages in establishing a secure communication channel between the mobile wallet and the payment terminal during an EMV transaction.

The method steps of the first aspect may be triggered by a payment transaction between a transaction device and the initiator device.

Ϊ» embodiments, the communication channel may be established between the initiator device and the endpoint device via the intermediary server.

In embodiments, the coimnunication channelmay be established directly between the initiator device and the endpoint device.

In some embodiments, the handover token may have been shared with the intermediary server by the endpoint device prior to the method being performed.

In other embodiments, the handover token may have been shared with the intermediary server by the endpoint device at the time of the method being performed. The handover token may comprise a public key (QE) of an endpoint cryptographic key pair (dE, QE), comprising a private key (dE) and a public key (QE), which has been generated at the endpoint device. The method may further comprise receiving, from the intermediary server, the public key (QE): generating an initiator device cryptographic key pair (dl, QI), comprising a private key (dl) and a public key (QI); computing a. shared secret (z) using the private key (dl) of the initiator device cryptographic key pair and the public key (QE) received from the intermediary server; deriving a session key (SK) from the shared secret (z); sending, to the endpoint device, the public key (QI) of the initiator device cryptographic key pair ( dl, QI) for generation of the same session key (SK); and establishing, using the session key (SK), the secure channel between the initiator device and the endpoint device.

The handover token may comprise a secret key (K) winch has been generated at the endpoint device. The methodmay further comprise receiving, from the intermediary server, the secret key (K); generating an initiator device cryptographic key pair (dl, QI), comprising a private key (dl) and a public key (QI); sending, to the endpoint device, the public key (QI) of the initiator device cryptographic key pair (dl, QI) for generation of the session key (SK); receiving, from the endpoint device, a public key (QE) of an endpoint cryptographic key pair (dE, QE), comprising a private key (dE) and a public key (QE), which has been generated at the endpoint device; computing a shared secret (z) using the private key (dl) of the initiator device cryptographic key pair and the public key (QE) received from the endpoint device; deriving· a session key (SK) from the shared secret (z) using the secret key (K); and establishing, using the session key (SK), the communication channel between the initiator device and the endpoint device.

The initiator device may comprise a payment terminal, the endpoint device may comprise a mobile device, the intermediary server may comprise a service gateway, and the method may further comprise establishing, using the handover token, the communication channel between the payment terminal and the mobile device.

The mobile device and the payment terminal may be provisioned with transaction data, and the method may be performed during a payment transaction between a transaction device and the payment terminal. The method may further comprise receiving, from thetransaction device, the payment card identifier (PAN) upon initiation of the payment transaction; sending, to the service gateway, the payment card identifier (PAN) with a request for a handover token (HT), wherein the handover token (HT) corresponds to the mobile device associated to the payment card identifier (PAN); receiving, from the service gateway, the handover token (HT) corresponding to the mobile device associated to the payment card identifier (PAN); and establishing, using the received handover token (HT), the communication channel between the mobile device and the payment terminal.

Preferably, the communication channel is independent of communication means for the payment transaction.

The payment transaction may be an EM V payment transaction.

The EMV payment transaction may be performed using NFC technology.

The transaction device may be the mobile device and the mobile device may comprise a digitised version of a payment card.

The transaction device may comprise a payment card and the mobile device may comprise _: a digitised version of the payment card.

The EMV payment transaction may be performed by a contact-based EMV payment transaction. Contact-based EMV payment transactions may include chip-based transactions or magstripe.

The initiator device may comprise a payment terminal, the endpoint device may comprise a service provider, the intermediary server may comprise a platform gateway, and the method may comprise establishing, rising the handover token, the communication channel between the payment terminal and the service provider.

The initiator device may comprise a mobile device, the endpoint device may comprise a service provider, the intermediary server "may comprise a platform gateway, and the method may comprise establishing, using the handover token, the communication channel between the mobile device and the sendee provider.

According to a second aspect of the present disclosure, there is provided a computing device comprising a processor, a memory, and communication capability, wherein the computing device is adapted to perform the method of the first aspect.

According to a third aspect of the present disclosure, there is provided a computer program product comprising instructions winch, when the program is executed by a computer, cause the computer to cany out the method of the first aspect.

According to a fourth aspect of the present disclosure, there is provided a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of the first aspect.

According to a fifth aspect of the present disclosure, there is provided a computer-implemented method of establishing a communication channel for exchanging messages securely between an initiator device and an endpoint device using an intermediary server, wherein the initiator device is in communication with the intermediary server via a first session encrypted according to a cryptographic protocol, and the endpoint device is in communication with the intermediary server via a second session encrypted according to a cryptographic protocol, and wherein the method is performed at the intermediary server. The method comprises receiving, from the initiator:device, a request for a handover token (HT), wherein the requested handover token (HT) comprises data that has been generated at the endpoint device and is configured to be used in setting up the communication channel between the initiator device and the endpoint device; and sending, to the initiator device, the handover token (HT) for establishing the communication channel between the initiator device and the endpoint device.

According to a sixth aspect of the present disc losure, there is provided an intermediary server adapted to perform the method, of the fifth aspect.

According to a seventh aspect of the present disclosure, there is provided a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the fifth aspect.

According to an eighth aspect of the present disclosure, there is provided a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of the fifth aspect. Within the scope of this application it is expressly intended that the various aspects, embodiments, examples and alternatives set out in the preceding paragraphs, in the claims and/or in the following description and drawings, and in particular the individual features thereof, may betaken independently or in any combination. That is, all embodiments and/or features of any embodiment can be combined in any way and/or combination, unless such features ar e incompatible. The applicant reserves the right to change any originally tiled claim or file any new claim accordingly, including the right to amend any originally filed claim to depend from and/or incorporate any feature of any other claim although not originally claimed in that manner .

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings _;, in which:

Figure la is a schematic diagram showing an initiator device, an endpoint device and an intermediary server, and a physical layer connecting the three entities, in accordance with embodiments of the present disclosure;

Figure lb is a schematic diagram showing the initiator device, the endpoint device and the intermediary server of Figure la, alongside the physical layer shown in Figure la and a security layer, wherein the security layer includes a secure communication channel between the initiator device and the endpoint device, in accordance with embodiments of the present disclosure;

Figure 2 is a flow chart showing a process, performed by the initiator device, of establishing the secure communication channel shown in Figure lb, in accordance with embodiments of the present disclosure;

Figure 3 is a flow chart showing the process, performed by theinitiator device, of the receiving and establishing steps shown in Figure 2 in further detail, for embodiments; where the handover token (HT) comprises an endpoint public key (QE);

Figure 4 is a flow chart showing the process, performed by the initiator device, of the receiving and establishing steps shown in Figure 2 in further detail, for embodiments where the handover token (HT) comprises an endpoint secret key (K);

Figure 5 is a flow' chart showing a process, performed by the intermediary server, of establishing the secure communication channel shown in Figure lb, in accordance with embodiments of the present disclosure; Figure 6 is a sdremaiic diagram showing a payment terminal, a mobile device, a platform gateway, alongside a physical layer and a security layer connecting the three entities, and EMV channels between the payment terminal and available EMV devices, wherein the security layer includes a secure communication channel between the payment terminal and the mobile device, in accordance with a first embodiment of the present disclosure;

Figure 7 is a schematic diagram showing components of the payment terminal , the mobile device and the TnC platform including the platform gateway shown hi Figure 6, and the corresponding layers of interaction, in accordance with the first embodiment:

Figure 8 is a flow chart showing a process, performed by the payment terminal , of establishing the secure comimmieation channel drown in Figure 6, in accordance with the first embodiment;

Figure 9 is a flow chart showing the process, performed by the payment terminal, of foe receiving and establishing steps shown in Figure 8 in further detail , for embodiments where the handover token (HT) comprises a mobile device public key (QE);

Figure 10 is a flow chart showing the process, performed by the payment terminal, of the receiving and establishing steps shawm in Figure 8 in further detail, for embodiments where the handover token (HT) comprises a mobile device secret key (K):

Figure 11 is a flow chart showing a process, performed by the platform gateway, of establishing the secure communication channel show'll in Figure 6, in correspondence with the "first embodiment;

Figure 12 is a sequence diagr am showing foe events occurring between the EMV device, the payment terminal, the platform gateway and the mobile device in establishing the secure communication channel shown in Figures 6 and 7, in accordance with the first embodiment;

Figure 13 is a sequence diagram showing the events occurring between the payment terminal, foe platform gateway and the mobile device in establishing foe secure cominnnication channel shown in Figures 6 and 7, for embodiments in which the handover token (HT) comprises an endpoint public key (QE);

Figure 14 is a sequence diagram showing the events occurring between foe payment terminal, the platform gateway and the mobile device in establishing the secure communication channel shown in Figures 6 and 7, for embodiments in which the handover token (FIT) comprises a mobile device secret key (K);

Figure 15 is a schematic diagram showing a payment terminal, a mobile device, a platform gateway and a service provider, alongside a physical layer and a security layer connecting the four entities, wherein the security layer includes a secure communication channel between the paymentterminal and the service provider, and between the mobile device -and the sendee provider, in accordance with a second embodiment of the present disclosure;

Figure 16 is a schematic diagram showing components of thepayment terminal, the mobile device and the platform gateway shown inFigure 15, and the corresponding layers of interaction, in accordance with the second embodiment;

Figure 17 is a flow chart showing a process, performed by the payment terminal, of establishing the secure communicationchannel between the payment ierminal and the service provider as shown in Figures 15 and 16, in accordance with the second embodiment;

Figure 18 is a flow chart showing a process, performed by the mobile device, of establishing the secure communication channel between the mobile device and the service provider as shown in Figures 15 and 16, in accordance with the second embodiment;

Figure 19 is a sequence diagram showing the events occurring between the payment terminal or the mobile device, the platform gateway and the sendee provider in establishing the secure communication channel shown in Figures 15 and 16, in accordance with the second embodiment; and

Figure 20 is a sequence diagram showing the events occurring between the payment terminal or the mobile device, the platform gateway and the service provider in establishing the secure communication channel shown in Figures 15 and 16, where the handover token (FIT) comprises an endpoint public, key (QE), in accordance with the second embodiment.

DETAILED DESCRIPTION

The present disclosure relates to a computer-implemented method for establishing a communication channel for exchanging messages securely, also called a secure communication channel, between an initiator device and an endpoint device using an intermediary server. Aspects of the disclosure include a computing device adapted to perform the method as outlined in any of the disclosed embodiments. Prather aspects of the disclosure include a computer program product and a computer- readable storage medium comprising instructions which cause a computer to perform the method as outlined in any of the disclosed embodiments.

It should be noted that the term ‘commimieatioii channel’., ‘secure communication channel’ and ‘secure channel’ may be used interchangeably throughout the specification. The terms ‘physical card’, ‘payment card’ and ‘physical payment card’ may also be used interchangeablythroughout the specification.

The secure communication channel can be established between different entities. The term initiator device’ represents the entity that initiates establishment of the secure communication channel and the term ‘endpoint device’ represents the entity with which the secure communication channel is established. For example, a secure communicationchannel may be established between a payment terminal (initiator device) and a mobile device (endpoint device). As another example, a secure communication channel may be -established between a mobile device (initiator device) and aservice provider (endpoint device) . As a further example, a secure communication channel may be established between a payment terminal (initiator device) and a service provider (endpoint device).

The term mobile device may be used synonymously herein with ‘mobile cellular telecommunications handset' or ‘mobile phone’ or ‘smartphone’.

General and specific embodiments of the disclosure will be described below with reference to Figures 1 to 20.

Figure la shows an initiator device 102, an endpoint device 104 and an intermediary server 106 in communication with one another where the communication is provided by a physical layer 108. The physical layer 108 comprises a cloud-based communication between the initiator device 102 and the intermediary server 106, between the endpoint device 104 and the intermediary server 106, and between the initiator device 102 and the endpoint device 1.04 via the intermediary server 106. The physical layer 108 also comprises a P2P communication between the initiator device 102 and the endpoint device 104.

The secure communication channel forms part of a securi ty layer or security protocol which exists alongside the physical layer 108. Accordingly, Figure lb shows the initiator device 102, the endpoint device 104 and the intermediary server 106 with the security layer 110 in addition to the physical lay er 108. The security layer 110 includes a secure communication channel 112 a, 112b between the initiator device 102 and the endpoint device 104.

The _, security layer 110 further comprises a Transport Layer Security (TLS) protocol connection between the endpoint device 104 and the intermediary server 106, and between the initiator device 102 and the intermediary server 106. The TLS protocol based on public key cryptography enables the communications between these entities to be encrypted topf event eavesdropping and tampering.

The secure communication channel 112a, 112b may comprise a wireless connection or a wired connection. The secure communication channel may be implemented directly between the initiator device 102 and the endpoint device 104, using a direct secure communication channel 11.2a. Alternatively., the secure communication channel may be implemented indirectly between the initiator device 102 and the endpoint device 104, using an indirect secure communication channel 112b. The intermediary server establishes the cloud-based connection betweeninitiator device 102 and endpoint device 104. Both entities connect independently to the intermediary server using the same channel identifier (UUID ), and the intermediary server connects the two entities using a conduit service that is provided in connection with the intermediary server.

The secure communication channel 112a, 112b enables messages to be exchanged securely between the initiator device 102 and an endpoint device 104, such that a wireless transaction can be performed.

Processes involved in establishing the secure comnmnication channel 112a, 112b will now be describedwith reference to Figures 2 to 5, in accordance with embodiments of the present disclosure.

Figure 2 shows a method performed by the initiator device 102 in establishing the secure communication channel. Firstly, the initiator device 102 sends, at Step 202, a request for a handover token (FIT) to the intermediary server 106. The handover token (HT) comprises data that has been generated at the endpoint device 104 and is configured to be used in setting up the secure communication channel between the initiator device 102 and the endpoint device 104, Next, the initiator device 102 receives, at Step 204, the handover token (HT) from the intermediary server 106. Then, the initiator device 102 establishes, at. Step 206, using the handover token (HT), the secure communication channel between the initiator device 102 and the endpoint device 104. Steps 204 and 206. in combination referred to as Collective Step 205, are described in further detail below with reference to Figures 3 and 4.

In Figure 3, Collective Step 205 of the method performed by the initiator device 102 is shown in further detail lor embodiments in which the handover token (HT) comprises an endpoint public key (QE), the endpoint public key (QE) being a public key which has been generated at the endpoint device 104. Collective Step 205 involves receiving the handover token (HT) from the intermediary server 106 and establishing a secure communication channel 11.2a, 112b between the initiator device 102 and the endpoint device 104 using the handover token (HT).

The initiator device 102 receives, at Step 302, the handover token (HT) from the intermediary sewer 106 whereby the handover token (HT) comprises a public key (QE), also called an endpoint public key (QE), of an endpoint cryptographic key pair (dE, QE). Step 302 thereby provides an example of Step 204 of Figure 2. The endpoint cryptographic key pair (dE, QE) comprises a private key (dE) and a public key (QE). The endpoint cryptographic key pair (dE, QE) has been generated at the endpoint device 104.

The initiator device 102 genera tes, a t Step 304, an initiator device cryptographic key pair (dl, QI), comprising a private key (dl) and a public key (QI). The initiator device then computes, at Step 306, a shared secret (z) using the private key (dl) of the initiator device cryptographic key pair and the public key (QE) received from the intermediary sewer 106. The initiator device 102 then derives, at Step 308, a session key (SK) from the shared secret (z).

Next, the initiator device 102 sends, at Step 310, the public key (QI) of the initiator device cryptographic key pair (dl, QI) to the endpoint device for generation of the same session key (SK). The initiator device 102 then establishes, at Step 312, using the session key (SK), the secure communication channel 112a, 112b between the initiator device 102 and the midpoint device 104. Step 312 thereby provides an example of Step 206 of Figure 2.

In Figure 4, Collective Step 205 of the method performed by the initiator device 102 is shown in further detail for embodiments in which the handover token (HT) comprises an endpoint secret key (K). Collective Step 205 involves receiving the handover token (HT) from the intermediary server 106 and establishing a secure communication channel 112a, 112b between the initiator device 102 and the endpoint device 104 using the handover token (HT). The initiator device 102 receives, at Step 402, the handover token (HT) from the intermediary server 106 whereby fee handover token (HT) comprises a secret key (K) also called an endpoint secret key, which has been generated at the endpoint device 104.

The initiator device 102 generates, as Step 404, an initiator device cryptographic key pair (dl, QI), comprising a private key (dl) and a public key (QI). The initiator, device 102 sends, at Step 406, the public key (QI) of the initiator device cryptographic key pair (dl, QI) to the endpoint device 104 for generation of fee session key (SK). Next, fee initiator device 102 receives, at Step 408, a public key (QE) of an endpoint cryptographic key pair (dE, QE) from the endpoint device 104, whereby the endpoint cryptographic key pair (dE, QE) comprises a private key (dE) and a pub lie key (QE) and has been generated at the endpoint device 104.

Once the initiator device 102 has received the public key (QE), fee initiator device 102 computes, at Step 410, a shared secret (z) using the private key (dl) of the initiator device cryptographic key pah and the public key (QE) received from the endpoint device 104. The initiator device 102 then derives, at Step 412, a session key (SK) from the shared secret (z) using the secret key (K.). Once the initiator device 102 has derived the session key (SK), the initiator device 102 uses the session key (SK) to establish, at Step 414, the secure communication channel 112a, 112b between fee initiator device 102 and fee endpoint device 104.

Figure 5 shows a method performed by fee intermediary server 106 in establishing the secure communication channel 112a, 112b. Firstly, the intermediary server 106 receives, at Step 502, a request for a handover token (HT) from fee initiator device 102. The requested handover token (FIT) comprises data feat has been generated at the endpoint device 104 and is configured to be used in setting up the secure communication channel 112a, 112b between the initiator device. 102 and the endpoint device 104. Next, the intermediary server 106 sends, at Step 504, fee handover token (HT) to fee initiator device 102 for establishing the secure communication channel 112a, 112b betweenthe initiator device 102 and the endpoint device 104.

The security of the secure communication channel 112a, 112b is thus based on a novel security using ECDHE with the above described Handover Token mechanisms. Specific embodiments of the disclosure will now be described with reference to Figures 6 to 20.

Figures 6 to 14, along with the accompanying description below, illustrate embodiments of the disclosure involvingestablishment of a secure communieaton channel between a payment terminal and a mobile device.

Tire mobile device may be a smartphone or another type of mobile computing device such as a tablet or a connected watch. The mobile computing device has cellular telecommunications capabilities along with some other form of wireless data connection. such as a Wi-Fi or Bluetooth connection. In general a mobile device comprising the following hardware elements are suitable for use with embodiments of the present disclosure. The mobile device may have a display providing, for example, a touchscreen user interface. The mobile device may be equipped with a remote wireless telecommunications apparatus comprising a remote transmitter/receiver for communication with a wireless telecommunications network. The mobile device may also equip with a local wireless telecommunications apparatus comprising a local hansmitter/receiver tor communication with a local transaction device such as a payment terminal. For example, the local transmiter/reeeiver may comprise an NFC receiver and an NFC transmitter for receiving and transmitting data to and from the mobile device to a local device. The mobile device further comprises a processor and a memory device.

A payment terminal 602, a mobile device 604 and a platform gateway 606 are used as examples of the initiator device 102 , the endpoint device 104 and the intermediary server 106, respectively. As shown in Figure 6, a physical layer 608 connects the three entities 602, 604, 606. The physical layer 608 comprises cloud- based communications between the payment terminal 602 and the platform gateway 606, and between the mobile device 604 and the platform gateway 606. The physical layer 608 also comprises a P2P communication between the payment terminal 602 and the mobile device 604.

The system shown in Figure 6 further comprises a security layer 610. The security layer 610 includes a: secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604.

The secure communication channel 612a, 612b enables messages to be exchanged securely between the payment terminal 602 and the mobile device 604.

The secure communication channel 612a, 612bmay comprise a wireless connection or a wired connection, Tire path of the secure communication channel, may incorporate different connection types, e.g, a wired connection and a wireless connection. For example, a wired connection may be used between the payment terminal 602 and the platform gateway 606 as part of the secure communication channel 612b, whilst a wireless Connection may be used between the mobile device 604 and the platform gateway 606.

The secure communication channel may be implemented directly between the payment terminal 602 and the mobile device 604, using a direct secure communication channel 612a. Alternatively, the secure communication channel may be implemented indirectly between the payment terminal 602 and the mobile device 604, using an indirect secure communication channel 612b. The platform gateway 606 establishes the cloud-based connection between payment terminal 602 and mobile device 604. Both entities connect independently to the platform gateway 606 using the same channel identifier (IJUID), and the platform gateway 606 connects the two entities using a conduit service (see Figure 7).

For example, data may transmit between the payment terminal 602 and the mobile device 604; however, the data is kept private and the platform gateway 606 is unable to access this data as it is exchanged through a secure communication channel. The secure communication channel may include a cloud-based communication channel. e.g. using a conduit service at the TnC Platform.

The security layer 610 further comprises a Transport Layer Security (TLS) prot ocol connection between the mobile device 604 and the platform ga teway 606, and between the payment terminal 602 and the platform gateway 606. The TLS protocol enables the communications between these entities to be encrypted to prevent eavesdropping arid tampering.

The system shown in Figure 6 further comprises an EMV layer 614. A transaction device, such as the mobile device 604 or a physical payment card 616, can be used to initiate a payment transaction withThe payment terminal 602, The EMV layer 614 includes an EMV channel between the payment terminal 602 and the mobile device 604, for initiating a payment transaction using the mobile device 604. Alternatively, the EMV layer 614 includes an EMV channel between the payment terminal 602 and the payment card 616, for initiating a payment transaction using the payment card 616. The secure communication channel 612a, 612b provides the following advantages. Once the secure communication channel 612a;, 612b is established, the payment terminal 602 and the mobile device 604 are able to connect in a secure manner. This provides the ability to perform secure -wireless payment transactions and secure wireless services. The seciirity of wireless payment transactions and services is independent from the EMV transaction based on issuer keys. A further advantage is that the entities accessing the platform gateway, namely the payment terminal 602 and the mobile device 604, can be authenticated as part of the TLS session. The system also ensures user privacy during the wireless transactions and services, as well as user privacy when accessing a cloud service. Afurther advantage is that it provides integrity and conditional confidentiality of data exchanged between the payment terminal 602 and the mobile device 604.

Figure 7 shows relevant components of the payinent terminal 602, the mobile device 604 and the platform gateway 606 as well as the above-described interactions in further detail.

Starling with the payment terminal 602, the payment terminal 602 comprises a turnkey (the turnkey handles the wireless transaction at the payment terminal 602), a card reader, an electronic cash register (ECR) and a value-added services (VAS) backend. The mobile device 604 comprises a mobile wallet, which itself includes a payment SDR and a ‘Tap and Connect’ (TnC) SDK. The platform gateway 606 is provided as part of a TnC platform. The TnC platform comprises a conduit service, a notification service, a registration service and a service directory, all of which are in communication with the platform gateway 606.

The physical layer 608 is shown as present in the system architecture of Figure 7, however it is omitted from the diagram for the sake of simplicity. As described above with respect to Figure 6, the physical layer 608 comprises cloud- based communications between the payment terminal 602 and the platform gate-way 606, and between the mobile device 604 and the platform gateway 606. More specifically, the physical layer 608 comprises cloud-based communications between the ECR of the paym.ent terminal 602 and the platform gateway 606, and between the turnkey of the payinent terminal 602 and the - platform gateway 606 Furthermore, the physical: layer 608 comprises a cloud-based communication between the TnC SDK of the mobile device 604 and the platform gateway 606. The physical layer also comprises a P2P communication between the payment terminal 602 and the mobile device 604. More specifically, the physical layer 60S comprises a P2P communication between the turnkey of the payment terminal 602 and the TaC SDK of the mobile device 604.

As can be seen in Figure 7, the secure communication channel 612a, 612b , which is part of the security layer 610, is e stablished b etween the turnkey of the payment terminal 602 and the TnC SDK of the mobile device 604. The indirect secure communication channel 612b is established via the conduit service of the TnC platform.

Transport Layer Security (TLS) protocol connections, which are also part of the security layer 610, are established between the TnC SDK of the mobile device 604 and the platform gateway 606, and between the turnkey of the payment terminal 602 and the platform gateway 606. The TLS protocol connections enable the communications between these entities to be encrypted to prevent eavesdropping and tampering.

The mobile device 604 and the payment card 616 are shown as examples of transaction devices in Figure 7. Transacti on devices can be used to initiate a payment transaction with the payment terminal 602. The EMV layer 614 includes an EMV channel between the card reader of the payment terminal 602 and the payment SDK of the mobile device 604, for initiating a payment transaction using the mobile device 604. The EMV layer 614 also includes an EMV channel between the card reader of the payment terminal 602 and the payment card 616, for initia ting a payment transaction using the payment card 616.

The payment card 616 is capable of performing both contact-based and contactless payment transactions. The payment card 616 comprises a chip for storing card data. The chip is an EMV payment chip and is thereby associated with the EMV chip specifications. The EMV payment chip provides the ability to store confidential information securely, perform processing functions and perform cryptographic processing. The EMV payment chip has installed therein a set of payment card credential data for an account associated with the payment card. The credential data can include, for example, the primary account number, expiration date, and cardholder name, but may extend beyond this to cryptographic keys obtained directly or indirectly from a card issuer and associated with the user account. The chip also has a payment application installed therein, the payment application being adapted to nse the credential data.

In order to initiate the transaction, the payment card 616 interacts with the card reader of the payment terminal 602 using the EMV channel between the card reader of the payment terminal 602 and the payment card 616. The card reader is configured to read the card data fromthe chip of the payment card 616. The card data can be read from the payment card 616 in a contactless manner, namely by bringing the payment card 616 into dose proximity with the card reader of the payment terminal 602. The payment card 616 lurther comprises an antenna and NFC capability for enablingacontactless connection with the card reader. The card data and details of the transaction are then sent to the issuer to authorise the transaction. Alternatively, the card data can be read from the payment card in a. contact-based manner, namely by inserting the payment card into the card reader and reading the card data from the chip (It is noted that whereas contactless transactions are performed with the card reader, wneless transactions are performed with the turnkey). In embodiments where the payment card 616 is used as the transaction device, the mobile device 604 eomprises a digitised version of this payment card 604.

The mobile device 604 as the transaction device is capable of performing contactless payment transactions. The card data is stored within the payment SDK as part of a digitised version of a payment card. The mobile device 604, therefore, comprises a digitised version of the payment card. In order to initiate the transaction, the mobile device 604 interacts with the card reader of the payment terminal 602 using the EMV channel between the card reader of the payment terminal 602 and the payment SDK of the mobile device 604. The card reader is configured to read the card data from the payment SDK of the mobile device 604. The card data is read from the payment SDK of the mobile device 604 in a contactless manner, namely by bringing the mobile device 604 into close proximity with the card reader of the payment, terminal 602. The mobile device 604 comprises an antenna and NFC capability for enabling a contactless connection with the card reader. The card data and details of the transaction are then sent to the issuer to authorise the transaction .

In some embodiments, a third-party wallet comprised within the mobile device 604 may be used to initiate the transaction, where the mobile device 604 is the transaction device. The third-party wallet is a separate entity to the mobile wallet. The third-party wallet may be, for example, a wallet that is provided by a third-party service provider and enables a user to instigate a payment transaction. In this case, the third-party wallet comprises a first digitised version of a payment card for use in the payment transaction. The mobile wallet, which comprises the payment SDK of the mobile device 604, comprises a second digitised version of the payment card. The card data is thus stored within the payment SDK as part of the second digitised version of the payment card. In order to initiate the transaction, the mobile device 604 interacts with/the card reader of the payment terminal 602 using the EMV channel between the card reader of the payment terminal 602 and the third-party Wallet of the mobile device 604. Tire card reader is configured to read the card data from the third-party wallet, which is stored within the third-party wallet as pati of the first digitised versi on of the payment card, of the mobile device 604. The card data is read from the third-party wallet of the mobile device 604 in a contactless manner, namely by bringing the mobile device 604 into close proximity with the card reader of the payment terminal 602, The mobile device 604 comprises an antenna and NFC capability for enabling a contactless connection with the card reader. The card data and details of thetransaction are then sent to the issuer to authorise the transaction.

Additional interactions between entities shown in Figure 7 will now be described. The system further comprises a proprietary layer 618. The proprietary layer 618 includes secure proprietary communication protocols and non-secure proprietary communication protocols. The notification service of the TnC platform is in communication with the mobile wallet of the mobile device 604 via a notification provider, using a proprietary (non -secure) protocol. The registration sendee of the TnC platform is in communication with a digital enablement sendee (MDES) for supporting mobile payments, which is in turn in commimieation with an issuer, both via a secure proprietary protocol. The issuer is in turn communicative with the ECU of the payment terminal 602, via a secure proprietary protocol.

Although not shown in Figure 7, the conduit service of the TnC platform may be in communication with the TnC SDK of the mobile device 604 and with the Turnkey of thepayment terminal 602, using a cloud-based connection.

The secure communication channel 612a, 612b is triggered by a payment transaction between the transaction device (mobile device 604 or payment card 616) and the payment: terminal 602. The process of establishing the secure communication channel 612a, 612b triggered by a payment transaction will now be described with reference to Figures 8 to 11. Figure 8 shows the process performed by the payment terminal 602. Firstly, the payment terminal 602 receives, at Step 802, the payment card identifier (Primary Account Number or PAN), upon initiation of the payment transaction, from the transaction device 604, 616, The payment transaction may be initiated as set out above with reference to Figure 7. The payment terminal 602 then sends, at Step 804, the payment card identifier (FAN) to the platform gateway 606 with a request for a handover token (HT). The requested handover token (HT) corresponds to the mobile device 604 associated to the payment card identifier (PAN). The payment terminal 602 then receives, at Step 806, the handover token (HT) from the platform gateway 606. The received handover token (FIT) corresponds to the mobile device 604 that is associated to the payment card identifier (PAN). Lastly, the payment terminal 602 establishes, at Step 80S, using the received handover token (HT), the secure conunnnicaiion channel between the mobile device 604 and the payment terminal 602. Steps 806 and 808, in combination referred to as Collective Step 805, are described in further: detail below with reference to Figures 9 and 10.

In Figure 9, Collective Step 805 of the method performed by the payment terminal 602 is shown in further detail for embodiments in which the handover token (HT) comprises a mobile device public key (QE). Collective Step 805 involves receiving the handover token (HI) from the platform gateway 606 and establishing a secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604 using the handover token (HT).

The payment terminal 602 receives, at. Step 902, the handover token (HT) from the platform gateway 606 whereby the handover token (HI) comprises a public key (QE) , also called a mobile device public key (QE), of a mobile device cryptographic -key pah (dE, QE). The mobile device cryptographic key pair (dE, QE) comprises a private key (dE) and a public key (QE), which has been generated at the mobile device 604.

The payment terminal 602 generates, at Step 904, an initiator device cryptographic key pair (dl, Qf), comprising a private key (dl) and a public key (QI). The payment terminal 602 then computes, at Step 906, a shared secret (z) using the private key (dE) of the initiator device cryptographic key pair and the public key (QE) received from the platform gateway 606. The payment terminal 602 then derives, at. Step 908, a session key (SK) from the shared secret (z). Next, the payment terminal 602 sends, at Step 910, the public key (QI) of the initiator device cryptographic key pair (dl, QI) to the mobile device 604 tor generation of the same session key (SK). The payment terminal 602 then establishes, at Step 912, using the session key (SK), the secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604.

In Figure 10, Collective Step 805 of the method performed by the payment terminal 602 is shown in further detail for embodiments in which the handover token (HT) comprises a mobile device secret key (K), Collective Step 805 involves receiving the handover token (HT) from the platform gateway 604 and establishing a secure communication channel 612a, 612b between -the payment terminal 602 and the mobile device 604 using the handover token (HT).

The payment terminal 602 receives, at Step 1002, the handover token (HT) from the platform gateway 606 whereby the handover token (HT) comprises a secret key (K) also called a mobile device secret key, which has been generated at the mobile device 604.

The payment terminal 602 generates, as Step 1004, an initiator device cryptographic key pair (dl. QI), comprising a private key (dl) and a public key (QI). The payment terminal 602 then sends, at Step 1006, the public key (QI) of the initiator device cryptographic key pair (dl, QI) to the mobile device 604 for generation of the session key (SK)· Next, the payment terminal 602 receives, at Step 1008, a public key (QE) of a mobile device cryptographic key pair (dE, QE) from the mobile device 604, whereby the mobile device cryptogr aphic key pair (dE, QE) comprises a private key (dE) and a public key (QE) and has been generated at the mobile device 604,

Once the payment terminal 602 has received the public key (QE), the payment terminal 602 computes, at Step 1010, a shared secret (z) using the private key (dl) of the initiator device cryptographic key pair and the public key (QE) received from the mobile device 604. The payment terminal 602 then derives, at Step 1012, a session key (SK) from the shared secret (z) using the secret key (K). Once the payment terminal 602 has derived the session key (SK), the payment terminal 602 uses the session key (SK) to establish, at Step 1014, the secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604.

Figure 11 shows a method performed by the platform gateway 606 in establishing the secure communication channel 612a, 612b. Firstly, the platform gateway 606 receives, at Step 1102, a request for a handover token (HT) from the payment terminal 602. The requested handover token (HT) comprises data that has been generated at the mobile device 604 and is configured to be used in setting up the secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604. Next, the platform gateway 606 sends, at Step 1104. the handover token (HT) to the payment terminal 602 for establishing the secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604.

Further details of how the secure communication channel 612a , 612b is established during a payment transaction will now be outlined with reference to Figures 12 to 14.

Figure 12 is a sequence diagram showing the events occurring between the transaction device 604, 616, which is also called the EMV device, the payment terminal 602, the platform gateway 606 and the mobile device 604, in establishing the secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604. The payment terminal 602 andthe mobile device 604 are used as examples of the initiator device 102 and the endpoint device 104, respectively. Firstly, an EMV transaction 1202 is performed between the EMV device 604, 616 and the payment terminal 602. A first TLS session is established between the payment terminal 602 and the platform gateway 606, and a second TLS session is established between the platform gateway 606 and the mobile device 604.

The payment terminal 602 submits, at Event 1204a, the request for a liaiidover token (HT) to the platform gateway 606 using the first TLS session between the payment terminal 602 and the platform gateway 606. The handover token (FIT) request is then submitted, at Event 1204b, from the platform gateway 606 to the mobile device 604 using the second TLS session between the platform gateway 606 and the mobile device 604, The handover token (HT) is then shared, at Event 1206a, from the mobile device 604 to the platform gateway 606, using the second TLS session, and then shared, at Event 1206b, from the platform gateway 606 to the payment terminal 602, using the first TLS session. As part of the request, a wireless connection 1208 is established between the payment terminal 602 and the mobile device 604, comprised within the physical layer 608.

Once the payment terminal 602 is in possession of the handover token (FIT), it performs a method called "Key Agreement’ 1201. Key Agreement 1201 is the process of using the handover token (HT) to establish the secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604.

The secure communication channel 61:2a, 612b, which is referred to in Figure 12 as ‘Data. Encryption’ 1203, is thereby established. The secure communication channel 612a , 612b forms pail of the security layer 610. The secure communication channel 612a, 612b may be wireless, or part of the secure communication channel may be wired, e.g, between the payment terminal 602 and the platform gateway 606.

The established secure communication channel 612a, 612b is independent of the wireless connection that forms part of the physical layer 608. In addition. the established secure communication channel 612a, 612b is independent of the EMV layer 614 comprising the EMV channels for the EMV transaction 1202. Furthermore, the established secure communication channel 612a, 612b is independent of the proprietary layer 618 shown in Figure 7. Moreover, within the security layer 610. the established secure communication channel 612a, 612b is independent of the TLS sessions.

Figures 13 and 14 show the events shown in Figure 12 in further detail in respect of transmission of the payment card identifier (PAN). The events occurring as part of the simplified EMV transaction 1202 between the EMV device 604, 616 and the payment terminal 602 are shown first. This involves the user tapping or dipping the EMV device 604, 616 on the payment terminal 602, followed by the payment terminal 602 submitting the payment data (pData) to the EMV device 604, 616, and then the EMV device 604, 616 returning the PAN from the EMV device 604, 616 to the payment terminal 602.

Next, the events occurring as part of the request (Events 1204a, 1204b) for the handover token (HT) from the payment terminal 602, via the platform gateway 606. to the mobile device 604, are described.

As part of the request (Events 1204a, 1204b), the payment terminal 602 generates a unique identifier (UUID) to represent the communication channel, and sends the PAN and UUID to the platform gateway 606. The platform gateway 606 retrieves the mobile identifier (mobilelD) conesponding to the PAN and sends the UUID to the mobile device 604 identified by the mobilelD. Alternatively, if the EMV device 604. 616 is the mobile device 604, the UIJID is generated by the mobile device 604 returning the UIJID to the payment terminal 602 along with the PAN.

As shown in Figures 13 and 14, the payment terminal 602 submits, at Event 1204a, the request for a handover token (FIT) to the platform gateway 606 using the first TLS session between the payment terminal 602 and the platform gateway 606. The handover token (HT) request is then submitted, at Event 1204b, from the platform gateway 606 to the mobile device 604 using the second TLS session between the platform gateway 606 and the mobile device 604.

As part of the request (Events 1204a, 1204b), a wireless connection

1208 is established between the payment terminal 602 and the mobile device 604, comprised within the physical layer 608. The wireless connection 1208 may be a cloud-based connection or a P2P connection. The wireless connection 1208 may be established as soon as the payment terminal 602 and the mobile device 604 shared the UUID.

The events occurring between the EMV device 604, 616, payment terminal 602, the platform gateway 606 and the mobile device 604 in establishing the secure communications channel between the payment terminal 602 and the mobile device 604 are shown for embodiments in which foe handover token (HT) comprises a mobile device public key (QE) in Figure 13. Accordingly, events corresponding to the process steps shown in Figure 9 are shown in Figure 13, alongside the events shown in Figure 12, in further detail.

The mobile device 604 generates, at Event 1209, a mobile device cryptographic- key pair (dE, QE), wherein the mobile device cryptographic key pair (dE, QE) comprises a mobile device private key (dE) and a mobile device public key (QE). The mobile device private key (dE) may comprise a random number. The mobile device 604 stores the private key (dE), The mobile device 604 may also store the public key (QE). The mobile device 604 then sends, at Event 1206a, the mobile device public key (QE) to the platform gateway 606 using the second TLS session, wherein the mobile device public key (QE) corresponds to the mobilelD. The platform gateway 606 stores the mobile device public key (QE) and sends, at Event 1206b, the mobile device public key (QE) to the payment terminal 602 using the first TLS session. The mobile device public key (QE) is comprised within the handover token (1 IT). Key Agreement 1201 is the process of using the handover token (HT) to establish the secure communication channel 612a, 612b. Key Agreement 1201 includes Events 1214 to 1218 and is described in further detail below.

The payment terminal 602 generates, at Event 1214, an initiator device cryptographic key pair (dl, QI), comprising a private key (dl) and a public key (QI), and then computes a shared secret (z) using the private key (dl) of the initiator device cryptographic key pair and the public key (QE) received from the platform gateway 606. The payment terminal 602 then derives a. session key (SK) from the shared secret (z).

The payment terminal 602 then sends, at Event 1216, the public key (QI) of the initiator device cryptographic key pair (dl, QI) to the mobile device 604 for generation of the same session key (SK). After receiving the public key (QI) of the initiator device cryptographic key pair (dl, QI), the mobile device 604 computes, at Event 1218, a shared secret (z) using the stored private key (rlE) of the mobile device cryptographic key pair (dE, QE) and the public key (QI) received from the payment terminal 602. The mobile device 604 then derives a session key (SK) from the shared secret (z) computed at the mobile device 604.

When data are encrypted with SK using an encryption -authentication algorithm (e.g. AES-GCM), this provides authentication of the payment terminal 602 to the mobile device 604, and simultaneously provides authentication of the mobile device 604 to the payment terminal 602. In other words, mutual authentication is performed between the payment terminal 602 and the mobile device 604. The secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604 is thus established ('Data Encryption ' 1203, as shown in Figure 13).

Turning to Figure 14, the events occurring between the EMV device 604, 616, payment terminal 602, the platform gateway 606 and the mobile device 604 in establishing; the secure communication channel between the payment terminal 602 and the mobile device 604 are shown tor embodiments in which the handover token (HT) comprises a mobile device secret key (K). Accordingly, events corresponding to the process steps shown in Figure 10 are shown in Figure 14, alongside events shown in Figure 12, ih further detail.

The mobile device 604 generates, at Event 1211, a mobile device secret key (K). The mobile device secret key (K) may comprise a random number.

The mobile device 604 stores the mobile device secret key (K). The mobile device 604 the» sends, at Event 1206a, the mobile device secret key (K) to the platform gateway 606 using the second TLS session. The platform gateway 606 stores the mobile device secret key (K) with the corresponding mobile ID, and sends, at Event 1206b, the mobile device secret key (K) to the payment terminal 602 using the first TLS session. The handover token (HT) comprises the mobile device secret key (K).

Next, at Event 1217, file payment terminal 602 generates an initiator device cryptographic key pair (dl, QI), compri sing a private key (dl) and a public key (QI). The payment terminal 602 then sends, at Event 1219, the public key (QI) of the initiator device cryptographic key pair (dl, QI) to the mobile device 604 for generation of a session key (SK).

At Event 1221, the mobile device 604 generates a mobile device cryptographic key pair (dE , QE), wherein the mobile device cryptographic· key pair (dE, QE) comprises a mobile device private key (dE) and a mobile device public key (QE). The mobile device 604 then compotes a shared secret (z) using the generated private key (dE) of the mobile device cryptographic key pair (dE, QE) and the public key (QI) received from the payment terminal 602. The mobile device 604 then derives a sessi on key (SK) from the shared secret (z) computed at the mobile device 604 and the stored mobile device secret key (K).

The mobile device 604 then sends, Event 1223, the mobile device public key (QE) to the payment terminal 602. After receiving the mobile device public key (QE), the payment terminal 602 computes, at Event 1225, a shared secret (z) using the private key (dl) of the initiator device cryptographic key pair (dl, QI) and the received mobile device public key (QE). The payment terminal 602 also derives a session key (SK) from the shared secret (z) computed at the mobile device 604 and the mobile device secret key (K).

When data are encrypted with SK using an encryption-authentication algorithm. (e,g. AES-GCM), this provides authentication of the payment terminal 602 to the mobile device 604, and simultaneously provides authentication of the mobile device 604 to the payment terminal 602. In other words, mutual authentication is performed between the payment terminal 602 and the mobile device 604. The secure communication channel 612a, 612b between the payment terminal 602 and the mobile device 604 is thus established ((Data Encryption" 1203, as shown in Figure 14). Key Agreement 1201 is the process of using the handover token (HT) to establish the secure communication channel 612a, 612b. In the present embodiment(figure 14), Key Agreement 1201 includes Events 1217 to 1225.

The secure communication channel 612a, 612b, once established, can then be used to continue a transaction wirelessly, i.e. a wireless transaction, if required. For example, a secure wireless transaction could be performed for a new amount, or a new payment card, or a different digitised payment card in the mobile wallet. The secure communication channel 612», 612b can also be used to send messages securely between the merchant and the mobile device, e.g. VAS messages.

Figures 15 to 20, along with the accompanying description below, illustrate embodiments of the disclosure involving establishment of a terminal service’ secure communication channel between a payment terminal and a service provider; and/or a 7 mobile-service secure communication channel between a mobile device and a service provider.

A payment terminal 1702, or a mobile device 1704, is used as an example of the initiator device 102. A service provider 1709 is used as an example of the endpoint device 104. A platform gateway 1706 is used as an example of the intermediary server 106.

As shown in Figure 15, a physical layer 1708 connects the four entities 1702, 1704, 1706, 1709. The physical layer 1708 comprises cloud-based communication between the payment terminal 1702 and the platform gateway 1706, aid between the mobile device 1704 and the platform gateway 1706. The physical layer 1708 further comprises cloud-based communications between the platform gateway 1706 and the service provider 1709, and between Pre payment terminal 1702 and the service provider 1709. The physical layer 1708 also comprises a P2P communication between the payment terminal 1702 and the mobile device 1704.

The system shown in Figure 15 "further comprises a "security layer 1710. The security layer 1710 includes a terminal-service secure communication channel 1712 a between the payment terminal 1702 and the service provider 1709. The security layer 1710 further comprises a mobile-service secure communication channel 1712b between the mobile device 1704 and the sendee provider 1709.

The secure communication channels 1712a, 1712b enable messages to be exchanged securely between the payment terminal 1702 and the service provider 1709, and between the mobile device 1704 and the service provider 1709, respectively. The secure communication channels 1712a, 1712b may comprise a wireless connection or a wired connection.

The secure communication channel is implemented directly between the payment terminal 1702 and the service provider 1709, or between the mobile device 1704 and the service provider 1709, using a direct secure communication channel, Alternatively, file secure communication channel may be implemented indirectly via the platform gateway 1706.

The security layer 1710 further comprises a Transport Layer Security (TLS) protocol connection between the mobile device 1704 and the platform gateway 1706, and between the payment terminal 1702 and the platform gateway 1706. The security layer 1710 further comprises a Transport Layer Security (TLS) protocol connection between the platform gateway 1706 and the service provider 1709. The TLS protocol enables the communications between these entities to be encrypted in order to prevent eavesdropping and tampering.

The secure communication channels 1712a, 1712b provides the following advantages. Once the secure commtmicafioii channels 1712a, 1712b are established, the payment terminal 1702 and the service provider 1709 are able to connect in a secure manner, and the mobile device 1704 and the service provider 1709 are able to connect in a secure manner.

This provides the ability to the payment terminal 1702 or the mobile device 1704 to access services provided by the service provider via a secure connection. A further advantage is that the entities accessing the platform gateway, namely the payment terminal 1702, the mobile device 1704 and the service provider 1709 can be authenticated. The system also ensures user privacy during the wirelessservice access, as well as user privacy when accessing a cloud service. A further advantage is that it provides integrity and conditional confidentiality· of data exchanged between the payment terminal 1702 and the service provider 1709, and between the mobile device 1704 and the service provider 1709.

Figure 16 shows relevant components of file payment terminal 1702, the mobile device 1704 and the platform gateway 1706 as well as the above-described interactions in further detail. The service provider 1709 is also shown in Figure 16.

Starting with the payment terminal 1702, the payment terminal 1702 comprises a turnkey, a card reader, an electronic cash register (ECR) and a value- added services (VAS) backend. The mobile device 1704 comprises a mobile wallet, which itself includes a payment SDK and a 'Tap and Connect’ (TnC) SDK. The platform gateway 1706 is provided as part of a TnC platform. The TnC platform comprises a conduit service, a notification sendee, a registration service and a service directory, all of which are in communication with the platform gateway 1706.

The physical layer 1708 is shown as present in the system architecture of Figure 16, however it is omitted from the diagram for the sake of simplicity. The physical layer 1708 comprises cloud-based cpnimimications between the ECR of the payment terminal 1702 and the platform gateway 1706. The physical layer 1708 further comprises cloud-based communications between the TnC SDK of the mobile device 1704 and the platform gateway 1706. The physical layer 1708 further comprises cloud-based communications between the platform gateway 1706 and the sendee provider 1709, and between the ECR of the payment, terminal 1702 and the service provider 1709.

As can he seen in Figure 16, the mobile-service secure communication channel 1712b, which is part of the security layer 1710, is established between the TnC SDK of the mobile device 1704 and the sendee provider 1709. The terminal- service secure communication channel 1712a, which is pari of the securitylayer 1710. is established between the ECR of the payment terminal 1702 and the service provider 1709.

Transport Laver Security (TLS) protocol connections, which are also part of the security layer 1710, are established between the TnC SDK of the mobile device 1704 and the platform gateway 1706, and between the ECR of the pa yment terminal 1702 and the platform gateway 1706. A further Transport Layer Security (TLS) protocol connection is provided between the platform gateway 1706 and tlieservice provider 1709. The TLS protocol connections enable the communications between these entities to be encrypted to prevent eavesdropping and tampering.

The process of establishing the secure communication channels 1712a, 1712b will now be described with reference to Figures 17 and 18.

Figure 17 shows the process performed by the payment terminal 1702 in establishing the terminal-service secure communication channel 1712a. Firstly, the payment terminal 1702 sends, at Step 1902, a request for a handover token (HT) to the service provider 1709. The payment terminal 1702 then receives, at S tep 1904, -the handover token (HT) from the service provider 1709. Lastly, the payment terminal 1702 establishes, at Step 1906, using the received handover token (HT), the terminal- service secure communication channel 1712a between the payment terminal 1702 and the service provider 1709. Collective Step 1905, which comprises Steps 1904 and 1906, is analogous to Collective Step 205 of Figure 2, where the payment terminal 1702 is the initiator device 102 and the service provider is the endpoint device 104. Accordingly, in some embodiments. Collective Step 1905 involves the handover token (HT) comprising an endpoint public key (QE), whereas in other embodiments, Collective Step 1905 involves the handover token (FIT) comprising an endpoint secret key (K). Therefore, Collective Step 1905 can be expanded into process steps that are analogous to the expansion of Collective Step 205, namely Steps 302 to 312 of Figure 3 and Steps 402 to 414 of Figure 4, and the corresponding description provided above with reference to Figures 2 to 4 applies in embodiments to which Figure 17 relates.

Figure 18 shows the process performed by the mobile device 1704 in establishing the mobile-service secure communication channel 1712b. Firstly, the mobile device 1704 sends, at Step 2002, a request for a handover token (HT) to the service provider 1709. Tire mobile device 1704 then receives, at Step 2004, the handover token (HT) from the sendee provider 1709. Lastly, the mobile device 1704 establishes, at Step 2006, using the received handover token (HT), the mobile-service secure communication channel 1712b between the mobile device 1704 and the service provider 1709. Collective Step 2005, which comprises Steps 2004 and 2006, is analogous to Collective Step 205 of Figure 2, where the mobile device 1704 is the initiator device 102 and the service provider is the endpoint device 104. Accordingly, in some embodiments. Collective Step 2005 involves the handover token (HT) comprising an endpoint public key (QE), whereas in other embodiments, Collecti ve Step 2005 involves the handover token (HT) comprising an endpoint secret key (K). Therefore, Collective Step 2005 can be expanded into process steps that are analogous to the expansion of Collective Step 205, namely Steps 302 to 312 of Figure 3 and Steps 402 to 414 of Figure 4, and the corresponding description provided above with reference to Figures 2 to 4 applies in embodiments to which Figure IS relates.

It should be noted that the methods performed by the service provider 1709 in establishing the terminal-sendee secure communication channel 1712a and the mobile-service secure communication channel 1712b are also analogous to the process shown in Figure Tl. The service provider 1709 receives a request for a handover token (HT) from the payment terminal 1702 (for establishing the terminal- service channel 1712a) or from the mobile device 1704 (for establishing the mobile- service channel 1712b). The requested handover token (HT) comprises data that is configured to be used in setting up the secure communication channels 1712a, 1712b. The service provider 1709 then sends the handover token (HT) to the payment terminal 1702 (for establishing the terminal-service channel 1712a) or mobile device 1704 (for establishing the mobile-service channel 1712b) for establishing the secure communication channels 1712a, 1712b,

Further details of how the secure communication channels 1712a, 1712b are established will now be outlined with reference to Figures 19 and 20.

Figure 19 is a sequence diagram showing the events occurring between the payment terminal 1702 or the mobile device 1704, the platform gateway 1706 and the sendee provider 1709, in establishing the secure communication channels 1712a,

1712b. A first TLS session is established between the payment terminal 1702 or the mobile device 1704 and the platform gateway 1706, and a second TLS session is establislied between the platform gateway 1706 and the service provider 1709.

The payment terminal 1702 or the mobile device 1704 submits _* at Event 2104a, the request for a handover token (HT) to the platform gateway 1706 using the first TLS session between the payment terminal 1702 or the mobile device 1704 and the platform gateway 1706. The handover token (HT) request is then submitted, at Event 2104b, from the platform gateway 1706 to the service provider 1709 using the second TLS session between the platform gateway 1706: and the service provider 1709. The handover token (HT) is then shared, at Event2106a, from the service provider 1709 to the platform gateway 1706, using the second TLS session, and then shared, at Event 2106b, from the platform gateway 1706 to the payment terminal 1702 or the mobile device 1704, using the first TLS session. As part of the request, a service connection 2108 is established between the payment terminal 1702 or the mobile device 1704 and the service provider 1709, comprised within the physical layer 1708.

Once the payment terminal 1702 or the mobile device 1704 is in possession of the handover token (HT), it performs amethod called Key Agreement 2101. Key Agreement 2101 is the process of using the handover token (HT) to establish the secure communication channels 1712a, 1712b.

The secure communication channels 1712a, 1712b, which is -referred to in Figure 19 as ‘Data Encryption’ 2103, are thereby established. The secure communication channels 1712a, 1712b forms part of the security layer 1710. The secure communication channels 1712a, 1712b may be wireless or wired

The established secure communication channels 1712a, 1712b are independent, of the wireless connection that forms part of the physical layer 1708. Furthermore, within the security layer 171:0, the established secure communication channels 1712a, 1712b are independent ofthe TLS sessions.

Turning to Figure 20, the events occurring between the payment terminal 1702 or the mobile device 1704, the platform gateway 1706 and the service provider 1709 in establishing the secure communication channel is shown for embodiments in which the handover token (HT) comprises a sendee public key (QE). Accordingly, events corresponding to the steps shown in Figures 17 to 19 are shown in further detail.

As shown in Figure 20, the payment : terminal 1702 or the mobile device 1704 submits, at Event 2104a, the request for a handover token (HT) to the platform gateway 1706 using the first TLS session. The handover token (HT) request comprises a sendee identifier (s ervice ID) to indicate which service provider 1709 the handover token (HT) request relates to. The platform gateway 1706 retrieves the sendee provider URL (serviceURL) and the handover token (HT) request is then submitted, at Event 2104b, from the platform gateway 1706 to the sendee provider 1709 using the second TLS session.

The service provider 1709 generates, at Event 2109, a sendee cryptographic key pair (dE, QE), wherein the sendee provider cryptographic key pair" (dE, QE) comprises a service private, key (dE) and a sendee public key (QE). The sendee provider 1709 then sends, at Event 2106a, the sendee public key (QE) to the platform gateway 1706 using the second TLS session. The platform gateway 1706 then sends, at Event 2106b, the sendee public key (QE) along with the servieeURL to the payment terminal 1702 or the mobile device 1704 using the first TLS session.

As pail of the request (Events 2104a, 2104b), a sendee connection 2108 is established between the payment terminal 1702 orthe mobile device 1704 and the sendee provider 1709, comprised wi thin the physical layer 1708. The wireless connection 2108 is a doud-based connection. The wireless connection 2108 may be established as soon as thepayment terminal 1702 or the mobile device 1704 received the servieeURL. Key Agreement 2101 is the process of using the handover token (HT) to establish the secure communication channels 1712a, 1712b. Key Agreement2:101 includes Events 2114 to 2118 and is described in further detail below.

The payment terminal 1702 or the mobile device 1704, at Event 2114, generates an initiator device cryptographic key pair (dl, QI), comprising a private key (dl) and a public key (QI), and then computes a shared secret (z) using the private key (dl) of the initiator device, cryptographic key pair and the public key (QE) recei ved from the platform gateway 1706. The payment terminal 1702 or the mobile device 1704 then derives a session key (SK) from the shared secret (z).

The payment terminal 1702 or the mobile device 1704 may connect, at Event 2108, to the service provider 1709 using the serviceURL in a cloud-based connection or ‘Service Connection’ as shown in Figure 20.

The payment terminal 1702 or the mobile device 1704 then sends, at Event 2116, the public key (QI) of the initiator device cryptographic key pair (dl, QI) to the service provider 1709 tor generation of the same session key (SK).

After receiving the public key (QI) of the initiator device cryptographic key pair (dl, QI), the service; provider 1709 computes, ai Event 2118, a shared secret (z) using the stored private key (dE) of the mobile device cryptographic _· key pair (dE, QE) and the public key (QI) received "from the payment terminal 1702 or the mobile device 1704. The service provider 1709 then derives a session key (SK) from the shared secret (z) computed at the service provider 1709.

"When dataare encrypted with SK using an encryption-authentication algorithm (e.g. AES-GCM), this provides authentication of the payment terminal 1702 or the mobile device 1704 to the sendee provider 1709, and simultaneously provides authentication of the service provider 1709 to prepayment terminal 1702 or the mobile, device 1704. In other words, mutual authentication is performed between the payment terminal 1702 or the mobile device 1704 and the service provider 1709.

The secure communication channels 1712a, 1712b between the payment terminal 1702 or the mobile device 1704 and the service provider 1709 are thus established (‘Data Encryption' 2,103, as shown in Figure 20).

For embodiments inWhich the handover token (HT) comprises a mobile device secret key (K), if should be noted that the events occurring between the payment terminal 1702 or the mobile device 1704, theplatform gateway 1706 and the service provider 1709 in establishing the secure communication channels are analogous to the events shown in Figure 14 and the corresponding description above.

After a communication channel for exchanging messages securely between a payment terminal 602, 1702 and a mobile device 604, 1704 has been established, the communication channel can be used to perform a secure wireless transaction, e.g. a wireless paymenttransaction.

Many modifications may be made to the specific embodiments described above without departing from the scope of the invention as defined in the accompanying claims. Fea tures of one embodiment may also be used in o ther embodiments, either as an addition to such embodiment or as a replacement thereof, it is to be understood that a payment card and a mobile device are used in the present disclosure as non-limiting examples of transaction devices . In other embodiments, the transaction device may he an alternative transaction device carrying card data, e.g. tablets or watches.