Processes and entities for securing journey data management

Abstract

Methods and entities for securing journey data management. The invention relates to a mechanism for securing journey data management in which a journey data management entity (EGD) verifies (EG4) before processing (EG6) a command, that the processing request (RQ) has been validated (ES6) by a control entity (CTR). Figure for the abstract: Fig. 4.

Description

Title of the invention: Methods and entities for securing the management of journey data technical field

[0001] The invention is situated in the general context of transport data management, and in particular biometric templates enabling passenger control.

[0002] In the remainder of this document, the terms "transport data" and "journey data" may be used interchangeably. This transport or journey data may include, in particular, a journey identifier (for example, a flight number, a train identifier, a sea crossing identifier) ​​and data relating to the passengers of this journey, for example, biometric data.

[0003] Sometimes, to simplify the description, we will place ourselves in the specific context of air journeys and flight data, but this disclosure applies similarly to other journeys and other means of transport.

[0004] It is known that at the time of airport security checks, such as boarding for a journey, passengers are asked, in order to control their access to the boarding area for the means of transport, to look at a camera or place a finger on a fingerprint sensor for example, in order to recalculate their biometric templates and compare them with the reference biometric templates of the passengers registered for that journey.

[0005] The invention aims in particular to protect these reference biometric templates, and more generally journey data, against malicious use. Description of the invention

[0006] To this end, and according to a first aspect, the present invention relates to a security method implemented by a control entity to secure processing carried out by a journey data management entity, said method comprising the following steps: - receipt of a request containing parameters of an order intended to be executed by said management entity, the parameters including at least a route identifier and a code of said order; - generation, using a private signature key of said controlling entity, of a cryptographic signature calculated from at least one of said parameters; - sending, to the said management entity, the said request and the said cryptographic signature.

[0007] Correspondingly, the invention relates to a control entity configured to secure the processing performed by a journey data management entity, said control entity comprising: - a communication module configured to receive a request containing parameters of an order intended to be processed by said management entity, the parameters including at least a route identifier and a code of said order; - a cryptographic module configured to generate, using a private signing key of said controlling entity, a cryptographic signature calculated from at least one of said parameters; and - a communication module configured to send, to said management entity, said request and said cryptographic signature.

[0008] According to a second aspect, the present invention relates to a method, implemented by a journey data management entity, this method comprising the following steps: - reception, from a controlling entity: (i) a request containing parameters of an order intended to be processed by said management entity, the parameters including at least a route identifier and a code of said order; and (ii) a cryptographic signature of at least one of said parameters; - verification of the validity of said signature using a public signature verification key of said controlling entity; - processing of said order, only if the validity of said signature is verified.

[0009] Correspondingly, the invention relates to a journey data management entity comprising: - a communication module configured to receive, from a control entity: (i) a request containing parameters for a command intended to be processed by that management entity, the parameters including at least a route identifier and a code for that command; and (ii) a cryptographic signature of at least one of said parameters; - a cryptographic module configured to verify the validity of said signature using a signature verification public key of said controlling entity; - a processing module configured to process said order, only if the validity of said signature is verified.

[0010] The invention also relates to a system comprising a control entity and a journey data management entity as mentioned above.

[0011] The invention applies in particular to air travel (flights), train travel, or boat travel (crossings). Thus, and more generally, the present invention proposes to make the processing of orders by the transport data management entity conditional upon the verification of a parameter signature of that order, said signature being calculated by a third party, namely the control entity. In a particular embodiment, the control entity and the transport data management entity are operated by separate operators.

[0012] The invention thus makes it possible to guarantee that access to and processing of journey data, in particular to reference biometric templates, only takes place in an authorized context, since any request received by the journey data management entity that is not accompanied by a valid signature is not processed.

[0013] In a particular embodiment of the invention, the journey data management entity has been certified by a third party.

[0014] More specifically, this management entity is certified to guarantee: (i) that it only processes said order if the request is of a predetermined type; and (ii) the processing of said order by said processing module.

[0015] This embodiment makes it possible to have a secure journey data management entity, in particular without a backdoor.

