DATA TRANSMISSION METHOD, DEVICE AND CORRESPONDING PROGRAM

Description

1. Field of the invention

[0001] The field of the invention is that of electronic devices comprising an open module and a secure module. Such electronic devices may be modular or integrated. More specifically, the invention relates to a method for transmitting data between the constituent modules of an electronic device, in particular an electronic payment device. 2. Prior art and its drawbacks

[0002] Modern data processing devices increasingly incorporate a traditional data processing device (such as a communication terminal, smartphone, tablet) and a secure module (such as a payment terminal or transaction terminal). These two devices are linked together to form a data processing device. Depending on the implementation methods, the data processing device either consists of two independent devices, manufactured separately and linked together in several different ways, or the data processing device directly integrates the two modules within itself.This latter configuration is becoming more and more common: a single device is ultimately manufactured with on one side a processing module, operating in an open manner and on the other side a secure data processing module, operating in a "closed" manner and protected against fraud attempts, both software and hardware (physical protection of access to signals) and software protection of access to data.

[0003] Whether integrated or made up of two independently manufactured devices (modules), such a data processing device has the particularity of connecting two modules whose functions and architectures are very different from each other. For example, the open module is characterized by its openness and modularity: the objective of such an open module is to allow users to carry out the actions they wish (for example, merchants, in their stores, to record the products or services purchased by customers) the open module therefore embeds multiple applications.

[0004] Thus, an open "sales" module includes, for example, applications for placing orders (i.e. scanning items) and / or for creating a shopping basket and / or for returning goods and / or for issuing invoices and / or for managing stocks, etc. The open module is based on an open architecture (for example Android ®< , Windows ®< , MacOS ®< , etc.). The open nature of this device (for example, sales) allows the development of numerous business applications. This openness is therefore appreciated by users.

[0005] In contrast, the secure data processing device (or module) is designed in a "closed" architecture which ensures that the data it processes, which is generally sensitive data, will not be diverted, stolen or used fraudulently. The secure module therefore incorporates technologies for maintaining security and confidentiality to ensure protection of the processed data: secure processor, secure memory, physical security devices (mesh, shielding, false keys, etc.). It may also include one or more communication interfaces (USB, Bluetooth, NFC, network) which are physical or virtualized (i.e. linked to the physical interfaces of the open module).

[0006] A general problem that therefore arises in a data processing device of this type is to ensure that the two modules (open and secure) can interact with each other, on the one hand while maintaining the attractiveness provided by the open module in terms of access and work potential and on the other hand while continuing to ensure the security of the data processed by the secure module.

[0007] Thus, for example, when the two devices are connected (permanent or temporary connection) to each other to carry out a transaction (for example a payment transaction), the security of the transaction and the data used must be ensured. A malicious application, which would be installed on the open device, must not be able to influence the transaction in progress by modifying it and / or obtaining protected data. However, to date, the two devices (or the two modules) communicate with each other using standardized technologies, mechanisms, protocols and processes, modeled on the OSI architecture, ranging from the application layer to the physical layer. For example, well-known protocols such as TCP and IP are currently used to make the two devices (or modules) communicate.The implementation of these protocols is often standard and is based on the implementation within general or dedicated components of libraries, which may be in the form of open source libraries. Thus, to date, when an application of the sales device wishes to carry out an operation with the data processing device, it transmits a series of TCP packets to a data processing application of the data processing device. However, these packets may intentionally or unintentionally carry fraudulent data or commands. These fraudulent data or commands may have been forged without the user's knowledge following an attack carried out directly on the open source library(s) used to attempt to obtain, from the secure data processing device, secret or personal data (certificates, signatures, bank identifiers, etc.).One solution could be to use a standard library and have it certified. However, this solution does not guarantee that such certification will be obtained and is very expensive.

[0008] US2002138549 describes secure and controlled web access using a smart proxy inside a smart card. A terminal and the smart card cooperate by relying on TCP layers 3 and 4 of the terminal to determine how to handle the request.

[0009] There is therefore a need to provide a technique for controlling the data required and provided between the two devices, particularly to ensure the overall security of the device while maintaining its open nature. 3. Statement of the invention

[0010] The invention meets this need by proposing a method for transmitting data between a first electronic module comprising a general processor, called an open module, and a second electronic module comprising a secure processor, called a secure module according to claim 1.

