WO2016037708A1

WO2016037708A1 - Payment-terminal sharing

Info

Publication number: WO2016037708A1
Application number: PCT/EP2015/001831
Authority: WO
Inventors: Mathieu Tahon; Lorenzo Bosco; Nicolas Hirel; Veronica Milani; Remi Diana
Original assignee: Amadeus S.A.S.
Priority date: 2014-09-12
Filing date: 2015-09-11
Publication date: 2016-03-17
Also published as: CN106663254B; CN106663254A

Abstract

A method is described of configuring a payment terminal to become usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal. An operator- and terminal-specific transport key is provided to the payment terminal. An operator- and terminal-specific initial-encryption key is derived, by the payment provider, from an operator-specific base-derivation key using the terminal-identification number, or an additional identification number of the payment terminal. The operator- and terminal-specific initial-encryption key is transmitted to the payment terminal, and is decrypted at the payment terminal. An operator- and transaction- specific encryption key is derived, both at the payment provider and the payment terminal, from the operator- and terminal-specific initial-encryption key using a transaction-specific number associated with this transaction, when performing a transaction with the payment terminal.

Description

PAYMENT-TERMINAL SHARING

FIELD OF THE INVENTION The invention relates to payment-terminal sharing and, for example, to a method of configuring a payment terminal to become usable as a payment terminal shared by a plurality of operators, a computerized controlling-entity system arranged to configure a payment terminal to be usable in this manner, a computerized controlling-entity system arranged to configure a payment terminal to be usable in this manner, and a payment terminal configured to be usable in this manner.

BACKGROUND

Cashless payment at vendors can be performed at payment terminals by means of payment cards, e.g. credit cards. Payment terminals typically enable payment-card-industry (PCI) compliant point-to-point transactions to be performed. Such payment terminals, for example, are also used at airports for ticket purchase at ticket counters, and also for last-minute purchases, for example, at boarding gates. SUMMARY OF THE INVENTION

A method is provided of configuring a payment terminal to become usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal. The payment terminal is arranged to communicate with at least one payment provider to perform payment transactions. The payment terminal is associated with a controlling entity that controls usage of the payment terminal in an operator-selective manner. The payment terminal has a terminal-specific access key stored therein, and has a terminal-identification number. The method comprises providing an operator- and terminal-specific transport key, encrypted by the terminal-specific access key, to the payment terminal. The encrypted operator- and terminal-specific transport key is decrypted at the payment terminal with the stored terminal-specific access key. An operator- and terminal-specific initial-encryption key is derived, by the payment provider, from an operator-specific base-derivation key using the terminal -identification number, or an additional identification number of the payment terminal. The operator- and terminal-specific initial-encryption key is symmetrically encrypted with the operator- and terminal-specific transport key. The encrypted operator- and terminal-specific initial-encryption key is transmitted to the payment terminal. The encrypted operator- and terminal -specific initial- encryption key is decrypted at the payment terminal with the decrypted operator- and terminal-specific transport key. An operator- and transaction-specific encryption key is derived, both at the payment provider and the payment terminal, from the operator- and terminal-specific initial-encryption key using a transaction-specific number associated with this transaction, when performing a transaction with the payment terminal. According to another aspect a computerized controlling-entity system is provided arranged to configure a payment terminal to be usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal. The memory may be non-volatile memory. The payment terminal has a terminal- identification number. The controlling-entity system is arranged to derive an operator- and terminal-specific transport key from an operator-specific master-transport key by using the terminal-identification number. The controlling-entity system is further arranged to symmetrically encrypt the operator- and terminal-specific transport key with a terminal- specific access key and to transmit the encrypted operator- and terminal-specific transport key to the payment terminal.

According to a further aspect a computerized payment-provider system is provided arranged to configure a payment terminal to be usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal. The memory may be non-volatile memory. The payment terminal has a terminal- identification number. The payment-provider system is arranged to derive an operator- and terminal-specific transport key from an operator-specific master-transport key by using the terminal-identification number and to derive an operator- and terminal-specific initial- encryption key from an operator-specific base-derivation key by using the terminal- identification number, or an additional identification number of the payment terminal. The payment-provider system is arranged to transmit the operator-specific master- transport key to a controlling entity in a confidentiality-securing manner, wherein the payment terminal is associated with the controlling entity, or, alternatively; to transmit the operator- and terminal- specific transport key to the controlling entity in a confidentiality-securing manner. The payment-provider system is further arranged to symmetrically encrypt the operator- and terminal-specific initial-encryption key with the operator- and terminal-specific transport key and to transmit the encrypted operator- and terminal-specific initial-encryption key to the payment terminal; and to derive an operator- and transaction-specific encryption key from the operator- and terminal-specific initial-encryption key using a transaction-specific identification number associated with the transaction, when performing a transaction with the payment terminal.

According to a still further aspect a payment terminal is provided which is programmed to be usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal and arranged to communicate with an operator or at least one payment provider to perform payment transactions and is arranged to be associated with a controlling entity that controls usage of the payment terminal in an operator-selective manner. The payment terminal comprises at least one tamper-resistant security module arranged to store a terminal-specific access key to enable usage of the payment terminal to be controlled by the controlling entity in the operator- selective manner.

Other features are inherent in the disclosed methods and systems or will become apparent to those skilled in the art from the following description of examples and its accompanying drawings.

GENERAL DESCRIPTION, ALSO OF OPTIONAL EMBODIMENTS OF THE

INVENTION The method disclosed is for configuring a payment terminal, for example a credit-card reader, to become usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal. Such an operator is, for example, an airline performing a check-in for a flight. The cryptographic segregation allows usage, i.e. transmitting payment transactions, of the same payment terminal by the different operators, e.g. different airlines at a boarding gate, secured with operator-specific encryption keys, thereby ensuring operator-specific privacy, such as if each of these operators were the only operator using that payment terminal. The payment terminal is arranged to communicate with at least one payment provider to perform payment transactions. The payment provider, for example, can be a payment gateway, a credit card company (a credit card company is also referred to as a "switch"), or an acquirer. A payment gateway may bundle transactions with various credit card companies.

The payment terminal is associated with a controlling entity that controls usage of the payment terminal in an operator-selective manner. The controlling entity is, for example, an airport owner that commissioned the payment terminals for an airport. An airport company managing the airport may order payment terminals from a manufacturer to distribute the payment terminals throughout check-in desks, boarding gates, kiosks, and the like.

The controlling entity grants usage to the different operators by using a terminal-specific access key, which allows the controlling entity to manage access authorization for each individual operator of the payment terminal. That is to say, the authorization of payment providers contracted by the operators, i.e. acquirers of the operators, can be controlled by the controlling entity in this manner. More specifically, the authorization of an operator is established by providing the payment terminal with an operator- and terminal-specific transport key, encrypted by the terminal-specific access key. In some examples the operator- and terminal-specific transport key is verified after decryption by the terminal- specific access key with a key control value (KCV), which is also transmitted along with the encrypted operator- and terminal-specific transport key. The KCV is, for example, the result of an application of a "one-way function" to the operator- and terminal- specific transport key to be verified. A "one-way function" is a function which cannot practically be inverted; that is a function which does not enable the input data which is due to be verified to be reconstructed from the result of the application of the one-way function to the input data. Examples of one-way functions are hash functions. To verify the operator- and terminal-specific transport key, the one-way function (e.g. a hash function) is applied to the decrypted operator- and terminal-specific transport key, and the result of the application is compared to the transmitted KCV. If the result is consistent with the KCV (e.g. if it is identical to the KCV), the operator- and terminal-specific transport key is deemed to be the valid operator- and terminal-specific transport key.

In other examples (without verification by a KCV) the validity of the decrypted operator- and terminal-specific transport key becomes evident during a subsequent payment transaction. If a bit sequence, i.e. a (presumed) operator- and terminal-specific transport key, not encrypted by the correct terminal-specific access key, is transmitted to the payment terminal, the decrypted bit sequence, i.e. the (presumed) operator- and terminal-specific transport key resulting from the decryption with the stored terminal-specific access key, will not be the correct operator- and terminal-specific transport key. Hence, all the keys derived from this incorrect operator- and terminal-specific transport key will also be incorrect. Therefore, communications encrypted by those derived incorrect keys, e.g. user or cardholder authentication requests, made by the payment terminal in the subsequent payment transaction, will not contain any useful information, and will therefore fail.

The payment terminal has a terminal-identification number, i.e. a string of alphanumeric digits of a given length, and has the terminal-specific access key stored within it, e.g. stored in a read-only memory (ROM).

The process of providing the payment terminal with an operator- and terminal-specific transport key, encrypted by the terminal-specific access key, can be performed in various alternative ways, denoted below by "Al ", "A2", and "A3". The beginning and end of the description of these alternatives is marked by "(StartAl "), "(EndAl)", "(StartA2)", etc.

(Start Al) In some embodiments, an operator-specific master-transport key is transmitted from at least one payment provider to the controlling entity in a confidentiality-securing manner. This operator-specific master-transport key is unique per operator and controlling entity. It is, for example, generated securely in the payment provider's tamper-resistant security module (TRSM) and then communicated to the controlling entity in the confidentiality-securing manner. The controlling entity stores the operator-specific master-transport key, for example, in another tamper-resistant security module (TRSM).

An operator- and terminal-specific transport key is derived, both at the payment provider's end and the controlling entity's end, e.g. in the respective TRSMs, from the operator-specific master-transport key using the terminal-identification number, which is, for example, a serial number of the payment terminal. The operator- and terminal-specific transport key, derived by the controlling entity is symmetrically encrypted, with the terminal-specific access key and then the encrypted operator- and terminal-specific transport key is transmitted to the payment terminal. (End Al)

