Patent Description:
Smart devices, such as smart cards, access cards, financial instruments such as payment cards, fobs and most recently mobile telephones and other portable electronic devices are increasingly being used to effect transactions. A transaction may involve a number of functions. In a simple form, a user in possession of a suitable smart device may be granted access through a security door. Alternatively, or in addition, such a user may be able to make payments for goods and services, or to use the smart device in ticketing for access to public transport or an event.

A suitable smart device has a processor and a memory. These may be combined in a secure element, which is a piece of tamper resistant hardware which can only be communicated with in a limited fashion.

In use, the smart device is presented to a terminal of a transaction processing system, for example a door lock, a point of sale device or a ticket barrier. The smart device communicates with the terminal. This communication may be contactless for example using near field communications (NFC), or through contact between the device and the terminal. The smart device may communicate solely with the terminal; however more often data provided by the smart device is transmitted through the transaction processing system to a suitable recipient. This recipient authenticates the smart device and may respond, for example by commanding the terminal to open a door or barrier, or by providing data to the smart device.

To enable a smart device to be used in this manner, the smart device is provided with a device identifier. This may be a number, or alphanumeric string which is capable of uniquely identifying the device and thereby enabling the transaction processing system to determine whether to grant access, or to effect payment, or similar. An example of a suitable device identifier used in payments is a primary account number or PAN, which is used on credit and debit cards to effect payments.

Methods have been proposed to modify or obscure a device identifier during a transaction to increase security. While such proposed systems make it harder for a malicious third party to clone or pretend to be the smart device, such systems still do not obviate a risk that a third party may track a user's movements and activity using data transferred from the device.

The Diffie-Hellman key exchange algorithm (see for example the text book "Applied Cryptography" by Bruce Schneider) allows two parties to generate the same shared secret following the exchange of respective public keys, with the public key for a party being generated based on a private key for that party in accordance with a cyclic group. This shared secret can then be used for symmetric encryption of data communicated between the two parties.

In accordance with at least one embodiment, methods, devices, systems and software are provided for supporting or implementing functionality to transmit and/or process transaction messages.

This is achieved by a combination of features recited in each independent claim. Accordingly, dependent claims prescribe further detailed implementations of various embodiments.

Further features and advantages will become apparent from the following description of preferred embodiments, given by way of example only, which is made with reference to the accompanying drawings.

Systems, apparatuses and methods will now be described as embodiments, by way of example only, with reference to the accompanying figures in which:.

Some parts, components and/or steps of the embodiments appear in more than one Figure; for the sake of clarity the same reference numeral will be used to refer to the same part, component or step in all of the Figures.

<FIG> shows a transaction system <NUM>. A transaction device <NUM>, is provided. Examples of suitable transaction devices include smart cards, access cards, fobs, financial instruments such as payment cards, mobile telephones and other portable electronic devices such as tablets and smart watches. The transaction device <NUM> has a data connection to a transaction terminal <NUM>. Examples of suitable transaction terminals include payment terminals, access points to transit systems, and doors.

The data connection between the transaction device <NUM> and the transaction terminal <NUM> may be contactless. Examples of contactless connection technologies which may be used include near field communications (NFC) and optical systems - the latter being, for example, provided by a system which uses a camera in a mobile telephone to identify and read data presented on e.g. a screen of the terminal. The data connection may alternatively be a contact connection using a suitable arrangement of electrically conductive pads and pins to enable communication.

The transaction terminal <NUM> is connected to a first transaction processing server <NUM>, which is in turn connected to a second transaction processing server <NUM>. Together the terminal <NUM> and servers <NUM> and <NUM> may be considered to constitute a transaction processing system <NUM>. While not shown, one or more additional transaction processing servers may be provided between the transaction terminal <NUM> and first transaction processing server <NUM>. Likewise, one or more additional transaction processing servers may be provided between the first transaction processing server <NUM> and the second transaction processing server <NUM>. Collectively, the transaction terminal <NUM> and any additional transaction processing servers between the transaction terminal <NUM> and first transaction processing server <NUM> may be considered as a first part of the transaction processing system <NUM>. Equally, the second transaction processing server <NUM> and any additional transaction processing servers between the first transaction processing server <NUM> and the second transaction processing server <NUM> may be considered as a second part of the transaction processing system <NUM>.

