Method for transmitting configuration data in a telecommunications network

Abstract

A method for transmitting configuration data (CONF) in a telecommunications network comprises the following steps: - preparation, by a first electronic device, of verification data (MAC'') based on the configuration data (CONF) and a cryptographic key (K), the first electronic device being a server (22) or a telecommunications network management module; - transmission of the configuration data (CONF) and the verification data (MAC'') to a second electronic device, the second electronic device being a telecommunications network management module (14) when the first electronic device is the server, and the second electronic device being a terminal when the first electronic device is the management module; - verification of the verification data (MAC'') by the second electronic device (14). Figure for the abstract: Figure 3

Description

Title of the invention: Method for transmitting configuration data in a telecommunications network. Technical field of the invention

[0001] The present invention relates to the technical field of telecommunications.

[0002] It relates in particular to a method of transmitting configuration data in a telecommunications network. State of the art

[0003] In computer networks, it is planned on certain occasions to transmit configuration data to a terminal in order to enable in particular its interoperability with other electronic devices of the computer network concerned.

[0004] This is particularly the case when the terminal is in communication with a telecommunications network (for example, a mobile phone network) and needs to obtain configuration data relating to a computer network which the terminal accesses via the telecommunications network. This computer network is, for example, the Internet.

[0005] This configuration data can be transmitted within frames defined in a communication protocol. Thus, the terminal receiving these frames can be programmed to interpret their content in accordance with this communication protocol and thereby have access to the configuration data.

[0006] This is the case, for example, in the context of the dynamic configuration of the IP parameters of a client terminal using the DHCP protocol (for "Dynamic Host Configuration Protocol").

[0007] The transmission of configuration data within specific frames makes certain attacks possible. For example, if an attacker knows the position of particular data within the frame, they can, in some cases, intercept the transmitted configuration data, replace certain data within the frame, and transmit the modified data to the client terminal. See, for example, the article "Breaking LTE on Loyer Two" by D. Rupprecht et al. in the 2019 IEEE Symposium on Security and Privacy (SP), pp. 1121-1136.

[0008] Techniques for verifying the integrity of data exchanged between the terminal and the server issuing the configuration data have been proposed in the literature. However, these techniques require the sharing of cryptographic keys between the terminal and the server, which is not easy in practice. Presentation of the invention

[0009] In this context, the present invention proposes a method for transmitting configuration data in a telecommunications network, comprising the following steps:

[0010] - preparation, by a first electronic device, of verification data based on configuration data and a cryptographic key, the first electronic device being a server or a telecommunications network management module;

[0011] - transmission of configuration data and verification data to a second electronic device, the second electronic device being a telecommunications network management module when the first electronic device is the server, and the second electronic device being a terminal when the first electronic device is the management module;

[0012] - verification of verification data by the second electronic device.

[0013] A telecommunications network management module (and the means with which such a management module is provided) is thus used to allow verification of the integrity of the configuration data on at least part of their transmission from the server to the terminal.

[0014] The telecommunications network is, for example, a mobile telephone network. The terminal can be a user device in communication with (or connected to) this mobile telephone network.

[0015] Other non-limiting and advantageous features of the transmission method according to the invention, taken individually or in all technically possible combinations, are as follows:

[0016] - the verification data step uses the cryptographic key;

[0017] - the first electronic device is the management module, the cryptographic key is a secret key associated with the terminal, and / or the management module has access to said secret key;

[0018] - the management module is a user data management module or a authentication management module or access management module;

[0019] - the cryptographic key is a public key;

[0020] - the second electronic device is the management module, the cryptographic key is the public key of the management module, and / or the verification of the verification data is performed by the management module using the private key associated with the public key;

[0021] - the cryptographic key is a private key;

[0022] - the first electronic device is the management module, the cryptographic key is a private key associated with a telecommunications network operator, and / or the Verification of verification data is performed by the terminal using the public key associated with the private key;

[0023] - the configuration data and the verification data are transmitted within of a message including an indicator of the secret key used to prepare the verification data;

[0024] - the management module is a session management module;

[0025] - the transmission of configuration data is part of a protocol of dynamic address configuration;

[0026] - the configuration data includes an address assigned to the terminal;

