Methods for transmitting configuration data, associated electronic devices, central network and server comprising such an electronic device

Abstract

Configuration data is formed from several blocks and includes at least one remote resource address. A method for transmitting this configuration data to a client terminal comprises the following steps: - transformation (E50) of the configuration data by random ordering of said blocks; - sending (E58) of the transformed configuration data to the client terminal within a frame of a communication protocol. Another method for transmitting data and associated electronic devices are also proposed, as well as a central network and a server comprising such an electronic device. Figure for the abstract: figure 3

Description

Title of the invention: Methods for transmitting configuration data, associated electronic devices, central network and server comprising such an electronic device Technical field of the invention

[0001] The present invention relates to the technical field of security of communication protocols allowing in particular an exchange of configuration data.

[0002] The present invention relates in particular to methods and devices for transmitting configuration data, as well as to associated computer programs. State of the art

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

[0004] This configuration data can be transmitted within frames defined in a communication protocol. Thus, the client terminal which receives these frames can be programmed to interpret their content in accordance with this communication protocol and thus have the configuration data.

[0005] 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").

[0006] 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, he can in certain cases intercept the transmitted configuration data, replace certain data within the frame (in particular when the encryption used to encrypt the data is malleable), and transmit the modified data to the client terminal. For example, on this subject, reference may be made to the article "Breaking LTE on Layer Two", by D. Rupprecht et al. in 2019 IEEE Symposium on Security and Privacy (SP), pp. 1121-1136.

[0007] Techniques for controlling the integrity of all transmitted data have been proposed to remedy this problem, but these techniques lead to an increase in the quantity of data transmitted and the processing required at the terminals to verify the integrity, which results in a reduction in the quantity of data potentially transmitted over a given time interval. Presentation of the invention

[0008] In this context, a method of transmitting configuration data to destination of a client terminal, the configuration data being formed of several blocks and including at least one remote resource address, the method comprising the following steps:

[0009] - transformation of the configuration data by random ordering of said blocks;

[0010] - sending the transformed configuration data to the client terminal within a frame of a communication protocol.

[0011] By means of random block ordering, the blocks containing the configuration data will be ordered differently each time the configuration data is sent, so that an attacker will not be able to deduce the position of particular data (i.e., a particular block) by observing previously sent frames.

[0012] The method may comprise the following steps:

[0013] - determination of a first random value and / or a second random value;

[0014] - construction of the frame by concatenating an initial block of length equal to the first random value and said transformed data, and / or a final block of length equal to the second random value.

[0015] The transmission of data to the client terminal can be carried out via at least one interface without integrity control. Furthermore, the data is transmitted to the client terminal via at least one communication channel encrypted using malleable encryption. In other words, during sending, the aforementioned frame can be encrypted, for example using malleable encryption.

[0016] A method is also proposed for transmitting configuration data to a client terminal via at least one interface without integrity control, the configuration data including at least one remote resource address, the method comprising the following steps:

[0017] - encoding the configuration data using an error correcting code application layer;

[0018] - sending the coded data to the client terminal within a frame of a protocol of communication.

[0019] Thus, even if certain data are modified by an attacker, the client terminal will recover the initial data (before modification by the attacker) by decoding the error-correcting code. This renders the attack ineffective without, however, using an integrity check (or a low-layer error-correcting code) for all the data exchanged, which would reduce the effective bandwidth (i.e. the quantity of data actually exchanged per unit of time).

[0020] The aforementioned protocol may be, for example, a dynamic address configuration protocol (or DHCP).

[0021] The aforementioned remote resource address may be an address of a server configured to receive a domain name and / or issue an IP address associated with the domain name. Such a server is, for example, a DNS server.

[0022] In some embodiments, the client terminal is a user equipment, such as used in a mobile telephone network. The configuration data (transformed or encoded) may be sent (in particular) via a radio link between the user equipment and a radio access network of the mobile telephone network.

[0023] Also provided is an electronic device programmed or configured to:

[0024] - transform configuration data formed from several blocks and including at at least one remote resource address, by random ordering of said blocks;

[0025] - send the transformed configuration data to a client terminal within of a frame of a communication protocol.

[0026] Such an electronic device may be programmed or configured to:

[0027] - determining a first random value and a second random value;

[0028] - construct said frame by concatenating an initial block of length equal to the first random value, said transformed configuration data and a final block of length equal to the second random value.

[0029] An electronic device programmed or configured to:

[0030] - encoding, by means of an application layer error correcting code, data configuration including at least one remote resource address;

[0031] - send the encoded data to the client terminal within a frame of a protocol communication and via at least one interface without integrity control.

[0032] These electronic devices are, for example, microprocessor-based electronic devices. Alternatively, these electronic devices could be application-specific integrated circuits.

[0033] Also described below is a central network for managing a mobile telephone network, comprising such an electronic device.

[0034] According to another possibility, an address allocation server is provided comprising such an electronic device.

[0035] Of course, the various features, variants and embodiments of the invention may be combined with each other in various combinations to the extent that they are not incompatible or mutually exclusive. Detailed description of the invention

[0036] Furthermore, various other characteristics of the invention emerge from the appended description given with reference to the drawings which illustrate non-limiting forms of embodiment of the invention and where:

[0037] [Fig.l] represents the elements of a telecommunications system useful for the description of a possible context of implementation of the invention;

[0038] [Fig.2] illustrates the main steps of an example of configuring an IP address for a client terminal of the telecommunications system of [Fig.l];

[0039] [Fig.3] is a flowchart illustrating a first example of a method for processing configuration data; and

[0040] [Fig.4] is a flowchart illustrating a second example of a method for processing configuration data.

[0041] [Fig.l] shows the main elements of a telecommunications system in which the invention can be implemented.

[0042] This telecommunications system comprises a client terminal 2, a radio access network (or "Radio Access Network") 4, a central network 10 (also called "core network" or "core network" according to the commonly used English term) and a data network 20.

[0043] The client terminal 2 is here a user equipment (or "User Equipment"), according to the terminology conventionally used in the field of cellular telephony.

[0044] The client terminal 2 thus comprises, for example, an identification module (such as a subscriber identification module or SIM for "Subscriber Identity Module"). Such an identification module may be produced in the form of a microcircuit card embedded in the client terminal or, as a variant, another circuit (such as an integrated circuit) included in the client terminal and emulating the identification module (solution known as e-SIM).

[0045] The identification module can then store information (such as at least one secret key) which allows the client terminal 2 to connect to a mobile telephone network, as explained below.

[0046] The client terminal 2 comprises a wireless communication unit by means of which the client 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 central network 10, by at least one link which can be a wired link or a wireless link. The radio access network 4 and the central network 10 can in certain embodiments be connected via several links.

[0048] The central network 10 ensures the management of the aforementioned mobile telephone network and in particular allows in this context the connection of terminals to the mobile telephone network and the exchange of data between the different connected terminals.

[0049] Indeed, only one client terminal 2 and one element of the radio access network 4 are shown in [Fig.l] for clarity of the presentation, but the telecommunications system can in practice comprise numerous client terminals connected to the network central 10 via other parts of the mobile telephone network's radio access network 4.

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

[0051] The central network 10 comprises an access management module 12, a session management module 14 and a data management module 16.

[0052] In practice, each of the modules 12, 14, 16 can be produced by an electronic device, for example a microprocessor electronic device (or, alternatively, an application-specific integrated circuit). These electronic devices are connected to each other by a bus or by a computer network in order to exchange data. 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 in particular in the aforementioned specification.

[0054] The access management module 12 is therefore designed in particular to verify that the client terminal 2 does indeed hold (here within the aforementioned identification module) the aforementioned information (in particular a secret key) allowing access to the mobile telephone network.

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

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

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

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

[0059] The data network 20 comprises in particular an address allocation server 22 (here IP address). 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").

[0060] In [Fig. 1], certain interfaces allowing exchanges of signaling data (or control plane data, generally denoted CP for "Control Plane"), namely an interface II between the radio access network 4 and the access management module 12, an interface 12 between the access management module 12 and the session management module 14 and an interface 13 between the session management module 14 and the data management module 16.

[0061] These interfaces used for the transport of signaling data use transmission techniques including protection of the integrity of the transmitted data.