While only a single instance of each of the device <NUM>, terminal <NUM> and servers <NUM> and <NUM> are shown, it will be appreciated that the transaction system <NUM> may be substantially more complex, with multiple devices <NUM> (representing devices provided to multiple users), multiple terminals <NUM> (representing, for example, multiple payment terminals or access terminals) and even multiple servers <NUM> and <NUM>.

The operation of the transaction system <NUM> shown in <FIG> during a transaction will now be described with reference to <FIG>. In general, in this transaction a transaction device <NUM> is presented to a transaction terminal <NUM>, and the transaction processing system <NUM> operates to authorise or deny the transaction. Depending on whether the transaction is authorised or denied, the transaction terminal, or a device connected thereto, may perform some action (such as opening a door), alternatively or additionally, a message may be sent back to the transaction device. A more detailed description follows.

In a first step <NUM>, a transaction is instigated and the transaction device <NUM> connects to the transaction terminal <NUM>. The instigation of the transaction may, for example, include a user selecting goods or services to purchase, or selecting a destination for a ticketing transaction. This may require user input, or alternatively may be predetermined based on the identity of the transaction terminal - for example an identity of a transaction terminal on a transit system may be used to define the service required without any specific user input.

The connection between the transaction device <NUM> and the transaction terminal <NUM> may be established by the transaction device <NUM> being presented to the terminal and a contactless, e.g. near field communication (NFC), connection being established. Alternatively, a transaction device <NUM> may be physically inserted into or connected to the transaction terminal <NUM> to enable an electrical connection to be established. Such methods are known in the art and need not be described in detail here.

Having, in step <NUM>, instigated the transaction and established the connection transaction data associated with the transaction may be sent, in step <NUM>, from the transaction terminal <NUM> to the transaction device <NUM>. This transaction data may include, for example, a price to be paid in the transaction or an identity of an entry or egress point for a ticketing transaction on a transit system. In general, the nature of the transaction as described above will define the transaction data.

In step <NUM>, the transaction device prepares a transaction message, and in step <NUM> the transaction message is sent to from the transaction device to the transaction terminal <NUM>. A more detailed description of the content of this message, and the methods by which it is created in steps <NUM> to <NUM> will be provided below with reference to <FIG>.

In step <NUM> transaction terminal then forwards the message on to the first transaction processing server <NUM>. As will be appreciated from the description above, this may involve sending the message via one or more further transaction processing servers.

In step <NUM>, the first transaction processing server <NUM> processes the transaction message. In some embodiment the first transaction processing server <NUM> may be capable of authorising or denying the transaction. In such cases, the signalling flow may pass straight to step <NUM> described below.

In the alternative, the second transaction processing server <NUM> may be the entity capable of authorising or denying the transaction. In such cases, the first transaction processing server <NUM> may modify the message. The modified message may then be sent to the second transaction processing server <NUM> in step <NUM>.

The second transaction processing server <NUM> then authorises or denies the transaction and, in step <NUM>, sends a response message to the first transaction processing server <NUM>. This response message may again be processed by the first transaction processing server <NUM>, before the modified response message is sent, in step <NUM>, to the transaction terminal <NUM>. A more detailed description of the processing of the message by the first transaction processing server <NUM> in steps <NUM> to <NUM> will be provided below with reference to <FIG>.