[0027] - the configuration data includes a remote resource address;

[0028] - said remote resource address is an address of a server configured for to receive a domain name and to issue an IP address associated with the domain name.

[0029] Of course, the various features, variants, and embodiments of the invention can be combined with one another in various ways, provided they are not incompatible or mutually exclusive. Detailed description of the invention

[0030] In addition, various other features of the invention become apparent from the attached description made with reference to the drawings which illustrate non-limiting embodiments of the invention and where:

[0031] [Fig.1] represents the main elements of a telecommunications system in which the invention can be implemented;

[0032] [Fig.2] represents a first example of a configuration data transmission method according to the invention;

[0033] [Fig.3] represents a second example of a configuration data transmission method according to the invention;

[0034] [Fig.4] represents a third example of a configuration data transmission method according to the invention; and

[0035] [Fig.5] represents a fourth example of a configuration data transmission method according to the invention.

[0036] It should be noted that, in these figures, the structural and / or functional elements common to the different variants may have the same references.

[0037] Figure 1 shows the main elements of a telecommunications system in which the invention can be implemented.

[0038] This telecommunications system includes a terminal 2 (or client terminal), a radio access network 4 (or "Radio Access Network" according to the corresponding Anglo-Saxon term), a core network 10 (or "core network" according to the commonly used Anglo-Saxon term) and a data network 20.

[0039] The radio access network 4 and the core network 10 are part of a telecommunications network 15, in this case a mobile telephone network. As explained below, the terminal 2 can be connected to the telecommunications network 15 in order to exchange data with other equipment connected to the telecommunications network 15.

[0040] In the example described here, the telecommunications network 15 is designed to operate in accordance with the 3GPP TS 23.501 specification (for example in version 15.12.0 of December 2020) defining a 5G system.

[0041] The invention is not limited to this context (5G system), but could also be applied to other contexts, and in particular to other generations of mobile telephony systems.

[0042] Terminal 2 is here a user equipment (or "User Equipment"), according to the terminology classically used in the field of cellular telephony.

[0043] Terminal 2 thus includes, for example, an identification module (such as a subscriber identity module or SIM for "Subscriber Identity Module"). Such an identification module can be implemented as a microcircuit board embedded in the client terminal or, alternatively, as another circuit (such as an integrated circuit) included in the client terminal and emulating the identification module (a solution known as e-SIM).

[0044] The identification module can then store information (such as at least one secret key) which allows terminal 2 to connect to the telecommunications network 15.

[0045] Terminal 2 can also store (here within the identification module) a public key associated with the mobile telephone network operator 15.

[0046] Terminal 2 includes a wireless communication unit by means of which terminal 2 can exchange data with the radio access network 4 via a radio link.

[0047] The radio access network 4 is connected to the core network 10 by at least one link, which may be a wired or wireless link. In some embodiments, the radio access network 4 and the core network 10 may be connected via several links.

[0048] The core network 10 ensures the management of the telecommunications network 15 and in particular allows in this context the connection of terminals to the telecommunications network 15 and the exchange of data between the different connected terminals.

[0049] Indeed, only one terminal 2 and one element of the radio access network 4 are represented in [Fig.1] for clarity of exposition, but the telecommunication system may in practice include many terminals connected to the core network 10 via other parts of the radio access network 4 of the telecommunication network 15.

[0050] The network core 10 is for example implemented in accordance with the 3GPP TS 23.501 specification, here in version 15.12.0 (December 2020).

[0051] The network core 10 includes an access management module 12, a session management module 14, a data exchange management module 16, a user data management module 18 and an authentication management module 19.

[0052] In practice, each of the modules 12, 14, 16, 18, 19 can be implemented by an electronic device, for example, a microprocessor-based electronic device (or, alternatively, an application-specific integrated circuit). These electronic devices are interconnected by a bus or a computer network in order to exchange data. In the example described here, the various modules 12, 14, 16, 18, 19 of the core network 10 exchange data using secure links via the TLS (Transport Layer Security) protocol. Alternatively, several of the aforementioned modules could be grouped within the same electronic device.

[0053] The access management module 12 provides the access and mobility management function (or "Access and Mobility Management Function", generally referred to as AMF) as provided for in particular in the aforementioned specification.