[0016] This advantageously allows the control entity to receive the request from a business application implemented by a non-certified entity, for example operated by the company operating the journey (airline, railway company, shipping company), these business applications thus being lightweight and easily updated, in particular on various media such as check-in kiosks or mobile devices such as mobile phones.

[0017] For example, the request received by the controlling entity may include a command for: - declare the journey (for example, the flight), or - delete the route, or - record a reference biometric template of a passenger encrypted with an encryption key known to said management entity, or - authenticate a passenger using a biometric template calculated with biometric data of that passenger acquired at the time of their passage through an airport security checkpoint.

[0018] The system of the invention then offers a perfectly secure mechanism since: - the certification of the journey data management entity prohibits any processing by this management entity outside the context of receiving a request in a determined format which is notably the subject of the certification;

[0019] - cooperation between the control entity and the journey data management entity ensures that only requests whose parameters are signed by the controlling entity with the controlling entity's private key will be processed by the managing entity.

[0020] In this sense, it can be considered that the invention makes it possible to validate and audit the requests processed by the journey data management entity.

[0021] Other conditions than verification of the validity of the signature may be required to process the order, but in any case, in accordance with the invention, the order is not processed by the trip data management entity if it determines that the signature of the request parameters is not valid or if it determines that the request is not accompanied by said signature.

[0022] In a particular embodiment, the control entity sends the request and the signature to the journey data management entity in the same message. Alternatively, they can be sent in separate messages.

[0023] In a particular embodiment, the security process includes a step of verifying the control parameters by said control entity.

[0024] For example, the control entity verifies that the format of the request corresponds to authorized formats, for example for which the journey data management entity has been certified.

[0025] For example, the control entity can verify the existence of a route associated with the route identifier included in the request. If the control entity detects one or more invalid parameters in the request, it can simply reject the request and not proceed with the signing and sending steps to the management entity. It can also issue an alert.

[0026] In a particular embodiment, the command parameters include an identifier of a request sender.

[0027] This embodiment may allow, for example, the controlling entity to check whether the issuer is an authorized issuer.

[0028] For example, authorized issuers are those whose identifier is registered in a whitelist or those whose identifier is not registered in a blacklist.

[0029] In another embodiment, the authorized issuers are those whose identifier verifies a particular format.

[0030] In a particular embodiment, the security process includes a step of recording, in a register, at least one transaction representing the receipt of said request and / or the sending, to said management entity, of the request and the cryptographic signature.

[0031] Preferably, the control entity records in this register a transaction for each request received and a transaction for each sending of the request and signature to the management entity.

[0032] A transaction includes, for example, for a received request: an identifier of the sender of the request, the date and time of receipt of the request, the request itself, and an indication of whether the received parameters are valid or not.

[0033] For each sending of a request and signature to a management entity, the transaction includes, for example: an identifier of the management entity, the date and time of sending, the request and signature.

[0034] This embodiment allows third parties to track all actions of the management unit. It also allows for statistical monitoring to detect an anomaly, and advantageously its origin, such as an abnormally high number of recording requests for the same route, for example via the same recording terminal, and thus to issue a dedicated alert.

[0035] In an embodiment of the invention in which the identifiers of the request senders are recorded in the register, an analysis of this register, for example statistical analysis, makes it possible to detect an unauthorized sender or an abnormally high number of requests originating from a particular sender. Upon such detection, an alarm can be raised.

[0036] In one embodiment, the ledger is a public ledger, for example a blockchain, traceability thus being made possible by third parties to the system according to the invention.

[0037] In a particular embodiment, if the signature is determined to be invalid, the request is simply ignored. Alternatively, a security alert may be raised.

[0038] Up to this point, it has been indicated how the invention made it possible to ensure that the journey data management entity only processed requests if it was solicited in a particular context.

[0039] In a particularly advantageous embodiment, the invention offers additional security by ensuring that the passengers' biometric templates are stored, deciphered and compared in a trusted environment.

[0040] Thus, in one embodiment of the journey data management process, the journey data management entity comprises a plurality of secure elements and the command included in said request is a command to register a passenger for the journey, a parameter of the command being a biometric reference template of said passenger encrypted with an encryption key known to the journey data management entity.