[0011] Thus, in such a device, whether integrated or not, it is possible to effectively control the data which transits between the open module and the secure module, particularly when the data is intended for a sensitive application running on the secure module. More generally, the invention relates to a method for transmitting data, within a device integrating an open module, running an open operating system, and a secure module, running an operating system qualified as secure (as opposed to the open operating system), the method comprising, during the execution, by an application of the open module, of a transaction involving the use of sensitive data (such as payment data, biometric data or encryption keys, etc.), a phase of transmission of this data via the specialized component, aggregating layers 3 and 4 of the OSI system, to a specialized component of the same type located within the secure module, this transmission implementing all or part of all the steps described herein.

[0012] According to a particular characteristic, the step of implementing said specialized data transmission component of the open module comprises at least one step of controlling authorization for data transmission from the application to the destination application. Thus, it is possible to immediately reject an attempt to transmit data from an application that would not be authorized to transmit such data to any service running on the secure module. This authorization control step can advantageously be implemented by the data transmission component of the secure module.

[0013] According to a particular characteristic, the step of implementing said specialized data transmission component of the open module comprises at least one data serialization step, according to a predetermined serialization format.

[0014] Thus, a fraudulent application that attempts to bypass the specialized data transmission component would not be able to easily serialize the data to be transmitted. According to a particular embodiment, the step of implementing said specialized data transmission component of the open module comprises the following steps: Opening a connection to a LibService component of the hybridized stack of the secure module; creation, by an ITP component of the hybridized stack, of a buffer for receiving the data to be transmitted; formatting, by the ITP component of the hybridized stack, of a buffer opening request to an ITP component of the hybridized stack of the secure module, said opening request comprising at least one identifier of the buffer for receiving the data to be transmitted and an access path required for the transmission of said data; transmission of said buffer opening request; reception, from the ITP component of the hybridized stack of the secure module, of an acknowledgment of receipt of said request; and when the acknowledgment of receipt authorizes the transmission of data: transmitting said data to said ITP component of the hybrid stack of the secure module; and closing the connection to the LibService component of the hybrid stack of the secure module.

[0015] According to a particular characteristic, the buffer opening request includes a buffer identifier and a certificate identifier.

[0016] Thus, the buffer opening request is secure in that it requires a certificate to appear to authorize the transmission of data.

[0017] According to a particular characteristic, the method comprises, at the level of the secure module, a step of verifying said certificate identifier, and when the verification of said certificate identifier delivers a negative result, a step of closing the connection.

[0018] So, when an invalid certificate is presented, data transmission cannot be performed.

[0019] According to a particular characteristic, the method comprises, at the level of the secure module, a step of verifying said certificate identifier, and when the verification of said certificate identifier delivers a positive result, a step of transmitting the acknowledgment of receipt of said buffer opening request.

[0020] According to a particular embodiment, after receiving said data by said ITP component of the hybrid stack of the secure module, it comprises a step of submitting the data to a filtering component; and when said data does not correspond to data expected for the destination application, a step of rejecting said transmitted data.

[0021] Thus, even if a fraudulent application manages to transmit data to the secure module, the data is checked to ensure that it complies with the specifications of the data intended for the destination application.

[0022] According to another aspect, the invention also relates to an electronic device associating within it a first electronic module comprising a general processor, called an open module, and a second electronic module comprising a secure processor, called a secure module according to claim 9.

[0023] According to one embodiment of the electronic equipment according to the invention, the open module is a communication module and the secure module is a payment terminal. The invention finally relates to a computer program product comprising program code instructions for implementing a method as described above, when executed by a processor.

[0024] The invention also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the method according to the invention as described above.

[0025] Such a recording medium may be any entity or module capable of storing the program. For example, the medium may comprise a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a USB key or a hard disk.

[0026] On the other hand, such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the computer program contained therein is remotely executable. The program according to the invention may in particular be downloaded over a network, for example the Internet.

[0027] Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method which is the subject of the aforementioned invention. 4. List of figures