[0054] The access management module 12 is therefore specifically designed to verify (for example by requesting the authentication management module 19) that the terminal 2 does indeed hold (here within the aforementioned identification module) the aforementioned information (in particular a secret key) allowing access to the telecommunications network 15.

[0055] The session management module 14 provides the session management function (or "Session Management Function", generally designated SMF) as provided in particular in the aforementioned specification.

[0056] The session management module 14 is therefore specifically designed to create, possibly update, and then delete sessions through which terminal 2 exchanges data with other electronic devices, as explained below.

[0057] The data exchange management module 16 provides the user plane management function (or "User Plane Function", generally designated UPF) as provided for in the aforementioned specification.

[0058] The data exchange management module 16 is therefore designed to transmit data from terminal 2 to the data network 20, and vice versa, within sessions managed by the session management module 14.

[0059] The user data management module 18 provides the unified data management (or UDM for "Unified Data Management") function as provided for in the aforementioned specification.

[0060] The user data management module 18 therefore has access to the (possibly secret) data associated with each user (here with each subscriber of the mobile telephone network, i.e. in practice with each identification module), this data being able to be stored in a memory of the user data management module 18 or in a user data repository (or UDR for "User Data Repository").

[0061] The user data management module 18 further stores here (for example in the aforementioned memory or data repository) the private key associated with the mobile network operator 15 (i.e. the private key associated with the already mentioned public key of the mobile network operator 15).

[0062] The authentication management module 19 provides the authentication server function (or "Authentication Server Function", generally designated AUSF) as provided in the aforementioned specification.

[0063] The authentication management module 19 is therefore designed to authenticate terminal 2 on request from the access management module 12 and by comparing data provided by terminal 2 and data provided by the user data management module 18.

[0064] The data network 20 includes, in particular, an address allocation server 22 (here, an IP address server). Such an address allocation server 22 is here designed to allocate addresses in accordance with a dynamic host configuration protocol or DHCP (for "Dynamic Host Configuration Protocol").

[0065] According to one possible embodiment (not shown in [Fig. 1]), the server 22 can be connected to the core network 10 via a proxy server (or "proxy" according to the commonly used Anglo-Saxon term).

[0066] Figure 2 represents a first example of a data transmission method configuration according to the invention.

[0067] Here, terminal 2 is considered to be connected to the telecommunications network 15, for example following an authentication step of terminal 2 by the core network 10, carried out here in accordance with the AKA protocol (for "Authentication and Key Agreement"), as proposed in the 3GPP TS 33.501 technical specification version 15.2.0 (December 2020).

[0068] The process in [Fig.2] begins with the issuance of a SE.REQ session establishment request (step E2). As illustrated in [Fig.2], this SE.REQ session establishment request is issued by terminal 2 and transmitted to the access management module 12 via the radio access network 4.

[0069] The access management module 12 then transmits the SE.REQ session establishment request to the session management module 14 at step E4.

[0070] Due to the reception of the SE.REQ session establishment request initially issued by terminal 2, the session management module 14 implements a dynamic host configuration protocol (or DHCP as already indicated), or dynamic address configuration protocol, on behalf of terminal 2, as explained now.

[0071] The session management module 14 first issues a DHCP.SLCT request to at least the address allocation server 22, here via the data exchange management module 16 (step E6). This DHCP.SLCT request is, for example, a "DHCP Solicit" type request and can be broadcast to a plurality of address allocation servers (DHCP servers).

[0072] Address allocation server 22 receives the DHCP.SLCT request and then prepares a DHCP.AD VT response at step E8.

[0073] The address allocation server 22 can also prepare supplementary data used as explained below to verify the integrity of the DHCP.ADVT response. This supplementary data can be obtained by applying to the DHCP.ADVT response (without the supplementary data) a cryptographic algorithm using a cryptographic key, for example a public key associated with the session management module 14 or, alternatively, a private key associated with the address allocation server 22.

[0074] The address allocation server 22 sends the DHCP.ADVT response (and optionally the accompanying data) to the session management module 14 (step E10) via the data exchange management module 16. This DHCP.ADVT response is, for example, a "DHCP Advertise" type response. The accompanying data can, for example, be placed in an option field of this response (which in this case combines the DHCP.ADVT response itself and the accompanying data).