Upon receipt of the response message in step <NUM>, the transaction terminal <NUM> may perform any number of actions. For example, the transaction terminal <NUM> may send a response message to the transaction device <NUM>. This response message may contain data indicative of the transaction being authorised, and may, if required, include a ticket or other data structure which may be stored by the transaction device <NUM> for later use. Alternatively, or additionally, the transaction device may take an appropriate action, shown by step <NUM>. This action may be, for example, to open a door or ticketing barrier, or may be the provision of an indication that the transaction has been authorised (and therefore that the user may be provided with purchased goods or services).

The above processing flow is known in the art of transaction systems and therefore has been described in overview only.

As mentioned above, a more detailed description of the operation of the transaction device in steps <NUM> to <NUM> will now be provided with reference to <FIG>. Here the transaction device will be assumed to be provided with a transaction device identifier. This is a value or code which enables the transaction processing system to identify the transaction device <NUM> and distinguish it from other similar transaction devices. An example of a suitable transaction device identifier is a primary account number (PAN) of a financial instrument. In addition to the transaction device identifier, authentication data may be stored by the transaction device <NUM>. This authentication data may be used to enable messages sent from the transaction device <NUM> to be authenticated by the transaction processing system, thereby enabling the transaction processing system to authorise or deny any given transaction. The authentication data may include supplementary credentials and cryptographic keys which have been earlier provided to the transaction device <NUM>.

In step <NUM>, as mentioned above, the transaction device <NUM> may receive transaction data from the transaction processing system. This transaction data may include data associated with the identity of the transaction terminal <NUM>, for example an identity of a merchant or transit services provider which provides or uses that terminal, an identity of the terminal itself, a location for the terminal, a channel or domain associated with the communication with the terminal (this may indicate whether wireless or electrical contact is used), and payment details to enable the merchant to receive payment. In addition, the transaction data may include data which is specific to the transaction itself, for example data indicative of a time for the transaction, an amount for a payment, an amount for a reduction in a pre-paid ticket, and/or an identification of any goods or services associated with the transaction. The transaction data comprises at least some data which is other than the transaction device identifier.

In step 26A, the transaction device <NUM> generates a cryptographic key using the received transaction data. Typically, the cryptographic key will be generated using the transaction data as an input to one or more cryptographic functions. The transaction data is not the only input to the function, and the following additional inputs may be used:.

One way of how a cryptographic key is generated will now be described. This example will use Elliptic Curve Cryptography (ECC) and a method called ECC El Gamal for key agreement. It will be assumed that a cyclic group G has been defined based on a generator value g. A public key PS for a transaction processing server, e.g. server <NUM> has been generated based on the group G and a private key ds for that server, as follows: <MAT>.

This public key has been made available to the transaction device. In addition, a further key K, the hashing key, has been defined and is known to both the transaction device <NUM> and to the first transaction processing server <NUM>. The hashing key K may be a value uniquely associated with the transaction device.

In a first step, the transaction device <NUM> calculates a hash value. This may be done using a keyed-hash message authentication code (HMAC). The inputs to the hash function include the hashing key K and a concatenation of the device identifier (ID) and the transaction data. The output of the hashing function is denoted by h, and can be written as: <MAT>.

Using h and the cyclic group G the transaction device <NUM> may generate an ephemeral public key PD for the device for use in the transaction. This public key PD represents the cryptographic key described above, as follows: <MAT>.

In addition, using h and the public key PS of the first transaction processing server <NUM>, the transaction device <NUM> generates a shared secret S, as follows: <MAT>.

Having generated the ephemeral cryptographic key PD, and from that computed the shared secret S, in step 26B the transaction device <NUM> encrypts the device identifier ID using the shared secret S to generate an encrypted transaction device identifier C, as follows: <MAT>.

The cryptographic key PD, and the encrypted transaction device identifier C may each be considered cryptographic data elements which are sent to the transaction terminal <NUM> in a transaction message.

In addition to generating the encrypted transaction device identifier C, in step 26C the transaction device <NUM> may generate a temporary transaction device identifier. The temporary transaction device identifier may be generated entirely randomly, or pseudo randomly. Alternatively it may be based on the encrypted transaction device identifier C; or generated using further data, at least some of which is data other than the transaction device identifier, for example the transaction data described above, or the public key PD generated for the device.

