Method for revoking a certification token for authenticating the establishment of a connection between two communication devices, and corresponding devices and computer programs

Abstract

The invention relates to a solution for revoking a certificate supplied to a device in an edge computing environment. Existing authentication solutions are not well suited to the context of edge computing since they cannot meet the demands required to manage these items of equipment which may be deployed in distributed infrastructures, but which may, above all, be reconfigured, suspended, removed, reactivated or even reassigned to another master node depending on the demands to be met. The solution, which is the subject matter of the present invention, makes it possible, by reusing components that are already present in a communication network, to revoke a certificate whose integrity cannot be called into question since the trusted third party issuing the certificate is the operator managing the communication network.

Description

[0001] DESCRIPTION

[0002] TITLE: Method for revoking a certification token for authenticating the establishment of a connection between two corresponding communication equipment, devices and computer programs

[0003] Field of invention

[0004] The field of the invention is that of the certification of equipment connected to a communications network. More specifically, the invention relates to a solution for managing the revocation of a certificate associated with equipment in an “edge computing” type environment or computing at the edge of the network.

[0005] Prior art and its drawbacks

[0006] A new phase in the development of cloud computing has emerged in recent years. This new development is called edge computing and involves processing data at the edge of the network, as close as possible to the data source.

[0007] Edge computing thus minimizes bandwidth requirements between devices, such as sensors, and data processing centers by undertaking analyses as close as possible to the data sources. This approach requires the mobilization of resources that may not be permanently connected to a network, such as laptops, smartphones, tablets, or sensors. Edge computing also has a prominent place in content ingestion and delivery solutions. In this regard, many content delivery network (CDN) architectures are based on edge computing architectures.

[0008] A well-known implementation of such an edge computing architecture is an architecture known as Kubernetes.

[0009] [Fig. 1] presents in a simplified manner the architecture of a cluster of nodes 1 conforming to the Kubernetes solution. The cluster of nodes 1 comprises a first node 10 called management node, or “Kubernetes master”, and N computing nodes, or “workers node”, Hi, i 6 {1, ..., N}, N being a natural integer.

[0010] The management node 10 comprises a controller 101, an API (Application Programming Interface) module 102 and a database 103 called ETCD (name of the main Kubernetes database, storing the configurations of the distributed systems or clusters of machines) which consists of a dynamic configuration registry of the computing nodes llj.

[0011] A compute node llj comprises M containers or "pods" 110j, i {1, ..., M}, where M is a natural number. Each container 110j is provided with resources to execute one or more tasks. A task, when executed, contributes to the implementation of a network service or function, such as a DHCP (Dynamic Host Configuration Protocol) function for example.

[0012] In an effort to reduce costs and improve the flexibility of network infrastructures, edge computing architectures are most often multi-site architectures in which the nodes constituting the clusters of nodes may not be co-located. For example, a management node 10 and two computing nodes Hi, II2 of a cluster of nodes 1 are located on a site A while three other computing nodes Ila, II4, They are located on a remote site B. Existing authentication solutions, such as the HyperText Transfer Protocol Secure (HTTPS) protocol, which relies on the introduction of an encryption layer compliant with the TLS (Transport Layer Security) protocol family, are not well suited to the context of edge computing.This family includes SSL (Secure Socket Layer) protocols, variants of TLS, cTLS, Q.UIC, MASQUE, DTLS, LAKE EDDOC, TLS over COAP, etc.

[0013] The https protocol allows a visitor's device, such as a personal computer, to verify the identity of a website that the visitor wishes to access from their device.

[0014] Thus, the equipment verifies the identity of a server hosting the website, using a public X509 authentication certificate issued by a third-party authority, deemed reliable, to a server providing a service. Such a certificate guarantees the confidentiality and integrity of the data transmitted by the visitor to the server providing a service.

[0015] Such a mode of operation, namely the verification of the identity of a device with which a communication session is intended to be established, cannot meet the needs required for the management of computing nodes. Indeed, such management is complex because computing nodes can be deployed in distributed, even private or even mobile infrastructures, but above all they can be reconfigured, suspended, deleted, restored, or even reassigned to another cluster of nodes depending on the needs to be met. Each of these operations can call into question the validity of the certificates associated with the computing nodes.

[0016] Furthermore, the computing nodes correspond, from a protocol point of view, to the visitor equipment described in the example described above. We can therefore see that the application of the https solution to an “edge computing” architecture is not suitable.

[0017] There is therefore a need to offer a solution for managing equipment belonging to an “edge computing” type architecture which does not present all or part of the aforementioned drawbacks.

[0018] Statement of the invention

[0019] The invention partly meets this need by proposing a method for revoking a first certification token corresponding to a first certificate, said first certification token making it possible to authenticate the establishment of a connection between a device connected to at least one communication network and at least one server of a service provider, said first certification token and said first certificate being generated from a digest of a physical address of said device, a certificate associated with a network address configuration server and at least one network address allocated to said device by said network address configuration server.

[0020] Such a method is particular in that it comprises the following steps implemented by a certificate management module:

[0021] - revocation of said first certification token triggered by obtaining information relating to a condition for revocation of said first certification token,

[0022] -transmission, to a domain name server, of a request to revoke an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name

[0023] The solution that is the subject of the present invention makes it possible to revoke a certificate systematically when the equipment is reconfigured, when its certificate is suspended, corrupted, when a lease associated with the network address allocated to the equipment expires or when an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name also expires. The present solution proposes to revoke a certification token corresponding to a certificate associated with the equipment, making it possible to reduce the number of exchanges relating to the management of this certificate for such equipment, which is particularly interesting in an edge computing context where agility is essential.

[0024] Such a certificate management module may be co-located with the configuration server or with the domain name server, in which an association of said certificate with at least one domain name provided by the configuration server is stored.

[0025] Finally, since the device can be allocated a plurality of network addresses, or "address pools," the first certification token is associated with all or part of this address pool. Similarly, the same device can simultaneously have several certificates and corresponding certification tokens.

[0026] Such a configuration token makes it possible to verify the authenticity and integrity of a certificate associated with the device and thus authorize the establishment of a connection with the device. Establishing such a connection corresponds, for example, to the integration of the device into a Kubernetes architecture as a computing node.

[0027] According to a particularity of the revocation method, said condition for revoking said first certification token belongs to a group comprising:

[0028] - a request for revocation of said first certification token, said revocation request being issued by the equipment,

[0029] - a request for revocation of said first certification token, said revocation request being issued by network equipment

[0030] - an expiration of an allocation period of the network address allocated to the equipment,

[0031] - an expiration of a lifetime of the first certification token,

[0032] - a usage conflict in an addressing plan,

[0033] - information relating to a compromise of the first certification token,

[0034] - information relating to a hack of the first certification token.

[0035] In an exemplary implementation, when the information relating to a condition for revoking said first certificate is information relating to the expiry of the duration of the association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name, the revocation method comprises, prior to the step of revoking the first certification token, the following steps:

[0036] - transmission of a request to revoke an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, the network address configuration server,

[0037] - receipt of a request for revocation of said first certification token issued by said network address configuration server following the revocation of the association established between, on the one hand, the first certificate and the first certification token and, on the other hand, the network address configuration server.

[0038] In such an implementation example, the certification token is revoked when domain name resolution is required. This helps reduce the load on the communication network.

[0039] Once the certification token has been revoked, the revocation method implements a step of transmitting, to the network address configuration server, a message acknowledging the revocation of said first certification token by the certificate management module.