[0075] Upon receipt of the DHCP.ADVT response by the session management module 14, the session management module 14 can proceed (when supplementary data is attached to the DHCP.ADVT response) to a step E12 of verification of the supplementary data, here using the private key of the session management module 14 (i.e., using the private key associated, within a private key-public key pair, with the public key of the session management module 14 already mentioned) when the public key of the session management module 14 is used in step E8. In the variant shown where the private key of the address allocation server 22 is used in step E8, the verification of the supplementary data is performed using the public key of the address allocation server 22.

[0076] If the check carried out in step E12 is negative, the process of [Fig.2] is terminated (possibly with sending a failure message to terminal 2).

[0077] If the check carried out in step E12 is positive, the session management module 14 prepares a DHCP.REQ message indicating acceptance of the proposed address (see below) and transmits this message in step E14 to the user data management module 18.

[0078] The user data management module 18 prepares in step E16 a SIG signature of the DHCP.REQ message using a Kpub public key, for example the public key of the address allocation server 22 already mentioned.

[0079] To do this, the user data management module applies, for example, to the DHCP.REQ message a cryptographic signature algorithm using the Kpub public key in order to obtain the SIG signature.

[0080] The user data management module 18 transmits the SIG signature to the session management module 14 at step E18.

[0081] The session management module 14 can then send (via the data exchange management module 16) the DHCP.REQ message and its SIG signature to the address allocation server 22 (step E20) in order to indicate to this address allocation server 22 the acceptance of the proposed address. This DHCP.REQ message is, for example, a "DHCP Request" type message.

[0082] Address allocation server 22 thus receives the DHCP.REQ message and can then verify the SIG signature at step E22. Address allocation server 22 verifies the SIG signature here, for example, using the private key associated with address allocation server 22.

[0083] The address allocation server 22 then prepares a DHCP.REP message at step E23, including:

[0084] - CONF configuration data, including for example an address (here a IP address) proposed for terminal 2;

[0085] - VERIF verification data obtained by applying to the data CONF configuration of a cryptographic algorithm using a cryptographic key, here the public key associated with the session management module 14 (or, alternatively, the private key of the address allocation server 22).

[0086] The VERIF verification data is obtained here, for example, by applying a cryptographic encryption algorithm using the public key of the session management module 14 to a digest of the CONF configuration data.

[0087] The address allocation server 22 then responds to step E24 by sending the DHCP.REP message to the session management module 14 (here via the data exchange management module 16) to confirm the allocation of the proposed address to terminal 2. The DHCP.REP response is, for example, a "DHCP Reply" type response. The VERIF verification data can then be placed in an option field of the DHCP.REP response.

[0088] Upon receiving the DHCP.REP response from session management module 14, session management module 14 can proceed to step E25 of verifying the CONF configuration data, here using the private key of session management module 14 (i.e., using the private key associated, within a private-public key pair, with the public key of session management module 14 already mentioned). In the variant shown where the private key of address allocation server 22 is used in step E23, the verification of the configuration data is performed using the public key of address allocation server 22.

[0089] For example, when a cryptographic encryption algorithm using the public key of the session management module 14 is used in step E23, the session management module 14 applies to the VERIF verification data a cryptographic decryption algorithm using the private key of the session management module 14, and compares the result obtained to the hash of the CONF configuration data (the verification being positive if and only if the result obtained is equal to the hash of the CONF configuration data).

[0090] The verification carried out makes it possible in particular to verify the integrity of the CONF configuration data.

[0091] If the check carried out in step E25 is negative, the process of [Fig.2] is terminated (possibly with sending a failure message to terminal 2).

[0092] If the check carried out in step E25 is positive, the session management module 14 transmits in step E26 a SE.ACC session establishment acceptance message to the client terminal 2 (here via the access management module 12 and the radio access network 4).

[0093] Figure 3 represents a second example of a configuration data transmission method according to the invention.

[0094] As in the case of the first embodiment, it is assumed here that terminal 2 is connected to the telecommunications network 15, for example following an authentication step of terminal 2 by the core network 10, carried out here in accordance with the AKA protocol (for "Authentication and Key Agreement"), as proposed in the 3GPP TS 33.501 technical specification version 15.2.0 (December 2020).