[0041] For example, the encryption key known to the journey data management entity may be a public key or a session key exchanged encrypted by a private key or calculated via the Diffie-Hellman protocol based on ECDH elliptic curves (from the English Elliptic curve Diffie-Hellman).

[0042] In this embodiment, the process comprises: - decrypt, within said secure element, the encrypted biometric reference template of the passenger using a private decryption key associated with the encryption key known to the journey data management entity; and - to record said biometric reference template in said secure element. For example, said biometric template can be recorded encrypted or decrypted.

[0043] Similarly, in one embodiment, the command included in the request is a command to authenticate a passenger boarding the journey, a parameter of the command being a biometric template of said passenger calculated from biometric data acquired at the time of their passage through the airport security checkpoint and encrypted with the encryption key known to the journey data management entity. In this embodiment, the journey data management process comprises: - decrypt this biometric template with the private decryption key; and - request the secure elements to compare this decrypted biometric template with the reference biometric templates recorded in these secure elements.

[0044] In this first embodiment of the invention, the secure elements, for example grouped in clusters of 64, can be configured to perform cryptographic and biometric processing in parallel.

[0045] Advantageously, the clear biometric templates remain confined within these secure elements, which can be certified.

[0046] In another variant of the invention, the processing of biometric profiles is implemented by a hardware security module (HSM for Hardware Security Module) connectable to a host device.

[0047] In a known manner, these HSM modules, which are presented for example in the form of embedded cryptographic electronic cards with a PCI, PCI-express or USB type connection interface, include secure cryptographic processing means, typically crypto-processors. Brief description of the drawings

[0048] Other features and advantages of the present invention will become apparent from the description below, with reference to the accompanying drawings which illustrate non-limiting examples of embodiments. In the figures:

[0049] [Fig-1] Fig. 1 schematically represents a system conforming to a mode particular implementation of the invention;

[0050] [Fig.2] Fig.2 illustrates an example of a query that can be used in a particular embodiment of the invention;

[0051] [Fig.3] Fig.3 represents an example of a journey data management entity that can be used in a particular embodiment of the invention;

[0052] [Fig.4] Fig.4 represents in flowchart form the main stages of a a securing process according to the invention and the main steps of a treatment process according to the invention.

[0053] [Fig. 5] [Fig. 5] represents the hardware architecture of a control entity conforming to a particular embodiment of the invention;

[0054] [Fig.6] Fig.6 represents the functional architecture of a control entity conforming to a particular embodiment of the invention;

[0055] [Fig.7] Fig.7 represents the hardware architecture of a management entity journey data conforming to a particular embodiment of the invention;

[0056] [Fig. 8] Figure 8 represents the functional architecture of a journey data management entity according to a particular embodiment of the invention. Description of embodiments

[0057] Figure 1 represents a system SYS according to the invention, in a particular embodiment. In this example, it comprises third-party entities ETPk, each implementing one or more applications APPk, a GTW gateway, a control entity CTR according to the invention, and a journey data management entity EGD according to the invention.

[0058] The APPk applications are configured to send RQ requests intended to be processed by the EGD entity for managing journey data.

[0059] Such queries are represented in [Fig.2]. They include, in particular and more specifically, the Py parameters of a C; command intended to be executed by the EGD entity for managing journey data, these Py parameters including at least one journey identifier, for example an NV flight number, and a C_COM code of said C; command.

[0060] The Py parameters may also include the identifier of a request sender.

[0061] By way of example, the following commands Ci to C4 can be considered: Ci: declaration of a route (for example of a flight) NV: command code C_COM = "DECL"; parameters Py = {NV}, C2: deletion of a route NV: command code C_COM = "DEL", parameters Py = {NV}; C3: Recording the reference biometric template of a PSG passenger for an NV journey: command code C_COM = "REG"; parameters Py = {NV, CRYP(GABr PSG, kcegd)}, C4: Authentication of a PSG passenger at the time of their passage through the airport security checkpoint for the NV journey, by comparing the biometric template GABbPSg calculated for this PSG passenger with biometric data acquired at the time of their passage through the airport security checkpoint with the reference biometric templates of passengers registered for this journey: command code C_COM = "BRD"; parameters Py = {NV, CRYP(GABbpsg, KCEGd)}-