[0040] Thus, the network address configuration server can release the network address associated with the equipment whose certification token has just been revoked. The revocation method can also comprise the following steps when the condition for revoking said first certification token is accompanied by a request for replacing said first certification token:

[0041] - generation of a second certificate associated with said equipment and a second corresponding certification token,

[0042] - transmission, to said domain name server, of a request to associate said second certificate and said second certification token with said domain name previously associated with the first certificate and the corresponding first certification token,

[0043] - transmission of said second certification token to said equipment.

[0044] Such an example is of interest when the validity of the certification token expires but also when the certificate associated with the equipment is corrupted or has been hacked. In such a case, the connection established between the equipment and the server of the service provider is maintained and the second certification token is transmitted to the equipment through this connection making the operation transparent for a user of the equipment. The generation of this second certification token in replacement of the first certification token activates a specific mechanism for managing the connection such as monitoring the use of this second certification token, the purpose of which is to track and examine the exchanges occurring between the equipment and the server of the service provider in order to determine the corrupted nature of the connection.

[0045] This results, for example, in a slowdown of exchanges initiated by the server through the connection in order to keep it active for longer so that it can be observed over a longer period.

[0046] Still in this example, the second certification token can also provide restricted access to a service provider's server resources.

[0047] Thus, the second certification token contributes to the establishment of a "sandbox" by limiting the equipment's access to certain services or by isolating traffic related to this service to or from the equipment.

[0048] In order to further isolate the traffic linked to the equipment, the method further comprises a step of transmitting, to the network address configuration server, a request to provide, to said equipment, at least one network address pointing to a host machine acting as a fictitious server of the supplier.

[0049] In this scenario, the network address provided to the equipment is a so-called "black hole" network address which does not allow traffic to be routed to the equipment or does not allow traffic to be transmitted from the equipment to the service provider's server but indicates to a router that this traffic can be routed to another dedicated equipment suitable for processing data from / destined to potentially corrupted equipment, or that this traffic may not be routed at all.

[0050] The invention also relates to a certificate management module adapted to revoke a first certification token corresponding to a first certificate, said first certification token making it possible to authenticate the establishment of a connection between a device connected to at least one communication network and at least one server of a service provider, said first certification token and said first certificate being generated by said certificate management module from a digest of a physical address of said device, a certificate associated with a network address configuration server and at least one network address allocated to said device by said network address configuration server, said certificate management module comprising at least one processor configured to:

[0051] - revoke said first certification token following the obtaining of information relating to a condition for revoking said first certification token,

[0052] -transmit, to a domain name server, a request to revoke an association established between the first certificate, the first certification token and at least one domain name.

[0053] The invention also relates to a network address configuration server comprising at least one certificate management module adapted to revoke a first certification token corresponding to a first certificate, said first certification token making it possible to authenticate the establishment of a connection between a device connected to at least one communication network and at least one server of a service provider, said first certification token and said first certificate being generated by said certificate management module from a digest of a physical address of said device, a certificate associated with said network address configuration server and at least one network address allocated to said device by said network address configuration server, said certificate management module comprising at least one processor configured to:

[0054] - revoke said first certification token following the obtaining of information relating to a condition for revoking said first certification token,

[0055] -transmit, to a domain name server, a request to revoke an association established between the first certificate, the first certification token and at least one domain name.

[0056] The invention finally relates to a computer program product comprising program code instructions for implementing a method as described above, when executed by a processor.

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

[0058] Such a recording medium may be any entity or device capable of storing the program. For example, the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a USB flash drive or a hard disk.

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

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

[0061] List of figures

[0062] Other aims, characteristics and advantages of the invention will appear more clearly on reading the following description, given as a simple illustrative, and non-limiting, example, in relation to the figures, among which:

[0063] [f ig- 1]: this figure represents in a simplified way the architecture of a cluster of nodes 1 conforming to the Kubernetes solution,

[0064] [fig- 2]: this figure represents a system in which the present solution can be implemented,

[0065] [fig. 3A]: this figure represents the different steps implemented during the execution of a first embodiment of the methods that are the subject of the present invention leading to obtaining the certification token within the system of figure 2, [fig- 3B]: this figure represents the different steps implemented during the execution of a second embodiment of the methods that are the subject of the present invention leading to obtaining the certification token within the system of figure 2,

[0066] [fig- 4]: this figure represents the sequence of steps of the processes relating to the use of the CNT certification token by equipment belonging to the system of figure 2,

[0067] [fig- 5]: this figure represents the different steps implemented by the different equipment constituting the system described with reference to figure 2 in a first embodiment of the method for revoking a certification token according to the invention,

[0068] [fig. 6]: this figure represents the different steps implemented by the different equipment constituting the system described with reference to figure 2 in a second embodiment of the method for revoking a certification token according to the invention,

[0069] [fig- 7]: this figure represents the different steps implemented by the different equipment constituting the system described with reference to figure 2 in a third embodiment of the method of revoking a certification token according to the invention,

[0070] [fig- 8]: this figure represents the different steps implemented by the different equipment constituting the system described with reference to figure 2 in a fourth embodiment of the method of revoking a certification token according to the invention,

[0071] [fig- 9]: this figure represents equipment capable of implementing the method of authenticated establishment of a connection between equipment connected to at least one communication network and a server of a service provider which is the subject of the present invention,

[0072] [fig- 10]: this figure represents a management module capable of implementing the various methods which are the subject of the present invention.

[0073] Detailed description of embodiments of the invention

[0074] The general principle of the invention relates to the management of a certificate, in particular but not exclusively, for equipment located in an “edge computing” type environment or computing at the edge of the network during the operation of said equipment. The invention proposes a mechanism for revoking a certification token corresponding to a certificate associated with said equipment. This revocation mechanism makes it possible to revoke a certificate associated with the equipment, for example, when the equipment is reconfigured, when its certificate is suspended, corrupted, when a lease associated with the network address allocated to the equipment expires or when an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name also expires, etc.

[0075] Such a solution has the advantage of being fast, which makes it particularly interesting for architectures requiring frequent dynamic configurations. Indeed, this makes it possible to reduce the number of exchanges and the amount of processing related to the management of this certificate for such equipment, which is particularly interesting in an "edge computing" context where agility is essential.

[0076] We now present, in relation to [fig. 2], a system in which the present solution can be implemented.

[0077] Such a system comprises at least one piece of equipment 10 connected to at least one communication network (not shown in the figures), at least one network address configuration server 11, such as a DHCP (Dynamic Hosts Configuration Protocol) server, at least one certificate management module 12, at least one domain name server 13 such as a DNS server and at least one server of a service provider 14 independent, or not, of the operator of the communication network. The equipment 10 can be a mobile terminal, a server, a node, or a container according to the Kubernetes solution, or even a sensor. It can also be a virtualized piece of equipment.

[0078] In the rest of the document, the configuration server 11 has the identifier 'srvcfgll' and belongs to a communication network whose domain name is 'example.com', the "Common Name" CN or the "Fully Qualified Domain Name" FQ.DN associated with the CertDHCP certificate of the configuration server 11 is 'srvcfgll.example.com'.

[0079] In an exemplary implementation, the configuration server 11 and the certificate management module 12 may be co-located in the same equipment 100 as shown in FIG. 2. In another exemplary implementation, the certificate management module 12 may be co-located with the domain name server 13 or integrated therein. In yet another exemplary implementation, the certificate management module 12 may be physically separated from the configuration server 11 and the domain name server 13.