[0095] It is further assumed that a key exchange protocol has been implemented beforehand between the session management module 14 and the address allocation server 22 so that the session management module 14 and the address allocation server 22 each store the same secret key K.

[0096] The process in [Fig. 3] begins with the issuance of a SE.REQ session establishment request (step E52). This SE.REQ session establishment request is issued by terminal 2 and transmitted to the access management module 12 via the radio access network 4.

[0097] The access management module 12 then transmits the SE.REQ session establishment request to the session management module 14 at step E54.

[0098] Due to the reception of the SE.REQ session establishment request initially issued by terminal 2, the session management module 14 implements a dynamic host configuration protocol, or dynamic address configuration protocol, on behalf of terminal 2, as explained hereafter.

[0099] The session management module 14 first issues a DHCP.SLCT request to at least the address allocation server 22, here via the data exchange management module 16 (step E56). This DHCP.SLCT request is, for example, a "DHCP Solicit" type request and can be broadcast to a plurality of address allocation servers (DHCP servers).

[0100] Address allocation server 22 receives the DHCP.SLCT request and then prepares a DHCP.AD VT response at step E58.

[0101] The address allocation server can also prepare initial MAC verification data by applying a cryptographic algorithm using a cryptographic key, here the secret key K, to the DHCP.ADVT response.

[0102] The address allocation server 22 sends the DHCP.ADVT response, optionally accompanied by the first MAC address verification data, to the session management module 14 (step E60) via the data exchange management module 16. This DHCP.ADVT response is, for example, a "DHCP Advertise" type response. The first MAC address verification data can, for example, be placed in an option field of the DHCP.ADVT response.

[0103] Upon receipt of the DHCP.ADVT response by the session management module 14, the session management module 14 can proceed to an E62 step of verifying the first MAC verification data, here using the secret key K.

[0104] If the check carried out in step E62 is negative, the process of [Fig.3] is terminated (possibly with sending a failure message to terminal 2).

[0105] If the check performed in step E62 is positive, the session management module 14 prepares in step E64 a DHCP.REQ message and second MAC verification data obtained on the basis of the DHCP.REQ message and the secret key K.

[0106] The second MAC' verification data is, for example, a message authentication code obtained by applying to a digest of the DHCP.REQ message the aforementioned cryptographic algorithm using the secret key K.

[0107] The session management module 14 then sends the DHCP.REQ message and the second MAC verification data to the address allocation server 22 at step E66 (via the data exchange management module 16) in order to inform that server Address allocation 22: Acceptance of the proposed address. This DHCP.REQ message is, for example, a "DHCP Request" type message.

[0108] Address allocation server 22 thus receives the DHCP.REQ message and the second MAC' check data and can then check this second MAC' check data at step E68.

[0109] For example, when a cryptographic algorithm using the secret key K is used in step E64, the address allocation server 22 applies to the digest of the DHCP.REQ message this same cryptographic algorithm using the secret key K, and compares the result obtained to the second MAC' check data, the check being positive if and only if the result obtained is equal to the second MAC' check data received.

[0110] Alternatively, still in the case where a cryptographic algorithm using the secret key K is used in step E64, the address allocation server 22 can apply the inverse cryptographic algorithm (this inverse cryptographic algorithm also using the secret key K) to the second MAC' verification data, and compare the result obtained to the digest of the DHCP.REQ message, the verification being positive if and only if the result obtained is equal to the digest of the DHCP.REQ message.

[0111] If the check carried out in step E68 is negative, the process of [Fig.3] is terminated (possibly with sending a failure message to the session management module 14).

[0112] If the check performed in step E68 is successful, the address allocation server 22 prepares a DHCP.REP message in step E70 to confirm the allocation of the proposed address and including:

[0113] - CONF configuration data, including for example an address (here a IP address) proposed for terminal 2;

[0114] - third MAC verification data” obtained by applying to CONF configuration data of a cryptographic algorithm using a cryptographic key, here the secret key K (shared by the session management module 14 and the address allocation server 22 as shown above).