[0062] On the other hand, interfaces allowing exchanges of user data (or user plane data, or UP for "User Plane") are represented in dotted lines, namely an interface 14 between the user equipment 2 and the data management module 16 and an interface 15 between the data management module 16 and the data network 20, this interface 16 being used in the following to exchange data between the data management module 16 and the address allocation server 22.

[0063] Here, it is chosen to use transmission techniques without data integrity protection for interfaces 14 and 15, which makes it possible not to reduce the effective bandwidth when transferring user plane data.

[0064] Furthermore, the data (in particular the configuration data mentioned below) are here transmitted to the client terminal 2 via at least one communication channel encrypted by means of malleable encryption.

[0065] It is noted that the illustration of these interfaces in [Fig.l] does not represent the physical path of the data: for example, the data exchanged between the client terminal 2 and the data management module 16 transits via the radio access network 4, although this is not represented in [Fig.l].

[0066] [Fig.2] illustrates the main steps of an example of configuring an IP address for the client terminal 2.

[0067] This method begins with a step E2 during which the client terminal 2 and the access management module 12 implement (via the radio access network 4) an authentication protocol so as to ensure that the client terminal 2 does indeed hold (here within its identification module) the information (for example a secret key) justifying its right of access to the network.

[0068] The authentication protocol is for example an authentication and key establishment protocol, or AKA protocol (for "Authentication and Key Agreement"), for example as specified in the technical specification 3GPP TS 33.501 version 15.2.0 (December 2020).

[0069] In practice, this authentication protocol may involve other elements of the central network 10, such as an authentication function (here the AUSF function for "Authentication Server Function") and a user data storage element. (here the UDM function for "Unified Data Management"), these elements being in this case used at the request of the access management module 12.

[0070] When the client terminal 2 is authenticated, the exchanges can continue, here by sending a session establishment request SE.REQ (step E4). As illustrated in [Fig.2], this session establishment request SE.REQ is sent by the client terminal 2 and transmitted to the access management module 12 via the radio access network 4.

[0071] The access management module 12 then transmits in step E6 the session establishment request SE.REQ to the session management module 14.

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

[0073] The session management module 14 first sends a DHCP.SLCT request to at least the address allocation server 22, here via the data management module 16 (step E8). 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).

[0074] The address allocation server 22 receives the DHCP.SLCT request and sends a DHCP.ADVT response including in particular an address (here an IP address) proposed for the client terminal 2 (step E10). This DHCP.ADVT response is for example a response of the "DHCP Advertise" type.

[0075] The DHCP.ADVT response is received by the session management module 14 (via the data management module 16). The session management module 14 can then send (via the data management module 16) a DHCP.REQ message intended for the address allocation server 22 (step E12) in order to indicate to this address allocation server 22 the acceptance of the proposed address. This DHCP.REQ message is for example a message of the "DHCP Request" type.

[0076] The address allocation server 22 receives the DHCP.REQ message and responds in step E14 with a DHCP.REP message intended for the session management module 14 (and transmitted to this session management module 14 via the data management module 16) in order to confirm the allocation to the client terminal 2 of the proposed address. The DHCP.REP response is for example a response of the "DHCP Reply" type.

[0077] The session management module 14 then transmits in step E16 a session establishment acceptance message SE.ACC to the client terminal 2 (here via the access management module 12 and the radio access network 4).

[0078] It is noted that, in the embodiment described here, the data exchanged during steps E4 to E16 are part of the control plane (or CP for "Control Plane"). and are therefore transmitted using techniques ensuring data integrity protection.

[0079] As already indicated, a method is described here in which the implementation of the dynamic host configuration protocol is carried out by the session management module 14 on behalf of the client terminal 2. However, as a variant, the implementation of the dynamic host configuration protocol could be carried out outside the central network 10, for example using a dedicated server (such as a DN-AAA type server for "Data Network - Authentication Authorization Accounting"). The client terminal 2 in this case receives the session establishment acceptance message (containing the address allocated to the client terminal 2) from this dedicated server.

[0080] The client terminal 2 then sends in step E18 a request for configuration data CONF.REQ to the address allocation server 22 (here via the data management module 16 and the session management module 14). Such a request is for example a request of the "Router Solicitation" type as presented in the technical specification 3GPP TS 29.561 version 16.4.0, part 10.2.4.