[0080] With reference to the system described in Figure 2, a first part of the sequence of processes leading to obtaining such a certification token is now described, followed by the process for revoking the certification token which is the subject of the invention. The different steps implemented during the execution of a first embodiment of the processes leading to obtaining the certification token within the system previously described are represented in the form of a diagram in [Fig. 3A],

[0081] In a step E1, the equipment 10 seeks to connect to a communications network. To this end, the equipment 10 sends a DHCP Discover request to the configuration server 11 so that the latter allocates it one or more network addresses such as IPv4 or IPv6 addresses.

[0082] In a step E2, upon receipt of the DHCP Discover request sent by the equipment 10, the configuration server 11 offers, in a conventional manner, one or more network addresses to the equipment 10 via the sending of a DHCP offer type message.

[0083] In another example, the configuration server 11 can implement an ACME-STAR type delegation method or a so-called "Delegated Credentials" method upon receipt of the DHCP Discover request sent by the equipment 10. These methods are described in the referenced document Acme-Star RFC 8739 published by the IETF.

[0084] They thus allow the delegated equipment 10 to receive, here in a DHCP Offer type message, a temporary certificate, possibly condensed, calculated on the basis of a private key of the delegating configuration server 11.

[0085] In a step E3, the equipment 10 validates the network address allocation proposal received during the step E2 and transmits, to the configuration server 11, a DHCP Request validating network addresses among those proposed and comprising parameters relating to the creation of a certificate. Such parameters include, among other things: a public key PUB_KEY_CPE of the equipment 10, a digest or “hash” HASH_CPE of a physical address of the equipment 10 such as a MAC address (Medium Access Control) as well as a TYP_HASH parameter on the manner in which the digest HASH_CPE is calculated. These different parameters can be transmitted in the form of a certificate that can be condensed.

[0086] Upon receipt of the DHCP Request, in a step E4, the configuration server 11 processes the information relating to the allocation of network addresses included in this request in a conventional manner. When processing this DHCP Request, the configuration server 11 detects the presence of parameters relating to the creation of a certificate in a field of the DHCP Request, i.e. the public key PUB KEY CPE, the digest HASH CPE or the parameter TYP_HASH, extracts this information and generates a request for the creation of a DCC certificate associated with the equipment 10.The request to create a DCC certificate includes: the public key PUB_KEY_CPE of the equipment 10, the hash HASH_CPE of a physical address of the equipment 10, a CertDHCP certificate associated with the configuration server 11, at least one CPE IP network address allocated to said equipment 10 by the configuration server 11 during step E4 (or a pool of network addresses POOL_IP_CPE allocated to the equipment 10), and finally the parameter TYP_HASH on how the hash HASH_CPE is calculated. The request to create a DCC certificate may also include a domain name, for example “4d2a.37f78dd8d99b3c75ddde3624155.example.com”, with which the certificate is intended to be associated.

[0087] In a step E5, the configuration server transmits the request to create a DCC certificate to the certificate management module 12.

[0088] Upon receipt of the request to create a certificate associated with the equipment 10, the certificate management module 12 generates, during a step E6, a CERT_CPE certificate associated with the equipment 10 from the information included in the DCC creation request.

[0089] Such a CERT_CPE certificate corresponds to a network address allocated to the equipment 10. Thus, the certificate management module 12 creates as many CERT_CPE certificates associated with the equipment 10 as the latter has network addresses. In another implementation example, the certificate management module 12 creates a single CERT_CPE certificate associated with the equipment 10 which applies to the network address pool POOL_IP_CPE allocated to the equipment 10. Such a CERT_CPE certificate includes the values ​​of the physical address of the equipment 10 and one or more network addresses chosen during step E3 by the equipment 10, in fields of the CERT_CPE certificate such as the Common Name (CN) or SAN fields for example.

[0090] The certificate management module 12 also generates a CNT certification token (Certificate Network Token) corresponding to the CERT_CPE certificate associated with the connectivity of the equipment 10 to the network of 11. Such a CNT certification token is a compact form of the CERT_CPE certificate associated with the equipment 10. More particularly, this CNT certification token comprises, among other things, information relating to the HASH_CPE digest of the physical address of the equipment 10, to the HASH_CERT_CPE digest of the CERT_CPE certificate associated with the equipment 10, and a CN CM identifier of the certificate management module 12. It is the CNT certification token or a HASH_CNT digest of the CNT certification token that will be used by the equipment 10 in all situations where the latter must provide authentication material to access a service.Since the CNT certification token is a compact form of the CERT_CPE certificate associated with the equipment 10, it can be introduced into many existing messages without detrimentally increasing the payload of the latter. In order to further limit the payload of existing messages, the equipment 10 can transmit the hash of the HASH_CNT certification token instead of the CNT certification token. Thus, the implementation of the solution that is the subject of the present invention does not introduce too heavy a load into a communication network.

[0091] The HASH_CNT certification token digest is calculated using a TYP_HASH_CNT parameter. In the rest of the document, the HASH_CNT certification token digest has the value "37f78dd8d99b3c75ddde3624155", and the TYP_HASH_CNT parameter has the value 4D2A.

[0092] So, for example, the CNT certification token corresponding to the CERT CPE certificate of Device 10 has the value "4D2A.37f78dd8d99b3c75ddde3624155", and the Common Name (CN) field of the CERT_CPE certificate of Device 10 includes the values ​​"4D2A .37f78dd8d99b3c75ddde3624155.srvcfgl.example.com".

[0093] In a step E7, the certificate management module 12 transmits a DAss association request for the CERT_CPE certificate associated with the equipment 10 thus generated with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” with which the CERT_CPE certificate is intended to be associated to the domain name server 13. Such a DAss association request comprises: the CERT_CPE certificate associated with the equipment 10, the corresponding CNT certification token, a HASH_CNT digest of the CNT certification token and a TYP HASH CNT parameter on how the HASH CNT digest is calculated. In an exemplary embodiment, the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated may comprise a public key of the certificate management module 12.

[0094] In a step E8, the domain name server 12 records all of the information included in the DAss association request in a table and associates it with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com”.

[0095] Optionally, once the association between all the information included in the DAss association request and the domain name has been carried out, the domain name server 13 informs the certificate management module 12 in a step E9.

[0096] In turn, the certificate management module 12 informs the configuration server 11 of the creation of the CERT_CPE certificate associated with the equipment 10 in a step E10. For this, the certificate management module 12 transmits to the configuration server 11 a message MSG1 comprising the CNT certification token corresponding to the CERT_CPE certificate associated with the equipment 10, the CNT HASH digest of the CNT certification token and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated. Such a step E10 is optional.

[0097] Finally, the configuration server 11 sends, in a step Eli, a network address assignment or update message, for example DHCP 'renew', or a new DHCP 'update' message, containing the CNT. In an existing or new field of this DHCP message, the configuration server 11 adds the CNT certification token corresponding to the CERT_CPE certificate associated with the equipment 10, the CNT HASH digest of the CNT certification token and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated. In another example of implementation of the step Eli, the configuration server 11 transmits only the HASH_CNT certification token digest and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated in the assignment message.