[0062] For both commands C3 and C4, CRYP(GABbpsg, KCEGd) and CRYP(GABbpsg, KCEgd) respectively denote: - the PSG passenger's reference biometric template GABrPSg, calculated for example using biometric data acquired at the time of the passenger's enrollment, for example by using the photograph from their passport, and - the GABbpsg biometric template of this PSG passenger recalculated with biometric data acquired at the time of his passage through the airport security checkpoint, encrypted with an encryption key KCEGd known to the flight data management entity EGD.

[0063] The two commands Ci and C2 for declaring a route and deleting a route are for example issued by an APPk application of the information system of a transport company operating the route.

[0064] The third C3 registration command is issued for example 24 hours before the journey, by an APPk application of the information system of the transport company operating the journey, to register the reference biometric templates GABrpsg of all PSG passengers expected for the journey.

[0065] The fourth authentication command C4 is, for example, issued by an application APPk embedded in a terminal located, for example, at the airport security checkpoint, this application being configured to: - acquire biometric data (facial recognition, fingerprint) from a PSG passenger at the time of their passage through the airport security checkpoint, - calculate a biometric template GABbpsg of this passenger from this biometric data, and - encrypt this biometric template GABbPSg with the encryption key KCEGd known to the journey data management entity EGD.

[0066] In one embodiment of the invention, the EGD journey data management entity comprises a CMP component based on a system as described in document FR 3 089 377. This CMP component, schematically represented in [Fig. 3], includes, in particular, like the system described in document FR 3 089 377, a electronic module 22 comprising a controller 32 and one or more clusters 34 of secure elements 35, the secure elements 35 being configured to perform elementary cryptographic tasks.

[0067] In one embodiment of the invention, the CMP component of the EGD journey data management entity differs in particular from the system described in document FR 3 089 377 in that it is further configured to perform biometric operations.

[0068] For example, when the controller 32 receives a C3 command to register a reference biometric template, the controller 32 is configured to decrypt this template (received encrypted in the C3 command) with a private decryption key KCPRIVEGD associated with the encryption key KCPUBEGD known to the management entity and to register the reference biometric template in plain GABrpsg in a secure element 35.

[0069] Similarly, when controller 32 receives a C4 authentication command from a passenger at the time of passing through the airport security checkpoint, controller 32 is configured to decrypt the biometric template of that passenger calculated on the basis of biometric data acquired at the time of passing through the airport security checkpoint (received encrypted in the C4 command) with the private decryption key KCPRIVEGd and to request the secure elements 35 to compare this decrypted biometric template GABbpsg with the previously recorded reference biometric templates.

[0070] Very advantageously, in this embodiment, this comparison is carried out within the secure elements 35 so that the reference biometric templates GABrpsg (in plain text) are not exposed.

[0071] According to the invention, RQ requests issued by third-party entities EPk and intended to be processed by the EGD journey management entity are signed by the control entity CTR using a private signing key KSPRIVctr of the control entity CTR.

[0072] In the embodiment described here, the SG_Py signature is calculated on the whole of the RQ request, but alternatively the signature can be calculated only on the basis of the Py parameters of the C command included in the request.

[0073] Thus, the EGD trip data management entity verifies the validity of the SG_Py signature, using a KSPUBCtr signature verification public key, before processing the C command;. More precisely, the EGD data management entity processes the Ci command if and only if the validity of the SG_Py signature is verified.

[0074] Figure 4 represents in flowchart form the main steps ES of a securing process according to a particular embodiment of the invention and the main ES steps of a route data management process conforming to a particular embodiment of the invention.

[0075] We will assume that the journey data management process is implemented by a journey data management EGD entity.

[0076] We will assume that the security process is implemented by a CTR control entity to secure processing carried out by this EGD entity for managing journey data.