[0115] The third MAC verification data is, for example, a message authentication code obtained by applying a cryptographic algorithm using the secret key K to a hash of the CONF configuration data.

[0116] The address allocation server 22 can then send the DHCP.REP message to the session management module 14 (via the data exchange management module 16) at step E72 to confirm the allocation of the proposed address to terminal 2. The DHCP.REP response is, for example, a "DHCP Reply" type response. The third MAC verification data is, for example, placed in an option field of the DHCP.REP response.

[0117] Upon receipt of the DHCP.REP response by the session management module 14, the session management module 14 can proceed to an E74 step of verification of the third MAC verification data”, here using the secret key K.

[0118] For example, when a cryptographic algorithm using the secret key K is used in step E70, the session management module 14 applies to the CONF configuration data digest (received within the DHCP.REP message) this same cryptographic algorithm using the secret key K, and compares the result obtained to the third MAC verification data” (received within the DHCP.REP message), the verification being positive if and only if the result obtained is equal to the third MAC verification data” received.

[0119] Alternatively, still in the case where a cryptographic algorithm using the secret key K is used in step E70, the session management module 14 can apply to the third MAC verification data” (received within the DHCP.REP message) an inverse cryptographic algorithm of the aforementioned cryptographic algorithm (this inverse cryptographic algorithm also using the secret key K), and compare the result obtained to the digest of the CONF configuration data (received within the DHCP.REP message), the verification being positive if and only if the result obtained is equal to the digest of the received CONF configuration data.

[0120] The verification performed makes it possible to verify the integrity of the CONF configuration data and the authenticity of the address allocation server 22.

[0121] If the check carried out in step E74 is negative, the process of [Fig.3] is terminated (possibly with sending a failure message to terminal 2).

[0122] If the check carried out in step E74 is positive, the session management module 14 then transmits in step E76 an acceptance message of SE.ACC session establishment to terminal 2 (here via the access management module 12 and the radio access network 4).

[0123] Figure 4 represents a third example of a configuration data transmission method according to the invention.

[0124] In this example, it is assumed that a process of the type described above with reference to Figures 2 and 3 has been implemented beforehand. As in those processes, terminal 2 is then connected to the telecommunications network 15.

[0125] The process in [Fig. 4] begins with a step E100 in which terminal 2 sends a CONF.REQ configuration data request to the session management module 14 (here via the radio access network 4 and the data exchange management module 16). Such a request is, for example, a "Router Solicitation" request as presented in the 3GPP TS 29.561 technical specification version 16.4.0, part 10.2.4.

[0126] In a 5G network, such a request is used for example to obtain configuration data relating to the IPv6 protocol which was not transmitted during previous exchanges in order to ensure backward compatibility with the Ipv4 protocol.

[0127] Upon receipt of this CONF.REQ configuration data request, the session management module 14 sends (step E102), to the user data management module 18, at least some of the CONF' configuration data intended to be sent later to terminal 2 (see below).

[0128] The CONF' configuration data includes, for example, data obtained during exchanges between the session management module 14 and the address allocation server 22 (such as the exchanges shown above with reference to Figures 2 and 3). The CONF' configuration data includes, for example, an address allocated to terminal 2 and / or an IPv6 prefix of the IP address allocated to terminal 2 and / or a remote resource address, such as an address of a server configured to receive a domain name and issue an IP address associated with the domain name (generally referred to as a "DNS server" for "Domain Name System") and / or an address of a gateway and / or network configuration data (for example, the data network 20 or the telecommunications network 15).

[0129] The user data management module 18 receives this CONF' configuration data and prepares VERIF' verification data at step E104 based on the CONF' configuration data and the private key of the mobile network operator 15.

[0130] The user data management module 18 obtains, for example, the VERIF' verification data by applying a cryptographic signature algorithm to the CONF' configuration data using the private key of the mobile network operator 15. This algorithm produces, for example, the VERIF' verification data by processing a digest of the CONF' configuration data using the private key of the mobile network operator 15.

[0131] The user data management module 18 transmits the VERIF' verification data to the session management module 14 at step E106.

