METHOD FOR CONFIGURING A PAYMENT TERMINAL AND CORRESPONDING PAYMENT TERMINAL

Description

technical field

[0001] The field of the invention is that of electronic devices used for implementing software applications that involve or relate to confidential information, and which are therefore required to comply with certain security requirements defined in particular within the framework of standards or certifications. Among these devices, the invention relates more specifically to payment terminals. Previous art

[0002] Payment terminals, used to process payments, are specifically designed, both in terms of hardware and software, to offer the highest possible level of protection for confidential data that may be entered or stored on them. To guarantee a sufficient level of security for these terminals, standards have been established, and certification procedures have been developed to verify the conformity of such devices to these standards. The use of payment terminals is therefore subject to strict, mandatory, and enforced security regulations. In particular, these terminals must be certified compliant with PCI standards (for " Payment Card Industry " , such as, for example, the PCI-PTS standard (for " Payment Card Industry - PIN Transaction Security " .These standards define security requirements for both the physical design of the hardware and the software implemented within these devices. For example, sensitive data must generally be encrypted, and its processing is subject to cryptographic protocols. The use of software components capable of being implemented only within secure processors, inaccessible to third parties, is also generally required.

[0003] The PCI-PTS standard notably mandates the deployment of means to verify the authenticity and integrity of payment applications installed and running on these terminals. On the payment terminal side, these means generally take the form of a unique cryptographic method (for example, a specific method based on the RSA cryptographic system), specific to the terminal manufacturer, which is implemented within firmware (" firmware »(in English) loaded at the factory into a secure memory within the terminal. The firmware incorporating the cryptographic method must have previously passed a certification process guaranteeing its compliance with the security requirements of the standard. EP patent application 3 588 359 A1 discloses a prior art payment terminal. US patent application 2011 / 131420 A1 discloses a secure device using techniques relevant to the implementation of multiple cryptographic methods.

[0004] The subsequent use of the specific cryptographic method embedded in the certified firmware equipping a fleet of payment terminals—for the purpose of verifying the authenticity and integrity of the payment applications installed on them—also requires the deployment of a set of dedicated tools at the acquiring customers' sites. These tools, which include cryptographic hardware specifically adapted to the implementation of the cryptographic method used in the acquired payment terminals (for example, signature tools), generally represent a costly investment for the customer.Also, some customers are sometimes reluctant to acquire new terminals based on a cryptographic method different from the one they usually use to verify the authenticity and integrity of payment applications installed in their existing fleet of payment terminals, given the significant costs involved in acquiring new tools compatible with the cryptographic method used in these new terminals.This reluctance can hinder the adoption of new terminals offered by a manufacturer, and close off markets to them, especially when that manufacturer markets ranges of payment terminals not all based on the same cryptographic method (which happens frequently for multiple reasons, for example during acquisitions of competitors or mergers between manufacturers, or following innovations allowing the development of ranges of payment terminals incorporating increasingly secure encryption techniques, etc.).

[0005] To address this issue, the solution generally adopted by manufacturers is to develop, for each range (or model) of payment terminals sold, as many firmware versions as there are cryptographic methods that could be offered to customers. However, this solution is not without its constraints for the manufacturer. In particular, it requires them to maintain several production lines in the factory for each terminal range, in order to be able to integrate, at the request of an acquiring customer, the specific firmware containing the appropriate cryptographic method, compatible with the verification tools already deployed at that customer's site. Furthermore, this solution obliges the manufacturer to multiply the certification processes to guarantee that the numerous firmware versions maintained all comply with current PCI standards, a process that often proves lengthy and difficult.All these constraints have direct impacts for the manufacturer, notably leading to an increase in the complexity and manufacturing costs of payment terminals.

[0006] Therefore, there is a need to develop solutions that address at least some of the drawbacks of prior art. More specifically, there is a need for solutions that offer greater flexibility in deploying and configuring methods for verifying the authenticity and integrity of applications loaded onto a payment terminal, while remaining compliant with the security requirements of current PCI standards. Summary of the invention

[0007] The present technique partially solves the problems posed by the prior art. The present technique relates to a method for configuring a payment terminal, which includes a step of loading, into a secure memory of said payment terminal, firmware comprising a plurality of distinct cryptographic methods, each cryptographic method of said plurality being intended to allow the subsequent implementation, by a third party possessing cryptographic hardware adapted to the method in question, of operations to verify the authenticity and integrity of at least one application installed on said electronic payment terminal.

[0008] In a particular embodiment, the configuration process includes at least one step of disabling at least one cryptographic method from said plurality of distinct cryptographic methods included in said firmware.

[0009] According to a particular characteristic, said step of disabling at least one cryptographic method includes a step of removing or revoking a certificate associated with said at least one cryptographic method, present in said payment terminal.

[0010] In a particular embodiment, the configuration process includes at least one step of activating at least one cryptographic method that was previously disabled.

[0011] According to a particular characteristic, said activation step of at least one cryptographic method includes a step of loading, within said payment terminal, a certificate associated with said at least one cryptographic method.

[0012] In another respect, the proposed technique also relates to an electronic payment terminal. Such a payment terminal includes at least one secure memory into which is loaded firmware comprising a plurality of distinct cryptographic methods, each cryptographic method of said plurality being intended to allow the subsequent implementation, by a third party possessing cryptographic hardware adapted to the method in question, of operations to verify the authenticity and integrity of at least one application installed on said electronic payment terminal.

[0013] In a particular embodiment, at least one of said separate cryptographic methods included in the payment terminal firmware is disabled.

[0014] According to a particular characteristic, at least one of said disabled cryptographic methods is reversibly disabled.

[0015] The different embodiments mentioned above can be combined with each other for the implementation of the invention. Figures

[0016] Other features and advantages of the invention will become clearer upon reading the following description of a preferred embodiment of the invention, given by way of simple illustrative and non-limiting example, and the accompanying drawings, among which: [ Fig 1 ] illustrates the main steps in a payment terminal configuration process, in a particular embodiment of the proposed technique; [ Fig 2 ] presents a simplified architecture of a payment terminal according to a particular embodiment of the proposed technique. Detailed description of the invention

[0017] This technique relates to a method for configuring a payment terminal, illustrated in relation to the figure 1in a particular embodiment. According to the general principle of the proposed technique, the method comprises a step 11 of loading, into a secure memory of the payment terminal, firmware comprising a plurality of distinct cryptographic methods (at least two), each cryptographic method of said plurality being intended to allow the subsequent implementation, by a third party possessing cryptographic hardware adapted to the method in question, of operations to verify the authenticity and integrity of at least one application installed on said electronic payment terminal. The firmware integrates, for example, in the form of different instruction sets, two distinct cryptographic methods, each enabling the execution (in a different manner) of operations to verify the authenticity and integrity of applications installed on the payment terminal.Thus, the firmware includes, for example, a first cryptographic method based on an RSA cryptography system, and a second cryptographic method based on elliptic curves. The preceding example is, of course, purely illustrative and not exhaustive, and the same firmware, using the proposed technique, can incorporate a larger number of distinct cryptographic methods. According to a particular feature, loading step 11 is performed at the factory during the manufacturing of the payment terminal.

[0018] Thus, unlike prior art solutions, several cryptographic methods—each capable of verifying the authenticity and integrity of applications (and more specifically, payment applications) installed on a payment terminal—are directly implemented in a single firmware file loaded into a secure memory within the terminal during manufacturing. This reduces the number of firmware files the manufacturer must submit for PCI certification, as it is no longer necessary to certify as many firmware files as there are methods offered. Furthermore, the payment terminal manufacturing chain is also simplified, and manufacturing costs are reduced, since the manufacturer is no longer required to maintain as many firmware production lines as there are methods offered.The integration of multiple cryptographic methods within the same firmware also offers new perspectives on security since it makes it possible to chain together operations to verify the authenticity and integrity of the same application using different methods, thus offering increased guarantees in terms of securing payment terminals.

[0019] In one particular embodiment, the configuration process according to the proposed technique optionally includes at least one step 12 of disabling at least one of the cryptographic methods implemented in the firmware loaded into the secure memory of the payment terminal. In the context of this technique, such disabling should not be understood as the removal of the cryptographic method in question: the cryptographic method remains present in the firmware, but it can no longer be invoked through the implementation of blocking means, which may be software or hardware-based, and an illustrative example of which is given later in this document.According to a specific characteristic, step 12 is implemented at least once, before the payment terminal is placed on the market, during a terminal customization phase designed to make it compliant with the needs and / or expectations of its acquirer. In this case, step 12 consists, for example, of disabling all cryptographic methods that do not correspond to or are not compatible with the tools already deployed at the customer's site for verifying the authenticity and integrity of the applications installed on the payment terminal. Depending on the customer and the tools at their disposal, the cryptographic methods disabled for the same terminal model will therefore not necessarily be the same. The proposed technique thus offers increased flexibility in terms of payment terminal customization.According to another specific feature, one or more iterations of step 12 of the deactivation process can also be implemented after the payment terminal has been placed on the market. This is particularly useful if it is detected that one of the cryptographic methods implemented in the firmware has a vulnerability that could be exploited by malicious actors to obtain sensitive data and / or carry out fraudulent payment transactions. With the proposed technique, the compromised method can be deactivated, and another cryptographic method present in the firmware can be used instead. A fallback solution is thus readily and quickly available, as it is present from the outset in the payment terminal's firmware.To this end, in a particular embodiment, the method optionally includes at least one step 13 for activating (or reactivating) a cryptographic method that was previously deactivated during the implementation of a deactivation step 12 as described above. In this way, the proposed technique makes it possible, in particular, to activate one of the cryptographic methods integrated from the outset into the firmware embedded in a payment terminal, but which had typically been deactivated for terminals acquired by a given customer because it did not correspond to the tools already deployed at that customer's site.This avoids having to replace all the payment terminals concerned (the number of which can reach thousands of terminals), by opting for a much less restrictive and more centralized solution consisting of deploying, if the customer did not already have them, the tools necessary to carry out the operations of verifying the authenticity and integrity of payment applications according to the newly activated cryptographic method.

[0020] In a particular embodiment of the proposed technique, the activation and / or deactivation of cryptographic methods—implemented in the payment terminal's firmware—for verifying the authenticity and integrity of applications is performed using electronic certificates. More specifically, in this embodiment, each cryptographic method is associated with a unique electronic certificate, derived directly or indirectly (via one or more intermediate certificates) from a root certificate of the manufacturer loaded into the payment terminal, or at least accessible from that payment terminal (via an interface and a communication network, for example). A cryptographic method is then usable (i.e., activated) only if the associated electronic certificate is also present in the payment terminal, and if that certificate is valid (i.e.,The certificate must be authentic and intact—which can be verified by tracing the certificate chain back to the root certificate—but also not expired or revoked. The electronic certificate associated with a method can therefore be considered, to a certain extent, as the activation certificate for that method. Thus, considering a payment terminal whose firmware includes multiple cryptographic methods as defined by the proposed technique, it is the choice of activation certificates loaded into the terminal that determines which cryptographic methods are activated or not from among the available options. Steps 12 and 13, described earlier and relating to the activation and deactivation of cryptographic methods present in the payment terminal's firmware, then refer to operations for processing the activation certificates associated with these methods.Thus, according to a specific characteristic, step 13 of activating a cryptographic method present in the firmware loaded into a payment terminal involves loading the activation certificate associated with that method into the terminal. As for step 12, deactivating a cryptographic method present in the firmware, it can be carried out in different ways. First, deactivating a cryptographic method in a payment terminal can be understood as not loading the activation certificate associated with that method into the terminal. This is typically the case during the initial configuration of the payment terminal, before its first release to the market: several cryptographic methods are present in the terminal's firmware, but only the activation certificates associated with the methods to be activated are loaded into the terminal (which is equivalent to deactivating the others).Secondly, disabling a cryptographic method can occur on a previously enabled method (for example, because it has been detected that the method in question, used until then, is compromised): in this case, disabling can be implemented directly, by deleting or revocating (temporarily or permanently) the activation certificate associated with the targeted method, or indirectly, by an action (e.g., deletion, revocation) on an intermediate certificate between the activation certificate and the root certificate, aimed at breaking the chain normally used to verify the authenticity and integrity of the validation certificate. Depending on the level of security required, such operations on activation certificates (loading, deleting, revocation, etc.) may be performed.These operations can be configured so that they can only be performed at the factory, requiring physical access to the terminal (for example, only after a complete terminal reset, i.e., a full reset to restore it to a "factory-out" state prior to customization). Alternatively, these activation certificate operations can be configured to be performed remotely, within secure procedures accessible via a communication network only to authorized personnel (with appropriate security measures, which may include various types: password, biometric authentication, PKI key, etc.).

[0021] In another respect, the proposed technique also relates to a payment terminal, a simplified architecture of which is presented in relation to the figure 2, in a particular embodiment. Such an electronic terminal (TermE) comprises a memory 21, a processing unit 22 equipped, for example, with a microprocessor, and controlled by a computer program 23. The electronic terminal also comprises a secure memory 24, which can be merged with the memory 21 (as indicated by the dotted line, in this case the memory 21 is a secure memory), a secure processing unit 25 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 controlled by a computer program 26 specifically dedicated to this secure processing unit 25.The secure processing unit 25 can in some cases, depending on the hardware solution chosen, be included in the processing unit 22 (it then takes the form, for example, of a dedicated secure area of ​​the processing unit 22, isolated from the rest of the processing unit 22 in order to guarantee perfect sealing between the functionalities performed by each part).The computer program 26 dedicated to the secure processing unit 25 may, in particular, take the form of firmware comprising instruction sets which, once loaded into the secure memory 24, define a plurality of distinct cryptographic methods, each intended to allow subsequent implementation, by a third party possessing cryptographic hardware adapted to the method in question and connected to the secure processing unit 25, of operations to verify the authenticity and integrity of at least one application installed on said electronic payment terminal. The group consisting of the secure processing unit 25, the secure memory 24, and the dedicated computer program 26 constitutes the secure portion (SP) of the electronic terminal.In at least one embodiment, this technique is implemented as firmware and a set of activation certificates installed partially or entirely on the secure portion of the payment terminal. In at least one other embodiment, this technique is implemented as a dedicated component (CpX) capable of processing data from the processing units and installed partially or entirely on the secure portion of the payment terminal. Furthermore, the terminal also includes communication means (CIE), for example, in the form of network components (WiFi, 3G / 4G / 5G), which enable the terminal to receive data (I) from entities connected to one or more communication networks and to transmit processed data (T) to such entities.

[0022] As explained previously, in a particular embodiment, the payment terminal using the proposed technique can be configured, either before or after its market launch, during a customization phase, so that at least one of the multiple cryptographic methods embedded in the firmware 26 is deactivated. According to a specific feature of this embodiment, such deactivation is reversible, and a previously deactivated cryptographic method can be reactivated (for example, to serve as an integrated fallback position in the event that a security vulnerability is detected in a previously used cryptographic method).

Claims

1. A method for configuring a payment terminal, said method being characterized in that it comprises: - a step of loading (11), within a secure memory of said payment terminal, a firmware comprising a plurality of distinct cryptographic methods, each cryptographic method of said plurality being intended to enable the subsequent implementation, by a third party having cryptographic hardware adapted to the method in question, of operations to verify the authenticity and integrity of at least one application installed on said payment terminal; - at least one step of deactivating (12) at least one cryptographic method of said plurality of distinct cryptographic methods included in said firmware, said deactivating step comprising a step of deleting or revoking a certificate associated with said at least one cryptographic method, present in said payment terminal.

2. The configuration method according to claim 1, characterized in that it comprises at least one step of activating (13) at least one of said previously deactivated cryptographic methods.

3. The configuration method according to claim 2, characterized in that said step of activating (13) at least one cryptographic method comprises a step of loading, within said payment terminal, a certificate associated with said at least one cryptographic method.

4. A payment terminal characterized in that it comprises: - at least one secure memory in which a firmware comprising a plurality of distinct cryptographic methods is loaded, each cryptographic method of said plurality being intended to enable the subsequent implementation, by a third party having cryptographic hardware adapted to the method in question, of operations to verify the authenticity and integrity of at least one application installed on said payment terminal; - means for deactivating at least one cryptographic method of said plurality of distinct cryptographic methods included in said firmware, said deactivating means comprising means for deleting or revoking a certificate associated with said at least one cryptographic method, present in said payment terminal.

5. The payment terminal according to claim 4 characterized in that at least one of said distinct cryptographic methods is deactivated.

6. The payment terminal according to claim 5 characterized in that at least one of said disabled cryptographic methods is reversibly deactivated.