(Start A2) In alternative embodiments, an operator-specific master-transport key that is unique to each operator and controlling entity is, for example, generated securely in the payment provider's tamper-resistant security module (TRSM). An operator- and terminal-specific transport key is derived, at the payment provider's end, e.g. in the TRSM, from the operator-specific master-transport key using the terminal- identification number, and is transmitted to the controlling entity in a confidentiality-securing manner. This operator- and terminal-specific transport key is symmetrically encrypted, by the controlling entity, with the terminal-specific access key and then the encrypted operator- and terminal-specific transport key is transmitted to the payment terminal. (End A2)

(Start A3) In other alternative embodiments, the operator- and terminal-specific transport key is provided to the payment terminal by manually inputting the operator- and terminal-specific transport key, symmetrically encrypted by the terminal-specific access key, into the payment terminal.

This manual input can be a manual interaction with the payment terminal, e.g. navigating through the payment terminal's guided menu and entering the operator- and terminal-specific transport key, encrypted with the terminal-specific access key, in binary-coded decimal (BCD) format. Alternatively, the manual input can be an insertion of a removable storage device into the payment terminal, for example, an USB flash drive or a memory card. (End A3)

In all these alternatives (Al, A2, A3), the controlling entity is able to control the usage of the payment terminal in the operator-selective manner with the operator- and terminal-specific transport key, as this key is used for decryption of subsequent communications between a payment provider and the payment terminal if an operator, associated with that payment provider, initiates a payment transaction.

In some embodiments the controlling entity can also control the usage of the payment terminal in the operator-selective manner by a withdrawal or wipe of the operator- and terminal-specific transport key. The controlling entity may delete the operator- and terminal- specific transport key and the operator- and terminal-specific initial-encryption key associated with a certain operator in the payment terminal. The operator- and terminal-specific transport key and the operator- and terminal-specific initial-encryption key of the operator at issue can be deleted, for example, by remote access to the payment terminal or by manual interaction with the payment terminal.

In some embodiments a wipe of the operator- and terminal-specific transport key and the operator- and terminal-specific initial-encryption key, for example, by the controlling entity by remote access to the payment terminal cannot be prevented locally at the payment terminal. In these embodiments, the payment terminal and the operator using the payment terminal cannot stop the controlling entity from wiping the operator- and terminal-specific transport key and the operator- and terminal-specific initial-encryption key remotely as the controlling entity has the terminal-specific access key, which grants the controlling entity access with administrator rights to the payment terminal.

Theoretically, after such a key wipe-out, the operator at issue using the payment terminal could still exchange data with payment providers, but without the correct operator- and terminal-specific initial-encryption key in its decrypted form communications with the corresponding payment provider could not be decrypted correctly, and would therefore be meaningless. Moreover, without the operator- and terminal-specific transport key the payment terminal could not decrypt the operator- and terminal-specific initial-encryption key even if a payment provider sent the operator- and terminal-specific initial-encryption key anew. Hence, in some embodiments the controlling entity cannot only positively control the usage of the payment terminal in an operator-selective manner by providing the operator- and terminal- specific transport key, but can also negatively control the usage of the payment terminal in an operator-selective manner by withdrawal of the operator- and terminal-specific initial- encryption key and the operator- and terminal-specific transport key of the operator at issue from the payment terminal.

Alternatively, in some embodiments the operator- and terminal-specific initial -encryption key and the operator- and terminal-specific transport key can be deleted locally by physically interacting with the payment terminal. For example, the keys can be deleted manually by a person via a user interface of the payment terminal.

On the one hand, the use of symmetrical encryption for the operator- and terminal-specific transport key permits less complex key management than, for example asymmetric encryption, as there is no independent certificate authority (CA) required to manage distribution of verified public keys. On the other hand, the transmission of the symmetric key is acceptable from the security perspective since a "shared secret" is derived at both ends of the transmission and can, as described above, be verified with a KCV or the like. Furthermore, the initial cryptographic key, used for both encryption and decryption of subsequent keys transmitted to the payment terminal, is fed into the payment terminal in confidentiality-securing manner, for example, within a secure room located at the terminal provider's manufacturing facilities.

The security modules mentioned above may be storage devices with physical characteristics that make successful tampering difficult and improbable. Tampering might include penetration without zeroization of security parameters, unauthorized modification of an internal operation of the TRSM, or insertion of tapping mechanisms or non-intrusive eavesdropping methods to determine, record, or modify secret data. The encrypted operator- and terminal-specific transport key is decrypted at the payment terminal with the stored terminal-specific access key, as described above.

In some examples the encrypted operator- and terminal-specific transport key is decrypted with the terminal-specific access key at the payment terminal upon receipt, and the decrypted operator- and terminal-specific transport key is stored in a secure storage of the payment terminal, such as the TRSM.

In alternatives examples the received encrypted operator- and terminal-specific transport key is first stored in the payment terminal in its encrypted form and is only later decrypted with the terminal-specific access key at the payment terminal "on the fly", i.e. only when the decrypted version of the operator- and terminal-specific transport key is required for the decryption of the encrypted operator- and terminal-specific initial-encryption key to perform a transaction with the payment terminal, e.g. a payment transaction.

The controlling entity can grant usage of the payment terminal to an operator with the corresponding operator- and terminal-specific transport key as this key is used for decryption of subsequent communication between the payment terminal and the payment provider associated with the operator performing transactions with the payment terminal.

An operator- and terminal-specific initial-encryption key is derived, by the payment provider, from an operator-specific base-derivation key using the terminal-identification number, or an additional identification number of the payment terminal. The operator-specific base-derivation key, for example, may be unique to each operator and payment provider and is generated securely in the payment provider's TRSM and, in normal circumstances, never leaves this secure environment. The operator- and terminal-specific initial-encryption key is unique to each payment terminal and is generated, for example, in the payment provider's TRSM by derivation from the operator- specific base-derivation key using derivation data based on the terminal-identification number of the payment terminal.

The operator- and terminal -specific initial -encryption key is symmetrically encrypted with the operator- and terminal-specific transport key. The encrypted version of that key is transmitted to the payment terminal. The encrypted version received at the payment terminal is decrypted at the payment terminal using the previously stored operator- and terminal-specific transport key.

In some examples the decrypted version of the operator- and terminal-specific initial- encryption key is stored in a secure storage of the payment terminal, for example, in the payment terminal's TRSM.

In some examples the encrypted operator- and terminal-specific initial-encryption key is decrypted with the operator- and terminal-specific transport key at the payment terminal upon receipt or input, and the decrypted operator- and terminal-specific initial-encryption key is stored in a secure storage of the payment terminal, for example the T SM.

The process of transmitting the encrypted operator- and terminal-specific initial-encryption key, decrypting the encrypted operator- and terminal-specific initial-encryption key, and storing the decrypted operator- and terminal-specific initial-encryption key in the payment terminal can be considered to be a process of feeding (or, figuratively speaking, "injecting") the operator- and terminal-specific initial-encryption key into the payment terminal. In an alternative example, the received encrypted terminal-specific initial-encryption key is first stored in the payment terminal in its encrypted form upon receipt or input and is only later decrypted with the operator- and terminal-specific transport key at the payment terminal when the decrypted terminal-specific initial-encryption key is required for obtaining the operator- and transaction-specific encryption key using the decrypted operator- and terminal- specific initial-encryption key to perform a transaction with the payment terminal, e.g. a payment transaction.

In this alternative example the operator- and terminal-specific initial-encryption key is stored still in the encrypted form in the payment terminal in a non-secure memory, e.g. a normal memory outside the TRSM, and is only decrypted when needed, i.e. it is "decrypted on the fly". In this alternative example security for the operator- and terminal-specific initial- encryption key is provided by encryption, rather than by storing it in the unencrypted form in a secure memory, such as a TRSM. In this alternative example the feeding (or the "injection") of the operator- and terminal-specific initial-encryption key process into the payment terminal can be seen in the transmission of the encrypted operator- and terminal-specific initial- encryption key to the payment terminal, and its storage in the still encrypted form in the payment terminal. The later decryption of this key "on the fly" can be considered to be part of the subsequent activity of deriving an operator- and transaction-specific encryption key. An operator- and transaction-specific encryption key is derived, both at the payment provider's end and at the payment terminal, from the operator- and terminal-specific initial- encryption key using a transaction- specific number associated with this transaction, when a transaction is performed with the payment terminal. Such a transaction would be performed when e.g. cashless payment is made by means of a payment card, such as a credit card, being inserted into the payment terminal, for example for ticket purchase at the ticket counter of an airport, or for a last-minute purchase, for example, at a boarding gate of an airport.

In some embodiments the operator- and transaction-specific encryption key is the key that is used for encrypting the data transmitted during a transaction with the payment terminal with cryptographic segregation between different operators. The other keys described are used in preparatory steps to enable this segregated encrypted communication by setting up the payment terminal, i.e. for configuring the payment terminal so that it becomes usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators.

In other examples the operator- and transaction-specific encryption key is not directly used for encrypting the transaction data but is the basis for further key derivation. The key, or keys derived from the operator- and transaction-specific encryption key is/are then used for encrypting the data transmitted during a transaction with the payment terminal with cryptographic segregation.

In some embodiments the payment terminal is shared by at least two operators. Each of these at least two operators has an individual operator- and terminal-specific initial-encryption key and an individual operator- and terminal- specific transport key assigned to it. These individual keys are different from each other, i.e. the at least two operator- and terminal-specific initial- encryption keys differ from each other, as do the at least two operator- and terminal-specific transport keys.

