Method and Server for Providing Transaction Keys

Abstract

A method and a server for providing transaction keys for a transaction system includes transaction units which use pre-delivered transaction keys, and are provided by a key provisioning server and wherein the transaction key usage is checked by a transaction checking server. A transaction key is derived from a master key of a transaction unit, wherein a varying derivation parameter is used in the step of deriving. The step of deriving comprises a first sub step of deriving a key from the master key and a second sub step of deriving the transaction key from the derived key. The first sub step or the second sub step of deriving is performed dependent on a security level of the transaction unit.

Claims

1-15. (canceled)

16. Method for providing a transaction key in a server of a transaction system, in which transaction units of the transaction system use pre-delivered transaction keys, the method comprising: deriving a transaction key from a master key of a transaction unit, wherein a varying derivation parameter is used in the step of deriving; wherein the step of deriving comprises a first sub step of deriving a key from the master key; and a second sub step of deriving the transaction key from the derived key; wherein the first sub step or the second sub step of deriving is performed dependent on a security level of the transaction unit.

17. The method according to claim 16 wherein transaction key is a single-use transaction key, wherein a transaction unit identifier is used in the step of deriving.

18. The method according to claim 16 wherein in a first operating mode the first derivation step is performed for host based transaction units, host based transaction units having the security level low.

19. The method according to claim 16 wherein in a second operating mode the first derivation step is not performed for security element based transaction units, security element based transaction units having the security level high.

20. The method according to claim 16 wherein in a third operating mode the first derivation step is performed for server based transaction units, server based transaction units having the security level medium.

21. The method according to claim 16 wherein the server stores security level information for the transaction units.

22. The method according to claim 16 wherein in one of the two sub steps of deriving a one-way function is used and in the other sub step a reversible function is used for key derivation.

23. The method according to claim 22 wherein the one-way function is applied to the transaction unit identifier and/or selected from a plurality of usable one-way functions.

24. The method according to claim 16 wherein the server provides the transaction key to the transaction unit.

25. The method according to claim 24 wherein the key provisioning server encrypts the transaction key before provisioning the transaction key to the transaction unit.

26. The method according to claim 25 wherein the key provisioning server is adapted to encrypt the transaction key for encrypted storage and for transaction based decryption in the transaction unit.

27. The method according to claim 24, wherein the key provisioning server is adapted to send multiple transaction keys to the transaction unit at a time.

28. The method according to claim 16 wherein the server provides the transaction key for checking transaction data created by using an alleged transaction key.

29. A key-provisioning server adapted to provide transaction keys derived according to claim 16 to at least one transaction unit.

30. A transaction checking server, the server providing transaction keys derived according to claim 16 for checking transaction data created by transaction units.

Description

[0023] Preferred embodiments of the invention will now be described in more detail with reference to the figures.

[0024] FIG. 1 illustrates steps performed on a key provisioning or transaction checking server; and

[0025] FIG. 2 illustrates the main components of the transaction system.

[0026] The present solution will now be described for a contactless mobile payment transaction system. The basic components of the transaction system, illustrated in FIG. 2, are a host based transaction unit 21 in a device 20, a transaction terminal 30, a key provisioning server 50 and a transaction checking server 40.

[0027] At least one transaction key required for the transaction is derived in the key provisioning server 50 and sent 17 in advance from the key provisioning server 50 to the transaction unit 21. Thus the transaction unit 21 and the terminal 30 can perform a contactless transaction via local data exchange 18. Transaction data created by using the transaction key are sent 19 to the transaction checking server 40. The transaction checking server 40 also derives the transaction key and checks or verifies the received transaction data.

[0028] Turning now to FIG. 1 the key derivation process will be described, which is performed in the server(s).

[0029] Initially the server determines 11 the master key CMK of a transaction unit for which a transaction key has to be derived. The transaction unit may be identified by a transaction unit identifier, wherein the transaction unit identifier is used for determining the master key CMK. Instead of directly using this master key, which is an individual key for the identified transaction unit already, a first sub step 12 of derivation is performed. The unit individual master key CMK may be derived from a further, e.g. transaction system operator or unit issuer, master key IMK.

[0030] In sub step 12 of the key derivation a one-way function, like a hash function, is applied to the transaction identifier. The one-way function to be used may be configured based on a function parameter. Multiple different one-way functions may be selected in the server. Furthermore, in sub step 12, the result of the applied one-way function is combined, via XOR, DES or 3DES, with the master key CMK, thereby deriving a modified master key CMK′ for the second key derivation sub step 14. The function of sub step 12 shall be specific per transaction system operator and/or unit issuer. Furthermore, the function shall be secret.

[0031] In sub step 14 a reversible function, like XOR, DES, or 3DES, is used for deriving the transaction key SK based on the modified master key CMK′ and a varying derivation parameter A determined 13 for the key derivation of a transaction key for the transaction unit. The session key SK is derived from the modified master key and the derivation parameter: SK=f(CMK′,A). The varying derivation parameter could be a time-dependent value, a pseudo random number or a transaction counter. Preferably, the derivation parameter is also determined based on the known transaction unit identifier.