[0081] In a 5G network, such a request is for example used to obtain configuration data relating to the IPv6 protocol, which were not transmitted during the previous exchanges (steps E4 to E16) to ensure backward compatibility with the IPv4 protocol.

[0082] Upon receipt of this CONF.REQ request, the address allocation server 22 prepares CONF.DAT configuration data, and transmits this CONF.DAT configuration data to the client terminal 2, in the form of a frame formed from different blocks, in accordance here with the dynamic host configuration protocol, or DHCP (each block corresponding in this case to an option, as explained later). This data is for example transmitted within a "Router Advertisement" type message as presented in the technical specification 3GPP TS 29.561 version 16.4.0, part 10.2.4.

[0083] In the example described here, the configuration data CONF.DAT are first transmitted from the address allocation server 22 to the session management module 14 via the data management module 16 (step E20).

[0084] The configuration data CONF.DAT are then processed by the session management module 14 in accordance with what is described below with reference to [Fig.3] or with reference to [Fig.4], then the processed data CONF.DAT' are sent from the session management module 14 to the data management module 16 (step E22).

[0085] The processed data CONF.DAT' are then sent from the data management module 16 to the client terminal 2 via the radio access network 4 (step E24), for example via at least one communication channel encrypted using malleable encryption.

[0086] In the example which has just been described, the processing of the configuration data CONF.DAT' (in accordance with what is proposed below with reference to [Fig.3] or with reference to [Fig.4]) is carried out within the session management module 14. However, as a variant, this processing could be carried out by another element, for example by the address allocation server 22 before sending the configuration data, or by an additional server interposed between the address allocation server 22 and the central network 10.

[0087] The processed configuration data CONF.DAT' are thus received by the client terminal 2 in step E26, so that the client terminal 2 can configure its parameters (here relating to IPv6) by means of the received configuration data CONF.DAT'.

[0088] The configuration data CONF.DAT' includes in particular a remote resource address, for example an address of a server configured to receive a domain name and in return transmit an IP address associated with the domain name (such a server is for example a DNS server, for "Domain Name System"'). The configuration data CONF.DAT' may contain other data, such as for example an IPv6 prefix of the IP address allocated to the client terminal 2.