In some embodiments the individual operator- and terminal-specific initial-encryptiori keys and the individual operator- and terminal-specific transport keys assigned to the at least two operators stored in the payment terminal for each operator in parallel, i.e. the individual keys are hold simultaneously in the payment terminal so that the payment terminal is in a configured state in which it is readily usable by either of the at least two operators in a cryptographically segregated manner. The payment terminal, for example, has a TRSM in which all these different operator- and terminal-specific initial-encryption keys are stored. Hence, the correct operator- and terminal-specific initial-encryption key associated with the operator currently operating the payment terminal can be retrieved from the TRSM of the payment terminal and can be loaded into its operating system. Thereby, the correct operator- and terminal-specific initial-encryption key is readily available if a transaction is initiated by the operator currently operating the payment terminal.

In some examples the "at least one payment provider" is a single payment-gateway provider that, for example, validates airline payments, combats fraud and enables fund collection. The payment-gateway provider may allow the airline to protect revenue via various checks of booking and/or payment data. The single payment- gateway provider may provide an interface to a plurality of credit-card companies, banks, etc., and can therefore be considered to be a mediator between the operator of the payment terminal and the various credit-card companies, banks, etc., and bundles the communications with the various credit-card companies, banks, etc. Hence, in the payment transactions the operator of the payment terminal transacts only indirectly with the various credit card companies, banks, etc. through the single payment- gateway provider.

In other examples the "at least one payment provider" is one of a plurality of payment providers, e.g. a credit-card company that settles payments with the operator of the payment terminal. In these other examples, the operator of the payment terminal interacts directly with the various credit-card companies, banks, etc., without the bundling effect mentioned for the case of a single payment-gateway provider. In some examples at least one of the terminal-specific access key, the operator-specific master-transport key, the operator- and terminal-specific transport key, the operator-specific base-derivation key, the operator- and terminal-specific initial-encryption key, and the operator- and transaction-specific encryption key is a symmetric-encryption key. In some examples some or all of these keys are symmetric-encryption keys.

Symmetric-encryption key in this context stands for usage of the same cryptographic keys for both encryption of plaintext and decryption of ciphertext. The encryption and decryption keys may be identical or there may be a simple transformation between them as, for example, in the International Data Encryption Algorithm (IDEA). The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link.

In some of these examples the at least one of, some of, or all of the symmetric-encryption keys are triple keys according to the Triple Data Encryption Algorithm (TDEA), which applies the Data Encryption Standard (DES) cipher algorithm three times to each data block. DES is a block cipher and encrypts data in 64-bit blocks. A 64-bit block of plaintext is input into the algorithm, and a 64-bit block of ciphertext is output. DES is symmetric: In principle, the same algorithm and key are used for both encryption and decryption (except for minor differences in key schedule). More specifically, DES uses keys with a key length of 56 bits. The key is usually expressed as a 64-bit number, but every eighth bit is used for parity checking and is ignored. At the simplest level, the algorithm is a combination of the two basic techniques of encryption: confusion and diffusion. The fundamental building block of DES is a combination of these techniques, i.e. a substitution followed by a permutation, on the text, based on the key. This is known as a round. DES has 16 rounds and therefore applies the same combination of techniques to the plaintext block 16 times. The algorithm uses standard arithmetic and logical operations on numbers of 64 bits at most.

Triple DES (3 DES) uses a "key bundle" that comprises three DES keys, Kl, K2 and K3, each of 56 bits (excluding parity bits). The procedure is as follows: DES encryption with Kl, DES decryption with K2, then DES encryption with K3. Decryption is the reverse, i.e., decryption with K3, encryption with K2, then decryption with Kl . Each triple encryption encrypts one block of 64 bits of data. The 3DES standard defines three keying options: (i) all three keys are independent, (ii) Kl and K2 are independent, and K3 = Kl, and (iii) all three keys are identical, i.e. Kl = K2 = K3. Keying option 1 is strongest with 3 x 56 = 168 independent key bits. Each DES key is nominally stored or transmitted as 8 bytes, each of odd parity. So a key bundle requires 24, 16 or 8 bytes for keying option (i), (ii), or (iii), respectively.

In some examples the payment terminal is arranged to provide at least two usage modes, a direct-usage mode in which transaction data is exchanged between the payment terminal and one of the operators, and a delegated-usage mode in which transaction data is exchanged between the payment terminal and at least one payment provider. The payment-terminal is pre-configured by an assignment of usage modes to operators of the plurality of operators (4). For example, considering operators A, B, C, D, E, the direct-usage mode might be assigned to the operators A, B, D, and the delegated-usage mode might be assigned to the operators C and E; and the payment terminal is pre-configured according to this assignment. When one of the operators of the plurality of operators, e.g. the operator A or the operator C, starts to use the payment terminal, e.g. to perform a transaction, the usage mode assigned to this operator, i.e. in this example the direct-usage mode and the delegated-usage mode, respectively, is automatically selected by the payment terminal, and the payment terminal performs the transaction using the selected usage mode, i.e. in this example the direct-usage mode and the delegated-usage mode, respectively.

The method described so far started from a state in which the payment terminal has a terminal-specific access key stored therein. There are various options of how the terminal- specific access key is obtained and stored. In some optional examples the terminal-specific access key used by the controlling entity for symmetric encryption is derived from a controlling-entity-specific master-access key using the terminal-identification number, e.g. payment-terminal serial number, or an additional identification number of the payment terminal, e.g. a random number generated for each individual payment terminal. The controlling-entity-specific master-access key may be unique to each controlling entity and payment-terminal manufacturer. The controlling-entity-specific master-access key is generated securely in the controlling entity's TRSM, and is optionally transmitted to the manufacturer, i.e. the terminal provider, in a confidentiality-securing manner, and is optionally stored there in another TRSM. In some examples the terminal-specific access key is stored in the payment terminal after being transmitted to the payment terminal in a confidentiality-securing manner by a terminal provider, i.e. the manufacturer of the payment terminal. The terminal-specific access key can be loaded into the payment terminal in a secure room at the terminal provider's, i.e. at the terminals provider's manufacturing facilities, before the payment terminal is delivered to the controlling entity.

In some examples the terminal- specific access key is derived, by the terminal provider, from a controlling-entity-specific master-access key by using the terminal-identification number, or an additional identification number of the payment terminal. The terminal provider retrieves the controlling-entity-specific master-access key, for example, from a TRSM on which that key is stored.

The terminal provider may then perform a derivation operation on the controlling-entity- specific master-access key using the terminal-identification number of that payment terminal. For example, cipher block chaining may be used. The cipher block chaining (CBC) algorithm described in ISO 9797-1, for example, uses 16 bytes (length of a double length key) derivation data. This derivation can be composed of the last eight bytes (right part) of the terminal-identification number in binary coded decimals (BCD) padded with binary zeroes on the left and the first eight bytes (left part) of the terminal-identification number in binary coded decimals (BCD) padded on 8 bytes XOR [FF FF FF FF FF FF FF FF]. In this context F stands for the highest hexadecimal value and XOR stands for "exclusive or", which is a logical operation that outputs true whenever both inputs differ, i.e. one is true, the other is false.

A terminal-identification number of, for example, 123456789 yields a right part of [00 .00 00 01 23 45 67 89] and a left part of [00 00 00 01 23 45 67 89] XOR [FF FF FF FF FF FF FF FF] = [FF FF FF FE DC BA 98 76]. This results in a derivation data block of [FF FF FF FE DC BA 98 76 00 00 00 01 23 45 67 89] used for the derivation of the controlling-entity-specific master-access key leading to the terminal-specific access key.

Once the key has been fed (or "injected") into the payment terminal, the payment terminal can be delivered and installed into the owner's premises. In some examples the controlling-entity-specific master-access key is transmitted to the terminal provider in a confidentiality-securing manner by the controlling entity. The controlling entity, for example, generates the controlling-entity-specific master-access key, which is used both for deriving the terminal-specific access key at the controlling entity's end and for implantation of the terminal-specific access key into the payment terminal by the terminal provider.

In some examples authorization for any number of operators and/or payment providers and thereby usage of the payment terminal by those operators and/or payment providers can be added dynamically, without physical intervention on the payment terminal. In other words, usage of the payment terminal by these operators and/or payment providers can be granted by the controlling entity remotely, without physical contact with the payment terminal.

Since the operator- and terminal-specific transport key is determined by the payment provider, e.g. by transmitting the master key from which the individual operator- and terminal-specific transport keys are derived or by transmitting the operator- and terminal-specific transport key itself, usage of the payment terminal by different operators is not limited to a predefined maximum number of different users. Only the terminal-specific access key is pre-installed in the payment terminal, all other keys needed for payment transactions performed by different operators are provided to the payment terminal in subsequent encrypted transmissions. Those transmissions are encrypted with the terminal-specific access key or are encrypted with keys derived from already received keys. In some examples the confidentiality-securing manner, in which the operator-specific master- transport key is transmitted from the payment provider to the controlling entity, is an asymmetric encryption-key algorithm. Generally, a communication being sent should not be readable during transit (preserving confidentiality) and the communication should not be modifiable during transit (preserving the integrity of the communication). Combining public- key cryptography with an enveloped public key encryption (EPKE) method, allows for relatively secure communication over an open networked environment. In public-key cryptography asymmetric key algorithms are used, where a key used to encrypt a message is not the same as the key used to decrypt the message. Each user has a pair of cryptographic keys - a public encryption key and a private decryption key. The keys are related mathematically, but parameters are chosen so that calculating the private key from the public key is either impossible or prohibitively expensive.