[0028] Other aims, characteristics and advantages of the invention will appear more clearly on reading the following description, given as a simple illustrative, and non-limiting, example, in relation to the figures, among which: [ fig. 1 ] represents the grouping of network layers implemented by the present technique; [ fig. 2 ] represents a path taken by a request from an application in the open module to a service in the secure module; [ fig. 3 ] sets out the protocol implemented in the context of a request such as that presented in figure 2 ; [ fig. 4 ] describes the protocol implemented for the transmission of TCP / IP type packets; [ fig. 5 ] represents a simplified physical architecture of the device of the invention; [ fig. 6 ] is another representation of the physical architecture of the device of the invention, emphasizing the connection between the two processors of the two devices forming the device. 5. Detailed description of embodiments of the invention

[0029] The general principle of the invention is based on the interception and filtering, by at least one of the open or secure modules (also called open device or secure device respectively) of the processing device (modular or not), of the data physically exchanged between the two modules via the physical link (wired) which connects the two processors of these modules (the processor of the open module is directly connected to the processor of the secure module), physical link of the SPI / UART type (hereinafter, only SPI is mentioned for greater clarity and conciseness).

[0030] The invention relates to the management of the security of data exchanged between an "open" module (device) and a "secure" module (device) integrated within the processing device, whether it is a modular processing device (in which the two modules can be physically connected or disconnected, without this affecting their individual operation when they are disconnected) or a completely integrated device where the two modules are physically linked to the device. The "open" module is so-called because it is managed by a user, who can, according to the specifications of this module, install software applications of his choice. This possibility is offered by the publisher of the operating device of the open module (such as for example Android ™< or iOS ™< ).To the extent that it is accepted that these freely installable applications are not secure (i.e. they may include all or part of the fraudulent modules) or that the user may themselves endanger the security of the open module by engaging in inappropriate behavior, the open module is by nature considered to be insecure, and therefore to potentially present risks to the operation of the secure module with which it is integrated within the processing device (risk of data theft or modification of the behavior and / or function of the secure module). On the contrary, the secure module is not manageable by the user: the manufacturer of the secure module does not authorize the installation of applications from public application stores and does not authorize the user to perform any action on this module.By nature, the secure module processes confidential or private data (banking data, biometric data, personal data) whose integrity and security must be preserved. However, in order to be able to provide new services, "extended" data exchanges between these two devices are authorized, and managed through the specific architecture presented.

[0031] Thus, the two modules (the "open" module and the "secure" module) exchange data with each other through a specific network stack portion imitating the operation of the corresponding network stack portion of the OSI model (the seven layers of these models are integrated within the open module and the secure module), with however a particular handshake protocol. This last characteristic is important because it allows to eliminate most of the attacks suffered by the secure module from harmful or fraudulent applications running on the open module. Such applications may attempt to transmit very large quantities of messages or data to the secure module with the aim of obtaining confidential data.The use of a network stack dedicated to communication between the two modules (two devices) integrated within the electronic device makes it possible to avoid these thefts of confidential data and / or modification of the secure module.