[0098] At the end of step Eli, the device 10 thus has a CNT certification token which will be used by the device 10 in all situations where the latter must provide authentication material to access a service. It will be noted that the device 10 is not in possession of its CERT_CPE certificate and does not know the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” associated with its CERT_CPE certificate. These two pieces of information are only stored in the domain name server 12.

[0099] With reference to the system described in Figure 2, a first part of the sequence of processes leading to the obtaining of such a certification token is now described, followed by the process for revoking the certification token which is the subject of the invention. The different steps implemented during the execution of a second embodiment of the processes leading to the obtaining of the certification token within the system previously described are represented in the form of a diagram in [Fig. 3B].

[0100] In a step E1', the equipment 10 seeks to connect to a communication network. To this end, the equipment 10 sends a DHCP Discover request to the configuration server 11 so that the latter allocates it one or more network addresses such as IPv4 or IPv6 addresses. The DHCP Discover request includes parameters relating to the creation of a certificate. Such parameters include, among other things: a public key PUB_KEY_CPE of the equipment 10, a digest or "hash" HASH_CPE of a physical address of the equipment 10 such as a MAC address (Medium Access Control) as well as a TYP_HASH parameter on the manner in which the digest HASH_CPE is calculated. These various parameters can be transmitted in the form of a certificate that can be digested.In a step E2' the configuration server 11 selects at least one network address to be allocated to said equipment 10 and implements a delegation method of the ACME-STAR type or a method called "Delegated Credentials" upon receipt of the DHCP Discover request sent by the equipment 10.

[0101] Such methods are described in the referenced documents Acme-Star RFC 8739 and "draft-ietf-tls-subcerts-15 - Delegated Credentials for (D)TLS" published by the IETF.

[0102] Upon receipt of the DHCP Request, in a step E3', the configuration server 11 processes the information relating to the allocation of network addresses included in this request in a conventional manner. When processing this DHCP Request, the configuration server 11 detects the presence of parameters relating to the creation of a certificate in a field of the DHCP Request, i.e. the public key PUB KEY CPE, the digest HASH CPE and the parameter TYP_HASH, extracts this information and generates a certificate CERT_CPE associated with the equipment 10 on the basis of this information.

[0103] Such a CERT_CPE certificate corresponds to a network address allocated to the equipment 10. Thus, the configuration server 11 creates as many CERT_CPE certificates associated with the equipment 10 as the latter has network addresses. In another implementation example, the configuration server 11 creates a single CERT_CPE certificate associated with the equipment 10 which applies to the network address pool POOL_IP_CPE allocated to the equipment 10. Such a CERT_CPE certificate includes the values ​​of the physical address of the equipment 10 and one or more network addresses selected during step E3' by the configuration server 11, in a field of the CERT_CPE certificate such as the SAN field for example.

[0104] The configuration server 11 also generates a CNT certification token (Certificate Network Token) corresponding to the CERT_CPE certificate associated with the connectivity of the equipment 10 to the communication network. Such a CNT certification token is a compact form of the CERT_CPE certificate associated with the equipment 10. More particularly, this CNT certification token comprises, among other things, information relating to the HASH_CPE digest of the physical address of the equipment 10, to the HASH_CERT_CPE digest of the CERT_CPE certificate associated with the equipment 10, and a CN_DHCP identifier of the configuration server 11. The configuration server 11 also determines a digest of the HASH CNT certification token by means of a TYP_HASH_CNT parameter.

[0105] As already mentioned, the hash of the HASH_CNT certification token has the value "37f78dd8d99b3c75ddde3624155", and the TYP_HASH_CNT parameter has the value 4D2A.

[0106] So, for example, the CNT certification token corresponding to the CERT_CPE certificate of Device 10 has the value "4D2A.37f78dd8d99b3c75ddde3524155", and the Common Name (CN) field of the CERT_CPE certificate of Device 10 includes the values ​​"4D2A .37f78dd8d99b3c75ddde3624155.srvcfgl.example.com".

[0107] It is the CNT certification token or a HASH_CNT digest of the CNT certification token that will be used by the equipment 10 in all situations where the latter must provide authentication material to access a service. Since the CNT certification token is a compact form of the CERT_CPE certificate associated with the equipment 10, it can be introduced into many existing messages without detrimentally increasing the payload of the latter. In order to further limit the payload of existing messages, the equipment 10 can transmit the digest of the HASH_CNT certification token instead of the CNT certification token. Thus, the implementation of the solution that is the subject of the present invention does not introduce too heavy a load into a communication network.

[0108] In a step E4', the configuration server 11 transmits the CERT_CPE certificate thus created to the certificate management module 12 accompanied by its CNT certification token, the HASH_CNT digest of the CNT certification token, the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated and a CertDHCP certificate associated with the configuration server 11. The transmission of the CERT_CPE certificate may also include a domain name, for example "4d2a.37f78dd8d99b3c75ddde3624155.example.com", with which the certificate is intended to be associated.

[0109] The configuration server 11 sends, during a step E5' which can be implemented before, concomitantly with or after step E4', a DHCP Offer type message to the equipment 10 comprising the corresponding CNT certification token as well as the network address(es) that the configuration server 11 allocated to it during step E3'.

[0110] In a step E6', the certificate management module 12 transmits a request DAss for association of the CERT_CPE certificate associated with the equipment 10 with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” with which the CERT CPE certificate is intended to be associated to the domain name server 13.

[0111] Such a DAss association request includes: the CERT_CPE certificate associated with the equipment 10, the corresponding CNT certification token, the HASH_CNT digest of the CNT certification token, and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated. In an exemplary embodiment, the TYP_HASH_CNT parameter on how the HASH CNT digest is calculated may include a public key of the configuration server 11.

[0112] In a step E7', the domain name server 13 records all of the information included in the DAss association request in a table and associates it with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com”.

[0113] Optionally, once the association between all the information included in the DAss association request and the domain name has been carried out, the domain name server 13 informs the certificate management module 12 in a step E8'.

[0114] In turn, the certificate management module 12 informs the configuration server 11 of the association between all of the information included in the DAss association request and the domain name in a step E9'.

[0115] At the end of step E9', the equipment can use the CNT certification token in all situations where the latter must provide authentication material to access a service. It will be noted that the equipment 10 is not in possession of its CERT_CPE certificate and does not know the domain name "4d2a.37f78dd8d99b3c75ddde3624155.example.com" associated with its CERT_CPE certificate. These two pieces of information are only stored in the domain name server 12.

[0116] Now that the equipment 10 is provided with a CNT certification token and / or a digest of the CNT HASH certification token, it can establish a connection with a server of a service provider 14. [Fig- 4] represents the sequence of steps of the methods relating to the use of the CNT certification token by the equipment 10.

[0117] The equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a TLS Hello client message during a step G1. In an existing field of this TLS Hello client message, or in a TLS_CNT extension, the equipment 10 adds the CNT certification token, the HASH_CNT digest of the CNT certification token and the TYP_H AS H_CNT parameter on the way in which the HASH_CNT digest is calculated. In practice the CNT certification token can be transported by any secure exchange protocol of the TLS family or other, in a field of any application protocol such as HTTP transported below any combination of protocols guaranteeing the integrity of the exchange, but also in an OAM (iOAM) field described in https: / / datatracker.ietf.org / doc / html / draft-ietf-ippm-ioam-data-17.txt.Thus the CNT certification token can be transported, or even updated at any time during the life of an exchange session between 10 and 14. In a step G2, the server of a service provider 14 obtains the public key PUB_KEY_CM from the certificate management module 12. The public key PUB_KEY_CM is, for example, a public field of the X509 certificate of the certificate management module 12 obtained, after step G1 or beforehand, for example upon the establishment of a secure tunnel established between the server of a service provider 14 and the certificate management module 12, or even pre-recorded in the server of a service provider 14.