The temporary transaction device identifier may be generated using a further function, with one of the values described above as an input. For instance, it is typically the case that the device identifier has a certain format - for example being of a certain length. In such cases, the input value may be modified to provide a temporary transaction device identifier. The temporary transaction device identifier may not be wholly generated, and may be based in part on predetermined data, such as a portion of the real transaction device identifier.

As an example, where the transaction device identifier is a <NUM> digit PAN, the first <NUM> digits represent a Bank Identification Number (BIN) or Issuer identification number (IIN), and the last digit represents a check digit. The BIN/IIN from the original transaction device identifier may be kept, and augmented with nine digits of the temporary transaction device identifier and a suitable check digit.

In step 26D, the transaction device <NUM> creates a transaction message to be sent to a transaction processing system using the values generated above. It will often be the case that the transaction message must conform to a certain standard. For example, the transaction message may be formatted in accordance with an EMV standard for payment processing, which specifies mandatory data elements for the transaction message including a data element configured to convey the PAN as a transaction device identifier. Accordingly this standard may specify that the message should comprise, at least, a first data field configured to hold a transaction device identifier and a second data field configured to hold supplementary data. Accordingly, the temporary transaction device identifier, that does not in fact identify the transaction device <NUM>, may be provided in the first data field and the encrypted transaction device identifier may be provided in the second data field. In addition the transaction message may comprise a third data field, and the cryptographic key PD associated with the encryption of the transaction device identifier may be provided in the third data field. It will be understood that the cryptographic key PD was not itself used in the encryption of the transaction device identifier. Instead, by virtue of being the public key associated with the shared secret used in the encryption, PD represents data identifying the cryptographic key associated with the encryption of the transaction device identifier. Finally, some or all of the transaction data may be provided in other fields of the message.

Having generated a suitable transaction message, the transaction device <NUM>, in step <NUM>, sends the transaction message to the transaction processing system, i.e. the transaction terminal <NUM>.

A more detailed description of the operation of the first transaction processing server <NUM> in steps <NUM> to <NUM> will now be provided with reference to <FIG>.

In step <NUM>, the first transaction processing server <NUM> receives the transaction message. In line with the description above, the message created by the transaction device <NUM> comprises a temporary transaction device identifier, an encrypted transaction device identifier C and the ephemeral cryptographic key PD. The encrypted transaction device identifier C and the ephemeral cryptographic key PD may be considered as cryptographic data elements. In addition, the message may contain at least some of the transaction data.

In step 32A, the first transaction processing server <NUM> may generate the shared secret S using the cryptographic key PD, as follows: <MAT>.

The shared secret S may then be used to decrypt the encrypted transaction device identifier C to generate the original transaction device identifier ID.

In addition, the first transaction processing server <NUM> validates any transaction data provided in the transaction message. This may be done by using the original transaction device identifier ID to look up the hashing key K for the transaction device <NUM> and then recreating the hash value h' and the ephemeral public key P'D as described above, as follows: <MAT> <MAT>.

A comparison of the public key PD sent in the transaction message and the newly generated public key P'D will demonstrate whether the transaction data received in the message corresponds to the transaction data used to generate the public key PD.

The first transaction processing server <NUM> may then process the transaction message based on the original transaction device identifier (i.e. at least part of the decrypted data derived from the encrypted data provided in the second data field). In other words, the transaction message may be processed as if the temporary transaction device identifier were replaced by the original transaction device identifier ID. As mentioned above, the first transaction processing server <NUM> itself may be able to authorise or deny the transaction at this point. If this is the case, then in step 32E, the first transaction processing server <NUM> determines, using the original transaction device identifier ID whether to authorise or deny the transaction and generates a suitable response message. In step <NUM> the first transaction processing server <NUM> then sends the response message back to the transaction terminal <NUM>.

