Patent Application
20160295404
The present invention generally relates to systems and methods for securing communications between a card reader device and a remote server through a connected terminal.
Particularly, the present invention relates to a system and method for establishing an end-to-end secure channel for a transaction payment between a reader of a card payment connected to a terminal and a remote server through an unsecure network.
Well known payment cards are used by millions of people worldwide to facilitate various types of commercial transactions. In a typical transaction involving the purchase of a product or service at a merchant location, the payment card is presented at a point of sale terminal (“POS terminal”) located at a merchant's place of business. The POS terminal may be a card reader or similar device that is capable of accessing data stored on the payment card, where this data includes identification and authentication data. Data read from the payment card is provided to the merchant's transaction processing system and then to the acquirer, which is typically a bank or other institution that manages the merchant's account.
To ensure the security and global interoperability of chip based payment cards, it is well known EMV standards which define the interaction between EMV-compliant payment cards and EMV-compliant POS terminals. Therefore to accept EMV payments, merchants have to deploy EMV-compliant POS terminals. Such EMV-compliant POS terminals hardware, their deployment and their maintenance are considerable costs for the merchants.
Today, technology has revolutionized the way that consumers make purchases and expanded the range of retail channels. Indeed, mobile devices, such as mobile phones, play an increasingly versatile role in daily life. Many new features and services are being developed in an attempt to expand mobile phones beyond their traditional role of voice and message transmission.
However, payment card has not been adopted by the online market, although they provide the best security to conduct electronic commerce. The main reasons are the high cost of the card reader and the complexity of the system for most people. Not only a card but also a reader must be provided to the millions of potential end-users who comprise this market base.
To make payment card adopted by the online market, low cost card reader device has been developed. The low cost card reader device comprises interfaces able to be connected to a mobile device. This kind of card reader has no secure random number generator or entropy source. Furthermore, the implementation should not embed advanced countermeasures against side-channel attacks. This unsecure low cost card reader does not provide necessary securities to conduct electronic commerce.
With this kind of card reader, it is clear that there is an increasing desire for faster, cheaper, secure and more convenient low cost card reader to conduct secure transactions.
There is a need to make safe credit card payments in stores, on Internet and person-to-person which are inexpensive, easy to manage and portable.
The following summary of the invention is provided in order to provide a basic understanding of some aspects and features of the invention. This summary is not an extensive overview of the invention and as such it is not intended to particularly identify key or critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented below.
The present invention addresses the aforementioned security drawbacks of transactions with a low cost card reader. The present invention relates to a system and method for protecting the data transiting between the card reader and a remote server through a mobile device, over an unsecure network during a transaction.
This invention concerns the implementation of end-to-end security for the communication between the low cost card reader and the remote server. The purpose of the present invention is the establishment of a secure channel between the card reader and the remote server through an un-trusted communication device (e.g. a smart phone or a tablet) that is intrinsically resistant to some basic differential side-channel analysis in a context where there is no secure random number generator and no source of entropy in the card reader, while providing the following characteristics:
The present invention does not attempt to mitigate attacks such as Simple Electromagnetic Analysis (SEMA) or Simple Power Analysis (SPA); mitigation techniques strongly depend on the hardware.
Instead, the present invention only intends to mitigate the feasibility of differentials attacks such as Differential Electromagnetic Analysis (DEMA), Correlation Electromagnetic Analysis (CEMA), Differential Power Analysis (DPA), Correlation Power Analysis (CPA).
With the present invention, the management of the crypto computation is within the card reader, while the server is not necessarily involved. Indeed, by forcing an attacker to use legitimate transactions in order to get sufficiently Electromagnetic or Power Measurements should first increase the time of the attack and second, the attacker could be detected (in some extend) on the server side.
The present invention provides an inexpensive and easy way to use card reader to secure any transactions (even online transactions) over the mobile device “such as a phone”. The card reader and the remote server authenticate both when managing bank accounts, making payments, or eventually voting online, for example.
The present invention proposes a method for securing the data transferred between the card reader and the remote server. For that, the present invention proposes a method for encrypting data transferred. Besides, the present invention proposes method of verifying of origin/integrity of the data transferred.
Aspects of the embodiments of the present invention relate in general to a method of defining how to setup the secure channel between the card reader and the remote server, how it runs and what are the required data and cryptography algorithms. The present invention defines a secure, simple and efficient protocol to make secure transaction with a card reader connected to a mobile device.
In a various method of the present invention, during a personalization/registration phase the followings steps can be performed:
The present invention focus on the protection of all the command/responses that can be sent to the card reader and received from it, without necessarily involving a legitimate server in the communication.
The present invention proposes a method to protect sensible Session-Setup command, since it is the only command that could enable an attacker to force the usage of the reader master key in crypto computation, without involving the legitimate server. Using this command, the card reader has on input a random value Server-RND and a Message Authentication Code (MAC) of a pre-defined format message that contains the value Server-RND. As an example, the pre-defined message could be:
Message=ConstantValue∥random value Server-RND.
The verification of the MAC by the card reader requires foremost the computation of the session key for MAC verification.
The present invention relates in general to a method of generating encryption session keys and integrity session keys. The session keys are computed using the secret reader key and a diversifying data that comprises the random value Server-RND that is chosen by the legitimate server (or the attacker) and a predictable value that is under the control of the card reader (the counter DTC). The reader key is derived from a master key and the serial number SN of the card reader
The random value chosen by the legitimate server (or the attacker) is useful to provide the guarantee to the server that the current secure channel session has not been pre-computed and the legitimate card reader is indeed at the other end of the channel. The size of this random value does not need to be very large, few bits could be sufficient. The size of the random value Server-RND is preferably set in accordance with the error management and the level of tolerance that is considered acceptable. The size of the random value may be small enough in order to upper bound the flexibility of an attacker that would want to recover the MAC verification session key using for example a DEMA or DPA.
The value of DTC is under the sole control of the card reader. The DTC value is involved in the session key derivation function and this value is updated only after a successful MAC verification is performed by the card reader allowing authenticating the server. The uniqueness of DTC is important in the invention, since it is the guarantee that the session keys will be unique per secure channel session. The size of DTC is preferably large enough to cover the full life-cycle of the product. As an example, a 4-bytes DTC value would be appropriate if the maximum number of transactions has to be upper bounded by 232.
Then, without involving the server, an attacker won't succeed in forging a valid MAC (assuming that the MAC algorithm is cryptographically secure) and the flexibility of the attacker in the message input of the diversification algorithm is only determined by the size of the random value Server-RND.
The format of the diversifying data and the size of the random value Server-RND have to be set by taking into account the specification of the session key derivation function. One main advantage of the invention is to use a single-step key derivation for involving both a randomness chosen by the server/attacker and a unique value per session which is under the sole control of the card reader, instead of using a 2 steps key derivation, i.e. 1 step to involve the unique value per session that is under the sole control of the card reader, and one additional step for using the random value chosen by the server/attacker.
During the phase of verification of the MAC and the step of incrementing the DTC the target of an attacker is the MAC verification session key. The size of the random value Server-RND and the format of the pre-determined message are means for limiting the attacker flexibility, i.e. the size of the message, the size of the constant, localization of the random value Server-RND. The format of the message to be verified by MAC is preferably set by taking into account the specification of the MAC algorithm.
Such systems and methods of the present invention improve the security of information transferred between a card reader and a server by providing efficient means for secure communication channel.
To achieve those and other advantages, and in accordance with the purpose of the invention as embodied and broadly described, the invention proposes a method for securing a transaction between an unsecure card reader connected to a mobile device and a remote server through an unsecure network, wherein when a validation step of the transaction is initiated:
The invention relates to a method for securing a transaction between an unsecure card reader connected to a mobile device and a remote server wherein when a transaction is initiated:
In other various methods, the reader key is derived from a master key and an identifier of the card reader. The identifier of the card reader is a serial number unique at each card reader.
In other various methods, the derivation session keys by the server comprise the following steps:
In other various methods, the authentication step of the server by the card reader comprises the following steps:
In other various methods, the current predictable value is updated with the incremented value when the authentication of the server is successful. The updated predictable value is stored into the database of the card reader or in a secure element of the card reader. When the updated predictable value reached a predefined maximum predictable value, the card reader is locked or in standby until a new predefined maximum value is defined.
In other various methods, the authentication step of the card reader by the server comprises the following steps:
In other various methods, when the authentication request of the server is sent to the card reader, a sequence number counter of the server is incremented sequentially. When the server is authenticated by the card reader, a sequence number counter of the card reader is incremented sequentially. The authentication request of the card reader by the server comprises the current sequence number value of the card reader. Upon the authentication request is received, the server checks if the received sequence number value corresponds to the value of its sequence number counter. If the verification is successful, the received MAC value is verified to authenticate the card reader.
In other various methods, a disabling-counter of the card reader is incremented when the authentication of the server by the card reader fails. If the disabling-counter value reached a predefined maximum error, the card reader de-activates itself.
In other various methods, after the establishment of the secure channel between the card reader and the remote server, an errorcounter of the card reader is incremented when an invalid incoming message is received. If the errorcounter value reached a predefined maximum error, the card reader closes the session of the validation step transaction. When the validation step transaction session is completed and the errorcounter value is less than the predefined maximum error, the errorcounter is cleared.
In other various methods, the authentication of the card reader by the server comprises the following steps:
In other various methods, the session encryption key and the session integrity key comprise four symmetric keys unique for each transaction session,
The present invention relates also a validation transaction processing system, comprising an unsecure card reader connected to a mobile device and a remote server wherein validation transaction messages transiting between a smart card connected to the card reader and the remote server are secured according to the present invention.
The method of the present invention has many technological advantages, among them: maintain a low cost card reader, simplicity of generating the session keys, and a strong protection of data transmitted.
The following detailed description will be better understood with the drawings, in which:
The present invention is not specific to any particular hardware or software implementation, and is at a conceptual level above specifics of implementation. It is to be understood that various other embodiments and variations of the invention may be produced without departing from the spirit or scope of the invention. The following is provided to assist in understanding the practical implementation of particular embodiments of the invention.
The same elements have been designated with the same referenced numerals in the different drawings. For clarity, only those elements and steps which are useful to the understanding of the present invention have been shown in the drawings and will be described.
Further, the mechanisms of data communication between the parties and their environment have not been detailed either, the present invention being here again compatible with usual mechanisms.
Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternatives or additional functional relationships or physical connections may be present in a practical system. Furthermore, the various entities in
Moreover, when an action is said to be performed by a device, it is in fact executed by a microprocessor in this device controlled by instruction codes recorded in a program memory on said device. An action is also ascribed to an application or software. This means that part of the instruction codes making up the application or software are executed by the microprocessor.
Reference throughout the specification to “an embodiment” or “another embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the subject matter disclosed. Thus, the appearance of the phrases “in an embodiment” or “in another embodiment” in various places throughout the specification is not necessarily referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.
Embodiments of the present invention will be exemplified using a mobile communication device such as a mobile phone. However, it should be appreciated that the invention is as such equally applicable to electronic devices which have wired- and/or wireless radio communication capabilities. Examples of such devices may for instance be any type of mobile phone, laptops (such as standard, ultra portables, netbooks, micro laptops, and pads), handheld computers, PDAs, gaming devices, accessories to mobile phones, etc. However, for the sake of clarity and simplicity, the embodiments outlined in this specification are exemplified with and related to mobile phones only.
The mobile phone 10 typically comprises a processor, a memory, input devices, output devices, and suitable communications scheme, all of which are operatively coupled to the processor. The mobile device 10 comprises, a display area 11, and means 12 for navigating among items displayed in the display area 11 and entering text and numbers into the mobile phone. The display area 11, which preferably is touch sensitive, may comprise one or more status indication areas and/or softkey bars. The display area 11, and the items displayed on it, may be operable using the navigation means 12 or by tapping the on it with a pen-like object or a finger. The mobile phone 10 may also comprise a communication interface 13 for external units. The mobile phone as a stand-alone device is from a secure transaction point of view classified as unsecure and not fit for conducting secure transaction with. Thus, a mobile phone in itself cannot be used for making secure transaction with.
A card reader device 14 comprises an interface 15 for connecting to another device such as the mobile phone 10 through preferably a free transport protocol. The interface 15 may be a typical communication interface (e.g. USB connector, audio connector etc.) used in the mobile communication and computer industry, or it may be a special interface used in conjunction with embodiments of the present invention. The card reader device 14 may be connected to the mobile phone 10 wirelessly or directly, using its communication interface 15. The card reader can be physically plugged into the mobile phone corresponding communication interface 13, or it could be connected via an adapter between the mobile phone's 10 communication interface 13 and the communication interface 15 of the card reader device 14. The card reader device may also in some variants of the embodiment be connected to the mobile phone 10 using a wire.
In another embodiment, the card reader 14 comprises a contactless interface capable of communicating using any suitable communications scheme with the mobile phone 10. The contactless interface can refer to a near-field communication (NFC) transceiver, a contactless reader or an unpowered RFID. The contactless interface of the card reader 14 establishes a contactless communication channel with the mobile phone 10 to exchange data using a short range communication method, such as a near field communications (NFC) capability. Examples of such NFC technologies or similar short range communications technologies include ISO standard 14443, RFID, Bluetooth™ and Infra-red communications methods.
In an example, a contactless communication channel can refer to exchanging information using NFC technology that requires the communicating devices to be “tapped”, which means that the contactless interfaces are brought within several centimeters of each other.
In the embodiment illustrated herein, the interface 15 of the card reader 14 is an audio connector connected to the interface 13 of the mobile device 10 for establishing a communication using audio signal to exchange data.
The card reader device 14 may comprise a smart card reader slot 16 where a smart card 17 may fully (completely), or in part (only a part of), be inserted into. The card reader device 4 may in a variant of the embodiment also comprise a common magnetic stripe reader with a reader slit, through which a card may be slided to be read. The card reader 14 can be classified as an unsecure card reader device which is much cheaper to manufacture than a secure card reader device.
The smart card 17 may comprise a secure element 18. The secure element 18 is used to host and store data and applications that require a high degree of security. The smart card 17 is provided to the user by a secure element issuer. The secure element issuer may not necessarily be a member of the transaction process or the same entity as a server 19. The smart card 17 can be connected to the card reader 14 through a free transport protocol. Typically this free transport protocol can be ISO-7816 1,3 protocols.
The mobile phone 10 interacts with the card reader 14 through a mobile transaction application 20. The mobile transaction application is an application providing transaction capabilities implemented within the mobile phone 10. For example, during a transaction, the mobile transaction application 20 may interact with the server 19 over the network 21 to enable the transaction using the mobile phone. In an embodiment, the entity issuing the mobile transaction application can be the manufacturer of the card reader 14, the same entity as the server 19, or not a member of the transaction process. The server 19 communicates with the card reader 14 via the mobile transaction application 20 of the mobile phone 10 through the network 21.
The expression “transaction” can be taken in its broadest meaning. It cannot be limited to financial transaction but can also cover any Internet transaction; any transaction occurring through a telecommunication network etc. The term transaction is intended to broadly cover various actions such as payment requests, order requests, share transfers, funds transfers, proof of identity requests, requests to release information, or a combination of these actions. Such actions may also be initiated in variety of ways, for example, a payment request may originate from a credit card transaction at a physical store, a purchase on an ecommerce website (click-to-buy), or a remote payment system which uses a customer's mobile phone to pay for goods and services such as text-to-buy or talk-to-buy systems.
As used herein, a “server” is a computing device that may be configured to interact in an automated fashion with other devices over a network to serve content and web pages, to issue responses to communications from other network devices and to respond to queries from other network devices.
During this personalization process, a reader master key RMK is created. The reader master key RMK can be generated, at step 31, by the key management system 22. The key management system 22 as illustrated in
At step 32, an identifier of the card reader is generated. In an embodiment the identifier can be generated by the key management system 22. In another embodiment, this identifier can be generated by the manufacturer of the card reader. This identifier can be a serial number SN of the card reader 14. This identifier SN is preferably unique at each card reader.
In a preferred embodiment, the key management system 22 derives a reader key RK from a derivation algorithm, the master key RMK and the identifier SN. The derivation algorithm used herein is well known by the person in the art and do not need to be described any more.
At step 33, the key management system 22 loads into the card reader 14 the unique identifier SN and the derived reader key RK associated. In an embodiment, the card reader comprises a secure element herein the identifier SN and the reader key are loaded.
In an embodiment, the key management system 22 loads into the card reader the master key instead of the derived reader key. In this case, the card reader derives the reader key RK from the derivation algorithm, the master key RMK and the associated identifier SN. The derived reader key RK can be stored into the card reader for next use.
At step 34, the key management system 22 shares the generated master key RMK and the associated unique identifier SN with the server 19. Upon received, the server 19 stores into its database the master key RMK with the associated unique identifier SN of the card reader 14.
So, the key management system 22 create a static key for the card reader which must in turn be used to create session keys for communicating with the card reader 14 and the server 19.
Any suitable form of generation and share of the shared key and the identifier SN between the card reader and the server 19 may be implemented as one of ordinary skill would recognize. The way of how the shared key and the identifier SN are generated and shared between the entities is outside the scope of the present invention.
The card reader device 14 comprises a counter 23. This counter 23 can be named a Device Transaction counter DTC. At step 36, the card reader 14 initializes the counter 23, by assigning it a value DTC. The value DTC is an integer. In the embodiment illustrated in
When the validation of the transaction is initiated, the mobile transaction application 20 is launched by the mobile phone 10 at step 41. At step 42, the mobile transaction application 20 establishes a communication session with the card reader 14. When the card reader is set up, a request for the establishment of a secure channel is sent, at step 43, from the card reader 14 to the server 19 via the mobile transaction application. This request for the establishment of a secure channel may comprise the current value DTC of the counter 20 of the card reader and its identifier SN. The current value DTC is the last value DTC updated into the database of the card reader.
Upon reception, the server 19 extracts, at step 44, from its database the master key RMK associated to the received identifier SN. Then, the server 19 derives the reader key from the derivation algorithm, the extracted master key RMK and the received identifier SN.
In an embodiment, the key management system derives the reader key. This derived reader key is sent with its associated identifier SN to the server for storage. Then when the server received an identifier SN at step 43, it extracts from its database the corresponding reader key.
In another embodiment, the derived reader key or the master key (depend on the embodiment) is stored into a secure database. When the server received an identifier SN at step 43, it sends a request to this database to get the corresponding reader key or master key. Upon reception, the secure database extracts the reader key or the master key corresponding to the identifier SN. Next, the extracted reader key or master key is sent to the server in response.
At step 45, the server 19 defines the diversifying data which are used to compute session keys. For that, the server 19 increments the received current value of the counter 23 and generates a random value Server-RND or challenge. The generated random value can provide the guarantee to the server 19 that the current secure channel session has not been pre-computed and the legitimate card reader is indeed at the other end of the channel. The size of this random value does not need to be very large, few bits could be sufficient. The diversifying data comprises the incremented counter current value and the generated random value.
In an embodiment, the random value Server-RND is 3 bytes length. The 3 bytes length is large enough to have sufficient variability for the generated session keys. The 3 bytes length is small to mitigate the differential attacks on the card reader to retrieve the reader key.
At step 46, the server 19 derives the session encryption keys and the session integrity keys from the derived reader key, the diversifying data and the derivation algorithm.
At step 47, the server 19 elaborates an authentication request comprising the generated random value and a MAC value. The MAC signature value is the result of a MAC (Message Authentication Code) operation on at least one part over the random value. The MAC operation uses the session integrity keys and a cryptographic checksum algorithm to produce the MAC signature value which later can be used to ensure the data has not been modified.
At step 48, the server 19 sends the authentication request to the mobile transaction application 20 of the mobile phone 10 through the network 21. Upon reception, the mobile transaction application forwards the authentication request to the card reader 14.
At step 48 upon reception, the card reader 14 defines the diversifying data. For that, the card reader increments the current value of its counter 23 DTC. The diversifying data comprises the incremented value of the counter 23 and the received challenge or random value Server-RND. At step 49, the card reader 14 derives the session encryption keys and the session integrity keys from the derived reader key stored into its database, the defined diversifying data and the derivation algorithm.
At step 50, the card reader computes a MAC value from the received random value and the computed session integrity keys. The computed MAC value is compared to the received MAC value to check if the random value has been altered. In an embodiment, if the verification of the MAC value fails, the process flow can be closed, at step 51, and the card reader 14 may notify the mobile transaction application and/or the server 19 that the MAC value is tampered. If on the other hand the MAC value is successfully verified, the server 19 is authenticated by the card reader 14 as a legitimate server.
At step 52, when the authentication of the server 19 is successful, the current value of the counter is updated with the incremented value of the counter. This updated current value is stored into the database of the card reader. Since the current value of the counter is updated only when the authentication of the server is successful and different for every transaction the resulting session keys will be different, avoiding replay attacks.
In an embodiment, when the current value of the counter is updated into the database, the card reader 14 analyses whether the updated counter value has reached a predefined maximum value DTC_MAX. The predefined maximum value DTC_MAX is a maximum number of authorized transactions. This predefined maximum value can be defined by default by the card reader or by the manufacturer of the card reader. In an embodiment, the predefined maximum value DTC_MAX is entered by the user through the mobile transaction application of the mobile phone 10. The predefined maximum value DTC_MAX is preferably large enough to cover the full life of the card reader.
If the updated counter value is equal to the predefined maximum value DTC_MAX, then the card reader can be locked or in standby until a new predefined maximum value is defined.
At step 53, the card reader 14 elaborates an authentication request comprising the stored updated value of the counter 23 and a MAC value. The MAC signature value is the result of a MAC (Message Authentication Code) operation on at least one part over the updated value of the counter 23. The MAC operation uses the session integrity keys and a cryptographic checksum algorithm to produce the MAC signature value which later can be used to ensure the data has not been modified.
At step 54, the card reader 14 sends the authentication request to the mobile transaction application 20 of the mobile phone 10. Upon reception, the mobile transaction application forwards the authentication request to the server 19 through the network 21.
At step 55 upon reception, the server 19 computes a MAC value from the received updated value of the counter 23 and the computed session integrity keys. The computed MAC value is compared to the received MAC value to check if the updated value of the counter 23 has been altered. In an embodiment, if the verification of the MAC value fails, the process flow can be closed, at step 56, and the server 19 may notify the mobile transaction application and/or the card reader 14 that the MAC value is tampered and the card reader is not a legitimate one. If on the other hand the MAC value is successfully verified, the card reader 14 is authenticated by the server 19 as a legitimate one.
At step 57, when the authentication of the server 19 and the card reader 14 are successful, a secure session communication to validate the transaction is established between the card reader and the server 19.
The process flow described in
When the secure channel is set up at step 57, the server 19 and the card reader use the mobile application transaction as “a pass through gateway”. The following steps can be performed to complete the validation transaction step:
The server uses the secure channel to send smart card commands and receives smart card response. Once the validation transaction process is completed, the server closes the secure channel.
In an embodiment, the card reader comprises a disabling-counter. The card reader 14 initializes the disabling-counter by assigning it a null value. When the verification of the MAC fails at step 50 of
If the disabling-counter value is less than the predefined maximum error, then the validation transaction flow diagram 40 can be repeated once again. If the disabling-counter value is equal to the predefined maximum error, then the card reader can forbid going further by denying executing the next requested processing, while possibly sending to the user through the mobile phone 10 and/or the server 19 a message for informing them about its de-activation.
To re-activate the card reader 14, the user has to enter an unlock code. This code could be provided to the user in a separate medium and if necessary user may request that code from a service provider.
In another embodiment, the card reader comprises an errorcounter. The card reader 14 initializes the errorcounter by assigning it a null value. When an invalid incoming message is received on the secure channel established at step 57 of
Next, the card reader analyses whether the errorcounter value has reached a predefined maximum error, for example “three”. If the errorcounter value is equal to the predefined maximum error, then the card reader can close the session and return ERR_SESSION_CLOSED to the user through the mobile phone 10 and/or the server 19.
These embodiments protect the card reader and provide flexibility on error management.
In another embodiment, the card reader 14 and the server 19 comprises a sequence number counter SCNTR. This sequence number counter SNCTR is incremented sequentially at each session transaction by the server and the card reader. At step 47 of
This sequence number value SCNTR is added to the authentication request sent by the card reader 14 to the server 19 at step 53 of
In an embodiment, the session encryption keys and the session integrity keys comprise four symmetric keys unique for each transaction session. The four symmetric session key can be:
An example of computation functions used to implement the present invention are illustrated below. The following cryptographic data and securities features are provided for these computation functions:
Computing the Reader Key:
Function Compute readerkey {masterkey, identifier SN}
Computing the Session Keys:
The session keys TENC, TMAC, RENC AND RMAC are computed by using additional data, e.g random value generated by an external entropy source or a constant value and by using HMAC-SHA2 algorithm. The result of the computation function of integrity keys and encryption keys can be different and can perform enough variability and unpredictability of session keys, and the impossibility to force the re-computation and replay of previous session keys. It is up to the embodiments to perform such variability and unpredictability of the session keys, and the impossibility to force the re-computation and replay of previous session keys.
Encrypting the Data:
The encryption function can handle padding.
Function EncryptData (iv(8 bytes), data, encryption-key)
Decrypting the Data:
The decryption function can return null if the encrypted-data is wrong for instance due to padding inconsistency.
Function DecryptData (iv, data, encryption-key)
Computing the MAC:
The MAC value can be a 8 bytes length
Function Compute MAC (data, mac-key)
In an embodiment, the session keys are retrieved by the card reader host controller of the card reader. The functions EncryptData( ), DecryptData( ), ComputeMac( ) are implemented in the card reader firmware and not in the Secure Element.
In another embodiment, the session keys are stored in the secure element of the card reader and the functions EncryptData( ), DecryptData( ), ComputeMac( ) are implemented in the secure element.
An example of implementation of the present invention is illustrated below. For this implementation the computation functions above described are used.
The Kind of Commands/Responses Available:
Validation Transaction Flow Diagram:
1: the transaction application sends the commands GET identifier SN to the card reader
GET identifier SN|(empty)
2: the card reader returns
ACK|SN
3: the transaction application sends the command GETSTATUS
GETSTATUS|(empty)
4: the card reader returns
ACK|<status data including Device Transaction Number DTC>
5: the transaction application sends the SN and the DTC to the server.
6: the server responds with a SESSION ETUP command.
The SESSIONETUP requires the server to generate authentication message. This MAC will be used by the card reader to verify that the server is genuine.
The server generates a server-challenge or a random value.
The server computes the session keys.
READERKEY:=Compute ReaderKey (MASTERKEY, SN)
TMAC=Compute TMAC (READERKEY, server-challenge, DTC+1)
RMAC=Compute RMAC (READERKEY, server-challenge, DTC+1)
TENC=Compute TENC (READERKEY, server-challenge, DTC+1)
RENC=Compute RENC (READERKEY, server-challenge, DTC+1)
The server computes the MAC of the message with Initial Vector
The server sets the sequence number value to {0x00, 0x01}
The server sends the Command=SESSIONETUP|server-challenge|MAC value to the transaction application,
7: the transaction application passes the command to the card reader
8: the card reader handles the SESSION ETUP command.
The card reader computes the new session keys.
TMAC:=Compute TMAC (READERKEY, server-challenge, DTC+1)
TENC:=Compute TENC (READERKEY, server-challenge, DTC+1)
RMAC:=Compute RMAC (READERKEY, server-challenge, DTC+1)
RENC:=Compute RENC (READERKEY, server-challenge, DTC+1)
The card reader computes the MAC value of the message with Initial vector
The card reader checks that the received MAC value is equal to the computed one.
On failure it returns ERR_INVALID_MAC.
Otherwise the reader checks the DTC is less than DTC_MAX
If DTC==DTC_MAX
The card reader returns ERR_BLOCKED
Otherwise THE SERVER IS AUTHENTICATED.
The card reader initializes the internal counters
Sequence number value={0x00, 0x01}
ERRORCOUNTER:=0
The card reader increments the DTC.
DTC:=DTC+1.
The card reader generates the message authentication code for the server
9: the transaction application passes the SESSIONETUP response to the server
10: the server checks the SESSIONETUP response.
Response=ACK|DTC|MAC value
The server checks the received message authentication code
The server checks if the received MAC value is equal to the compute one.
On failure the server returns: COMPLETED_ERROR.
Otherwise, the card reader is authenticated. At this moment, the SESSIONETUP is completed. The card reader/server mutual authentication has been successfully performed. The server can send commands SENDAPDU or READMAGSTRIPE.
11: on valid SESSIONETUP or SENDAPDU response, the server sends a smart card command (apdu). The processing for magstripe command according the secure channel aspect is identical.
The server encrypts the apdu.
The server computes the message authentication code.
Finally, the message is
12: the transaction application passes the server command to the card reader
13: the card reader handles the SENDAPDU command
Command=SENDAPDU|SCNTR|encrypted-data|MAC value
The card reader checks the received message authentication code
Iv: {0x00, 0x00, 0x00, 0x00, 0x00, 0x00}|SCNTR
MAC value:=Compute MAC(iv|encrypted-apdu, TMAC);
The card reader checks the MAC value against the received one.
On failure the reader increments the ERRORCOUNTER.
If the MAC value verification is successful, the card reader decrypts the encrypted apdu
On failure the card reader increments the ERRORCOUNTER
If the decryption is successful, the card reader clears the errorcounter.
The card reader sends the apdu to the smart card and receives the response.
The card reader encrypts the response
The card reader generates the message authentication code
Finally, the card reader generates the response
The card reader increments the sequence number SCNTR counter for next incoming command.
14: the transaction application sends the response to the server
15: the server handles the response.
The server checks the received message authentication code
If (computed MAC value==received MAC value) the server decrypts the response
The server generates new command (see steps 11 to 15);
or complete the session by sending COMPLETED_OK.
16: the transaction application presents the user with the completion status.
With the present invention smart card data are not transmitted in clear to the mobile transaction application, and they do not circulate in clear during the transfer from the mobile device to the remote server.
The invention is simple and easy to implement. A mutual authentication between the payment application and the gateway is performed to ensure the confidentiality of user credentials and the integrity/origin of the message.
The protocol as defined by the present invention allows protecting the card reader against differential attacks by:
Furthermore, the protocol as defined by the present invention is self reliable by 1) using the MAC feature and 2) by verifying the consistence of the decrypted data by verifying the result padding.
| Number | Date | Country | Kind |
|---|---|---|---|
| 13306551.6 | Nov 2013 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2014/072825 | 10/24/2014 | WO | 00 |