In some embodiments the communication between the payment terminal and the controlling entity and that between the payment terminal and the payment provider are independent of each other. The transactions conducted with the payment terminal, for example, are dealt with directly between the payment terminal and the payment provider, thereby circumventing the controlling entity after an initial setup phase, i.e. after distributing the operator- and terminal- specific transport key from the controlling entity to the payment terminals. The initial setup phase on the other hand may be dealt with by the controlling entity without inclusion of the payment provider. Hence, the operator- and terminal-specific transport key and the operator- and terminal-specific initial-encryption key are received by the payment terminal via distinct communication channels. While the operator- and terminal-specific transport key is received from the controlling entity via a first communication channel not involving the payment provider, the operator- and terminal-specific initial-encryption key is received from the payment provider via a second communication channel not involving the controlling entity.

Hence, there is also cryptographic segregation between the controlling entity and the plurality of payment providers. A payment provider is not involved in the injection of the operator- and terminal-specific transport key for a particular operator into the payment terminal, and does not need to know (and will not know) the terminal-specific access key, which is used to inject the operator- and terminal-specific transport key into the payment terminal. On the other hand, the controlling entity is not involved in the transmission of the operator- and terminal- specific initial encryption key from a payment provider to the payment terminal for a particular operator, but the operator- and terminal-specific initial encryption key can rather be directly transmitted from the payment provider to the payment terminal without passing the controlling entity. Therefore, the controlling entity does not need to know (and will not know) the operator- and terminal-specific initial encryption key. Data exchanged in payment transactions may be directly transmitted between the operator using the payment terminal and the payment provider, without passing the controlling entity. As the data exchanged in payment transactions between the operator using the payment terminal and the payment provider are encrypted by means of a key cryptographically derived from the operator- and terminal-specific initial encryption key, the controlling entity could not get hold of the plaintext of payment-transaction data (even if they were transmitted via the controlling entity). Hence, due to the cryptographic segregation between the controlling entity and the plurality of payment providers, although the controlling entity can control whether an operator using the payment terminal can communicate with payment providers, the contents of the communication exchanged in payment transactions is not accessible by the controlling entity.

In some embodiments the payment terminal is equipped with an embedded computer system, e.g. in the form of a microcontroller. The embedded computer system has non-volatile readonly memory. Payment-terminal-configuration functions and payment-transaction functions of the payment terminal are implemented by at least one computer program stored in the readonly memory and executable by the processor. The operating system and application software stored in such an embedded system's read-only memory is typically referred to as "firmware". In some embodiments the read-only memory storing said at least one computer program is electrically erasable programmable read-only memory (EEPROM). In some embodiments the read-only memory of the payment terminal is flash EEPROM. Erase circuits of flash EEPROM may be shared by large blocks of cells (e.g. 512x8). In other embodiments the read-only memory of the payment terminal is non-flash EEPROM. Non- flash EEPROM is, for example, byte-programmable EEPROM, which allows individual bytes to be erased and reprogrammed.

The flash EEPROM, for example, may be NAND-flash EEPROM or NOR-flash EEPROM. The designations "NOR" and "NAND" refer to the structure of the interconnections between memory cells. In NOR-flash EEPROM, cells are connected in parallel to the bit lines, allowing cells to be read and programmed individually. The parallel connection of cells resembles the parallel connection of transistors in a CMOS NOR gate. In NAND-flash EEPROM, cells are connected in series, resembling a NAND gate.

In some embodiments with EEPROM (flash or non-flash EEPROM) the EEPROM can only be re-programmed using programming and/or erasing voltages (negative and/or positive) which have an absolute value greater than the usual voltage for read operation of the readonly memory. In some of these embodiments the payment terminal does not provide such programming or erasing voltages so that the payment device cannot be re-programmed by a user, e.g. the operator. The computerized controlling-entity system disclosed is arranged to configure a payment terminal, which has a terminal-identification number, to be usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal. The controlling-entity system may be arranged to derive an operator- and terminal-specific transport key from an operator-specific master-transport key by using the terminal- identification number.

The controlling-entity system may be arranged to encrypt the operator- and terminal-specific transport key symmetrically with a terminal-specific access key and transmit the encrypted operator- and terminal-specific transport key to the payment terminal.

In some examples the computerized controlling-entity system is arranged to configure the payment terminal according to any or all of the above-mentioned examples. The computerized payment-provider system disclosed is arranged to configure a payment terminal, which has a terminal-identification number, to be usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal.

The payment-provider system may derive an operator- and terminal-specific transport key from an operator-specific master-transport key by using the terminal-identification number and may derive an operator- and terminal-specific initial-encryption key from an operator- specific base-derivation key also by using the terminal-identification number, or by using an additional identification number of the payment terminal.

The payment-provider system is arranged to transmit the operator-specific master-transport key to a controlling entity in a confidentiality-securing manner, wherein the payment terminal is associated with the controlling entity. Alternatively, the payment-provider system is arranged to transmit the operator- and terminal-specific transport key to the controlling entity in a confidentiality-securing manner.

The payment-provider system may encrypt the operator- and terminal-specific initial- encryption key symmetrically with the operator- and terminal-specific transport key and may feed the operator- and terminal-specific initial-encryption key into the payment terminal by transmitting the encrypted operator- and terminal-specific initial-encryption key to the payment terminal. The payment-provider system may derive an operator- and transaction-specific encryption key from the operator- and terminal-specific initial-encryption key using a transaction- specific number associated with the transaction, when performing a transaction with the payment terminal. In some examples the computerized payment-provider system is arranged to configure the payment terminal according to any or all of the above-mentioned examples.

The payment terminal disclosed is programmed to be usable as a payment terminal shared by a plurality of operators with cryptographic segregation between the different operators of the payment terminal. The payment terminal is arranged to communicate with at least one payment provider to perform payment transactions and is arranged to be associated with a controlling entity that controls usage of the payment terminal in an operator-selective manner. The payment terminal may have at least one tamper-resistant security module (TRSM) used for key management. The at least one TRSM, as mentioned above, for example, has physical characteristics that make successful tampering of information stored therein difficult and improbable, e.g. as defined in ANSI X9.24- 1-2009 (Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques). Such physical characteristics may include, for example, a memory on which cryptographic keys are stored, which oxidizes when in contact with air, i.e. self-destructs, to make any stored cryptographic key unreadable.

The payment terminal's tamper-resistant security module(s) is (are) arranged to store an manage within the TRSM one ore more cryptographic keys, that is at least the terminal- specific access key to enable usage of the payment terminal to be controlled by the controlling entity in the operator-selective manner.

In some examples the at least one operator- and terminal-specific transport key and/or the at least one encrypted operator- and terminal- specific initial-encryption key may be decrypted at the payment terminal upon receipt or input. The at least one operator- and terminal-specific transport key and/or the at least one operator- and terminal-specific initial-encryption key may also be stored and managed within the secure memory, e.g. the TRSM. The securely stored decrypted operator- and terminal-specific transport key and/or the securely stored decrypted operator- and terminal-specific initial-encryption key is/are then readily available for the decryption of the encrypted operator- and terminal-specific initial-encryption key and/or for obtaining the operator- and transaction-specific encryption key.

The operator- and transaction-specific encryption key, or a key derived from it, may then be used, for example, for encrypting all data, or sensitive data, exchanged during a transaction performed by an operator with the payment terminal.

In other examples in which the decrypted version of the operator- and terminal-specific transport key and/or the operator- and terminal-specific initial-encryption key is/are not stored in a secure storage of the payment terminal, for example, the payment terminal's TRSM, the encrypted operator- and terminal-specific transport key and/or the encrypted operator- and terminal-specific initial-encryption key can be stored a normal (unsecure) memory, and is/are only decrypted "on the fly" when needed for the decryption of the encrypted operator- and terminal-specific initial-encryption key and/or for obtaining the operator- and transaction- specific encryption key to perform a transaction with the payment terminal, e.g. a payment transaction.

In some examples the payment terminal is configured according to any or all of the above mentioned examples.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention are now described, also with reference to the accompanying drawings, wherein

Fig. 1 illustrates a diagram summing up cryptographic key generations, derivations, and exchanges between different payment-transaction actors (divided into Fig. la and Fig. lb),

Fig. 2 illustrates an exemplary key-derivation algorithm that generates a new key derived from a basic key,

Fig. 3a illustrates functional relationships between the different payment-transaction actors shown in Fig. 1,

Fig, 3 b illustrates the termination of use of a payment terminal by a particular operator, in a representation analogous to that of Fig. 3 a,

Fig. 3 c illustrates use termination by a remote wipe of cryptographic keys from a payment terminal,

Fig. 4 illustrates key exchanges for an encrypted data transmission, Fig. 5 illustrates an exemplary payment terminal for payment cards,

Fig. 6 illustrates a tamper-resistant security module of the payment terminal shown in

Fig. 5,

Fig. 7 illustrates an exemplary computer system, according to the controlling-entity system and the payment-provider system described herein, arranged to configure the payment terminal,

Fig. 8 illustrates an embedded computer system in a payment terminal.

The drawings and the description of the drawings are of examples of the invention and are not of the invention itself.

DESCRIPTION OF EMBODIMENTS

In the exemplary embodiment illustrated by Figures la and lb, key exchanges between the payment provider 2, e.g. the acquirer of an airline, the controlling entity 3, e.g. the airport owner, the payment-terminal manufacturer, i.e. the terminal provider 5, and the payment terminal 1 are shown.

Curved arrows indicate a derivation either by using the terminal-identification number 44 of the payment terminal 1 or a transaction-specific number 27 of an ongoing transaction 26. The key derivations based on the terminal-identification number 44 are indicated as SI, S3, S5, S7, and S10. The key derivations based on a transaction-specific number 27 are indicated as S13 and S14. Line-dotted arrows indicate symmetrical encryptions S8 and S l l, whereas dotted arrows indicate secure transmissions S2, S4, and S6, e.g. by a courier. Line-dotted boxes around keys indicate sent copies of these keys.