[0032] Finally, if the steps 11 to 14 are performed by a key derivation unit 51 of the key provisioning server, in step 15 the at least one derived transaction key is storage encrypted 15 for the transaction unit 20 and transmitted to the transaction unit 20.

[0033] If however the steps 11 to 14 are performed by a key derivation unit 41 of the transaction checking server 40, the derived transaction key is finally used in step 15 for checking transaction data.

[0034] In a second operating mode, particularly if the security level of the transaction unit is determined to be high, sub step 12 is skipped and the master key CMK is directly used for key derivation sub step 14.

[0035] Returning now to FIG. 2, both servers 40 and 50 further comprise repositories 42 and 52 respectively. The repository 42, 52 stores any data required for the key derivation process. For example, the repository 42, 52 stores one or more of:

[0036] a security level per transaction unit,

[0037] the master keys per transaction unit,

[0038] a most recent value of the varying derivation parameter (per transaction unit),

[0039] the selection parameters for the one-way functions,

[0040] a counter for the current number of transaction keys available on the transaction unit, increased upon transmission by server 40 and decreased after use in transactions by server 50.

[0041] The repositories 42, 52 should be synchronised such that, at least for the terminal 30, the transmitted data 18 and 19 remain unchanged.

[0042] A request for transaction keys may be sent 16 from the transaction unit 21 to the key provisioning server 50. In a preferred solution the transaction unit 21 automatically requests further transaction keys, if a number of stored transaction keys falls under a predetermined number. Alternatively, the transaction unit 21 regularly triggers the key provisioning server 50, which determines whether further transaction keys would have to be sent and/or whether stored transaction keys have to be deleted or modified.

[0043] In the illustrated embodiment the transaction unit 21 is a host based transaction unit of the device 20. The device comprising a network interface 22 for communicating 16, 17 with the server 50 and a local interface 23 for performing 18 the transaction with a terminal 30. The network interface 22 may be a (mobile) telecommunication or internet interface. The local interface 22 may be a RFID, UHF, NFC or Low Energy Bluetooth interface. Security elements like a SIM card or a secure NFC unit (which could be a part of unit 23), are not illustrated, but may exist in device 20 and may have their own transaction unit. The terminal 30 basically may comprise similar interfaces 33 and 32 for local and/or network communication. Since, the present solution is particularly designed to leave the transaction software 31 of the terminal 30 unamended, no further description appears required.

[0044] Hence, multiple transaction units of a device, executed on the host and/or the security elements, may receive transaction keys form the key provisioning server. Depending on their security level the key derivation process will differ.

[0045] Furthermore, a transaction proxy on the device 20 may use a server based transaction unit. Hence, the key provisioning server 50 may provide transaction keys, derived in a third operating mode including sub step 12, to a non-illustrated server executing the transaction unit for (the transaction proxy of) the device 20.

[0046] For host based transaction units the device further may comprise a server-encrypted storage area 24. The key provisioning server 50 encrypts one or more transaction keys for encrypted storage in the storage area 24. In contrast to transport encryption approaches, the transmitted encrypted transaction keys remain encrypted until they are used. Accordingly, the server 50 will encrypt the transaction keys in such a way that they can be decrypted separately. In an even more improved version the encryption could be adapted to enforce consecutive decryption (e.g. by using 3DES in CBC mode or variation thereof), the next stored key thus cannot be decrypted without having decrypted the previous key. The request for transaction keys 16 for example could also include the number of used and/or decrypted transaction keys.

[0047] Finally, a step of checking 15 in the server 40 the transaction data received 19 from the terminal 30 shall be shortly described.

[0048] The received transaction data typically include transaction details, e.g. an amount and/or a transaction identifier, and a transaction check value, e.g. a checksum, MAC or signature created with the transaction key for the transaction details. Preferably the transaction details and/or the transaction data comprise the transaction unit identifier of the transaction unit and the varying derivation parameter.

[0049] The transaction checking unit 41 of the server 40 uses the transaction unit identifier to determine 11 the individual master key CMK of the corresponding transaction unit. Furthermore, it determines the security level of the transaction unit, and depending thereon performs sub step 12 or not. In sub step 14 the session key SK to be provided in the server 40 is derived (in the given mode). Any information required for the key derivation is stored in repository 42.

[0050] The session key SK re-derived in server 40 now can be used to check the transaction data in step 15. For example, the transaction check value may be re-calculated for the transaction, namely the transaction details, and the re-calculated value may be compared with the received transaction check value.

[0051] Although not illustrated in FIG. 2 the server 40 may confirm to the terminal 30 that the transaction has been successfully checked (approved by the system). Furthermore, FIG. 2 shows a direct communication between servers 40, 50 and terminal 30/device 20 respectively, nevertheless the transaction system may be more complex and include further components. For example, servers 40, 50 could be implemented on a single server or could be added as external service entities to any existing transaction system.