[0118] Using the public key PUB_KEY_CM of the certificate management module 12, the server of a service provider 14 proceeds, during a step G3, to verify the authenticity of the certification token CNT by means of the public key PUB_KEY_CM of the certificate management module 12 and the digest HASH_CNT of the certification token CNT and the information TYP_HASH_CNT on how the digest HASH_CNT is calculated.

[0119] Once this verification has been carried out, the server of a service provider 14 requests, in a step G4, the domain name server to provide it with the CERT_CPE certificate associated with the CNT certification token that it has just verified. For this, the server of a service provider 14 sends a DNS Query type message including, in an existing field, the CNT certification token.

[0120] In a step G5, the domain name server 13 returns the CERT CPE certificate corresponding to the received CNT certification token.

[0121] In a step G6, the server of a service provider 14 then verifies that the CERT_CPE certificate corresponds to the network address(es) provided in the TLS Hello client message knowing that such a CERT_CPE certificate is issued for one or more network addresses allocated to the equipment 10.

[0122] Once the equipment 10 has been authenticated, the server of a service provider 14 sends a Server Hello message to the equipment 10, thus finalizing the establishment of the connection between the latter and the server of a service provider 14 in a step G5. The service server 14 also adds the information 'UE authenticated' in the TLS_CNT extension of the Server Hello message, thus indicating that the equipment 10 is authenticated.

[0123] [Fig. 5] represents the different steps implemented by the different equipment constituting the system described with reference to FIG. 2 in a first embodiment of the method for revoking a CNT certification token associated with the equipment 10.

[0124] The implementation of this revocation method may or may not occur following the execution of step G6 during which a connection is established between the equipment 10 and the server of a service provider 14.

[0125] In a first implementation, the equipment 10 sends, to the configuration server 11, a message requesting the release of the network address(es) allocated to it during a step H1.

[0126] The sending of such a message to the configuration server 11 may be triggered when the equipment 10 leaves the coverage area of ​​a first access node, such as for example a Wi-Fi access node, to attach to a second access node such as a base station. Such a change of access network requires the release of the network address allocated to the equipment 10, resulting in the revocation of the certification token associated with the equipment 10 which was generated by means of this network address.

[0127] In a first example, such a message is a DHCP Release message including the CNT certification token, the HASH_CNT digest of the CNT certification token, and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated.

[0128] In a second example, the device 10 sends a new type of message, called DHCP Revoke. Such a DHCP Revoke message also includes the corresponding CNT certification token, the HASH_CNT digest of the CNT certification token and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated.

[0129] Upon receipt of the DHCP Release or DHCP Revoke message, in a step H2, the configuration server 11 processes the information relating to the release of the network addresses included in this request in a conventional manner.

[0130] When processing the DHCP Release message, the configuration server 11 detecting the presence of parameters relating to the CERT_CPE certificate in a field of the message, i.e. at least the corresponding CNT certification token, or the HASH_CNT digest of the CNT certification token, see in addition and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated, extracts this information and generates a request for revocation of the CNT certification token associated with the equipment 10 and the CERT CPE certificate.

[0131] When processing the DHCP Revoke message, the very nature of the message indicates to the configuration server 11 that it must extract the parameters relating to the CERT_CPE certificate included in a field of the DHCP Revoke message, i.e. the corresponding CNT certification token, the HASH_CNT digest of the CNT certification token and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated, and generate a request to revoke the CNT certification token associated with the equipment 10 and the CERT CPE certificate.

[0132] In a second implementation, the revocation of the CNT certification token associated with the equipment 10 and the CERT_CPE certificate is initiated by the network; such a network change may also be detected and signaled by the radio access point to which the equipment 10 is attached, such as a base station or a Wi-Fi access point. In this second implementation, the transmission of the DHCP Release message or the DHCP Revoke message is initiated by the network and is triggered, for example, by the detection of inactivity of the equipment 10 by the network, the detection of faulty routing of traffic from or to the equipment 10, the detection of a new association between a network address allocated to the equipment 10 and a new physical address (MAC for “Medium Access Control”), etc.

[0133] The CNT certification token revocation request includes: the corresponding CNT certification token, the HASH_CNT digest of the CNT certification token, the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated and the CertDHCP certificate associated with the configuration server 11. The CNT certification token revocation request may also include the domain name, for example “4d2a.37f78dd8d99b3c75ddde3624155.example.com”, with which the CERT_CPE certificate was associated during step E8 described with reference to FIG. 3A.

[0134] Regardless of the implementation implemented, the configuration server 11 transmits, in a step H3, the request for revocation of the CNT certification token to the certificate management module 12.

[0135] Upon receipt of the request to revoke the CNT certification token, the certificate management module 12 optionally proceeds, in a step H4, to verify the authenticity of the CNT certification token by means of the CertDHCP certificate associated with the configuration server 11.

[0136] Once the authenticity of the CNT certification token by means of the CertDHCP certificate associated with the configuration server 11 has been verified, the certificate management module 12 deletes the CERT_CPE certificate associated with the equipment 10 and the corresponding CNT certification token in a step H5. In the case where step H4 is not implemented, the execution of step H5 is triggered by the reception of the request for revocation of the certification token issued by the configuration server 11. Once this verification has been carried out, the certificate management module 12 transmits, in a step H5, a request for revocation DRev of the association of the CERT_CPE certificate associated with the equipment 10 with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” with which the CERT_CPE certificate was associated during the step E8 described with reference to FIG. 3A, to the domain name server 13.

[0137] Such a DRev revocation request includes: the corresponding CNT certification token, the CERT_CPE certificate and the public key PUB_KEY_CM of the certificate management module 12.

[0138] At the same time, the management module 12 deletes the CERT_CPE certificate and the corresponding CNT certification token from a database.

[0139] In a step H6, the domain name server 13 extracts all of the information included in the revocation request DRev and revokes the association established between, on the one hand, the CERT_CPE certificate and the corresponding CNT certification token and, on the other hand, the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com”.

[0140] Once the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name has been revoked, the domain name server 13 informs the certificate management module 12 in a step H7.

[0141] In a particular implementation, the operation of deleting the CERT_CPE certificate and the corresponding CNT certification token from a database of the management module 12 is triggered by the reception of the information relating to the revocation of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name received in step H7.

[0142] In turn, the certificate management module 12 informs the configuration server 11 of the revocation of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name in a step H8.

[0143] At the end of step H8, the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a classic TLS Hello client message, i.e. not including a CNT certification token since the latter has been revoked.

[0144] Since a service provider's server 14 does not find a CNT certification token in the TLS Hello message, it cannot verify the validity of any certificate relating to the equipment 10.

[0145] The server of a service provider 14 then sends a Server Hello message to the equipment 10 indicating that the certificate associated with the equipment 10 is not valid and that a connection cannot be established with the equipment 10.

[0146] These classic TLS client Hello and Server Hello message exchanges between the device 10 and the server 14 are not shown in Figure 5.

[0147] If by chance, device 10 needs to obtain a new certificate and the corresponding certification token, it must then implement steps El to Eli again.