The controlling entity 3 generates a controlling-entity-specific master-access key Kl and securely transmits S2 the controlling-entity-specific master-access key Kl to the terminal provider 5 that manufactures the payment terminals 1 for the controlling entity 3. The terminal provider 5 stores this key, as it does with the keys of all the other controlling entities the terminal provider 5 does business with. This controlling-entity-specific master-access key Kl is unique for each controlling-entity-to-terminal-provider relation, i.e. business contract.

The terminal provider 5 derives S3 a terminal-specific access key K2 for each payment terminal 1 based on the controlling-entity-specific master-access key Kl and the identification number 44 of the payment terminal 1. The future owner of the payment terminals 1, i.e. the controlling entity 3, can derive SI the individual terminal-specific access keys K2 in the same way, as both the terminal provider 5 and the controlling entity 3 share the same key derivation algorithm (see Fig. 2). The terminal-specific access key K2 is implanted S4 into the corresponding payment terminal 1 in a secure room at the terminal provider's production facilities.

The above-described way of implantation of the terminal-specific access key K2 into the payment terminal 1 is optional. Various alternative ways for the terminal-specific-access-key implantation are also covered.

The payment provider 2 generates an operator-specific master-transport key K3 and securely transmits S6 the operator-specific master-transport key K3 to the controlling entity 3, for example, by means of an asymmetric encryption algorithm or by a certified courier. This operator-specific master-transport key K3 is unique for each controlling-entity-to-operator relation, i.e. business contract.

The controlling entity 3 derives S7 an operator- and terminal-specific transport key K4 from the operator-specific master-transport key K3 and the terminal-identification number 44 of the payment terminal 1. The payment provider 2 can derive S5 the individual operator- and terminal-specific transport keys K4 in the same way, as both the payment provider 2 and the controlling entity 3 share the same key-derivation algorithm (see Fig. 2).

The controlling entity 3 encrypts S8 the individual operator- and terminal-specific transport keys K4 with the corresponding terminal-specific access keys K2 before transmitting the operator- and terminal-specific transport keys K4 to the corresponding payment terminals 1. The controlling entity 3 transmits S9 the operator- and terminal-specific transport keys K4 to the corresponding payment terminals 1. In other words, each operator- and terminal-specific transport key K4 is encrypted S8 by an individual terminal-specific access key K2 corresponding to the same terminal-identification number 44 and can only be decrypted in the corresponding payment terminal 1 , which has been loaded S4 with the same terminal-specific access key K2. In some embodiments, the operator- and terminal -specific transport key K4 is decrypted with the corresponding terminal-specific access key K2 upon receipt at the payment terminal 1 , and the decrypted operator- and terminal-specific transport key K4 is stored in the payment terminal 1, e.g. in a secure manner, for example in a tamper-resistant security module (TRSM) 45 (Fig. 6, Fig. 8).

In an alternative embodiment the operator- and terminal-specific transport key K4 is not decrypted upon receipt, but is stored still in the encrypted form in the payment terminal 1 , and is only decrypted when needed, i.e. it is "decrypted on the fly". In this alternative embodiment security for the operator- and terminal-specific transport key K4 is provided by keeping it encrypted, rather than by storing it in the unencrypted form in a secure storage, such as a TRSM 45. Hence, in this alternative embodiment the operator- and terminal-specific transport key K4 can optionally be stored in a non-secure memory, e.g. a normal memory (for example, a ROM) outside the TRSM 45.

The payment provider 2 generates an operator-specific base-derivation key 5, which is unique for each operator-to-payment-provider relation, i.e. business contract. The payment provider 2 derives S 10 an individual operator- and terminal-specific initial-encryption key K6 for each payment terminal 1 from the operator-specific base-derivation key K5 and the terminal-identification number 44 of the payment terminals 1.

The payment provider 2 encrypts Sll the individual operator- and terminal-specific initial - encryption keys K6 with the corresponding operator- and terminal-specific transport keys K4 before transmitting the operator- and terminal-specific initial-encryption keys K6 to the corresponding payment terminals 1. The payment provider 2 transmits S12 the encrypted operator- and terminal-specific initial-encryption keys K6 to the corresponding payment terminals 1. In other words, each operator- and terminal-specific initial-encryption key K6 is encrypted Sl l by an individual operator- and terminal-specific transport key K4 corresponding to the same terminal-identification number 6 and can only be decrypted in the corresponding payment terminal 1 , which has been fed in S9' with the respective operator- and terminal-specific transport key K4. In some embodiments, the operator- and terminal- specific initial-encryption key K6 is decrypted with the corresponding operator- and terminal- specific transport key 4 upon receipt at the payment terminal 1 , and the decrypted operator- and terminal-specific initial-encryption key K6 is stored in the payment terminal 1, e.g. in a secure manner, for example in a tamper-resistant security module (TRSM) 45 (Fig. 6, Fig. 8). In an alternative embodiment the operator- and terminal-specific initial-encryption key K6 is not decrypted upon receipt, but is stored still in the encrypted form in the payment terminal 1 , and is only decrypted when needed, i.e. it is "decrypted on the fly". In this alternative embodiment security for the operator- and terminal-specific initial-encryption key K6 is provided by keeping it encrypted, rather than by storing it in the unencrypted form in a secure storage, such as a TRSM 45. Hence, in this alternative embodiment the operator- and terminal-specific initial-encryption key K6 can optionally be stored in a non-secure memory, e.g. a normal memory (for example, a ROM) outside the TRSM 45.

The payment terminal 1 derives S14 an operator- and transaction-specific encryption key K7 from the operator- and terminal-specific initial-encryption key K6 and the transaction-specific number 27 of an ongoing transaction 26. The payment provider 2 can derive S13 the individual operator- and transaction-specific encryption keys K7 in the same way, as both the payment terminal 1 and the payment provider 2 share the same key derivation algorithm (see Fig. 2).

The operator- and transaction-specific encryption key K7 is the basis for deriving, for example, a PIN-encryption key, sensitive-data-encryption keys, and MAC-signature keys used in the transmission of encrypted data S17 between the payment terminal 1 and the payment provider 2, e.g. currency-transfer operations, authentication requests, or the like, during a transaction 26.

Alternatively, in other embodiments the operator- and transaction-specific encryption key K7 may be used directly for encrypting the data exchanged between the payment terminal 1 used by an operator 4 and a payment provider 2 during the transaction 26. Thereby, the sensitive data is encrypted by the operator- and transaction-specific encryption key K7 during the transmission of encrypted data S17 between the payment terminal 1 used by the operator 4 and the payment provider 2.

An exemplary key-derivation algorithm, the cipher block chaining (CBC) algorithm described above, is shown in Fig. 2. A basic key having n basic-key blocks 10, 11, 12 is used to create new keys, which are based on the basic key and a derivation data 15, and have n derived-key blocks 18, 19, 20. This derivation data 15 can be a hexadecimal number, based on the terminal-identification number 44 or a transaction-specific number 27, with a length corresponding to the basic key, e.g. double the key length.

A new key is generated, i.e. derived, from the basic key by encrypting all basic-key blocks 10, 11, to 12 with a block cipher encryption 16, which has a given cipher block size. The encryption is sequential and the basic key is padded to a multiple of the cipher block size.

The first basic-key block 10 is XORed 14, i.e. is summed modulo two, with an initialization vector (IV) 13. Without this initialization vector 13 each subsequent derivation of the same first block would yield the same derived block. Since this algorithm is used for key derivation, based on a terminal- or transaction-specific number 44, 27, and not for data encryption, i.e. the derivation data 15 used for the block cipher encryption 16 changes for each derived key, the XORing of the first basic-key block 10 with an initialization vector 13 is optional. The second basic-key block 11 is combined 17 with the first derived-key block 18 by XORing 14. Hence, an input of the block cipher encryption 16 is dependent on an output of a preceding block cipher encryption 16. The algorithm is therefore called cipher block chaining (CBC) algorithm. The second basic-key block 11 XORed the first derived-key block 18 yields the second derived-key block 19 after block cipher encryption 16 with the derivation data 15.

This process is repeated until all n basic-key blocks have been XORed with the preceding derived-key block and have been encrypted with the derivation data 15. This way, each derived-key block depends on all basic-key blocks processed up to that point. The resulting derived key has the same length as the basic key. As this derivation is a unique mapping rule, different entities in different locations can derive the same key from the same basic key with the above described algorithm.

Functional relationships and a chronological order of activities (reference signs 21 to 26 in ascending order) for a payment transaction, executed by different payment- and transaction actors, are illustrated for an example shown in Fig. 3a.

The controlling entity 3 instructs a terminal provider 5, i.e. a payment terminal manufacturer, to produce the payment terminal 1 by making a business contract, i.e. by ordering 21 the payment terminal 1 from the terminal provider 5.

The terminal provider 5 delivers 22 the payment terminal 1 based on the controlling entity's specifications to the controlling entity 3 on completion of the payment terminal 1. The specifications include, for example, an implanted given access key, e.g. a terminal-specific access key 2, derived from a controlling-entity-specific master-access key Kl and the terminal-identification number 44 of the payment terminal 1.

After delivery 22 of the payment terminal 1 to the controlling entity 3, an operator 4 can request usage 23 of the payment terminal 1. The operator can, for example, rent the payment terminal 1 from the controlling entity 3 for the duration of a business contract.

Once the controlling entity 3 grants the operator 4 the right to use the payment terminal 1 (the grant being labelled as 24) an operator- and terminal-specific transport key K4 is injected S9' into the payment terminal 1 by the controlling entity 3. The operator- and terminal-specific transport key K4 is individually chosen for the operator 4 and enables the operator 4 to operate the payment terminal 1.

