Patent Application
20190043044
The invention relates to the field of secured data transmission between two devices. More particularly, the present technique relates to the field of secured data transmission between a master device and a slave device during a process of pairing of the master device with the slave device. According to one particular aspect, the present technique applies to the pairing of a peripheral, such as a payment terminal (as a slave device also called a peripheral) with a payment-receiving device, such as a cash register (acting as a master device).
The payment-receiving device (such as for example the cash register) and the payment terminal are two essential tools of the merchant, whatever his activity. These are two devices which, as a rule, are connected to each other in order to form a unit enabling the merchant to accept numerous means of payment. The advantages of the payment terminal are many: it is an often secured device that accepts numerous means of payment (smartcard, magnetic stripe card, contactless card, prepaid card, wallets installed on mobile smartphone type terminals) and is well known to the customers.
The payment-receiving device, for its part, enables the merchant to make logs of his activity and centralize sales whatever the means of payment used (card, check or cash). The payment-receiving device also frequently has a barcode reader that is used to scan products, recognize them, display the price and prepare the cash receipt. The cash register has also benefitted from the digitization of the economy and can be connected to a server, by means of a communications network, in order to transmit and receive information coming from inventory management software, accounting software, etc.
In many businesses, the payment-receiving device is a cash register. In many businesses again, the payment-receiving device and the payment terminal are connected with each other. This connection plays a role in the efficiency of the sale process. For example, when the list of articles to be purchased has been prepared, the merchant endorses the amount of the transaction. This amount is automatically transmitted to the payment terminal (the slave device) which then carries out the payment operation independently (i.e. the payment operation as such is not under the control of the cash register). Thus, the user presents his payment means to the payment terminal which, if necessary, requests the entry of additional data (such as a PIN code for example). When the transaction is validated, the payment terminal transmits a piece of data relating to the end of the transaction to the cash register. Hence, a link that is relatively important from the security viewpoint is set up between the cash register and the payment terminal. Indeed, it can be understood that if the payment terminal is replaced or modified without the merchant spotting it, the content of the data that travels between the payment terminal and the cash register can be modified or falsified to the merchant's detriment, for example by the crediting of an account other than that of the merchant or by the obtaining confidential of data on the payment cards used in the payment terminal.
This is why there is a process for setting up secured links between the payment terminal and the cash register. There is a pairing enabling the cash register, in theory, to make sure that the payment terminal with which it is communicating is not a fraudulent terminal. The setting up of a secured link between the peripheral (for example the payment terminal) and the cash register comprises the creation of one and only one secured communications link between the peripheral and a specific securing component, in passing through the payment-receiving device (i.e. through the unsecured operating system). The setting up of a secured link between the peripheral (for example the payment terminal) and the cash register also includes the transmission of an acknowledgement message to the cash register by the peripheral. This message is transmitted at the initiative of the peripheral when the secured link has been set up.
The problem lies by the fact that, on the one hand, this process is implemented through the unsecured operating system of the cash register and, on the other hand, the finalizing of the pairing process is at the initiative of the terminal (of the peripheral).
A fraudulent person who has succeeded in snooping on the data exchanges between a peripheral and a payment-receiving device can therefore replace this peripheral by a fraudulent peripheral configured to replay these same data exchanges and thus obtain confidential data and/or execute unauthorized actions.
The proposed technique does not have at least certain of the drawbacks mentioned here above. The present technique indeed makes it possible to implement a pairing between a peripheral and a payment-receiving device that is truly secured. More particularly, the present technique relates to a method for transmitting data, a method implemented within a secured execution environment of an electronic device, called a trusted component, said trusted component being coupled to a payment-receiving device, said method of data transmission comprising at least one step of transmission, by a peripheral, of a piece of data intended for said payment-receiving device.
Such a method comprises, prior to said step for transmitting data:
Thus, the peripheral is not capable of directly communicating data to the payment-receiving device. To this end, it must use the trusted component which alone can transmit data to the peripheral.
According to one particular characteristic, said step for setting up said first secured communications channel comprises:
Thus, the trusted component is capable of verifying the validity of the request that is transmitted to it: it can if necessary detect an attempt at fraudulent connection on the part of the payment-receiving device.
According to one particular characteristic, said step for setting up said second secured communications channel comprises:
Thus, the trusted component is capable of verifying the validity of the request that is transmitted to it: it can if necessary detect an attempt at fraudulent connection on the part of the peripheral.
According to one particular embodiment, subsequently to the step for setting up said second secured communications channel, said method comprises:
According to one particular characteristic, said step for receiving a message of confirmation of pairing coming from said peripheral comprises a step for receiving said at least one first piece of encrypted data coming from said payment-receiving device, which plays the role of a relay between said peripheral and said trusted component.
According to another aspect, the invention relates to an electronic device for the transmission of data, having available a secured execution environment, called a trusted component, said trusted component being coupled with a payment-receiving device, said trusted component comprising means for transmitting data intended for the payment-receiving device and for at least one peripheral.
Such a trusted component comprises:
According to another aspect, the present invention also relates to a system of payment of the type comprising a payment-receiving device and a peripheral, said peripheral being configured to carry out payment operations in favor of said payment-receiving device.
Such a system comprises an electronic data transmission device called a trusted component as described here above.
According to one particular characteristic, said peripheral is a device belonging to the group comprising:
According to a preferred implementation, the different steps of the method according to the invention are implemented by one or more software programs or computer programs comprising software instructions to be executed by a data processor of a device according to the invention and being designed to command the execution of different steps of the methods.
The invention is therefore also aimed at providing a program capable of being executed by a computer or by a data processor, this program comprising instructions to command the execution of the steps of a method as mentioned here above.
This program can use any programming language whatsoever and be in the form of source code, object code or intermediate code between source code and object code such as in a partially compiled form or in any other desirable form whatsoever.
The proposed technique is also aimed at providing an information carrier readable by a data processor and comprising instructions of a program as mentioned here above.
information carrier can be any entity or device whatsoever capable of storing the program. For example, the carrier can comprise a storage means such as a ROM, for example, a CD ROM or a microelectronic circuit ROM or again a magnetic recording means, for example a floppy disk or a hard disk drive.
Furthermore, the information carrier can be a transmissible carrier such as an electrical or optical signal that can be conveyed via an electrical or optical cable, by radio or by other means. The program according to the proposed technique can especially be uploaded to an Internet type network.
As an alternative, the information carrier can be an integrated circuit into which the program is incorporated, the circuit being adapted to executing or to being used in the execution of the method in question.
According to one embodiment, the proposed technique is implemented by means of software and/or hardware components. In this respect, the term “module” can correspond, in this document, equally well to a software component and to a hardware component or to a set of hardware and software components.
A software component corresponds to one or more computer programs, one or more sub-programs of a program or more generally to any element of a program or a piece of software capable of implementing a function or a set of functions according to what is described here below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router etc) and is capable of accessing hardware resources of this physical entity (memories, recording media, communications buses, input/output electronic boards, user interfaces etc).
In the same way, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions according to what is described here below for the module concerned. It can be a programmable hardware component or a component with an integrated processor for the execution of software, for example, an integrated circuit, a smart card, a memory card, an electronic board for the execution of a piece of firmware etc.
Each component of the system described here above implements of course its own software modules.
The different embodiments mentioned here above can be combined with one another to implement the invention.
Other features and advantages of the invention shall appear more clearly from the following description of a preferred embodiment, given by way of a simple illustratory and non-exhaustive example and from the appended drawings, of which:
As explained here above, the general principle of the proposed technique consists of the implementing of a secured relay between the peripheral and the payment-receiving device.
Here above and here below, it is considered that:
In the prior-art technique, the cash register (or payment-receiving application) plays the role of a relay (proxy relay) between the payment terminal and the trusted component (or application). The prior-art method for transmitting data limits itself to making a secured transmission of data between the trusted component and the payment terminal.
Subsequently, when the peripheral wishes to transmit a piece of data to the payment-receiving device, it carries out a transmission of this piece of data to the trusted component. The trusted component receives this piece of data, encrypts and retransmits it to the peripheral. The peripheral then transmits this encrypted data (received from the trusted component) to the payment-receiving device. These exchanges between the trusted component and the peripheral travel through the payment-receiving device, because it is within the non-secured execution environment (in which the payment-receiving application works) that the communications interfaces (for example, network, USB, Wi-Fi, Bluetooth) are available and usable. The trusted component does not have direct access to these communications interfaces and therefore cannot directly interact with the peripheral. Thus, in a relatively counterproductive way, the payment-receiving device “relays” the data transmitted between the peripheral and the trusted component, but does so imperfectly.
Thus, in the prior-art technique, if the peripheral is fraudulent, the secured channel will not be established between the trusted component and the peripheral but the payment-receiving device (and the payment-receiving application) is not able to know this because it is the peripheral that finally informs the payment-receiving application that it is properly connected. It is therefore sufficient for the attacker to “replay” data previously “picked up” to create the illusion and make the payment-receiving application believe that everything has taken place properly.
The principle of the relay proposed in the present technique is different from the prior-art technique: it consists in setting up a first secured communications channel between the trusted component and the payment-receiving device and then in setting up a second secured channel between the trusted component and the peripheral (for example the peripheral).
This principle is described with reference to
Here below, any piece of data (d) coming from the peripheral (PERIPH) and intended for the payment-receiving device (DEC) is transmitted (4) to the trusted component (TC) in this second secured communications channel (3). The trusted component extracts the piece of data received and retransmits (5) this piece of data by using the first secured communications channel (1) to the payment-receiving device (DEC).
In this way, it becomes difficult to directly operate a transmission of data between the peripheral and the payment-receiving device. The transmission of a piece of data is necessarily routed towards the trusted component.
The relay can be qualified as a “double stage” relay in a certain sense, because:
Thus, it can be understood that the trusted component plays the role of a secured relay between the peripheral and the payment-receiving device; it acts so to speak as a first stage of the relay. The second stage is constituted by the routing function implemented within the payment-receiving device: indeed, the trusted component cannot directly receive the data coming from the peripheral because it does not have its own communications interfaces with the exterior. This means that the data coming from the peripheral and intended for it are routed by the payment-receiving device.
The security is increased because the peripheral is no longer capable of directly transmitting data to the payment-receiving device: it must for this purpose necessarily pass through the trusted component and therefore cannot reutilize the data previously exchanged with the payment-receiving device.
In this embodiment, an implementation of the present technique applied to a payment system is described. This embodiment is described with reference to
The cash register (CRA) also embeds at least one component making available a secured execution environment. In the embodiment presented here, this component is directly integrated into the motherboard of the cash register (CRA) and is called a trusted component (TC). In other embodiments, a dongle or a USB stick could also be considered to be a secured execution environment and be connected to the cash register (CRA) (connected for example within an internal connector, to the motherboard, on a dedicated connector). From the viewpoint of physical security, it is preferable that the secured execution environment should not be accessible from the exterior in order to prevent any fraud in which this element would be replaced.
In this embodiment, the payment terminal (TERMP) is connected to the cash register (CRA) by means of the Bluetooth interface of this cash register. This interface has the advantage firstly of being a wireless interface and secondly of being a short-range interface that ensures the use of third-party securing mechanisms if the payment terminal (TERMP) should be at a distance for a prolonged period of time. The secured communications channel between the payment terminal (TERMP) and the trusted component (TC) is therefore set up through the Bluetooth interface.
The method of data transmission implemented is the same as the one described here above.
In particular, when the cash register (CRA) is started up, it transmits (301) a request (RSC#1) to the trusted component (TC) for setting up the first secured communications channel (SC#1). On the basis of the request received (RSC#1), the trusted component (TC) sets up (302) the secured transmission channel. To this end, the trusted component (TC) extracts, from the received request (RSC#1), an identifier and makes a search in the list, called a white list, for the presence of this identifier. If it is able to identify the identifier in the white list, the secured communications channel is set up.
In one variant of this embodiment, the identifier of the cash register (CRA) is contained in a piece of data encrypted with a private key of the cash register (CRA). This encrypted data is decrypted (by means of the public key of the cash register (CRA)) by the trusted component (TC) and delivers a piece of clear data (the identifier as such). The trusted component (TC) then makes a search for this piece of clear data in the white list.
In another variant of this embodiment, the identifier of the cash register (CRA) is contained in a piece of data encrypted with a public key of the trusted component (TC). This piece of encrypted data is decrypted (by means of the private key of the trusted component (TC)) by the trusted component (TC) and delivers a piece of clear data. The trusted component (TC) then searches for this piece of clear data in the white list.
In another variant of this embodiment, the identifier of the cash register (CRA) is contained in a piece of data encrypted with a session key shared between the trusted component (TC) and the cash register (CRA). This piece of encrypted data is decrypted (by means of the private session key) by the trusted component (TC) and delivers a piece of clear data. The trusted component (TC) then searches for this piece of clear data in the white list. The session key is renewed periodically, for example either each time that the cash register (CRA) is started up or at regular intervals.
Once the first secured channel is set up, a communication of data (for example comprising data packets coming from a predetermined communications protocol) can be set up from the trusted component (TC) to the cash register (CRA) (and vice versa).
There follows a second step, comprising the creation of the second secured channel, between the payment terminal (TERMP) and the trusted component (TC). This second step is initiated by the transmission (303) by the cash register (CRA), to the payment terminal (TERMP), of a pairing instruction (IApp). This pairing instruction, according to the present technique, is accompanied by a piece of session-initializing data (DS) (for example a counter value), determined by the cash register (CRA). This session-initializing data (DS) is known only to the cash register (CRA). Upon reception of this pairing instruction, the payment terminal (TERMP) initiates the pairing process and, with the trusted component (TC), sets up the second secured communications channel. The payment terminal (TERMP) transmits (304) a request (RSC#2) to the trusted component (TC) for setting up the second secured communications channel (SC#2).
On the basis of the request (RSC#2) received by the payment terminal (TERMP), the trusted component (TC) sets up the secured transmission channel: the trusted component (TC) extracts an identifier from the received request (RSC#2) and searches for the presence of this identifier in a list called a white list. It if succeeds in identifying the identifier in the white list, the secured communications channel is set up (305). The variants of transmission of the identifiers for setting up this second communications channel are the same as those presented here above for the first communications channel.
Once the pairing is done (and therefore once the secured communication is set up with the trusted component (TC)), the payment terminal (TERMP) maintains itself in a state known as a “blocked” state (i.e. it is not capable of carrying out a payment transaction). While it is being maintained in the blocked state, the payment terminal (TERMP) builds a message (MSG) addressed to the cash register (CRA). This message comprises the session-initializing data (DS) (for example, a session-initialization counter or a message sequential counter) previously received from the cash register (CRA) as well as a random number. It is specified that the session-initializing data (for example the counter) must be modified (incremented) in each new message generated by the peripheral towards the cash desk (in order to prevent an attack by replay during a session).
The payment terminal (TERMP) transmits (306) this message to the trusted component (TC); the message (MSG) comprises an instruction for redirecting (IRd) to the cash register (CRA); then the payment terminal (TERMP) passes into a state known as a “transaction ready” state.
Upon reception of this message (MSG), the trusted component (TC) processes this message and then retransmits it (307) on the first secured transmission channel (SC#1). The cash register (CRA) receives (and/or intercepts) this message and decrypts it.
The cash register (CRA) then possesses the information according to which the payment terminal is properly connected (and identified) within the payment system (SYSP). In a complementary and optional way, the method comprises a step of transmission (308) by the cash register (CRA) to the payment terminal (TERMP) of an acceptance message (Accp). This message can advantageously include the “nonce” (random number) previously transmitted by the payment terminal at the initialization of the connection.
In one particular embodiment of the present technique, the step of transmission (306) of the message (MSG) to the trusted component (TC) comprises:
The step of transmission 307 is then implemented to retransmit the encrypted data to the trusted component.
More precisely, in at least one particular embodiment, the setting up of a secured communications channel is carried out as follows (the example taken is that of a communications channel between a peripheral and the trusted component): Prior to the setting up, the trusted component is provided with a white list containing a tuple {Peripheralldentifier, PeripheralPublicKey} for each authorized peripheral. “Peripheralldentifier” is the identifier of the peripheral and “PeripheralPublicKey” corresponds to the public key of the peripheral. Then, the setting up of the channels as such comprises the following steps:
Referring to
For example, the peripheral comprises a memory 41 constituted by a buffer memory, a processing unit 42 equipped for example with a microprocessor and driven by the computer program 43 implementing a method of data transmission in a secured communications channel. At initialization, the code instructions of the computer program 43 are, for example, loaded into a memory and then executed by the processor of the processing unit 42. The processing unit 42 inputs a pairing instruction from the payment-receiving device. The microprocessor of the processing unit 42 implements the steps of the transmission method according to the instructions of the computer program 43 to set up a secured communications channel with a trusted component (that is coupled with the payment-receiving device), the channel being established through the payment-receiving device (playing the role of a proxy relay); once the secured communications channel has been set up, the peripheral builds a message (the content of which is encrypted) addressed to the payment-receiving device, said message being relayed by the trusted component.
To this end, the peripheral comprises, in addition to the buffer memory 41, communications means such as network communications modules, data transmission means and, as the case may be, a dedicated encryption processor.
All these means can take the form of a particular processor implemented within the peripheral, said processor being a secured processor. According to one particular embodiment, this peripheral implements a particular application that is in charge of the performance of the encryption and the transmission of data, this application being for example provided by the manufacturer of the processor in question in order to enable the use of said processor. To this end, the processor comprises unique identification means. These unique identification means ensure the authenticity of the processor.
Besides, the peripheral also comprises an identifier, said identifier being used by the trusted component during the creation of the secured communications channel in order to authorize or not authorize the peripheral to get connected to the payment-receiving device.
Referring to
For example, the trusted component comprises a memory 51 comprising a buffer memory, a processing unit 52 for example with a microprocessor and driven by the computer program 53 implementing a method for receiving encrypted data.
At initialization, the code instructions of the computer program 53 are, for example, loaded into a memory and then executed by the processor of the processing unit 52. The processing unit 52 inputs requests for setting up secured channels (coming from a peripheral and/or a payment-receiving device) and thereafter inputs encrypted data coming from these devices. The microprocessor of the processing unit 52 implements the steps of the data transmission method according to the instructions of the computer program 53 to control the validity of the requests for setting up secured channels (as a function of identifiers provided in these requests).
To this end, the device comprises, in addition to the buffer memory 51, communications means, data transmission means and, as the case may be, an independent encryption processor.
All these means can take the form of a particular processor constituting the trusted component, said processor being a secured processor and/or making use of a secured memory (Msec). According to one particular embodiment, this trusted component implements a particular application which is in charge of carrying out the reception and control of the received data, this application being for example provided by the manufacturer of the processor in question in order to enable the use of said processor. To this end, the processor comprises unique identification means. These unique identification means ensure the authenticity of the processor.
Besides, the trusted component furthermore comprises means for obtaining encryption keys, for example encryption keys known as “session” keys which are derived for example from master keys recorded within the component itself.
Depending on the embodiments, the trusted component also comprises means for managing a list, called a white list, of devices authorized to set up secured transmission channels. More particularly, the trusted component can comprise a first physical memory, of a predetermined size, into which a list is inserted. The trusted component can also include a second physical memory, of a predetermined size, into which encrypted (or decrypted) data blocks are inserted subsequently to the reception processing of these pieces of data. These pieces of data can also be inserted and managed in the secured memory (Msec) of the trusted component when this component is provided with one. This makes it even more complicated to intercept data and understand the operation of the trusted component.
A remote transmission server can also transmit the white list (through a proxy/component executed in Rich OS) in the secured memory of the trusted component. This communication can then be protected by a secured channel having a nature different from that of the secured channels used for the pairing.
Referring to
For example, the payment-receiving device comprises a memory 61 comprising a buffer memory, a processing unit 62, equipped for example with a microprocessor and driven by the computer program 63, implementing a method for receiving encrypted data.
At initialization, the code instructions of the computer program 63 are, for example, loaded into a memory and then executed by the processor of the processing unit 62. The processing unit 62 inputs especially encrypted data coming from a trusted component, data received subsequently to the initialization of the payment-receiving device and to the transmission, by this device, of a request for setting up a secured communications channel with the trusted component. The microprocessor of the processing unit 62 implements the steps of the data transmission method according to the instructions of the computer program 63 to receive data coming from the trusted component and to route the data coming from the peripheral towards the trusted component.
To this end, the device comprises, in addition to the buffer memory 61, communications means (such as network communications means), data transmission means and, possibly an independent encryption processor.
All these means can take the form of a particular processor implemented within the payment-receiving device, said processor being a secured processor and/or making use of a secured memory (Msec). According to one particular embodiment, this payment-receiving device implements a particular application that is in charge especially of receiving and controlling the received data, this application being for example provided by the manufacturer of the processor in question in order to enable the use of said processor. To this end, the processor comprises unique identification means. These unique identification means ensure the authenticity of the processor.
Besides, the payment-receiving device furthermore comprises means for obtaining encryption keys, for example encryption keys known as “session” keys which are derived for example from master keys, recorded within the payment-receiving device itself.
Depending on the embodiments, the payment-receiving device also comprises means for managing secured data. More particularly, the payment-receiving device can comprise a first physical memory, of a predetermined size, in which the data coming from the peripheral are recorded and then routed. The payment-receiving device can also include a second physical memory, of a predetermined size, in which the encrypted data blocks (or decrypted data blocks) are inserted subsequently to the processing of the reception of this data coming from the trusted component. These data can also be inserted and managed in the secured memory (Msec) of the payment-receiving device when this device is provided with such a memory. This makes the task of intercepting data and understanding the working of payment-receiving device even more complex.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1650827 | Feb 2016 | FR | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2017/051864 | 1/27/2017 | WO | 00 |