[0089] The client terminal can thus use this DNS server, that is to say for example transmit a given domain name to the DNS server (using the address of this server contained in the configuration data CONF.DAT') and receive in return the IP address associated with this given domain name.

[0090] The data transmission of step E24 is carried out without integrity protection.

[0091] This is particularly the case when the transmitted data is user plane (or UP for "User Plane") data in a 5G network and integrity protection is not used for the interface between the client terminal 2 and the data management module 16 (interface 14 in [Fig.l]).

[0092] An attacker can therefore attempt to replace certain data (for example the aforementioned remote resource address, here the address of the DNS server) among the configuration data during their transmission between the radio access network 4 and the client terminal 2 (due in particular to the use of a communication channel encrypted by means of malleable encryption for the transmission of the data). Indeed, even if the exchanges between the radio access network 4 and the client terminal 2 are encrypted, an attacker can have access to the usual order of the different data blocks forming the configuration data by observing data legitimately received from the address allocation server 22 and can then replace the data block corresponding to the data that he wishes to replace (here the address of the DNS server).

[0093] If the attacker successfully completes his attack, the client terminal 2 configures its parameters with falsified data, here a falsified DNS server address, and the client terminal 2 will then contact a fraudulent DNS server, which will return an IP address erroneous so as to cause a connection from client terminal 2 to a server managed by the attacker.

[0094] The processing of the CONF.DAT configuration data, two examples of which are given below with reference to Figures 3 and 4 respectively, makes it possible to avoid these attacks.

[0095] [Fig.3] represents a first example of a method for processing configuration data, here within the session management module 14.

[0096] The configuration data is formed from an ordered sequence of blocks Bb ..., B;, ..., Bn. Each block can for example contain at least one configuration parameter, such as a remote address (here as already indicated a DNS server address), a maximum packet size value (or MTU for "Maximum Transmission Unit") or an IPv6 prefix.

[0097] In the example described here, each block corresponds to an option of the dynamic host configuration protocol (or DHCP) as defined in the document RFC 2132. In this case in particular, each block includes a code indicative of the option (i.e. the type of parameter) defined in this block.

[0098] For example, among the blocks forming the configuration data, one block may contain the code 6 and the aforementioned remote address (DNS server address).

[0099] The method of [Fig.3] begins with a step E50 of random reordering of the blocks Bb ..., B;, ..., BN so as to produce transformed configuration data formed by the randomly reordered sequence of blocks.

[0100] The transformed configuration data therefore corresponds to the ordered sequence of blocks Bj(i), ..., Bj(i), ..., Bj(N), where j is a random function from [1; N] to [1; N], and can be written: Bj(i)l ...IBj(i)l ...IBj(N), where I is the concatenation operator.

[0101] The method of [Fig.3] continues by drawing a first random value a between 1 and 132 (step E52) and by drawing a second random value b between 1 and 132 (step E54). In the example described here, the first random value a and the second random value b are such that the frame to be transmitted constructed as explained below does not exceed the maximum authorized size (i.e. the sum of the length of the configuration data, the random value a and the random value b does not exceed this maximum size). If this condition is not verified, it is possible, for example, to repeat steps E52 and E54 until the condition is verified.

[0102] The method of [Fig.3] then comprises a step E56 of constructing a frame to be transmitted by concatenating:

[0103] - an initial block B(a) of length a bytes;

[0104] - the transformed configuration data Bj(iJ .. .IBj(i)l .. .IBj(N);

[0105] - a final block B(b) of length b bytes.

[0106] The frame to be transmitted can therefore be written B(a)IBj0)l ....IBj(N)IB(b).

[0107] In the example described here, each of the blocks B(a) and B(b) can be constructed as an option of the DHCP protocol, for example with a code equal to 43 indicating a proprietary option (or "vendor-specified" according to the Anglo-Saxon term), and / or can contain random data.

[0108] The frame thus constructed can be transmitted (here from the session management module 14) to the client terminal 2 at step E58 (possibly via other network entities as explained above).

[0109] Thanks to the code included in each block, the client terminal 2 correctly interprets the content of each block and the random reordering does not pose any operational problems within the client terminal 2.

[0110] Similarly, the client terminal 2 can ignore the content of blocks B(a) and B(b), here by detecting code 43 (in accordance with what the DHCP protocol provides).

[0111] On the other hand, an attacker will not be able to determine the location of data that he wishes to modify (such as the address of the DNS server as explained above) since this location changes with each transmission thanks to random reordering.

[0112] Furthermore, thanks to the addition of random-sized blocks, it cannot anticipate a particular reordering: even if it manages by chance to come across the correct ordering of blocks for a given message, the presence of random-sized blocks prevents it from knowing what a given bit corresponds to. It would also be necessary for it to guess, again by chance, the length of the random-sized block for this given message, which is very unlikely.

[0113] [Fig.4] represents a second example of a method for processing data from configuration (here by the session management module 14) before their transmission to the client terminal 2.

[0114] This method comprises a step E70 of coding the configuration data by means of an application layer error correcting code.

[0115] For example, an error correction code of the AL-FEC type (for "Application Loyer - Forward Error Correction") is used here, i.e. a code applied to the application layer and allowing forward error correction.

[0116] During this step, due to the execution of application layer software by a processor (here by a processor of the session management module 14), such an application layer error correcting code is applied to the configuration data (which comprises, as already indicated, a remote resource address, such as a DNS server address, and possibly other parameters) in order to obtain coded data.

[0117] It is proposed here to use as application layer error correcting code a RaptorQ type code, as mentioned for example in the article "AL-FEC for streaming services in LTE E-MBMS", by J. Calabuig et al. in Eurasip Journal on Wireless Communications and Networking. Reference may also be made to the document RFC 5053 "Raptor Forward Error Correction Scheme for Object Delivery" or to the article "Cross-layer Raptor coding for broadcasting over wireless channels with memory", by Yu Cao and SD Blostein in 2009 1 Ith Canadian Workshop on Information Theory, Ottawa, ON, 2009, pp. 130-135.

[0118] The processed data (i.e. here the data coded by the error-correcting code) can thus be transmitted to the client terminal 2 in step E72.

[0119] It is noted that the use of an application layer error correcting code makes it possible to apply this error correcting coding to the configuration data (processed by the aforementioned software) without however applying it to other data transmitted (here by the session management module 14 to the client terminal 2) so as not to limit the effective bandwidth.

[0120] In this case, it is expected that upon receipt of the configuration data, the client terminal 2 proceeds to decode the coded configuration data received before use.

[0121] Thanks to the use of the error correcting code (here application layer), if some of the transmitted data are manipulated by an attacker, the modifications will be taken into account as transmission errors and the decoding will then make it possible to find the initial configuration data, as sent by the address allocation server 22.

[0122] Other treatments can be performed to counter the attack described above during which an attacker replaces some of the configuration data received by the client terminal (for example a user equipment) within the framework of the dynamic host configuration protocol or DHCP:

[0123] - installation of an application on the client terminal (user equipment) and use using a proprietary protocol (or other means via signaling, i.e. the control plane) to confirm that the configuration data received by the user terminal is indeed that expected by the address allocation server. It is also possible to open the ports to let the application manage the various exchanges, but this risks creating vulnerabilities in the client terminal.

[0124] - send an SMS to an application pre-installed in the client terminal (user equipment), this SMS containing the configuration data, so that this application can compare with the configuration data received under the DHCP protocol (as explained above) and automatically (and only) validate the configuration if there is a match.

[0125] - send an SMS to the user containing the configuration data so that the user validates them or not.

Claims

Claims

1. Method for transmitting configuration data (CONF.DAT') to a client terminal (2), the configuration data being formed from several blocks and including at least one remote resource address, the method comprising the following steps: - transformation (E50) of the configuration data by random ordering of said blocks; - sending (E58) of the transformed configuration data to the client terminal (2) within a frame of a communication protocol.

2. Transmission method according to claim 1, comprising the following steps: - determination (E52, E54) of a first random value and a second random value; - construction (E56) of the frame by concatenating an initial block of length equal to the first random value, said transformed data and a final block of length equal to the second random value.

3. A transmission method according to claim 1 or 2, wherein said protocol is a dynamic address configuration protocol.

4. A transmission method according to one of claims 1 to 3, wherein said remote resource address is an address of a server configured to receive a domain name and transmit an IP address associated with the domain name.

5. A transmission method according to one of claims 1 to 4, wherein the client terminal is a user equipment (2), and wherein the transformed configuration data is sent via a radio link between the user equipment (2) and a radio access network (4).

6. Method for transmitting configuration data (CONF.DAT') to a client terminal (2) via at least one interface (14) without integrity control, the configuration data including at least one remote resource address, the method comprising the following steps: - encoding the configuration data by means of an application layer error correcting code; - sending the encoded data to the client terminal (2) within a frame of a communication protocol, said protocol being a dynamic address configuration protocol.

7. The transmission method of claim 6, wherein said remote resource address is an address of a server configured to receive a domain name and transmit an IP address associated with the domain name.

8. A transmission method according to one of claims 6 to 7, wherein the client terminal is a user equipment (2), and wherein the coded data is sent via a radio link between the user equipment (2) and a radio access network (4).

9. Electronic device (14) programmed or configured to: - transform configuration data (CONF.DAT) formed from several blocks and including at least one remote resource address, by random ordering of said blocks; - send the transformed configuration data (CONF.DAT') to a client terminal (2) within a frame of a communication protocol.

10. Electronic device (14) according to claim 9 programmed or configured to: - determine a first random value and a second random value; - construct said frame by concatenating an initial block of length equal to the first random value, said transformed configuration data and a final block of length equal to the second random value.

11. Electronic device (14) programmed or configured to: - encode, by means of an application layer error correcting code, configuration data (CONF.DAT) including at least one remote resource address; - send the encoded data (CONF.DAT') to the client terminal (2) within a frame of a communication protocol and via at least one interface (14) without integrity control, said protocol being a dynamic address configuration protocol.

12. Central network (10) for managing a mobile telephone network, comprising an electronic device (14) according to one of claims 9 to 11.

13. Address allocation server comprising an electronic device according to one of claims 9 to 11.

Images