The payment terminal 1 can then be used 25 by the operator 4 to perform transactions 26 with one or more payment providers 2, i.e. acquirers of the operator 4. During these transactions 26 encrypted transmissions of sensitive data S 17 are exchanged between the payment terminal 1 and a payment provider 2.

Fig. 3b illustrates the termination of use of a payment terminal 1 by a particular operator 4, in a representation analogous to that of Fig. 3 a.

In the example of Fig. 3b the operator 4 wants to terminate the operator's ability to use 25' the payment terminal 1, and therefor informs the controlling entity 3 correspondingly 23', e.g. by a termination message. Upon receiving the termination message from the operator 4 the controlling entity 3 revokes usage 24' of the payment terminal 1 by the operator 4 by deleting the corresponding cryptographic keys, e.g. the operator- and terminal-specific transport key K4 and the operator- and terminal-specific initial-encryption key K6 associated with operator 4 from the payment terminal 1. Alternatively or additionally the controlling entity 3 can initiate the deletion of the cryptographic keys, e.g. the operator- and terminal-specific transport key K4 and the operator- and terminal-specific initial-encryption key K6, of a an operator 4 who should no longer be able to use the payment terminal 1.

After the key deletion the payment terminal 1 has no operator- and terminal-specific initial- encryption key K6 for the operator 4 at issue any more, and could not decrypt the key K6 any more even if it received the key K6 decrypted by the operator- and terminal-specific transport key K4 anew from payment provider 2. Without the (decrypted) operator- and terminal- specific initial-encryption key K6 no exchange of meaningful transaction data for the payment provider 2 at issue is possible anymore, and therefore no transaction 26' between the payment terminal 1 and the payment provider 2 can take place for the provider 2 at issue anymore; however, since the key deletion is operator-specific transactions 26 of other operators remain unaffected.

An exemplary key revocation of an operator- and terminal-specific transport key K4 from a payment terminal 1 initiated by the controlling entity 3 by remote, is illustrated in Fig. 3c. The dashed boxes indicate to-be deleted encryption keys, the dotted arrow indicates a symmetrical encryption, and the solid arrows indicate a data transmission.

If the controlling entity 3 wants to revoke an operator's ability to use 24' the payment terminal 1 the controlling entity 3 sends an operator-specific key-deletion command to the payment terminal 1. When the payment terminal 1 has received the key-deletion command it performs the commanded key deletion for the operator 4 at issue.

Exemplary activities to prepare a payment transaction 26 at a check-in desk are shown in Fig. 4. At S15 usage of the payment terminal 1 is first of all requested at 23 by an operator 4, e.g. when the operator 4 opens a contractual relationship with the controlling entity 3.

If usage of the payment terminal 1 is granted at 24 by the controlling entity 3 of the airport to the operator 2, an operator- and terminal-specific transport key K4 is fed into the payment terminal S9'. The operator- and terminal-specific transport key K4 is symmetrically encrypted S8 with a terminal-specific access key K2, where both keys are derived SI, S7 with the same terminal- identification number 44. The injection of the operator- and terminal-specific transport key K4, labeled as S9' in Fig. 4, involves transmitting S9 the symmetrically encrypted operator- and terminal-specific transport key 4 from the controlling entity 3 to the payment terminal 1. In some embodiments, the key injection S9' also involves decrypting the encrypted operator- and terminal-specific transport key K4 with the terminal-specific access key K2, which was previously stored in the payment terminal 1 , e.g. during production, and storing of the operator- and terminal- specific transport key K4 within the payment terminal 1 upon decryption, e.g. in a secure manner. In other embodiments, the decryption of the operator- and terminal-specific transport key 4 may be deferred until the decrypted operator- and terminal- specific transport key 4 is actually needed. It can therefore be stored in a non-secure manner. The activity of decrypting the encrypted operator- and terminal-specific transport key K4 with the stored terminal-specific access key K2 in the payment terminal 1 "on the fly" will then form part an initial part of the decryption of the encrypted operator- and terminal-specific initial-encryption key K6 described below.

As the name suggests, the operator- and terminal- specific transport key 4 is used for transportation of another encryption key in a confidentiality-securing manner, i.e. encryption. An operator- and terminal-specific initial-encryption key 6 is fed into the payment terminal SI 2', which is the basis for transaction-related encryption keys.

The operator- and terminal-specific initial-encryption key K6 is symmetrically encrypted Sl l with the operator- and terminal-specific transport key K4, where both keys are derived S7, S10 with the same terminal-identification number 44. The injection of the operator- and terminal-specific initial-encryption key 6, labeled as SI 2' in Fig. 4, involves transmitting S12 the symmetrically encrypted operator- and terminal-specific initial-encryption key K6 from the payment provider 2 to the payment terminal 1. In some embodiments, the key injection S 12' also involves decrypting the encrypted operator- and terminal-specific initial- encryption key K6 with the decrypted operator- and terminal-specific transport key K4 in the payment terminal 1, and storing of the operator- and terminal-specific initial-encryption key K6 upon decryption within the payment terminal 1 , e.g. in a secure manner. In other embodiments, the decryption of the encrypted operator- and terminal-specific initial- encryption key K6 may be deferred until the decrypted operator- and terminal-specific initial- encryption key K6 is actually needed. It can therefore be stored in a non-secure manner. The activity of decrypting the encrypted operator- and terminal-specific initial-encryption key K6 with the operator- and terminal-specific transport key K4 decrypted in the payment terminal 1 "on the fly" will then form part of the derivation S14 of the operator- and transaction-specific encryption key K7 described below.

At a certain stage there will be a need to start doing some transactions with the payment terminal 1 for one of the operators 4. For example, in the case of shared airport's kiosks, a customer would select the airline at issue (= operator 4) on the kiosk's screen; and in the case of shared check-in workstations an airline's agent (= operator's 4 agent) would log in at the payment terminal to start the check-in for the flight.

As a first sub-process, the operator- and terminal-specific initial-encryption key K6 associated with the operator 4 (e.g. the airline) at issue is selected, depending on the operator associated with the customer or the agent performing the transaction.

In some optional embodiments the payment terminal 1 provides more than one usage modes, or more than one type of "device behavior". The payment terminal 1 is arranged to provide the various types of device behavior. In these embodiments, as a further optional sub-process, when use of the payment terminal 2 is started to perform a transaction, the device behavior associated with the operator at issue is automatically and dynamically selected. For example, two different usage modes may be provided in some embodiments: A "direct-usage mode" and a "delegated-usage mode". In the direct-usage mode the payment terminal 1 is initialized to return all payment data back to an operator application over a serial connection to the operator 4; it is then up to the operator application to transmit the data to the payment provider 2. In the delegated usage-mode the payment terminal 1 is initialized to establish a direct connection over a network interface providing access to a wide-area network (WAN) to the payment provider 2. In embodiments in which the payment terminal 1 to provide the delegated-usage mode the payment terminal 1 is therefore equipped with a suitable network interface, and the payment terminal 1 is pre-configured with network parameters (such as IP, DNS, DHCP, Firewalls, VPN, ...) suitable to communicate directly with the payment provider 2 over the WAN. If the delegated-usage mode is selected, a TCP/IP connection is established to the payment provider's host, and all further configuration messages will be initiated by the payment provider's host using this connection.

The below exemplary XML code shows an example of the initialization of the delegated mode. It can be seen from the exemplary XML code that the automatic selection is controlled by a variable named "<usageMode>" which, in this example, can take the values "delegated" and "direct":

<?xml version=" 1.0" ?>

<usageMode>delegated</usageMode>

<host>payment.com</host>

</networkParameters>

</operatorUsageRequest> As another sub-process, after the operator- and terminal-specific initial-encryption key K6 has been obtained and decrypted at the payment terminal 1 (either in advance, or "on the fly" during the initialization-of-a-transaction stage), transaction keys for further transaction activities can be derived from the decrypted operator- and terminal-specific initial-encryption key K6 using a transaction-specific number 27, which is labeled as S14 in Fig. 4. As indicated by the labeling, the derivation S14 of the operator- and transaction-specific encryption key K7 from the operator- and terminal-specific initial-encryption key K6 by the payment terminal 1 using the transaction-specific number 27 is one of these transaction keys. The derivation is performed in an analogous manner at the payment provider 2, there labeled as SI 3. Further transaction keys, derived from the operator- and transaction-specific encryption key K7 using the transaction-specific number 27 or another transaction-specific number, e.g. a PIN-encryption key, sensitive-data-encryption keys, and MAC-signature keys, are also covered by the activity labeled SI 3, S14 in Fig. 4. In some embodiments the controlling entity 3 can also control the usage of the payment terminal 1 in the operator-selective manner by a revocation of the operator- and terminal- specific transport key K4. The controlling entity 3 has remote access to the TRSM of the payment terminal 1 and can order the payment terminal 1 to delete key(s) associated with a specific operator. The below exemplary XML code shows an example of the revocation of the operator- and terminal-specific transport key K4 defined by a merchant code identifying the operator 4 at issue (here "Ml ") and a payment provider code (here "PI "):

<?xml version="1.0" ?>

</merchantAccessRemoveRequest>

Access to the payment terminal is granted in this example by authentication data, here marked by a tag "authenticationData". Upon positive verification of the authentication data the payment terminal 1 deletes' the operator- and terminal-specific transport key K4 and the operator- and terminal-specific initial-encryption key K6 of the identified operator 4, and optionally further data associated with that operator 4, such as a transaction counter associated with the identified operator 4, stored in the payment terminal 1.

In Fig. 4, in embodiments in which the payment terminal 1 has an optional usage-mode functionality, the label S14 also represents the optional activity of the operator-dependent selection of the usage mode (e.g. the selection of the direct-usage mode or the delegated- usage mode).