However, in the alternative the first transaction processing server <NUM> may, in step 32C, modify the transaction message, replacing the temporary transaction device identifier with the original transaction device identifier ID. The first transaction processing server <NUM> may additionally, in step 32D, store an association between the temporary transaction device identifier and the original transaction device identifier ID.

Subsequently, in step <NUM> the first transaction processing server <NUM> may send the modified transaction message with the temporary transaction device identifier replaced by the original transaction device identifier the second transaction processing server <NUM>. The second transaction processing server <NUM> may then process the modified transaction message as a normal message which had been originally provided with an unencrypted transaction device identifier.

In step <NUM> the first transaction processing server <NUM> may receive a response message from the second transaction processing server <NUM>. This response message may comprise a data field configured to hold a transaction device identifier, which consequently comprises the original transaction device identifier ID.

In step <NUM>, the first transaction processing server <NUM> may modify the response message to replace the original second transaction device identifier ID with the first transaction device identifier, using the association stored in step 32D. The modified response message may then, in step <NUM>, be sent to the transaction terminal <NUM>.

The above described methods present the following advantages. Firstly, the field designed to contain the transaction device identifier in a typical transaction system is limited in size and needs to adhere to strict formatting rules. This puts restrictions on the degree of freedom for any temporary transaction device identifier. By providing a temporary transaction device identifier in a message and separately providing an encrypted transaction device identifier, the degree of freedom for encrypting the transaction device identifier is increased, and therefore security is correspondingly increased. Equally, it is easier to generate the temporary transaction device identifier as it only needs to conform to the requirements of being random, or pseudo random, and enabling the transaction message to be properly handled by the transaction system.

Furthermore, by providing the ephemeral cryptographic key with the transaction message, it is possible to ensure that no information provided in the transaction message can be used to track a user. This is because the ephemeral cryptographic key is itself non deterministic or random and therefore cannot be used to track a user.

It should be noted that a system may be used - in examples falling outside the claimed invention - where a transaction device identifier is encrypted using solely a public key of a recipient server. The disadvantage of such system is that they are susceptible to attack, as the relatively static key (that of the server) means that multiple messages are all sent using the same key, which in turn reduces the security of the system.

A further advantage relates to the size of a cryptographic key which is required to enable effective encryption of the transaction device identifier. For example, a typical length of an ECC cryptographic key required to provide adequate encryption is <NUM> bytes or more. Providing this key in a message takes up a large amount of the message data, often significantly more than the transaction device identifier itself. For example, a PAN may be uniquely identified by less than <NUM> bytes of data, a quarter of the data size of the key which may be used to encrypt the PAN. However, in embodiments the cryptographic key also serves as data enabling the transaction data to be verified. This dual use improves the data size efficiency of any message and enables messages, encrypted according to the embodiments described above, to be transmitted using existing systems with restrictions on the size of any message.

While a specific implementation of ECC cryptography has been described above, it will be appreciated that modifications may be made, or entirely different systems may be used, for the generation and use of the cryptographic key. In a non-claimed example, the shared secret S may be used directly to encrypt the device identifier, however in the also non-claimed alternative, a further key, generated using S may be used. Alternatively - and also non-claimed, an implementation may use lattice based cryptographic methods such as NTRU. For such an implementation, there would be no need to communicate a separate ephemeral key to the server since the output of the encryption mechanism is effectively random.

In the specific implementation described above, the temporary transaction device identifier is random so that no information in the transaction message can be used to track the transaction device <NUM>, and accordingly potentially track the user of the transaction device <NUM>. Alternatively, instead of a random temporary transaction device identifier, a fixed number stored by the transaction device <NUM> that is the same for many or all transaction devices utilising the invention could be inserted in the field in the transaction message for the transaction device identifier. In this way, it is not possible to determine the identity of the transaction device from the entry within the transaction device identifier field within the transaction message. Further, such a static transaction device identifier can be used to indicate to a recipient of the transaction message that an encrypted version of the actual transaction device identifier is provided in a separate field of the transaction message.