[0148] [Fig. 6] represents the different steps implemented by the different equipment constituting the system described with reference to FIG. 2 in a second embodiment of the method for revoking a CNT certification token associated with the equipment 10.

[0149] The implementation of this revocation method may or may not occur following the execution of step G6 during which a connection is established between the equipment 10 and the server of a service provider 14.

[0150] In this second embodiment, the equipment 10 sends, to the configuration server 11, a message requesting the release of the network address(es) allocated to it during a step PI. The sending of such a message to the configuration server 11 may be triggered when the equipment 10 leaves the coverage area of ​​a first access node, such as for example a Wi-Fi access node, to attach to a second access node such as a base station. The release of the network address allocated to the equipment 10 results in the revocation of the certification token associated with the equipment 10 which was generated by means of this network address.

[0151] In a first example, such a message is a DHCP Release message including the CNT certification token, the HASH_CNT digest of the CNT certification token, and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated.

[0152] Upon receipt of the DHCP Release message, in a step P2, the configuration server 11 processes the information relating to the release of the network addresses included in this request in a conventional manner.

[0153] At a given moment, occurring after the request to release the network address(es) allocated to the equipment 10 and without correlation with the sending of this release request, the server of a service provider 14 sends a domain name resolution request RQT-DNS to the domain name server 13, for example for the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” associated with the CERT_CPE certificate of the equipment 10, in a step P3.

[0154] When the domain name server 13 finds that the association existing between the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” and the CERT_CPE certificate has expired, the domain name server 13 sends, in a step P4, an MSG-TTL message indicating that the association existing between the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” and the CERT_CPE certificate has expired to the certificate management module 12. Such an MSG-TTL message comprises at least the CNT certification token. Such a MSG-TTL message is for example implemented by adding a new id-pkix-ocsp-cnt message to the definition of the Online Certificate Status Protocol (OCSP) as defined in ASN.l in the document published at the following address: https: / / www.rfc-editor.org / rfc / rfc6960#appendix-Bl:

[0155] An example MSG-TTL message that expects a response containing a CNT certification token includes an identification of the message type "id-pkix-ocsp-cn" in its "AcceptableResponses" field.

[0156] Upon receipt of this MSG-TTL message, the certificate management module 12 sends an MSG-lnf information message to the configuration server 11 informing it that the association existing between the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” and the CERT_CPE certificate has expired, in a step P5. Such an MSG-lnf message is for example implemented using the message conforming to the OCSP protocol instantiating a 'ServiceLocator' extension of the OCSP protocol (see section 4.4.6 of the document RFC6960 published by the IETF), such a message comprising identifiers of the configuration server 11 and of the certificate management module 12:

[0157] ServiceLocator := SEQUENCE { issuer '172.3.2.1', locator '172.3.2.2'} where the "service locator" field comprises either the network address '172.3.2.2' of the configuration server 11 or its "common name" 'srvcfgll.example.com', and the "issuer" field comprises the network address 172.3.2.1' or the CN_CM identifier of the certificate management module 12. In response to the MSG-lnf message and knowing that the equipment 10 and, in a step P6, a request for revocation of the certification token CNT to the certificate management module 12.

[0158] Such a revocation request includes: the corresponding CNT certification token, the HASH_CNT digest of the CNT certification token, the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated and the CertDHCP certificate associated with the configuration server 11. The CNT certification token revocation request may also include the domain name, for example “4d2a.37f78dd8d99b3c75ddde3624155.example.com”.

[0159] Upon receipt of the request to revoke the CNT certification token, the certificate management module 12 optionally proceeds, in a step P7, to verify the authenticity of the CNT certification token by means of the CertDHCP certificate associated with the configuration server 11.

[0160] Once the authenticity of the CNT certification token by means of the CertDHCP certificate associated with the configuration server 11 has been verified, the certificate management module 12 deletes the CERT_CPE certificate associated with the equipment 10 and the corresponding CNT certification token in a step P8. In the case where step P7 is not implemented, the execution of step P8 is triggered by the reception of the request for revocation of the certification token issued by the configuration server 11.

[0161] Once this verification has been carried out, the certificate management module 12 transmits, in a step P9, a revocation request DRev of the association of the CERT_CPE certificate associated with the equipment 10 with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com”, to the domain name server 13.

[0162] Such a DRev revocation request includes: the corresponding CNT certification token, the CERT_CPE certificate and the public key PUB_KEY_CM of the certificate management module 12.

[0163] At the same time, the certificate management module 12 deletes the CERT_CPE certificate and the corresponding CNT certification token from a database.

[0164] In a step P10, the domain name server 13 extracts all of the information included in the revocation request DRev and revokes the association established between, on the one hand, the CERT_CPE certificate and the corresponding CNT certification token and, on the other hand, the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com”.

[0165] Once the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name has been revoked, the domain name server 13 informs the certificate management module 12 in a Pli step which may be optional.

[0166] In a particular implementation, the operation of deleting the CERT_CPE certificate and the corresponding CNT certification token from a database of the management module 12 is triggered by the reception of the information relating to the revocation of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name received in step Fold.

[0167] In turn, the certificate management module 12 optionally informs the configuration server 11 of the revocation of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name in a step P12.

[0168] At the end of step P10, the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a classic TLS Hello client message, i.e. one not including a CNT certification token since the latter has been revoked. Since the server of a service provider 14 does not find a CNT certification token in the TLS Hello message, it cannot verify the validity of any certificate relating to the equipment 10.

[0169] The server of a service provider 14 then sends a Server Hello message to the equipment 10 indicating that the certificate associated with the equipment 10 is not valid or does not make it possible to identify the equipment 10 and / or its service provider and that a connection cannot be established with the equipment 10.

[0170] These classic TLS client Hello and Server Hello message exchanges between the device 10 and the server 14 are not shown in Figure 5.

[0171] If by chance, device 10 needs to obtain a new certificate and the corresponding certification token, it must then implement steps El to Eli again.

[0172] [Fig. 7] represents the different steps implemented by the different equipment constituting the system described with reference to FIG. 2 in a third embodiment of the method for revoking a CNT certification token associated with the equipment 10.

[0173] The implementation of this revocation method may or may not occur following the execution of step G6 during which a connection is established between the equipment 10 and the server of a service provider 14.

[0174] In a step SI, the expiration of a lifetime associated with one or more network addresses allocated to the equipment 10 triggers the release of these network addresses by the configuration server 11. In another example, the configuration server 11 receives a request to release the network addresses allocated to the equipment 10 following a decision by the network management operator.

[0175] In a step S2, the configuration server 11 transmits a request for revocation of the CNT certification token to the certificate management module 12. Such a revocation request includes the CNT certification token and a code indicating the reasons for this suspension request.

[0176] In parallel with step S2, the configuration server 11 sends a DHCP NACK message to the equipment 10 in a step S3. Such a DHCP NACK message indicates to the equipment 10 that it is no longer authorized to use the network addresses allocated to it. Since the DHCP NACK message also includes the CNT certification token, the equipment 10 also understands that it is no longer authorized to use this CNT certification token. Such a step S3 may occur in certain embodiments before the implementation of step S2 or before the implementation of step S1.

[0177] Upon receipt of the request to revoke the CNT certification token, the certificate management module 12 optionally proceeds, in a step S4, to verify the authenticity of the CNT certification token by means of the CertDHCP certificate associated with the configuration server 11.