Those further transaction keys are used for encrypting S 16 sensitive data for transmission between the payment terminal 1 and the payment provider 2, e.g. a PIN for an account that is to be debited.

Hence, the actual encrypted transmission of sensitive data S 17 of the payment transaction 26 between the payment terminal 1 and the payment provider 2 can be performed using the above-mentioned transaction keys.

An exemplary payment terminal 1, on which the key injections labeled S9' and SI 2' in Fig.4 and described in conjunction with Fig. 1 and Fig. 4 are performed, is illustrated in Fig. 5. The payment terminal 1 shown in Fig. 5 has a PIN pad 41 to accept and encrypt a cardholder's personal identification number (PIN). The PIN pad 41 utilizes access to a payment card 50 (in the case of a chip card) and allows secure entering of the PIN into the payment terminal 1 and subsequent encryption of the PIN by the payment terminal 1.

The PIN is encrypted immediately upon entry and an encrypted PIN block is created. This encrypted PIN block is erased as soon as it has been sent from the PIN pad 41 to the attached payment terminal 1 and/or the chip card 50. The PINs are encrypted using a triple DES algorithm.

The payment terminal 1 is equipped with a display 40 to show relevant data to both the customer, e.g. a passenger, and the operator 4, as for example, a payment-order amount or an authentication status of the entered PIN.

Additionally, the payment terminal 1 is equipped with a payment-card slit reader 42, where the payment card 50 is inserted into the payment terminal 1 and card data is read from the payment card 50, e.g. for verification of the customer's identity, i.e. checking if the customer can provide the correct PIN for the payment card 50.

In alternative embodiments the payment terminal 1 is equipped with a payment-card swipe reader in addition, or as an alternative, to the payment-card slit reader 42. In these alternative embodiments the card data is read from the payment card 50 by swiping the payment card 50 to a swipe-reader's slit.

Fig. 6 depicts additional features of the exemplary payment terminal 1 illustrated in Fig. 5. The payment terminal 1 has a memory 43 and a tamper-resistant security module (TRSM) 45. The TRSM 45 can be a logical partition of the memory 43 or can, alternatively, be an individual secure-reading-and-exchange-of-data (SRED) module, on which the individual terminal-specific access, transport, and encryption the key 2, and optionally the encryption keys K4, and K6 are stored. The memory 43 includes a non-volatile memory where executable program code, e.g. compiled C code, and/or interpretable script code is stored.

The payment terminal's unique terminal-identification number 44 is embossed on the housing of the payment terminal 1. In an alternative example of the payment terminal 1 , the terminal- identification number 44 is stored on the memory 43 and can be read out by authorized parties. Thereby, the terminal-identification number 44 is not visible to anyone without clearance.

A diagrammatic representation of an exemplary computer system 100 arranged to execute a set of instructions 110, to cause the computer system to perform any of the methodologies used for configuration of a payment terminal 1 for a payment transaction 26, as described herein, is shown in Fig. 7. The computerized controlling-entity system and the computerized payment-provider system may be such a computer system 100.

The computer system 100 includes a processor 102, a main memory 104 and a network interface 108. The main memory 104 includes a user space 104', which is associated with user-run applications, and a kernel space 104", which is reserved for operating-system- and hardware-associated applications. The computer system 100 further includes a static memory 106, e.g. non-removable flash and/or solid state drive and/or a removable Micro or Mini SD card, which permanently stores software enabling the computer system 100 to execute functions of the computer system 100. Furthermore, it may include a video display 103, a user interface control module 107 and/or an alpha-numeric and cursor input device 105. Optionally, additional I/O interfaces 109, such as card reader and USB interfaces may be present. The computer system components 102 to 109 are interconnected by a data bus 101. In some exemplary embodiments the software programmed to carry out the method of configuring the payment terminal 1 discussed herein is stored on the static memory 106. The method of configuring the payment terminal 1 discussed herein is performed via the network interface device 108. An executable set of instructions (i.e. software) 110 embodying any one, or all, of the methodologies described above, resides completely, or at least partially, permanently in the non- volatile memory 106. When the instructions 110 are executed, process data resides in the main memory 104 and/or the processor 102. The software 110 may further be transmitted or received as a propagated signal 111 through the network interface device 108 from/to a software server within a local area network or the Internet.

Fig. 8 illustrates an embedded computer system 243 in a payment terminal 1. The payment terminal 1 has a read-only memory (ROM) 43a, a processor 202, and a tamper-resistant security module (TRSM) 45. The processor 202 and the read-only memory 43 a together form the embedded computer system 243, e.g. in the form of a programmable microcontroller. The read-only memory 43a may by an EEPROM, for example a flash EEPROM or a non-flash EEPROM. In embodiments in which the embedded computer system 243 of the payment terminal 1 corresponds to the computer system 100 of Fig. 7 the read-only memory 43a is represented by the static memory 106 in Fig. 7.

The read-only memory 43a of the embedded computer system 243 permanently stores firmware comprising one or more computer programs 211 to perform payment-terminal- specific functions of the embedded computer system 243. The computer program 211 stored in the read-only memory 43a provides instructions 210 for the processor 202 that, when executed by the processor 202 perform the payment-terminal-configuration functions and payment-transaction functions of the payment terminal 1 described herein.

All publications and existing systems mentioned in this specification are herein incorporated by reference.

Although certain methods and products constructed in accordance with the teachings of the invention have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all embodiments of the teachings of the invention fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.

Claims

Claims:

1. A method of configuring a payment terminal (1) to become usable as a payment terminal (1) shared by a plurality of operators (4) with cryptographic segregation between the different operators (4) of the payment terminal (1), the payment terminal (1) communicates (SI 7) with at least one payment provider (2) to perform payment transactions (26), and being associated with a controlling entity (3) that controls usage of the payment terminal (1) in an operator-selective manner, the payment terminal (1) having a terminal-specific access key ( 2) stored therein, and a terminal-identification number (44), the method comprising: providing an operator- and terminal-specific transport key (K4), encrypted by the terminal-specific access key ( 2), to the payment terminal (1);

decrypting the encrypted operator- and terminal-specific transport key (K4) at the payment terminal (1) with the stored terminal- specific access key (K2);

deriving (S10), by the payment provider (2), an operator- and terminal-specific initial- encryption key (K6) from an operator-specific base-derivation key (K5) using the terminal- identification number (44), or an additional identification number of the payment terminal (1), and symmetrically encrypting (Sl l) the operator- and terminal-specific initial-encryption key (K6) with the operator- and terminal-specific transport key (K4);

transmitting (SI 2) the encrypted operator- and terminal-specific initial-encryption key (K6) to the payment terminal (1);

decrypting the encrypted operator- and terminal-specific initial-encryption key (K6) at the payment terminal (1) with the decrypted operator- and terminal-specific transport key (K4);

deriving (SI 3, SI 4), both at the payment provider (2) and the payment terminal (1), an operator- and transaction-specific encryption key (K7) from the operator- and terminal- specific initial-encryption key (K6) using a transaction-specific number (27) associated with this transaction (26), when performing a transaction (26) with the payment terminal (1).

2. The method of claim 1, wherein the operator- and transaction-specific encryption key (K7), or a key derived from it, is used to encrypt transaction data exchanged between the payment terminal (1) and the at least one payment provider (2) during transactions (26) performed after the configuring of the payment terminal (1).

3. The method of claim 1 or 2, wherein the payment terminal (1) is shared by at least two operators (4), and wherein an operator- and terminal-specific initial-encryption key ( 6) and an operator- and terminal -specific transport key (K4) are provided for each of the at least two operators (4), the operator- and terminal-specific initial-encryption keys (K6) of the at least two operators (4) being different from each other, and the operator- and terminal-specific transport keys ( 4) of the at least two operators (4) being different from each other, and wherein at least the different operator- and terminal-specific initial-encryption keys (K6) of the at least two operators (4) are hold simultaneously in the payment terminal (1).

4. The method of any one of claims 1 to 3, wherein the operator- and terminal-specific transport key (K4) is provided to the payment terminal (1) by

transmitting (S6) an operator-specific master-transport key (K3) from the at least one payment provider (2) to the controlling entity (3) in a confidentiality-securing manner and deriving (S5, S7), both at the payment provider (2) and the controlling entity (3), the operator- and terminal-specific transport key (K4) from the operator-specific master-transport key (K3) using the terminal-identification number (44),

symmetrically encrypting (S8), by the controlling entity (3), the operator- and terminal-specific transport key (K4) with the terminal-specific access key (K2), and

transmitting (S9) the encrypted operator- and terminal-specific transport key ( 4) to the payment terminal (1),

the controlling entity (3) controlling the usage of the payment terminal (1) in the operator-selective manner by said transmission (S9) of the operator- and terminal-specific transport key (K4).

5. The method of any one of claims 1 to 3, wherein the operator- and terminal-specific transport key (K4) is provided to the payment terminal (1) by

deriving (S5) at the payment provider (2) the operator- and terminal-specific transport key (K4) from the operator-specific master-transport key (K3) using the terminal- identification number (44),

transmitting the operator- and terminal-specific transport key (K4) from the at least one payment provider (2) to the controlling entity (3) in a confidentiality-securing manner, symmetrically encrypting (S8), by the controlling entity (3), the operator- and terminal-specific transport key (K4) with the terminal-specific access key (K2), and transmitting (S9) the encrypted operator- and terminal-specific transport key (K4) to the payment terminal (1),

6. The method of claim 4 or 5, wherein the controlling entity (3) further controls the usage of the payment terminal (1) in an operator-selective manner by initiating a deletion of the operator- and terminal-specific transport key (K4) and the operator- and terminal-specific initial-encryption key (K6) from the payment terminal (1) from remote, i.e. by remote access to the payment terminal (1).