[0132] The session management module 14 receives the VERIF' verification data and can then transmit the CONF' configuration data and the VERIF' configuration data to terminal 2 at step E108 (via the data exchange management module 16 and the radio access network 4). This CONF', VERIF' data is, for example, sent within a "Router Advertisement" type message as presented in the 3GPP TS 29.561 technical specification version 16.4.0, part 10.2.4.

[0133] Terminal 2 can thus verify the VERIF' verification data at step 10, here using the public key of the mobile network operator 15 (i.e. that is, the public key associated, within a private key - public key pair, with the private key of the mobile telephone network operator 15).

[0134] To do this, terminal 2 applies, for example, to the CONF' configuration data and the VERIF' verification data, a cryptographic signature verification algorithm using the public key of the mobile network operator 15. This algorithm processes, for example, the VERIF' verification data using the public key of the mobile network operator 15, and compares the result of the processing with the hash of the CONF' configuration data (the signature verification being positive if and only if the result of the processing is equal to the hash of the CONF' configuration data).

[0135] If the VERIF' verification data is successful (which notably guarantees the integrity of the CONF' configuration data), terminal 2 can use the CONF' configuration data. For example, terminal 2 can transmit a domain name to the remote resource address in order to obtain in response the IP address associated with that domain name.

[0136] If the VERIF' verification data check is negative, terminal 2 does not use the CONF' configuration data. Indeed, the data passing through the data exchange management module 16 is not protected in integrity in certain cases and can therefore be manipulated by an attacker.

[0137] Figure 5 represents a fourth example of a configuration data transmission method according to the invention.

[0138] In this example, it is also assumed that a process of the type described above with reference to Figures 2 and 3 has been implemented beforehand. As in those processes, terminal 2 is then connected to the telecommunications network 15.

[0139] The process in [Fig. 5] begins with a step E120 in which terminal 2 sends a CONF.REQ configuration data request to the session management module 14 (here via the radio access network 4 and the data exchange management module 16). Such a request is, for example, a "Router Solicitation" request as presented in the 3GPP TS 29.561 technical specification version 16.4.0, part 10.2.4.

[0140] Upon receipt of this CONF.REQ configuration data request, the session management module 14 sends (step E122), to a management module belonging to the network core 10 (here to the user data management module 18), at least some of the CONF' configuration data intended to be sent later to terminal 2 (see below).

[0141] In other embodiments, the management module to which the session management module 14 sends the CONF' configuration data may be another module that the user data management module 18; it may be for example the authentication management module 19 or the access management module 12.

[0142] As in [Fig. 4], the CONF' configuration data includes, for example, data obtained during exchanges between the session management module 14 and the address allocation server 22 (such as the exchanges shown above with reference to Figures 2 and 3). The CONF' configuration data includes, for example, an address allocated to terminal 2 and / or an IPv6 prefix of the IP address allocated to terminal 2 and / or a remote resource address, such as an address of a server configured to receive a domain name and issue an IP address associated with the domain name (generally referred to as a "DNS server" for "Domain Name System") and / or an address of a gateway and / or network configuration data (for example, the data network 20 or the telecommunications network 15).

[0143] The relevant management module (here the user data management module 18) receives this CONF' configuration data and prepares VERIF verification data at step E124 on the basis of the CONF' configuration data and a secret key shared between the relevant management module and terminal 2.

[0144] When the management module concerned is the user data management module 18, this secret key is for example the cryptographic key IK (shared between the user data management module 18 and terminal 2).

[0145] When the management module concerned is the authentication management module 19, this secret key is for example the KAUSF cryptographic key (shared between the authentication management module 19 and terminal 2).

[0146] When the management module concerned is the access management module 12, this secret key is for example the Kamf cryptographic key (shared between the access management module 12 and terminal 2).

[0147] For more information on these potentially used IK, KAUSF, Kami cryptographic keys, reference may be made, for example, to the ETSI TS 133 501 V16.3.0 (August 2020), part 6.2 specification.

[0148] The VERIF verification data is, for example, a message authentication code obtained by applying to a hash of the CONF configuration data a cryptographic algorithm using the aforementioned secret key (here the IK secret key or, in the aforementioned variants, respectively the KAUSF secret key or the Kamf secret key)-

[0149] The relevant management module (here the user data management module 18) then transmits the VERIF verification data to the session management module 14 at step E126.