[0178] Once this verification has been carried out, the certificate management module 12 transmits, in a step S5, a revocation request DRev of the association of the CERT_CPE certificate associated with the equipment 10 with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” with which the CERT_CPE certificate was associated during step E8 to the domain name server 13.

[0179] Such a revocation request DRev includes at least the corresponding CNT certification token, and optionally the CERT_CPE certificate and the public key PUB_KEY_CM of the certificate management module 12. Such a revocation request also includes the code indicating the reasons for this suspension request. At the same time, the certificate management module 12 deletes the CERT_CPE certificate and the corresponding CNT certification token from a database.

[0180] In a step S6, the domain name server 13 extracts all of the information included in the revocation request DRev and revokes the association established between, on the one hand, the CERT_CPE certificate and the corresponding CNT certification token and, on the other hand, the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com”.

[0181] Once the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name has been revoked, the domain name server 13 informs the certificate management module 12 in a step 57 which may be optional.

[0182] In a particular implementation, the operation of deleting the CERT_CPE certificate and the corresponding CNT certification token from a database of the management module 12 is triggered by the reception of the information relating to the revocation of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name received in step S7.

[0183] In turn, the certificate management module 12 optionally informs the configuration server 11 of the revocation of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name in a step 58.

[0184] At the end of step 58, the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a classic TLS Hello client message, i.e. not including a CNT certification token since the latter was revoked in a step S9.

[0185] These classic TLS client Hello and Server Hello message exchanges between the device 10 and the server 14 are not shown in Figure 5.

[0186] If by chance, device 10 needs to obtain a new certificate and the corresponding certification token, it must then implement steps El to Eli again.

[0187] [Fig. 8] represents the different steps implemented by the different equipment constituting the system described with reference to FIG. 2 in a fourth embodiment of the method for revoking a CNT certification token associated with the equipment 10.

[0188] The implementation of this revocation method occurs following the execution of step G6 during which a connection is established between the equipment 10 and the server of a service provider 14.

[0189] In a step F1, the management module 12 receives a request to revoke a first certification token CNT1 associated with the equipment 10 from the network management operator. Such a revocation request t may be issued for several reasons: the first certification token CNT1 is a temporary certification token that must be replaced because it is expiring, the first certification token CNT1 is corrupted or its corruption is suspected, the first certification token CNT1 is hacked or its hacking is suspected, etc.

[0190] In the implementation example described below, the revocation request comprises a request to replace the first certification token CNT1 associated with the equipment 10. Nevertheless, this fourth embodiment can be applied to a request to revoke a certification token not comprising a request to replace the latter. Similarly, although the first, second and third embodiments of the revocation method have been described with a request to revoke a certification token not comprising a request to replace the latter, they can of course process in a manner similar to that described below with reference to the fourth embodiment, a request to revoke a certification token comprising a request to replace the latter. In a step F2, the certificate management module 12 revokes the first certification token CNT1 and the corresponding first certificate CERT1_CPE.

[0191] In a step F3 carried out before, after or concomitantly with step F2, the certificate management module 12 generates a second CERT2 CPE certificate associated with the equipment 10.

[0192] If the second certificate CERT2_CPE is a conventional certificate, the latter is generated from the following information: the public key PUB_KEY_CPE of the equipment 10, the hash HASH_CPE of a physical address of the equipment 10, a certificate CertDHCP associated with the configuration server 11, at least one network address IP_CPE allocated to said equipment 10 by the configuration server 11 during step E4 described with reference to FIG. 2 (or a pool of network addresses POOL_IP_CPE allocated to the equipment 10), and finally the parameter TYP_HASH on the way in which the hash HASH CPE is calculated.

[0193] If the CERT2 CPE certificate is a restricted access certificate, or “black hole” certificate, it is generated from information unrelated to the equipment 10 in order to isolate it.

[0194] Regardless of the type of certificate generated, the certificate management module 12 also generates a CNT2 or CNTbh certification token corresponding to the CERT2_CPE certificate associated with the equipment 10. Such a CNT2, CNTbh certification token is a compact form of the CERT2_CPE certificate associated with the equipment 10.

[0195] It is this CNT2, CNTbh certification token that will now be used by equipment 10 in all situations where the latter must provide authentication material to access a service.

[0196] To do this, the management module 12 transmits, during a step F4, the second certification token CNT2, CNTbh to the configuration server 11 so that the latter replaces the first certification token CNT1 associated with the equipment 10 with the second certification token CNT2, CNTbh.

[0197] In a particular implementation, the reception by the configuration server 11 of the second certification token CNTbh triggers, in a step F5, the allocation of a new network address, called a “black hole” address, to the equipment 10. The use of such a “black hole” address in the exchanges from or to the equipment 10 makes it possible to isolate the data exchanged by the equipment 10 with other equipment and particularly the server of a service provider 14. More particularly, the data transmitted from or to the equipment 10 by means of this “black hole” address may in a first case not be delivered or delivered to a server emulating the server of a service provider 14, in a second case be routed to a dedicated equipment in order to study them with a view to confirming the corruption of the equipment 10.

[0198] In parallel with the execution of step F4, the management module 12 transmits, in a step F6, a revocation request DRemp of the CERT1_CPE certificate associated with the equipment 10 with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com”, this request requesting the deletion of the association established between, on the one hand, the CERT1_CPE certificate and the corresponding CNT1 certification token and, on the other hand, the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” and its replacement by the second CERT2_CPE certificate to the domain name server 13.

[0199] Such a revocation request DRemp includes: the first certification token CNT1, the first certificate CERT1_CPE, the second certification token CNT2, CNTbh, the second certificate CERT2_CPE and the public key PUB_KEY_CM of the certificate management module 12.

[0200] At the same time, the management module 12 stores in a database that the first certificate CERT1_CPE and the first corresponding certification token CNT1 are revoked and replaced by the second certificate CERT2_CPE and the second corresponding certification token CNT2, called CNTbh.

[0201] In a step F7, the domain name server 13 extracts all the information included in the revocation request DRemp, revokes the association of the first certificate CERT1_CPE and the first corresponding certification token CNT1 with the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” and proceeds to associate the domain name “4d2a.37f78dd8d99b3c75ddde3624155.example.com” with the second certificate CERT2_CPE and the second corresponding certification token CNT2, CNTbh.

[0202] In a step F8 which can be implemented before, after or at the same time as steps F6 and F7, the configuration server 11 transmits a DHCP ACK message to the equipment 10. Such a DHCP ACK message comprises the second certification token CNT2, CNTbh. The DHCP ACK message comprising the second certification token CNT2, CNTbh, the equipment 10 understands that it is no longer authorized to use the first certification token CNT1 which has been revoked and that it must now use the second certification token CNT2, CNTbh. If step F5 has been implemented by the configuration server 11, then the DHCP ACK message also comprises the “black hole” address.

[0203] At the end of step F8, the equipment 10 wishing to establish a connection with the server of a service provider 14, because the connection established at the end of step G6 has been interrupted, transmits to the latter a client Hello message comprising the certification token CNT2, CNTbh in a step F9.

[0204] Upon receipt of this Hello TLS client message, the server of a service provider 14 transmits a DNS Query type message comprising the certification token CNT2, CNTbh to the domain name server 13 in a step F10.

[0205] The domain name server 13 then verifies, during a step Fil, the validity of the certification token CNT2, CNTbh and returns, during a step F12, a message indicating that the certification token CNT2, CNTbh is valid but that it does not offer restricted access to the resources of the server of a service provider 14.