[0077] In the embodiment described here, the security process includes an ES2 step of receiving an RQ request, as described previously with reference to [Fig.2], issued by an APPk application of a third-party entity ETPk.

[0078] This RQ query includes Py parameters of a Ci command intended to be executed by the journey data management entity EGD.

[0079] The Py parameters comprising at least one NV journey identifier and a C_C0M code of the Ci command. They may also include, for example, an identifier of a request sender, a reference biometric template GABrpsg of a PSG passenger calculated, for example, with biometric data of the passenger acquired at the time of the passenger's enrollment, for example, using the photograph of their passport, or a biometric template GABbpsg of a PSG passenger calculated with biometric data of the passenger acquired, for example, at the time of the passenger's boarding, these templates having been encrypted by the APPk application with the KCEGd encryption key known to the journey data management entity EGD.

[0080] In the embodiment of the SYS system of [Fig. 1], the RQ request issued by the APPk application is more precisely transmitted to the CTR control entity by the GTW gateway.

[0081] In the embodiment described here, the securing process includes a step ES4 during which the control entity CTR checks the parameters Py of the command Q.

[0082] In the embodiment described here, if at least one Py parameter of the Ci command is incorrect, the EGD entity sends (step ES5) an error message to the APPk application.

[0083] In the embodiment described here, if all the Py parameters are valid, the security process includes an ES6 step in which the CTR control entity generates, using a KSPRIVCtr private signature key of the CTR control entity, a cryptographic signature SG_Py calculated from at least one Py parameter (preferably all) of the Ci command.

[0084] In the embodiment described here, the control entity CTR sends the RQ request and the cryptographic signature SG_Pÿ to the journey data management entity EGD during an ES8 step of the securing process.