[0150] The session management module 14 receives the VERIF verification data and can then transmit the CONF' configuration data and the VERIF verification data to terminal 2 at step E128 (via the data exchange management module 16 and the radio access network 4). This CONF', VERIF data is, for example, sent within a "Router Advertisement" type message as presented in the 3GPP TS 29.561 technical specification version 16.4.0, part 10.2.4.

[0151] The message transmitted from the session management module 14 to terminal 2 and containing the CONF' configuration data and the VERIF' verification data may further include an indicator designating the secret key used for the preparation of the VERIF' verification data in step E124 (for example from among the aforementioned IK, KAUSF, Kamp secret keys).

[0152] When this message conforms to the DHCP protocol as provided herein, the aforementioned flag (designating the secret key used in step E124) can, for example, be stored in the field called "secret 1D" of option 90 contained in this message and defined in RFC 3118 specification.

[0153] Terminal 2 receives this message (containing the CONF' configuration data, the VERIF verification data and the aforementioned flag) and can thus verify the VERIF verification data at step E130, here using the secret key designated by the received flag (namely the secret key shared between terminal 2 and the management module that prepared the VERIF verification data at step E124, here the IK secret key shared between the user data management module 18 and terminal 2).

[0154] To do this, terminal 2 applies here to the digest of the received CONF' configuration data the cryptographic algorithm used in step E124 and using the shared key designated by the flag, and compares the result obtained and the received VERIF' verification data, the verification being positive if and only if the result is identical (i.e. equal) to the received VERIF' verification data.

[0155] If the verification of the VERIF data is successful (which notably guarantees the integrity of the CONF' configuration data), terminal 2 can use the CONF' configuration data. For example, terminal 2 can transmit a domain name to the remote resource address in order to obtain in response the IP address associated with that domain name.

[0156] If the verification of the VERIF data is negative, terminal 2 does not use the CONF' configuration data. Indeed, the data passing through the data exchange management module 16 is not protected in integrity in certain cases and can therefore be manipulated by an attacker.

Claims

Demands

1. A method for transmitting configuration data (CONF; CONF') in a telecommunications network (15), comprising the following steps: - preparation (E8; E58; E104; E124), by a first electronic device (22; 18), of verification data (VERIF; MAC; VERIF'; VERIF”) based on the configuration data (CONF; CONF') and a cryptographic key (K; IK), the first electronic device being a server (22) or a management module (18; 19) of the telecommunications network (15); - transmission (E10; E60; E108; E128) of the configuration data (CONF; CONF') and the verification data (VERIF; MAC; VERIF'; VERIF”) to a second electronic device (14;2), the second electronic device being a management module (14) of the telecommunications network (15) when the first electronic device is the server (22), and the second electronic device being a terminal (2) when the first electronic device is the management module (18; 19); - verification (E12; E62; E10; E130) of the verification data (VERIF; MAC; VERIF'; VERIF") by the second electronic device (14; 2), the verification step (E62; E130) of the verification data using the cryptographic key (K; IK).;

2. A method according to claim 1, wherein the first electronic device is the management module (18; 19), wherein the cryptographic key is a secret key (IK) associated with the terminal and wherein the management module (18; 19) has access to said secret key (IK).

3. A method according to claim 2, wherein the management module is a user data management module (18) or an authentication management module (19) or an access management module (12).

4. A method according to any one of claims 1 to 3, wherein the configuration data (CONF') and the verification data (VERIF”) are transmitted within a message comprising an indicator of the secret key (IK) used to prepare the verification data (VERIF”).

5. A method according to any one of claims 1, 2 and 4, wherein the management module is a session management module (14).

6. A method according to any one of claims 1 to 5, wherein the transmission of configuration data (CONF; CONF') is part of a dynamic address configuration protocol.

7. A method according to any one of claims 1 to 6, wherein the configuration data (CONF; CONF') includes an address assigned to the terminal (2).

8. A method according to any one of claims 1 to 7, wherein the configuration data (CONF; CONF') includes a remote resource address.

9. A method according to claim 8, wherein said remote resource address is an address of a server configured to receive a domain name and issue an IP address associated with the domain name.

Images