Embodiments are intended to be compatible with existing systems. Therefore the message sent by the transaction device <NUM> may conform to existing protocols. In particular, it is intended that only the transaction device <NUM> and the first transaction processing server <NUM> need be modified to enable the overall system to operate as before. Consequently, the first transaction processing server <NUM> may operate to convert any message provided by the transaction device <NUM> into a format which is usable by the second transaction processing server <NUM> without requiring modification of the second transaction processing server <NUM>.

In some embodiments, the temporary transaction device identifier may correspond to the encrypted transaction device identifier, and may therefore be used to retrieve the original device identifier. This obviates the need for any further field.

While the cryptographic key has been described as being transmitted with the transaction message, some embodiments may be arranged to generate the cryptographic key from the transaction data in a manner which can be replicated by the first transaction processing server <NUM>. Accordingly, at the first transaction processing server <NUM>, a cryptographic key may be generated using at least the transaction data provided in the transaction message. This cryptographic key may then be used to decrypt any cryptographic data element containing the original transaction device identifier.

In embodiments, the original transaction device identifier may be a pointer to a transaction device identifier useable by the second transaction processing server <NUM>. As such the first transaction processing server <NUM> may possess a lookup table which enables the pointer to be used to identify a suitable transaction device identifier. Therefore, no modification is needed for the second transaction processing server <NUM>, but the identifier passed between the transaction device <NUM> and the first transaction processing server <NUM> need not be selected according to the requirements for a suitable identifier useable by the second transaction processing server <NUM>.

In the specific implementation described above, the transaction terminal <NUM> forwards the transaction message from the transaction device <NUM> to a first transaction processing server <NUM> and the first transaction processing server <NUM> recovers the transaction device identifier for the transaction device <NUM>. In some implementations, the transaction terminal <NUM> may be required to authorise a transaction faster than can be achieved if the transaction terminal awaits a response from the first transaction processing server. An example of such an implementation is a ticket gate arrangement in which a transaction terminal within a ticket gate needs to authorise a transaction and transfer ticket information to a transaction device <NUM> within a short time. In such an implementation, the transaction terminal <NUM> may send a message to the transaction device <NUM> including a public key certificate for the transaction terminal <NUM>, and the transaction device <NUM> may encrypt the transaction device identifier using the public key derived or extracted from the certificate for the transaction terminal <NUM>, preferably using a cryptographic scheme as described above, and send the encrypted transaction device identifier to the transaction terminal <NUM>. The transaction terminal <NUM> may then recover the transaction device identifier and, for example, compare the recovered transaction device identifier with a blacklist of transaction device identifiers stored by the transaction terminal <NUM>, indicating transaction devices <NUM> for which no transaction should be made, before authorising the transaction.

In embodiments, the transaction device itself may be a self-contained device, such as a smart card or fob. In other embodiments, the transaction device <NUM> be a general purpose computing device, such as a mobile phone or computer, which is contains, or is connected to apparatus which generates the transaction messages. Such an apparatus may be tamper resistant hardware; that is a secure element. In such cases, it will be appreciated that reference to the transaction device performing a given operation, such as sending a message to a terminal, is representative of the transaction device causing another device (e.g. the mobile telephone) to send such a message.

Recently, systems whereby a computing device (such as a mobile telephone) can be used without requiring a secure element, have been proposed. On such system is called "Host Card Emulation" whereby a transaction application executes within a device's application processor. An alternative, but similar system is the use of a "Trusted Execution Environment" within a suitable device. Embodiments of the invention are applicable to these and similar systems.