[0032] More specifically, each module (the open module and the secure module) has a standard network stack (ranging from application layer 6 to physical layer 1), with layer 7 being the application layer. This standard network stack allows each of the two devices to independently conduct data transmissions and receptions with the outside world (i.e. with the servers to which these two devices are connected to transmit and receive data).Thus, through the standard stack, the open module can transmit and receive data from a processing server internal or external to the organization within which the open module is assigned (for example, the open module can communicate, through its standard stack, with an order management server or an accounting server of a merchant, but also with an application download server of a software provider, located outside the merchant's communication network).Thus, through its standard stack, the secure module can communicate with one or more secure servers, in order to conventionally carry out secure data transmission and reception operations with these secure servers (for example, the secure module can communicate, through its standard stack, with a banking server, a server of a payment service provider, a server of an acquirer, but also with a software update server of the manufacturer of the secure module). These two standard stacks are implemented on the secure module and on the open module through one or more hardware and software components dedicated to each device.

[0033] Furthermore, according to the invention, when the open module and the secure module need to communicate with each other (i.e. when data needs to be exchanged between the open module and the secure module, for example payment data or any other sensitive information, such as biometric data, personal data, etc.), specific components implementing a specific network stack are used. The specific network stack resulting from the use of one or more specific software or hardware components is referred to as a secure stack. According to the invention, in a particular embodiment, two components of the standard network stack are replaced by one component of the specific network stack. The two components that are replaced are the components of layer 3 (network, IP) and layer 4 (transport, TCP / UDP).In the specific stack, these two components are replaced by a component called ITP, which manages both the network (layer) functionality and the transport (layer) functionality. Thus, the open module and the secure module each have an ITP component (indifferently called specialized component or ITP component) which is used for the transmission / reception of information between the open module and the secure module, in certain specific cases. Thus, in this embodiment, the standard stack comprises standard components while the specific stack comprises standard components and a specialized component, used to replace the standard components of layers 3 and 4. The standard components, which are not replaced, are common and shared for both stacks. The . figure 1 explains the component architecture as presented previously. The components common to both stacks are: Presentation (Pres), Session (Sess), Serial Link (SL) with an SPI / UART component for direct communication between the two devices. The ITP component is specific (specialized) to the communication between the two modules of the device: it is only used for the transmission of certain specific types of data, for example payment data that must circulate between the open module and the secure module and vice versa, as part of the execution of a payment transaction for example. The TCP and IP components are used in a standard way for any other reception and / or transmission of data. As indicated on the figure 1 , we therefore have a “secure” stack, which is also hybrid, and which includes an additional, secure component (ITP).

[0034] Furthermore, according to the invention, the stack of the secure module is equipped with an additional filtering and suppression component. This component is configurable and is integrated within and / or in cut-off from the ITP component.

[0035] Additionally, still according to the invention, the standard components and the ITP components are linked to the kernels of the devices. More particularly, for the open device, the (modified) components of the standard stack and the ITP component are integrated into the kernel of the operating device (within a non-modifiable memory, for example a ROM) and are signed and verified at startup of the open device. This guarantees the absence of the possibility of using these components when the signature thereof is different from a pre-recorded signature. The same applies to the secure module. These characteristics are additional and prevent, particularly at the level of the open device, a malicious application from attempting to modify the standard network stack or the ITP component.

[0036] In other words, to ensure the integration of the open module and the secure module within the same device, the inventors had the idea of ​​modifying the support for requesting (i.e., the transmission and reception of data) within the open module and the secure module. More specifically, the new "secure" stack is hybridized with the existing components in order to allow more secure and more efficient processing of commands from one or other of the devices within the device, this new hybridized stack implementing the ITP component exclusively dedicated to exchanges between these two devices of the device. The hybridized stack also remains usable for interactions with other devices external to the device, without however using the ITP component.

[0037] In addition to this new communication stack which, in an exemplary embodiment, performs the operations assigned to the TCP component and the IP component, the stack is equipped with a switcher (session, layer 5) which adapts its behavior (switching to ITP or TCP / IP) according to the formatted data received from the presentation manager (layer 6), which performs a structuring of the data received from the application layer (layer 7, application). According to the invention, the presentation manager (Pres, layer 6) uses a "Protocol Buffer" type mechanism to format the data received from the application layer, according to a predetermined format. Once the formatting control has been carried out, the formatted and binarized data are obtained by the switcher of the session layer (layer 5), which, depending on the formatted and binarized data present in the buffer, switches them to the ITP component or to the TCP component.

[0038] We present, in relation to the figure 2 , the logic of data transmission between the open module (device) and the closed module (device), an APP application requiring obtaining a service (SERV) from the secure module.

[0039] In this example, the open module is equipped with an SPI component, driving a synchronous serial data bus (serbus) and operating in full-duplex mode. In this implementation, the circuits communicate according to a master-slave scheme, where the master controls the communication. For example, the SPI component of the open module controls the communication with the equivalent SPI component of the secure module. The SPI component receives its encoded data from a SLIP component and performs encoding / decoding of the data received from the SPI component before transmitting it to the IP component or to the new transmission stack. The SLIP component implements encoding and decoding functionalities for SLIP packets, according to the provisions of RFC 1055.It defines the encoding, decoding, and validation functions, as well as a driver class that can be used to implement a SLIP protocol stack and higher-level classes that apply the SLIP protocol to TCP / IP connections or SPI streams. The SLIP component receives its data (packets) either from the IP component of the conventional network stack or from the specialized ITP component of the new secure stack (in the diagram, the reception is from the ITP component, dotted curved line). To do this, the SLIP component has access to two different groups of buffers that each receive, from the component in question (ITP or IP), the data packets to be transmitted.According to the present technique, the SLIP component works by interrogating these transmission buffers in turn to extract the packets to be transmitted, carry out the encoding of these packets and transmit them to the SPI component for actual transmission on the serial link between the two processors (UC). The SLIP component also works by receiving the packets from the SPI component, carrying out their decoding, identifying the reception buffer and depositing this packet in the corresponding reception buffer.

[0040] Thus, the process implemented is for example the following: Reception, by the session management component (LibService) of the hybridized communication stack of the open module, from the application (APP) running on the open module, of a request for data transmission to the destination application (Serv) running on the secure module; Determination, by the session management component (LibService), of a transmission path for said data (traditional component or ITP component) depending for example on the request of the application; and When the application (APP) wishes to transmit said data via the specialized data transmission component (ITP), a step of implementing the specialized data transmission component (ITP) of the open module to transmit the data to the corresponding specialized data transmission component (ITP) of the secure module.

[0041] This implementation of the specialized ITP component includes: Opening a connection to a LibService component of the hybrid stack of the secure module; creation, by the ITP component of the hybrid stack, of a buffer for receiving the data to be transmitted; formatting, by the ITP component of the hybrid stack, of a buffer opening request to an ITP component of the hybrid stack of the secure module, said opening request comprising at least one identifier of the buffer for receiving the data to be transmitted and an access path (pathname) required for the transmission of said data; transmission of said buffer opening request; reception, from the ITP component of the hybrid stack of the secure module, of an acknowledgment of receipt of said request; and when the acknowledgment of receipt authorizes the transmission of data: transmitting said data to said ITP component of the hybrid stack of the secure module; and closing the connection to the LibService component of the hybrid stack of the secure module.

[0042] In the following and the preceding, of course, it is agreed that the transmission steps described for a component of one of the two modules correspond to reception steps for the other module. It is also understood that the modules which transmit data are able to receive data, as is the case for the ITP components of the two modules.the invention relates to a method for transmitting data, within a device (for example a payment terminal of the Android payment terminal type or any other device) integrating an open module, running an open operating system, and a secure module, running an operating system qualified as secure (as opposed to the open operating system), the method comprising, during the execution, by an application of the open module, of a transaction involving the use of sensitive data (such as payment data, biometric data or encryption keys, etc.), a phase of transmitting this data via the specialized component, aggregating layers 3 and 4 of the OSI system, to a specialized component of the same type located within the secure module, this transmission implementing all or part of all the steps described herein.

[0043] There figure 3 discloses a set of steps leading to the transmission of data in a device as disclosed herein via specialized ITP components. The figure 4 illustrates the transmission of TCP / IP packets using the same ITP components.

[0044] The ITP component receives its data from the LibService (LibServ) component (Java / JNI socket), which itself received this data from the calling application (App). For the LibService (LibServ) component, the principle consists of formatting the data so that it is transmitted, via the ITP component of the open device, to the corresponding ITP component of the secure module, according to a data path principle (DataPath). The LibService (LibServ) component also constructs the session data (endpoints). The LibService (LibServ) component receives, from the APP application, a request to obtain data and / or to implement a service for the secure module. The LibService (LibServ) component requests from the ITP component the implementation of an effective data transmission. The ITP component accepts this implementation by returning an identifier (clientFD).This acceptance is subsequent to a reciprocal acceptance on the part of the LibService (LibServ) component of the secure module. Then, the LibService (LibServ) component of the open module constructs, from the data provided by the APP application, a request to the LibService (LibServ) component of the secure module, request including the identification of the formatted data (proto_id), the length of the data, the connection command, the identifier (clientFD, buffer identifier), a certificate identifier (CertID) and a path (pathname). The path (pathname), targets a particular application on the secure module. This data is then transmitted to the secure module via the principle previously described (ITP component, SLIP component, SPI component - SPI component, SLIP component, ITP component).

[0045] The ITP component of the secure module receives the data and performs a verification of them, in particular the path (pathname) and the calling application (APP). If these data correspond to authorized data (in particular with regard to the calling application and the targeted path), it transmits an acknowledgment of receipt to the ITP component of the open module which relays this information to the LibServ component of the open device. Then, the LibService component of the open module receives the data from the calling application and formats it (protobuff) and transmits it (it deposits it on the corresponding buffer) to the ITP component of the open device. The ITP component of the open module produces a request from the data deposited in the buffer (clientFD) and transmits the data of this request to the secure module via the principle previously described (ITP component, SLIP component, SPI component - SPI component, SLIP component, ITP component).Upon receipt of this data, the ITP component of the secure module calls the verification and filtering component (FW) to determine whether the data is correctly formatted and whether it is acceptable. If this is the case, the data is written to a buffer corresponding to the buffer (ClientFD) of the secure module. The LibServ component of the secure module receives this data in the buffer (ClientFD) and transmits it to the target service (SERV) in the path (pathname).

[0046] It is noted that according to the invention, as set out in figure 4 , it is also possible to transmit classic TCP / IP packets using the libService components of the open and secure devices respectively. To do this, the libService component requires the creation of a "classic" session (within traditional TCP / IP) by connecting to a specific IP address and port on the device (open or secure) to which it is connected.

[0047] More particularly in figure 3 , the ITP component is listening to support a data transmission between the sending device and the receiving device. To do this, the ITP component listens to a particular "channel", materialized by a proxy path ("proxy_pathname"). The libService component of the sending device (the open device, in the case of the figure 3 ), defines a new inter-CPU transmission tunnel, connecting it to the previously opened channel. On the receiving device side, a similar mechanism is implemented to allow listening to the channel set up between the two processors. After acceptance by both devices, the proxy protocol is implemented, in particular by performing serialization and formatting (protocolBuffer) of the data to be transmitted. The data from the buffer of the sending device is transmitted to the buffer of the receiving device, after a certificate verification step (CertID) attached to an initialization phase: during this phase, the Certld certificate is verified and the data reception buffer is created on the receiving side. A formatted acknowledgment is transmitted by the ITP component of the receiver to the ITP component of the sender to indicate acceptance of the transmission request and confirm the creation of the reception buffer.The libService component is then informed by the ITP component.

[0048] Upon receipt of this confirmation, the libService component transmits the data that must be transmitted to the receiver: it informs the ITP component of the length (LNE) of this data and subsequently provides the data in question: to do this, it inserts the length and the data of this length into the buffer previously created by the ITP component. The ITP component reads this buffer and formats and serializes the data intended for the ITP component of the receiver. Upon receipt, the ITP component calls a verification component ("Firewall"), which checks on the one hand the formatting of the received data and on the other hand their actual origin. When the firewall does not detect any problem relating to this data, it is written into the destination buffer and made available (reverse formatting) to the LibService component of the receiver which reads this data.These transmission steps can be repeated as many times as necessary until the data is completely transmitted. When all the data has been transmitted, the sender's LibService component informs the ITP component of the end of transmission by closing the transmission channel. The sender's ITP component then informs its receiver counterpart to free the reception buffer and close the connection.

[0049] More specifically, in figure 4 , the sender's LibService component opens a transmission channel and connects to a given IP address and port. The receiver's LibService component sets up the tunnel allowing the transmission of a first transmission notification packet. The receiver's LibService component accepts the received packet and notifies the receiver's LibService component. The sender's LibService component then transmits as many packets as necessary, until it closes the tunnel. The packets are transmitted and received, in this case, without the verification and filtering component (firewall) being used since this type of data transmission does not, a priori, address protected or confidential data.

[0050] According to this technique, the network and transport layers are either handled by the TCP component and the IP component of the standard stack or through the ITP component when it comes to data exchanged between the open module and the secure module.

[0051] More specifically, the ITP component: exposes Berkley sockets as the APIs between applications held on secure and open modules (devices); manages the Maximum Transmission Unit (MTU); ensures that the application held on the open module (device) is authorized to access the services of the secure module (device): a. upon socket creation, on the open device, the ITP evaluates the authorization of the calling application to request the creation of such a socket; b. upon socket binding to the secure module, A-ITP transfers the authorization to T-ITP which acknowledges or denies the binding; c. T-ITP returns the decision to A-ITP which returns it to the calling application; Allows two transfer modes: a. command / response in both directions; b. media buffer.

[0052] We present, in relation to the figure 5 , a simplified architecture of an electronic device (SystE) capable of carrying out the transmission processing as presented previously. An electronic device comprises a first electronic module comprising a memory 31, a processing unit 32 equipped for example with a microprocessor, and controlled by a computer program 33. The electronic device also comprises a second electronic module comprising a secure memory 34, which can be merged with the memory 31 (as indicated by dotted lines, in this case the memory 31 is a secure memory), a secure processing unit 35 equipped for example with a secure microprocessor and physical protection measures (physical protection around the chip, by lattice, vias, etc.and protection on the data transmission interfaces), and driven by a computer program 36 specifically dedicated to this secure processing unit 35, this computer program 36 implementing all or part of the method for processing a transaction as previously described. The group composed of the secure processing unit 35, the secure memory 34 and the dedicated computer program 36 constitutes the secure module (PS) of the electronic device. In at least one embodiment, the present technique is implemented in the form of a set of programs installed in part or in full on this secure portion of the transaction processing terminal. In at least one other embodiment, the present technique is implemented in the form of a dedicated component (CpX) capable of processing data from the processing units and installed in part or in full on the secure portion of the processing device.Furthermore, the device also includes communication means (CIE) presented for example in the form of network components (WiFi, 3G / 4G / 5G, wired) which allow the device to receive data (I) from entities connected to one or more communication networks and to transmit processed data (T) to such entities.

[0053] Such a device comprises, depending on the embodiments: means for obtaining data from transactional devices presented to users (access card, transaction card, etc.; these means may be presented, for example, in the form of a smart card reader, or contactless card readers of the NFC or RFID type); input means, allowing the user to enter one or more data for the implementation of the transaction, when necessary (physical input keyboard, screen, virtual input keyboard) means for processing the data obtained by the means for obtaining data from the transactional devices and means for processing the data entered by the users; these means are materialized for example in the form of a specialized component; means for processing a transaction; means for providing data to one or more transactional servers connected to the device;

[0054] As explained above, these means are implemented through modules and / or components, for example secure ones. They thus ensure the security of the transactions carried out while guaranteeing greater maintainability of the device.

[0055] There figure 6 is another representation of a processing device in which the present invention is implemented in a particular embodiment.

[0056] Such a modular processing device comprises a first module O2, such as an open module (i.e. comprising an open operating device), connected by means of a physical connection L3 (of the SPI / UART type) to a second module C4, a closed module, called a payment module. The payment module C4 is capable of executing operations relating to secure transactions such as payment transactions.

[0057] The first module O2 comprises in particular a user interface 21 and a processor 20. The user interface 21 may be, in one embodiment of the invention, constituted by an alphanumeric keyboard and a screen. In another embodiment of the invention, the user interface 21 may be a touch screen. The module O2 incorporates a first operating device OS1, such as for example the Android ™ operating device.

[0058] The L3 physical connection is a wired connection that physically connects the two modules O2 and C4.

[0059] The payment module C4 comprises a processor 40 and a payment card reader 41. In a first implementation, the payment card reader 41 is a secure card reader (magnetic and / or IC with contact and / or IC without contact) using a suitable connection in order to exchange data with a payment card 5. The payment module C4 incorporates a second specific and secure operating device OS2 capable of executing operations relating to secure transactions such as payment transactions.

Claims

1. Method for transmitting data between a first electronic module comprising a general-purpose processor, called the open module, and a second electronic module comprising a secure processor, called the secure module, the two modules being combined in an electronic device, the first module executing a first operating system and the second module executing a second operating system, the open module comprises a hybrid communication stack comprising, alongside standard components of layers 3 and 4 of the OSI model, a specialised data transmission component (ITP) managing both the network layer and the transport layer functionality and connecting layers 3 and 4 of the OSI model, and the secure module also comprises a hybrid communication stack comprising, alongside standard components of layers 3 and 4 of the OSI model, a specialised data transmission component (ITP) managing both the network layer and the transport layer functionality and connecting layers 3 and 4 of the OSI model, the method comprising the following steps: - Reception, by a session management component (LibService) of the hybrid communication stack of the open module, from an application (APP) running on the open module, of a request to transmit data to a destination application (Serv) running on the secure module; - Determination, by the session management component (LibService) of the hybrid communication stack of the open module, of a channel to transmit said data which is required by the application (APP), depending on the content of said request, either via the specialised data transmission component (ITP) of the hybrid communication stack of the open module, without using the standard components, of layers 3 and 4 of the OSI model, of the hybrid communication stack of the open module, or via the standard components, of layers 3 and 4 of the OSI model, of the hybrid communication stack of the open module, without using the specialised data transmission component (ITP) of the hybrid communication stack of the open module; and - When the application (APP) wants to transmit said data via the specialised data transmission component (ITP) of the hybrid communication stack of the open module, a step of implementing said specialised data transmission component (ITP) of the open module to transmit the data to the corresponding specialised data transmission component (ITP) of the secure module.

2. Method for transmitting data according to claim 1, characterised in that the step of implementing said specialised data transmission component (ITP) of the open module comprises, before this implementation, at least one step of checking the authorisation to transmit data from the original application (APP) to the destination application (Serv).

3. Method for transmitting data according to claim 1, characterised in that the step of implementing said specialised data transmission component (ITP) of the open module comprises at least one data serialisation step, according to a predetermined serialisation format.

4. Method for transmitting data according to one of claims 1 to 3, characterised in that the step of implementing said specialised data transmission component (ITP) of the open module comprises the following steps: - Opening of a connection intended for a session management component (LibService) of the hybrid stack of the secure module; - creation, by the specialised data transmission component (ITP) of the hybrid stack of the open module, of a buffer for receiving the data to be transmitted; - formatting, by the specialised data transmission component (ITP) of the hybrid stack of the open module, of a buffer opening request intended for a specialised data transmission component (ITP) of the hybrid stack of the secure module, said opening request comprising at least one identifier of the buffer for receiving the data to be transmitted and a pathname required for the transmission of said data; - transmission of said buffer opening request; - reception, from the specialised data transmission component (ITP) of the hybrid stack of the secure module, of an acknowledgement of receipt of said request; and when the acknowledgement of receipt authorises the data transmission: - transmission of said data to said specialised data transmission component (ITP) of the hybrid stack of the secure module; and - closure of the connection to the session management component (LibService) of the hybrid stack of the secure module.

5. Transmission method according to claim 4, characterised in that the buffer opening request comprises a buffer identifier (FD) and a certificate identifier (CertID).

6. Transmission method according to claim 5, characterised in that it comprises, in the secure module, a step of checking said certificate identifier, and when the check of said certificate identifier delivers a negative result, a step of closing the connection.

7. Transmission method according to claim 5, characterised in that it comprises, in the secure module, a step of checking said certificate identifier, and when the check of said certificate identifier delivers a positive result, a step of transmitting the acknowledgement of receipt of said buffer opening request.

8. Transmission method according to claim 4, characterised in that after the reception of said data by said specialised data transmission component (ITP) of the hybrid stack of the secure module, it comprises a step of submitting the data to a filtering component (firewall); and when said data does not correspond to data expected for the destination application (Serv), a step of rejecting said transmitted data.

9. Electronic device combining a first electronic module comprising a general-purpose processor, called the open module, and a second electronic module comprising a secure processor, called the secure module, the first module executing a first operating system and the second module executing a second operating system, the open module comprises a hybrid communication stack comprising, alongside standard components of layers 3 and 4 of the OSI model, a specialised data transmission component (ITP) managing both the network layer and the transport layer functionality and connecting layers 3 and 4 of the OSI model, and the secure module also comprises a hybrid communication stack comprising, alongside standard components of layers 3 and 4 of the OSI model, a specialised data transmission component (ITP) managing both the network layer and the transport layer functionality and connecting layers 3 and 4 of the OSI model, the device further comprising: - means for receiving, by a session management component (LibService) of the hybrid communication stack of the open module, from an application (APP) running on the open module, a request to transmit data to a destination application (Serv) running on the secure module; - means for determining, by the session management component (LibService) of the hybrid communication stack of the open module, a channel to transmit said data which is required by the application, depending on the content of said request, either via the specialised data transmission component (ITP) of the hybrid communication stack of the open module, without using the standard components, of layers 3 and 4 of the OSI model, of the hybrid communication stack of the open module, or via the standard components, of layers 3 and 4 of the OSI model, of the hybrid communication stack of the open module, without using the specialised data transmission component (ITP) of the hybrid communication stack of the open module; and - means for implementing said specialised data transmission component (ITP) of the open module to transmit the data to the corresponding specialised data transmission component (ITP) of the secure module executed when the application (APP) wants to transmit said data via the specialised data transmission component (ITP).

10. Computer program product comprising program code instructions for the implementation of a communication method according to claim 1, when it is executed by a processor.