7. The method of any one of claims 1 to 3, wherein the operator- and terminal-specific transport key (K4) is provided to the payment terminal (1) by

manually inputting the encrypted operator- and terminal-specific transport key (K4) into the payment terminal (1),

the controlling entity (3) controlling the usage of the payment terminal (1) in the operator-selective manner by means of the operator- and terminal-specific transport key (K4).

8. The method of any one of claims 4, 5, or 7, wherein the usage of the payment terminal (1) is further controlled in an operator-selective manner by manual deletion of the operator- and terminal-specific transport key (K4) and the operator- and terminal-specific initial-encryption key (K6) from the payment terminal (1).

9. The method of any one of claims 1 to 8, wherein

the encrypted operator- and terminal-specific transport key (K4) is decrypted with the terminal-specific access key ( 2) at the payment terminal (1) upon receipt, and the decrypted operator- and terminal-specific transport key (K4) is stored in a secure storage (TRSM) (45) of the payment terminal (1); or

the received encrypted operator- and terminal-specific transport key (K4) is first stored in the payment terminal (1) in its encrypted form and is only later decrypted with the terminal-specific access key ( 2) at the payment terminal (1) when the decrypted operator- and terminal-specific transport key (K4) is required for the decryption of the encrypted operator- and terminal-specific initial-encryption key (K6) to perform the transaction (26) with the payment terminal ( 1 ).

10. The method of any one of claims 1 to 9, wherein

the encrypted operator- and terminal-specific initial-encryption key ( 6) is decrypted with the operator- and terminal-specific transport key ( 4) at the payment terminal (1) upon receipt or input, and the decrypted operator- and terminal-specific initial-encryption key (K6) is stored in a secure storage (TRSM) (45) of the payment terminal (1); or

the encrypted operator- and terminal-specific initial-encryption key (K6) is stored in the payment terminal (1) in its encrypted form upon receipt or input, and is only later decrypted with the operator- and terminal-specific transport key ( 4) at the payment terminal (1) when the decrypted operator- and terminal-specific initial-encryption key (K6) is required for obtaining the operator- and transaction-specific encryption key (K7) using the decrypted operator- and terminal-specific initial-encryption key (K6) to perform the transaction (26) with the payment terminal ( 1 ).

1 1. The method of any one of claims 1 to 10, wherein the at least one payment provider (2) is a single payment-gateway provider, or the at least one payment provider (2) is one of a plurality of payment providers (2).

12. The method of any one of claims 1 to 1 1, wherein at least one of the terminal-specific access key (K2), the operator-specific master-transport key (K3), the operator- and terminal- specific transport key ( 4), the operator-specific base-derivation key (K5), the operator- and terminal-specific initial-encryption key (K6), and the operator- and transaction-specific encryption key (K7) is a symmetric-encryption key.

13. The method of claim 12, wherein the at least one symmetric-encryption key is a triple key according to the Triple Data Encryption Algorithm (TDEA).

14. The method of any one of claims 1 to 13, wherein

the payment terminal (1) provides at least two usage modes, a direct-usage mode in which transaction data is exchanged between the payment terminal (1) and one of the operators (4), and a delegated-usage mode in which transaction data is exchanged between the payment terminal (1) and at least one payment provider (2), the payment terminal (1) being pre-configured by an assignment of usage modes to operators (4) of the plurality of operators (4), and

upon one of the operators (4) of the plurality of operators (4) starting to use the payment terminal (1) the usage mode assigned to this operator (4) is automatically selected by the payment terminal (1), and the payment terminal (1) performs the transaction (26) using the selected usage mode.

15. The method of any one of claims 1 to 14, wherein the terminal-specific access key (K2) used by the controlling entity (3) for symmetric encryption (S8) is derived (S I) from a controlling-entity-specific master- access key (Kl) using the terminal-identification number (44), or an additional identification number of the payment terminal (1).

16. The method of any one of claims 1 to 15, wherein the terminal-specific access key ( 2) is stored in the payment terminal (1) after being transmitted (S4) to the payment terminal (1) in a confidentiality-securing manner by a terminal provider (5).

17. The method of claim 16, wherein the terminal-specific access key (K2) is derived (S3), by the terminal provider (5), from a controlling-entity-specific master-access key (Kl) by using the terminal-identification number (44), or an additional identification number of the payment terminal (1).

18. The method of claim 17, wherein the controlling-entity-specific master-access key (Kl) is transmitted (S2) to the terminal provider (5) in a confidentiality-securing manner by the controlling entity (3).

19. The method of any one of claims 1 to 18, wherein the operator- and terminal-specific transport key ( 4) and the operator- and terminal- specific initial-encryption key ( 6) are received by the payment terminal (1) via distinct communication channels, i.e. the operator- and terminal-specific transport key (K4) is received from the controlling entity (3) via a first communication channel not involving the payment provider (2), and the operator- and terminal-specific initial-encryption key ( 6) is received from the payment provider (2) via a second communication channel not involving the controlling entity (3).

20. The method of any one of claims 1 to 19, comprising providing the payment terminal (1) with a processor (202) and read-only memory (43 a) forming an embedded computer system, wherein payment-terminal-configuration functions and payment-transaction functions of the payment terminal (1) are implemented by at least one computer program stored in the read-only memory (43a) and are executable by the processor (202).

21. The method of claim 20, wherein the read-only memory (43a) is electrically erasable programmable read-only memory (EEPROM).

22. A computerized controlling-entity system, comprising a processor (102) and memory (106) comprising a computer program with executable instructions (110) stored therein, for configuring a payment terminal (1) to be usable as a payment terminal (1) shared by a plurality of operators (4) with cryptographic segregation between the different operators (4) of the payment terminal (1), the payment terminal (1) having a terminal - identification number (44), the executable instructions (110), when executed by the processor (102), cause the processor (102) to:

derive (S7) an operator- and terminal-specific transport key (K4) from an operator- specific master-transport key (K3) by using the terminal-identification number (44);

symmetrically encrypt (S8) the operator- and terminal-specific transport key (K4) with a terminal-specific access key (K2);

transmit (S9) the encrypted operator- and terminal-specific transport key (K4) to the payment terminal (1).

23. The computerized controlling-entity system of claim 22, wherein the executable instructions (110), when executed by the processor (102), further cause the processor (102) to carry out the activities of any one of claims 2 to 21.

24. A computerized payment-provider system, comprising a processor (102) and memory (106) comprising a computer program with executable instructions (110) stored therein, for configuring a payment terminal (1) to be usable as a payment terminal (1) shared by a plurality of operators (4) with cryptographic segregation between the different operators (4) of the payment terminal (1), the payment terminal (1) having a terminal- identification number (44), the executable instructions (110), when executed by the processor (102), cause the processor (102) to: derive (S5) an operator- and terminal-specific transport key (K4) from an operator- specific master-transport key (K3) by using the terminal-identification number (44);

transmit (S6) the operator-specific master-transport key (K3) to a controlling entity (3) in a confidentiality-securing manner, wherein the payment terminal (1) is associated with the controlling entity (3), or,

alternatively, transmit the operator- and terminal-specific transport key (K4) to the controlling entity (3) in a confidentiality-securing manner;

derive (S10) an operator- and terminal-specific initial-encryption key (K6) from an operator-specific base-derivation key (K5) by using the terminal-identification number (44), or an additional identification number of the payment terminal (1);

symmetrically encrypt (Sl l) the operator- and terminal-specific initial-encryption key ( 6) with the operator- and terminal-specific transport key (K4);

transmit (SI 2) the encrypted operator- and terminal-specific initial-encryption key ( 6) to the payment terminal (1);

derive (SI 3), when performing a transaction (26) with the payment terminal (1), an operator- and transaction-specific encryption key (K7) from the operator- and terminal- specific initial-encryption key (K6) using a transaction-specific identification number (27) associated with the transaction (26).

25. The computerized payment-provider system of claim 24, wherein the executable instructions (110), when executed by the processor (102), further cause the processor (102) to carry out the activities of any one of claims 2 to 21.

26. A payment terminal (1) programmed to be usable as a payment terminal (1) shared between a plurality of operators (4) with cryptographic segregation between the different operators (4) of the payment terminal (1) and arranged to communicate with an operator (4) or at least one payment provider (2) to perform payment transactions (26) and arranged to be associated with a controlling entity (3) that controls usage of the payment terminal (1) in an operator-selective manner, the payment terminal (1) comprising at least one tamper-resistant security module (TRSM) (45) arranged to store a terminal-specific access key (K2) to enable usage of the payment terminal (1) to be controlled by the controlling entity (3) in the operator- selective manner.

27. The payment terminal (1) of claim 26, wherein the at least one tamper-resistant security module (TRSM) (45) is also arranged to store at least one of:

at least one operator- and terminal-specific transport key (K4) for decrypting a symmetrically encrypted operator-specific key, and

at least one operator- and terminal-specific initial-encryption key (K6) for deriving (S14) an operator- and transaction-specific encryption key (K7).

28. The payment terminal (1) of claim 26 or 27, comprising non-volatile read-only memory (43a) and a processor (202), wherein the read-only memory (43a) and the processor (202) form an embedded computer system (243), wherein payment-terminal- configuration functions and payment-transaction functions of the payment terminal (1) are implemented by at least one computer program (211) stored in the read-only memory (43a) and are executable by the processor (202).

29. The payment terminal (1) of claim 28, wherein the read-only memory (43a) comprises at least one of non-flash EEPROM and flash EEPROM.

30. The payment terminal (1) of any one of claims 26 to 29 further programmed to carry out the activities of any one of claims 2 to 21.