[0085] In the embodiment described here, during a step ES10, the control entity CTR records, in an LDG register of the system S: -(i) a transaction for each RQ received (corresponding to the occurrences in step ES2). These transactions include, for example, the time the RQ was received and an identifier of the APPk application and / or the ETPk third-party entity that issued the request; and (ii) - a transaction for each sending of an RQ request and the associated signature SG_Pÿ to a journey data management EGD entity (corresponding to the occurrences of the ES8 step. These transactions include, for example, the time of this sending and an identifier of the journey data management EGD entity.

[0086] In the embodiment described here, the RQ request and the SG_Pÿ signature sent by the control entity CTR at step ES8 are received by the EGD journey data management entity during a step EG2 of the journey data management process.

[0087] During an EG4 step of the journey data management process, the EGD entity verifies the validity of the SG_Pij signature using a KSPUBCTr signature verification public key of the CTR control entity.

[0088] If the validity of the signature is not verified, the command included in the RQ request is not processed, and, in a particular embodiment, an ALM alarm is generated (step EG5) and, for example, transmitted to a station of the airline or an airport agent.

[0089] If the validity of the signature is verified, the command included in the RQ request is processed (step EG6),

[0090] For example: -if the command is a Ci command declaring an NV journey, the EGD entity for managing journey data prepares a data structure to record the reference biometric templates of the passengers of the NV journey; - if the command is a C2 command to delete an NV journey, the EGD entity for managing journey data destroys the reference biometric templates of the passengers of the NV journey; - if the order is a C3 order to register the reference biometric template of a PSG passenger for an NV journey, this template received encrypted with an encryption key KCEGD known to the management entity EGD is decrypted by this entity EGD with an associated private key KCPRIVEGd and is registered; - if the command is a C4d' authentication command of a PSG passenger at the time of their passage through the airport security checkpoint for the NV journey, the biometric template GABbPSg calculated for this PSG passenger with biometric data acquired at the time of their passage through the security checkpoint (at boarding for example) is decrypted by the EGD entity and compared with the reference biometric templates of the passengers registered for this journey.

[0091] Most advantageously, and as already described, when the EGD entity for managing journey data includes a CMP component as described with reference to [Fig.3], the decryptions of biometric templates and their comparisons are carried out within the secure elements 35 so that they are not exposed.

[0092] Figure 5 represents the hardware architecture of a CTR control entity according to the invention. In the embodiment described herein, the CTR control entity has the hardware architecture of a computer. In particular, it includes a processor 10, random access memory 11, read-only memory 12, and communication means 13.

[0093] The read-only memory 12 constitutes a recording medium within the meaning of the invention. It includes a computer program PGS according to the invention.

[0094] This PGS computer program includes instructions for executing the steps of the security process described with reference to [Fig. 4] when said program is executed by a computer, and in particular steps for: - receive a request containing parameters of a command intended to be executed by said management entity, the parameters including at least an identifier of said route and a code of said command; - generate, using a private signing key of said controlling entity, a cryptographic signature calculated from at least one of said parameters; - send, to said management entity, said request and said cryptographic signature.

[0095] This computer program PGS here defines functional modules of the control entity CTR, and which include in particular, as illustrated in [Fig.6]: - a first communication module configured to receive a request RQ containing parameters Py of a command Q intended to be processed by the EGD entity for managing journey data, the parameters including at least a journey identifier and a command code; - a CRY1 cryptographic module configured to generate, using a private signing key of said CTR controlling entity, an SG_Py cryptographic signature calculated from at least one of said parameters; and - a second COM communication module configured to send, to said journey data management entity EGD, said RQ request and said cryptographic signature SG_Py.

[0096] In the embodiment of [Fig.6], the two communication modules are the same module referenced COM1.

[0097] Figure 7 represents the hardware architecture of a trip data management entity (TDE) according to the invention. In the embodiment described herein, the trip data management entity has the hardware architecture of a computer. It includes, in particular, a processor 20, random access memory 21, read-only memory 22, and communication means 23.

[0098] The read-only memory 22 constitutes a recording medium within the meaning of the invention. It includes a computer program PGg according to the invention.

[0099] This computer program PGg includes instructions for executing the steps of the journey data management process described with reference to [Fig. 4] when said program is executed by a computer, and in particular steps for: - receiving, from a control entity: (i) an RQ request containing parameters for a command intended to be processed by said management entity, the parameters including at least an identifier for said route and a code for said command; and (ii) a cryptographic signature SG_Pÿ of at least one of said parameters; - verify the validity of said signature SG_Pÿ using a public signature verification key KSPUBCTR of said controlling entity; - to process said order, only if the validity of said signature is verified.

[0100] This computer program PGg here defines functional modules of the journey data management entity EGD, which include, in particular, as illustrated in [Fig.8]: - a COM2 communication module configured to receive, from a control entity: (i) an RQ request containing parameters for a command intended to be processed by said management entity, the parameters including at least an identifier for said route and a code for said command; and (ii) a cryptographic signature SG_Pÿ of at least one of said parameters; - a CRY2 cryptographic module configured to verify the validity of said signature using a KSPUBCTR signature verification public key of said controlling entity; - an MT processing module configured to process said order, only if the validity of said signature is verified.

[0101] The CMP component of the journey data management entity described above with reference to [Fig.3] constitutes an advantageous example of a CRY2 cryptographic module.

Claims

Demands

1. A security method implemented by a control entity (CTR) to secure processing carried out by a journey data management entity (EGD), said method comprising the following steps: - receiving (ES2) a request (RQ) containing parameters (Pÿ) of a command (Ci) intended to be executed by said management entity (EGD), the parameters (Pÿ) comprising at least one journey identifier (NV) and a code (C_COM) of said command (Q); - verifying (ES4) the parameters of the command; and if the parameters (Pij) are all valid: - generating (ES6), using a private signing key (KSPRIVctr) of said control entity (CTR), a cryptographic signature (SG_Pÿ) calculated from at least one of said parameters (Pÿ); - sending (ES8), to said management entity (EGD), of said request (RQ) and of said cryptographic signature (SG_Pÿ).

2. A security method according to claim 1, characterized in that said parameters (Pÿ) include an identifier of an issuer of said request (RQ).

3. A security method according to claim 11112, characterized in that said parameters (Pÿ) include a biometric template (GABRPSG, GABBPSG) of a passenger, said template having been encrypted by an application (APPk) of a third-party entity (ETPk) issuing the request (RQ) with an encryption key (KCEGd) known to the journey data management entity (EGD).

4. A security method according to any one of claims 1 to 3, characterized in that it comprises a step (ES 10) of recording, in a register (LDG), at least one transaction representing the receipt of said request and / or the sending, to said management entity, of the request and the cryptographic signature.

5. A security method according to any one of claims 1 to 4, characterized in that said request (RQ) received by said control entity (CTR) includes a command to: - declare the route, or - delete the journey, or - record a reference biometric template (GABrpsg) of a passenger encrypted with an encryption key (KCEGD) known to said management entity (EGD), or - authenticate a passenger (PSG) by means of a biometric template (GABBPSG) calculated with biometric data of that passenger acquired at the time of their passage through an airport security checkpoint.

6. A method for managing trip data, implemented by a trip data management entity (DGE), said method comprising the following steps: - receiving (EG2), from a control entity (CTR): (i) a request (RQ) containing parameters (Pÿ) of a command (Ci) intended to be processed by said management entity (DGE), the parameters comprising at least one trip identifier (NV) and a code (C_COM) of said command; and (ii) a cryptographic signature (SG_Pÿ) of at least one of said parameters (Pÿ) generated by implementing the security method according to any one of claims 1 to 5; - verifying (EG4) the validity of said signature (SG_Pÿ) using a signature verification public key (KSPUBCTr) of said control entity (CTR); - processing (EG6) of said order, only if the validity of said signature is verified.

7. A journey data management method according to claim 6, wherein said journey data management entity (JDE) comprises a plurality of secure elements (35), the command included in said request being a command to register a passenger (PSG) for the journey (NV), said parameter (P;) of said command being a reference biometric template (GABpsg) of said passenger encrypted with an encryption key (KCEGd) known to the journey data management entity (JDE), said method comprising: - decrypting, in said secure element (35), the encrypted reference biometric template of the passenger with a private decryption key (KCPRIVegd) associated with said encryption key (KCEGD) known to the journey data management entity (JDE); and - record said biometric reference template in said secure element (35).

8. A journey data management method according to claim 6, the command included in said request being a command to authenticate a passenger (PSG) boarding for the journey (NV), said parameter (Pi) of said command being a biometric template (GABpsg) of said passenger calculated from biometric data acquired at the time of their passage through a security checkpoint and encrypted with said encryption key (KCEGD) known to the journey data management entity (EGD), said method comprising: - decrypting this biometric template with said private decryption key (KCPRIVEGd); and - requesting said secure elements (35) to compare this decrypted biometric template with the reference biometric templates stored in these secure elements.

9. System (SYS) comprising: - a control entity (CTR) comprising: - a first communication module configured to receive a request (RQ) containing parameters (Py) of a command (Ci) intended to be processed by a journey data management entity (EGD), the parameters comprising at least a journey identifier and a command code; - a cryptographic module (CRY1) configured to generate, once all the command parameters have been verified and validated, using a private signing key of said control entity (CTR), a cryptographic signature (SG_Py) calculated from at least one of said parameters; and - a second communication module (COM) configured to send, to said journey data management entity (EGD), said RQ and said cryptographic signature (SG_Py);and - a journey data management entity (EGD) comprising: - a communication module (COM2) configured to receive, from a control entity (CTR): (i) a request (RQ) containing parameters (Py) of a command (Ci) intended to be processed by said management entity; (EGD), parameters including at least one route identifier (NV) and a code (C_COM) of said command; and (ii) a cryptographic signature (SG_Pÿ) of at least one of said parameters (Pÿ); - a cryptographic module (CRY2) configured to verify the validity of said signature (SG_P;) using a signature verification public key (KSPUBCTr) of said control entity (CTR); - a processing module (MT) configured to process said command, only if the validity of said signature is verified.

10. System (SYS) according to claim 9, characterized in that the trip data management entity (EGD) is certified to ensure: (i) that it only processes said command if said request is of a predetermined type; (ii) the processing of said command by said processing module.

Images