In some examples, the transaction device <NUM> may not receive any transaction data from the transaction terminal <NUM>, but may generate the transaction data itself. In further embodiments the transaction data may be received by other means. For example it has been proposed to use mobile telephones in transactions, and to enable those mobile telephones to send and receive data via the mobile network alongside any transaction which may occur over a contactless (e.g. NFC) connection between the mobile telephone and a terminal. In such cases, it is envisaged that at least some of the communications described above, whether the provision of transaction data to the transaction device, or transmission of the transaction message, may not involve the transaction terminal <NUM>, but other communications systems.

The connection between the transaction device <NUM> and the transaction terminal <NUM> may be bidirectional as described above, but may equally be unidirectional. For example, a mobile telephone may receive transaction data from a terminal via a unidirectional connection (e.g. by photographing a code optically displayed by the terminal) and may then create and send a suitable transaction message via a wireless communications network such as a cellular connection or WiFi. In such cases the transaction terminal may not itself have any communications capabilities with the transaction processing network, and may be, for example, a poster displaying an optical code such as a QR code.

In other embodiments, there may not be a transaction terminal <NUM> as such, and the transaction device <NUM> may communicate directly with a network and thereby with the first transaction processing server <NUM>. This may be used for online transactions where the transaction device <NUM> is a connected computer or portable device.

In some embodiments, other information, such as credentials for enabling the message to be authenticated, may be encrypted alongside the device identifier.

The cryptographic key may be compressed. For example a full elliptical function cryptographic key has an X and a Y component. It is possible to compress the key be providing only the X component alongside one or two bits of data to indicate a sign for the Y component. Knowledge of the X component, the function used, and the sign of the Y component enables the cull cryptographic key to be recreated. In the above description it will be appreciated that where a key is described as being determined or provided, a compressed version thereof may be equivalently used.

The transaction device <NUM>, transaction terminal <NUM> and transaction processing servers <NUM> and <NUM>, may comprise computerised hardware as is known in the art. An exemplary computerised system <NUM>, capable of performing the method steps described above, will now be described with reference to <FIG>.

The computerised system <NUM> comprises a processing system <NUM>, such as a CPU, or an array of CPUs. The processing system <NUM> is connected to a computer readable storage medium such as memory <NUM>. This memory may be a volatile memory, for example RAM; or a non-volatile or non-transitory memory, for example a solid state drive (SSD) or hard disk drive (HDD). The system <NUM> may also comprise an interface <NUM>, capable of transmitting and/or receiving data from other elements in the system.

The memory <NUM> stores computer readable / computer executable instructions <NUM>. The computer readable instructions may be configured such that when they are executed by the processing system <NUM>, the computerised system <NUM> is caused to perform the methods described above. To enable this, the processing system <NUM> may retrieve the computer instructions <NUM> from memory <NUM> and execute these instructions. In so doing, the processing system <NUM> may cause the interface to transmit or receive data as required.

Claim 1:
A method for transmitting a transaction message from a transaction device (<NUM>) having a transaction device identifier ID to a transaction processing system (<NUM>), the method comprising:
receiving, at the transaction device (<NUM>), transaction data from a transaction terminal (<NUM>) of the transaction processing system (<NUM>);
receiving, at the transaction device (<NUM>), a public key PS for the transaction processing server (<NUM>) generated based on a cyclic group G and a private key dS for the transaction processing server (<NUM>);
calculating, at the transaction device (<NUM>), a hash value h by inputting a hashing key K, known to both the transaction device (<NUM>) and the transaction processing server (<NUM>), and a concatenation of the transaction device identifier and the transaction data;
generating, at the transaction device (<NUM>), an ephemeral public key PD for the transaction device (<NUM>) using the hash value h and the cyclic group G;
generating, at the transaction device (<NUM>), a shared secret S using the hash value h and a public key PS for the transaction processing server (<NUM>);
encrypting, at the transaction device (<NUM>), the transaction device identifier ID for the transaction device (<NUM>) using the shared secret S to generate an encrypted transaction device identifier C;
sending the transaction message to the transaction processing system (<NUM>), the transaction message comprising, at least, the ephemeral public key PD and the encrypted transaction device identifier C.