[0206] The server of a service provider 14 then sends a Server Hello message to the equipment 10 indicating that the certificate associated with the equipment 10 is valid and indicating that access to its resources is restricted, thus establishing a connection with the equipment 10.

[0207] [Fig. 9] represents a piece of equipment 10 capable of implementing the method for authenticated establishment of a connection between a piece of equipment connected to at least one communication network and a server of a service provider which is the subject of the present invention.

[0208] A device 10 may comprise at least one hardware processor 1001, a storage unit 1002, an interface 1003, and at least one network interface 1004 which are connected to each other via a bus 1005. Of course, the constituent elements of the device 10 may be connected by means of a connection other than a bus.

[0209] The processor 1001 controls the operations of the equipment 10. The storage unit 1002 stores at least one program for implementing the various methods that are the subject of the invention to be executed by the processor 1001, and various data, such as parameters used for calculations performed by the processor 1001, intermediate data of calculations performed by the processor 1001, etc. The processor 1001 may be formed by any known and suitable hardware or software, or by a combination of hardware and software. For example, the processor 1001 may be formed by dedicated hardware such as a processing circuit, or by a programmable processing unit such as a central processing unit (Central Processing Unit) that executes a program stored in a memory thereof. The storage unit 1002 may be formed by any suitable means capable of storing the program or programs and data in a computer-readable manner.Examples of storage unit 1002 include non-transitory computer-readable storage media such as semiconductor memory devices, and magnetic, optical, or magneto-optical recording media loaded into a read / write unit.

[0210] Interface 1003 provides an interface between equipment 10 and a network address configuration server 11.

[0211] The network interface 1004 provides a connection between the equipment 10 and at least one server of a service provider with which it wishes to establish an authenticated connection.

[0212] [Fig. 10] represents a management module 12 capable of implementing the various methods which are the subject of the present invention.

[0213] A management module 12 may comprise at least one hardware processor 1201, a storage unit 1202, an interface 1203, and at least one network interface 1204 which are connected to each other through a bus 1205. Of course, the constituent elements of the management module 12 may be connected by means of a connection other than a bus. In an exemplary embodiment, the certificate management module 12 is embedded in the configuration server 11.

[0214] The processor 1201 controls the operations of the management module 12. The storage unit 1202 stores at least one program for implementing the various methods that are the subject of the invention to be executed by the processor 1201, and various data, such as parameters used for calculations performed by the processor 1201, intermediate data of calculations performed by the processor 1201, etc. The processor 1201 may be formed by any known and suitable hardware or software, or by a combination of hardware and software. For example, the processor 1201 may be formed by dedicated hardware such as a processing circuit, or by a programmable processing unit such as a central processing unit (Central Processing Unit) which executes a program stored in a memory thereof.

[0215] The storage unit 1202 may be formed by any suitable means capable of storing the program(s) and data in a computer-readable manner. Examples of the storage unit 1202 include non-transitory computer-readable storage media such as semiconductor memory devices, and magnetic, optical, or magneto-optical recording media loaded into a read-write unit.

[0216] The interface 1203 provides an interface between the management module 12 and at least one device 10 wishing to connect to a communication network.

[0217] The network interface 1204 provides a connection between the management module 12 and a domain name server 13.

Claims

CLAIMS 1. Method for revoking a first certification token (CNT, CNT1) corresponding to a first certificate (CERT_CPE, CERT1_CPE), said first certification token making it possible to authenticate the establishment of a connection between a device (10) connected to at least one communication network and at least one server of a service provider (14), said first certification token and said first certificate being generated from a digest (HASH_CPE) of a physical address of said device, a certificate (CertDHCP) associated with a network address configuration server (11) and at least one network address (IP_CPE) allocated to said device by said network address configuration server, the method comprising the following steps implemented by a certificate management module (12): - revocation of said first certification token triggered by obtaining information relating to a condition for revocation of said first certification token, - transmission, to a domain name server (13), of a revocation request (DRev) of an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name.

2. A method of revoking a certification token according to claim 1, wherein said condition for revoking said first certification token belongs to a group comprising: - a request for revocation of said first certification token, said revocation request being issued by the equipment, - a request for revocation of said first certification token, said revocation request being issued by network equipment, - an expiration of an allocation period of the network address allocated to the equipment, - an expiration of a lifetime of the first certification token, - an expiration of a duration of the association established between on the one hand the first certificate and the first certification token and on the other hand at least one domain name, - a usage conflict in an addressing plan - information relating to a compromise of the first certification token, - information relating to a hack of the first certification token.

3. Method for revoking a certification token according to claim 2 which, when the information relating to a condition for revoking said first certificate is information relating to the expiry of the duration of the association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name, comprises, prior to the step of revoking the first certification token, the following steps: - transmission of a request to revoke an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, the network address configuration server, - receipt of a request for revocation of said first certification token issued by said network address configuration server following the revocation of the association established between, on the one hand, the first certificate and the first certification token and, on the other hand, the network address configuration server.

4. Method for revoking a certification token according to claim 3 further comprising a step of transmitting, to the network address configuration server, a message acknowledging the revocation of said first certification token by the certificate management module.

5. Method for revoking a certification token according to any one of claims 1 to 4 further comprising the following steps when the condition for revoking said first certification token is accompanied by a request for replacement of said first certification token: - generation of a second certificate (CERT2_CPE) associated with said equipment and a corresponding second certification token (CNT2), - transmission, to said domain name server, of a request for association between, on the one hand, said second certificate and said second certification token and, on the other hand, said domain name previously associated with the first certificate and the corresponding first certification token, - transmission of said second certification token to said equipment.

6. A method of revoking a certification token according to claim 5 wherein the second certification token provides restricted access to the resources of a service provider's server.

7. Certificate management module (12) adapted to revoke a first certification token (CNT, CNT1) corresponding to a first certificate (CERT_CPE, CERT1_CPE), said first certification token making it possible to authenticate the establishment of a connection between a device (10) connected to at least one communication network and at least one server of a service provider (14), said first certification token and said first certificate being generated by said certificate management module from a digest (HASH CPE) of a physical address of said device, a certificate (CertDHCP) associated with a network address configuration server (11) and at least one network address (IP_CPE) allocated to said device by said network address configuration server, said certificate management module comprising at least one processor configured to: - revoke said first certification token following the obtaining of information relating to a condition for revoking said first certification token, -transmit, to a domain name server (13), a revocation request (DRev) of an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name.

8. Network address configuration server (11) comprising at least one certificate management module (12) adapted to revoke a first certification token (CNT, CNT1) corresponding to a first certificate (CERT_CPE, CERT1_CPE), said first certification token making it possible to authenticate the establishment of a connection between an equipment (10) connected to at least one communication network and at least one server of a service provider (14), said first certification token and said first certificate being generated by said certificate management module from a digest (HASH_CPE) of a physical address of said equipment, a certificate (CertDHCP) associated with said network address configuration server (11) and at least one network address (IP_CPE) allocated to said equipment by said network address configuration server, said certificate management module comprising at least one processor configured to: - revoke said first certification token following the obtaining of information relating to a condition for revoking said first certification token, -transmit, to a domain name server (13), a revocation request (DRev) of an association established between, on the one hand, the first certificate and the first certification token and, on the other hand, at least one domain name.

9. A computer program product comprising program code instructions for implementing a method of revoking a first certification token according to claim 1, when executed by a processor.

Images