EP4544740A1 - Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants - Google Patents

Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants

Info

Publication number
EP4544740A1
EP4544740A1 EP23734539.2A EP23734539A EP4544740A1 EP 4544740 A1 EP4544740 A1 EP 4544740A1 EP 23734539 A EP23734539 A EP 23734539A EP 4544740 A1 EP4544740 A1 EP 4544740A1
Authority
EP
European Patent Office
Prior art keywords
certificate
certification token
equipment
server
certification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23734539.2A
Other languages
German (de)
English (en)
Inventor
Romuald CORBEL
Emile Stephan
Gaël FROMENTOUX
Frédéric FIEAU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4544740A1 publication Critical patent/EP4544740A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security

Definitions

  • TITLE Method for suspending a certification token making it possible to authenticate the establishment of a connection between two corresponding communication equipment, devices and computer programs
  • 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 suspension of a certificate associated with equipment in an “edge computing” or network edge computing environment.
  • edge computing or computing at the edge of the network and consists of processing data at the edge of the network as close as possible to the source of the data.
  • “Edge computing” thus makes it possible to minimize bandwidth requirements between equipment, such as sensors, and data processing centers by undertaking analyzes as close as possible to the data sources. This approach requires mobilizing resources that may not be permanently connected to a network, such as laptops, smartphones, tablets or sensors. “Edge computing” also has a place of choice in content ingestion and delivery solutions. In this regard, many content delivery network or CDN (Content Delivery Network) architectures are based on “edge computing” type architectures.
  • CDN Content Delivery Network
  • a known implementation of such an “edge computing” type architecture is an architecture known under the name Kubernetes.
  • FIG. 1 presents in a simplified manner the architecture of a cluster of nodes 1 compliant with the Kubernetes solution.
  • the cluster of nodes 1 includes a first node 10 called the management node, or “Kubernetes master”, and N computing nodes, or “workers node”, lli, i e ⁇ 1, N ⁇ , N being a natural integer.
  • the management node 10 includes a controller 101, an API (Application Programming Interface) module 102 and a database 103 called ETCD (name of the main Kubernetes database, storing the system configurations or distributed machine clusters) which consists of a dynamic configuration register of the computing nodes lli.
  • API Application Programming Interface
  • ETCD database 103
  • a calculation node lli includes M containers or “pods” 110j, j e ⁇ 1, ..., M ⁇ , M being a natural number.
  • Each 110j container is equipped with resources allowing the execution of 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.
  • DHCP Dynamic Host Configuration Protocol
  • edge computing architectures are most often multi-site architectures in which the nodes constituting the clusters of nodes can be non-co-located.
  • a management node 10 and two calculation nodes II, II2 of a cluster of nodes 1 are located on a site A while three other calculation nodes II3, II4, Us are located on a remote site B .
  • Existing authentication solutions such as HyperText Transfer Protocol Secure (https), which relies on the introduction of an encryption layer compliant with Secure Socket Layer (SSL) ) or on the introduction of an encryption layer conforming to the TLS (Transport Layer Security) protocol are not well suited to the context of “edge computing”.
  • the https protocol allows a visitor's equipment, such as a personal computer, to verify the identity of a website that the visitor wishes to access from their equipment.
  • the equipment verifies the identity of a server hosting the website, using a public authentication certificate of type X509 issued by a third-party authority, deemed reliable, to a server providing a service.
  • a public authentication certificate of type X509 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.
  • Such a mode of operation namely the verification of the identity of equipment with which a communication session is intended to be established, cannot meet the needs required for the management of computing nodes. Indeed, such management turns out to be complex because the calculation nodes can be deployed in distributed, even private or even mobile infrastructures, but above all they can be reconfigured, suspended, deleted, reestablished, or even reassigned to another cluster of nodes in functions of the needs to be satisfied. Each of these operations can call into question the validity of the certificates associated with the calculation nodes.
  • calculation 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 comuting” architecture is not suitable.
  • the invention partly meets this need by proposing a method for suspending a first certification token corresponding to a first certificate, said first certification token making it possible to authenticate the establishment of a connection between equipment 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 equipment, a certificate associated with a server for configuring network addresses and at least one network address allocated to said equipment by said network address configuration server.
  • Such a method is particular in that it comprises the following steps implemented by said certificate creation module:
  • the solution which is the subject of the present invention makes it possible not to systematically revoke a certificate when the equipment is reconfigured, suspended, corrupted or, when it is mobile equipment, when it changes network. access or access technology.
  • This solution proposes to suspend a certification token corresponding to a certificate associated with the equipment instead of revoking it. It is then no longer necessary to carry out all the steps necessary to obtain a new certificate. This makes it possible to reduce the number of exchanges relating to the management of this certificate for such equipment, which is particularly interesting in a context of “edge computing” where agility is essential.
  • Such a certificate creation module can 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.
  • the equipment can be allocated a plurality of network addresses, or "address pool"
  • the first certification token is associated with all or part of this address pool.
  • the same equipment can simultaneously have several certificates and corresponding certification tokens.
  • Such a configuration token makes it possible to verify the authenticity and integrity of a certificate associated with the equipment and thus authorize the establishment of a connection with the equipment.
  • Establishing such a connection corresponds, for example, to the integration of the equipment into a Kubernetes architecture as a computing node.
  • the method further comprises the following steps:
  • the equipment is mobile equipment, such as a smartphone, in a mobility situation.
  • the first certification token associated with the equipment is for example used when the latter is attached to a home network.
  • the first certification token is suspended.
  • the equipment re-attaches to the home network, such as when the smartphone user returns home, the suspension of the first certification token can be lifted, allowing the smartphone to access the server of a provider of service without having to request a certificate again.
  • the equipment has a second certificate and therefore a second certification token
  • the first certification token is suspended, and the second token certification, which is intended for use when the equipment is attached, for example, to a fifth generation or 5G radio network, is used independently by the second network.
  • the suspension of the first certification token can be lifted and the second certification token is suspended.
  • the method further comprises the following steps when the condition of suspension of said first certification token is accompanied by a request for replacement of said first certification token:
  • the second certification token can also provide restricted access to a service provider's server resources.
  • the second certification token contributes to the establishment of a “sandbox” by limiting the equipment's access to certain services or by isolating traffic linked to this service to or from the equipment.
  • the method further comprises a step of sending, to the network address configuration server, a request to supply, to said equipment, at least a network address pointing to a host machine acting as a dummy server of the provider.
  • the network address provided to the equipment is a so-called “black hole” network address which does not allow the routing of traffic to the equipment or does not allow the transmission of traffic from the equipment to the service provider's server but indicates to a router that this traffic may be routed to other dedicated equipment suitable for processing data originating from/intended for potentially corrupted equipment, or that this traffic may not be routed at all.
  • condition of suspension of said first certification token belongs to a group comprising:
  • the invention also relates to a certificate creation module adapted to suspend a first certification token corresponding to a first certificate, said first certification token making it possible to authenticate the establishment of a connection between equipment connected to at least one network communication and at least one server of a service provider, said first certification token and said first certificate being generated by said certificate creation module from a digest of a physical address of said equipment, a certificate associated with a network address configuration server and at least one network address allocated to said equipment by said network address configuration server, said certificate creation module comprising at least one processor configured to: - suspend said first certification token following obtaining information relating to a condition for suspending said first certification token,
  • the invention also relates to a network address configuration server comprising at least one certificate creation module adapted to suspend a first certification token corresponding to a first certificate, said first certification token making it possible to authenticate the establishment of a connection between equipment 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 creation module from a condensed form of a physical address of said equipment, of a certificate associated with said network address configuration server and of at least one network address allocated to said equipment by said network address configuration server, said certificate creation module comprising at least one processor configured to:
  • 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.
  • 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.
  • Such a recording medium can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a USB key or a hard disk.
  • 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 program computer it contains can be executed remotely.
  • the program according to the invention can in particular be downloaded onto a network, for example the Internet network.
  • 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.
  • FIG. 1 this figure represents in a simplified manner the architecture of a cluster of nodes
  • 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 of suspending a certification token according to the invention
  • 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 of suspending a certification token according to the invention
  • 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 suspending a certification token according to the invention
  • fig- 8 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 this present invention
  • fig- 9 this figure represents a creation module capable of implementing the different processes which are the subject of the present invention.
  • the general principle of the invention concerns 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 suspending a certification token corresponding to a certificate associated with said equipment. This suspension mechanism avoids having to revoke a certificate associated with the equipment temporarily, for example because the equipment is in a mobile situation, or because it has been reconfigured, or even for the duration of check suspicion of corruption, etc.
  • 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 server (Dynamic Hosts Configuration Protocol or protocol dynamic host configuration), at least one certificate creation module 12, at least one domain name server 13 such as a DNS server and at least one server from an independent service provider 14, or not, of the communications network operator.
  • network address configuration server 11 such as a DHCP server (Dynamic Hosts Configuration Protocol or protocol dynamic host configuration)
  • certificate creation module 12 at least one domain name server 13 such as a DNS server
  • DNS server Dynamic Hosts Configuration Protocol or protocol dynamic host configuration
  • 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 may also be virtualized equipment.
  • the configuration server 11 and the certificate creation module 12 can be co-located in the same equipment 100 as shown in Figure 2.
  • the certificate creation module certificates 12 may be co-located with or integrated into the domain name server 13.
  • the certificate creation module 12 can be physically separated from the configuration server 11 and the domain name server 13.
  • 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 one or more network addresses such as IPv4 or IPv6 addresses.
  • the configuration server 11 offers, in a conventional manner, one or more network addresses to the equipment 10 via the transmission of a message type DHCP offer.
  • 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 issued by the equipment 10. These methods are described in the document referenced Acme-Star RFC 8739 published by the IETF.
  • the delegating equipment 10 to receive, here in a DHCP Offer type message, a possibly condensed temporary certificate calculated on the basis of a private key of the delegating configuration server 11.
  • the equipment 10 validates the network address allocation proposal received during step E2 and transmits, to the configuration server 11, a DHCP Request validating network addresses among those proposed and including settings relating to the creation of a certificate.
  • a DHCP Request validating network addresses among those proposed and including settings relating to the creation of a certificate.
  • Such parameters include among others: 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 or access control to the support) as well as a TYP_HASH parameter on how the HASH_CPE digest is calculated.
  • the configuration server 11 On receipt of the DHCP Request 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. During the processing of this DHCP Request, the configuration server 11 detecting the presence of parameters relating to the creation of a certificate in a field of the DHCP Request, that is to say the public key PUB_KEY_CPE, the digest HASH_CPE or the TYP_HASH parameter, extracts this information and generates a request for creation of a DCC certificate associated with the equipment 10.
  • the configuration server 11 detecting the presence of parameters relating to the creation of a certificate in a field of the DHCP Request, that is to say the public key PUB_KEY_CPE, the digest HASH_CPE or the TYP_HASH parameter, extracts this information and generates a request for 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_CPE digest of a physical address of the equipment 10, a CertDHCP certificate associated with the configuration server 11, at least one network address I P_CP E allocated to said equipment 10 by the configuration server 11 during step E4 (or a pool of POOL_IP_CPE network addresses allocated to the equipment 10), and finally the TYP_HASH parameter on the way in which the HASH_CPE digest is calculated.
  • the request to create a DCC certificate may also include a domain name, for example "CNT.example.com", with which the certificate is intended to be associated.
  • the configuration server transmits the request to create a DCC certificate to the certificate creation module 12.
  • the certificate creation module 12 On receipt of the request to create a certificate associated with the equipment 10, the certificate creation 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.
  • Such a CERT_CPE certificate corresponds to a network address allocated to the equipment 10.
  • the certificate creation module 12 creates as many CERT_CPE certificates associated with the equipment 10 as it has network addresses.
  • the certificate creation module 12 creates a single CERT_CPE certificate associated with the equipment 10 which applies to the POOL_IP_CPE network address pool allocated to the equipment 10.
  • Such a CERT_CPE certificate includes the values of the physical address of the equipment 10 and of 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.
  • CN Common Name
  • the certificate creation 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 11.
  • a CNT certification token is a compact form of the CERT_CPE certificate associated with the equipment 10. More particularly, this CNT certification token includes, 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 creation module 12.
  • This CNT certification token which will be used by the equipment 10 in all situations where the latter must provide authentication material to access a service.
  • This CNT certification token being a compact form of the CERT_CPE certificate associated with the equipment 10, it can be introduced into numerous existing messages without increasing the payload of the latter in a detrimental manner.
  • the implementation of the solution which is the subject of the present invention does not introduce too heavy a load into a communication network.
  • the certificate creation module 12 transmits a DAss association request for the CERT_CPE certificate associated with the equipment 10 thus generated with the domain name “CNT.example.com” with which the CERT_CPE certificate is intended to be associated with the domain name server 13.
  • Such a DAss association request includes: 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 the way in which the HASH_CNT digest is calculated.
  • the TYP_HASH_CNT parameter on the way in which the HASH_CNT digest is calculated may include a public key of the certificate creation module 12.
  • 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 “CNT.example.com”.
  • the domain name server 13 informs the certificate creation module 12 in a step E9.
  • the certificate creation module 12 informs the configuration server 11 of the creation of the CERT_CPE certificate associated with the equipment 10 in a step E10. To do this, the certificate creation module 12 transmits to the configuration server 11 a message MSG1 including the corresponding CNT certification token, the HASH_CNT digest of the CNT certification token and the TYP_HASH_CNT parameter on the way in which the HASH_CNT digest is calculated. Finally, the configuration server 11 sends, in an Eli step, an acknowledgment message for assignment of a DHCP ack network address. In an existing field of this DHCP ack message, the equipment 10 adds 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.
  • the equipment 10 thus has a CNT certification token which will be used by the equipment 10 in all situations where the latter must provide authentication material to access a service . It will be noted that equipment 10 is not in possession of its CERT_CPE certificate and does not know the domain name “CNT.example.com” associated with its CERT_CPE certificate. These two pieces of information are only stored in the domain name server 12.
  • FIG. 4 represents the continuation of the steps of the processes relating to the use of the CNT certification token by the equipment 10.
  • a step Gl the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits a Hello TLS client message to the latter.
  • the equipment 10 adds 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.
  • the CNT certification token can be transported by any secure exchange protocol such as the QUIC protocol, 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 field (iOAM) described in https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-17.txt
  • the server of a service provider 14 obtains the public key PUB_KEY_CM of the certificate creation module 12.
  • the public key PUB_KEY_CM is for example a public field of the certificate X509 of the certificate creation module 12 obtained, after step Gl or previously, for example to the establishment of a secure tunnel established between the server of a service provider 14 and the certificate creation module 12, or even pre-recorded in the server.
  • the server of a service provider 14 proceeds, in a step G3, to verify the authenticity of the CNT certification token by means of the key public PUB_KEY_CM of the certificate creation module 12 and the HASH_CNT digest of the CNT certification token and TYP_HASH_CNT information on how the HASH_CNT digest is calculated.
  • 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. To do this, the server of a service provider 14 sends a DNS Query type message including, in an existing field, the CNT certification token.
  • the domain name server 13 returns the CERT_CPE certificate corresponding to the CNT certification token received.
  • the server of a service provider 14 then verifies that the CERT_CPE certificate corresponds to the network address(es) provided in the Hello TLS client message, knowing that such a CERT_CPE certificate is delivered for one or more network addresses.
  • FIG. 5 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 of suspending a CNT certification token associated with the equipment 10.
  • step G6 The implementation of this suspension process may or may not take place following the execution of step G6 during which a connection is established between the equipment 10 and the server of a service provider 14.
  • a step Hl the equipment 10 sends, to the configuration server 11, a message requesting the release of the network address(es) allocated to it.
  • the sending of such a message to the configuration server 11 can 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.
  • a first access node such as for example a Wi-Fi access node
  • a second access node such as a base station.
  • such a message is a DHCP Release type message comprising the CNT certification token, the HASH_CNT digest of the CNT certification token and the TYP_HASH_CNT parameter on the way in which the HASH_CNT digest is calculated.
  • the equipment 10 transmits a new type of message, called DHCP Suspend.
  • DHCP Suspend 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.
  • the configuration server 11 On receipt of the DHCP Release or DHCP Suspend 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.
  • the configuration server 11 detecting the presence of parameters relating to the CERT_CPE certificate in a field of the message, that is to say 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, extracts this information and generates a request for suspension of the CNT certification token associated with the equipment 10 and the CERT_CPE certificate.
  • 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 Suspend message, that is to say the certification token corresponding CNT, 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 for suspension of the CNT certification token associated with the equipment 10 and the CERT_CPE certificate.
  • the suspension of the CNT certification token associated with the equipment 10 and the CERT_CPE certificate is triggered after the detection of inactivity of the equipment 10 by the network.
  • the request to suspend the CNT certification token 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 request to suspend the CNT certification token may also include the domain name, for example "CNT.example.com", with which the CERT_CPE certificate was associated during step E8.
  • the configuration server 11 transmits the request for suspension of the CNT certification token to the certificate creation module 12.
  • the certificate creation 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 server configuration 11.
  • the certificate creation module 12 transmits, in a step H5, a DSusp suspension request of the association of the CERT_CPE certificate associated with the equipment 10 with the domain name “CNT.example.com” with which the CERT_CPE certificate was associated during step E8 intended for the domain name server 13.
  • Such a DSusp suspension request includes: the corresponding CNT certification token, the CERT_CPE certificate and the public key PUB_KEY_CM of the certificate creation module 12.
  • the creation module 12 stores in a database that the CERT_CPE certificate and the corresponding CNT certification token are both suspended.
  • the domain name server 13 extracts all of the information included in the DSusp suspension request and suspends the association established between on the one hand the CERT_CPE certificate and the corresponding CNT certification token and on the other share the domain name “CNT.example.com”.
  • the domain name server 13 informs the certificate creation module 12 in a step H7.
  • the certificate creation module 12 informs the configuration server 11 of the suspension of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name in a step H8.
  • step H8 the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a classic Hello TLS client message, that is to say not including a CNT certification token since it has been suspended.
  • 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 invalid and that a connection cannot be established with the equipment 10.
  • the equipment 10 When the equipment 10 needs to lift the suspension of the CNT certification token, for example when it attaches again to the Wi-Fi access node of the first access network, it transmits in a step H9, at destination of the configuration server 11, a message requesting the allocation of one or more network addresses.
  • such a message is a DHCP Request type message comprising the CNT certification token suspended during step H6, the HASH_CNT digest of the CNT certification token and the TYP_HASH_CNT parameter on the manner in which the HASH_CNT digest is calculated.
  • the equipment 10 sends a new type of message, called DHCP Activate.
  • a DHCP Activate 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.
  • the configuration server 11 processes the information relating to the request for allocation of network addresses included in this request in a conventional manner.
  • the configuration server 11 detecting the presence of parameters relating to the CERT_CPE certificate in a field of the message, that is to say 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, extracts this information and generates a request to lift the suspension of the CNT certification token associated with the equipment 10 and the CERT_CPE certificate.
  • 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 Activate message, that is to say the certification token corresponding CNT, the HASH_CNT digest of the CNT certification token and the TYP_HASH_CNT parameter on the way in which the HASH_CNT digest is calculated, and generate a request to lift the suspension of the CNT certification token associated with the equipment 10 and the CERT_CPE certificate.
  • the request to lift the suspension of the CNT certification token 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 request to lift the suspension of the CNT certification token may also include the domain name, for example “CNT.example.com”, with which the CERT_CPE certificate was associated during step E8.
  • the configuration server 11 transmits the request to lift the suspension of the CNT certification token to the certificate creation module 12.
  • the certificate creation module 12 Upon receipt of the request to lift the suspension of the CNT certification token, the certificate creation module 12 optionally proceeds, in a step H12, to verify the authenticity of the CNT certification token by means of the associated CertDHCP certificate to configuration server 11.
  • the certificate creation module 12 transmits, in a step H13, a request to lift the DReac suspension of the association of the CERT_CPE certificate associated with the equipment 10 with the domain name “CNT.example. com” with which the CERT_CPE certificate was associated during step E8 intended for the domain name server 13.
  • Such a DRéac suspension lifting request includes: the corresponding CNT certification token, the CERT_CPE certificate and the public key PUB_KEY_CM of the certificate creation module 12.
  • the creation module 12 stores in a database that the suspension of the CERT_CPE certificate and the corresponding CNT certification token is lifted.
  • the domain name server 13 extracts all of the information included in the DRéac suspension lifting request and reestablishes the association between on the one hand the CERT_CPE certificate and the corresponding CNT certification token and on the other hand on the other hand the domain name “CNT.example.com”.
  • the domain name server 13 informs the certificate creation module 12 in a step H15.
  • the certificate creation module 12 informs the configuration server 11 of the reestablishment of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name in a step H16.
  • the equipment 10 wishing to establish a connection with the server of a service provider 14 again implements the steps G1 to G6 previously described.
  • FIG. 6 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 of suspending a CNT certification token associated with the equipment 10.
  • step G6 The implementation of this suspension process may or may not take place following the execution of step G6 during which a connection is established between the equipment 10 and the server of a service provider 14.
  • 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.
  • the configuration server 11 receives a request to release the network addresses allocated to the equipment 10 following a decision by the network manager operator.
  • the configuration server 11 transmits a request for suspension of the CNT certification token to the certificate creation module 12.
  • a suspension request includes the CNT certification token and a code indicating the reasons for this suspension request. .
  • the configuration server 11 sends a DHCP NACK message to the equipment 10 in a step S3.
  • a DHCP NACK message indicates to the equipment 10 that it is no longer authorized to use the network addresses allocated to it.
  • 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.
  • the certificate creation module 12 Upon receipt of the request for suspension of the CNT certification token, the certificate creation 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 server configuration 11.
  • the certificate creation module 12 transmits, in a step S5, a DSusp suspension request of the association of the CERT_CPE certificate associated with the equipment 10 with the domain name “CNT.example.com” with which the CERT_CPE certificate was associated during step E8 intended for the domain name server 13.
  • Such a DSusp suspension request includes: the corresponding CNT certification token, the CERT_CPE certificate and the public key PUB_KEY_CM of the certificate creation module 12.
  • Such a suspension request also includes the code indicating the reasons for this suspension request.
  • the creation module 12 stores in a database that the CERT_CPE certificate and the corresponding CNT certification token are suspended.
  • the domain name server 13 extracts all of the information included in the DSusp suspension request and suspends the association of the CERT_CPE certificate and the corresponding CNT certification token with the domain name “CNT.example. com”.
  • the domain name server 13 informs the certificate creation module 12 in a step S7.
  • the certificate creation module 12 informs the configuration server 11 of the suspension of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name in a step S8.
  • the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a Hello client message including the CNT certification token in a step S9.
  • the server of a service provider 14 On receipt of this Hello TLS client message, the server of a service provider 14 transmits a DNS Query type message including the CNT certification token to the domain name server 13 in a step S10.
  • the domain name server 13 then checks, during a step SU, the validity of the CNT certification token and returns, during a step S12, a message indicating that the CNT certification token is no longer valid.
  • the returned message also includes the code indicating the reasons for this suspension.
  • the server of a service provider 14 finally sends, in a step S13, a Server Hello message to the equipment 10 indicating that the certificate associated with the equipment 10 is invalid and that a connection cannot be made. not be established with equipment 10, indicating the reasons for this suspension.
  • the configuration server 11 receives a request to lift the suspension of the CNT certification token associated with the equipment 10, for example following a decision by the network manager operator.
  • a step S15 the configuration server 11 transmits a request to lift the suspension of the CNT certification token to the certificate creation module 12. Such a request to lift the suspension includes the CNT certification token.
  • the certificate creation module 12 Upon receipt of the request to lift the suspension of the CNT certification token, the certificate creation module 12 optionally proceeds, in a step S16, to verify the authenticity of the CNT certification token by means of the associated CertDHCP certificate to configuration server 11.
  • the certificate creation module 12 transmits, in a step S17, a request to lift the DReac suspension of the association of the CERT_CPE certificate associated with the equipment 10 with the domain name “CNT.example. com” with which the CERT_CPE certificate was associated during step E8 intended for the domain name server 13.
  • Such a DRéac suspension lifting request includes the corresponding CNT certification token, the CERT_CPE certificate and the public key PUB_KEY_CM of the certificate creation module 12.
  • the creation module 12 stores in a database that the suspension of the CERT_CPE certificate and the corresponding CNT certification token is lifted.
  • the domain name server 13 extracts all of the information included in the DRéac suspension lifting request and reestablishes the association between on the one hand the CERT_CPE certificate and the corresponding CNT certification token and on the one hand on the other hand the domain name “CNT.example.com”.
  • the domain name server 12 informs the certificate creation module 12 in a step S19.
  • the certificate creation module 12 informs the configuration server 11 of the lifting of suspension of the association between the CERT_CPE certificate and the corresponding CNT certification token and the domain name in a step S20.
  • step S20 the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a Hello client message including the CNT certification token in a step S21.
  • the server of a service provider 14 transmits a DNS Query type message including the CNT certification token to the domain name server 13 in a step S22.
  • the domain name server 13 then checks the validity of the CNT certification token and returns, during a step S23, a message indicating that the CNT certification token is valid.
  • the server of a service provider 14 finally sends, in a step S24, a Server Hello message to the equipment 10, thus establishing a connection with the equipment 10.
  • FIG. 7 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 suspending a CNT certification token associated with the equipment 10.
  • step G6 The implementation of this suspension process 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.
  • the creation module 12 receives a request for replacement of a first certification token CNT1 associated with the equipment 10 from the network management operator.
  • a replacement request may be issued for several reasons: the first CNT1 certification token is a temporary certification token that needs to be replaced because it is expiring, the first CNT1 certification token is corrupted or its corruption is suspected, the first CNT1 certification token is hacked or its hacking is suspected, etc.
  • the certificate creation module 12 suspends the first certification token CNT1 and the first corresponding certificate CERT1_CPE.
  • step F3 carried out before, after or concomitantly with step F2, the certificate creation module 12 generates a second CERT2_CPE certificate associated with the equipment 10.
  • the second CERT2_CPE certificate is a classic certificate, the latter is generated from the following information: the public key PUB_KEY_CPE of the equipment 10, the HASH_CPE digest of a physical address of the equipment 10, a CertDHCP certificate associated with the server configuration 11, at least one IP_CPE network address allocated to said equipment 10 by the configuration server 11 during step E4 (or a pool of POOL_IP_CPE network addresses allocated to the equipment 10), and finally the TYP_HASH parameter on how the HASH_CPE digest is calculated.
  • the CERT2_CPE certificate is a restricted access certificate, or “black hole” certificate, it is generated from information having no link with the equipment 10 in order to isolate it.
  • the certificate creation module 12 also generates a CNT2 or CNTbh certification token corresponding to the CERT2_CPE certificate associated with the equipment 10.
  • a CNT2, CNTbh certification token is a compact form of the certificate CERT2_CPE associated with equipment 10.
  • the creation 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 by the second CNT2 certification token, CNTbh.
  • 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. equipment 10.
  • a black hole” address the allocation of a new network address, called a “black hole” address
  • the use of such a “black hole” address in exchanges from or to equipment 10 makes it possible to isolate the data exchanged by 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, in a second case be routed to dedicated equipment in order to study them with a view to confirming the corruption of the equipment 10.
  • step F4 the creation module 12 transmits, in a step F6, a DRemp replacement request for the CERT1_CPE certificate associated with the equipment 10 with the domain name “CNT.example.com” by the second CERT2_CPE certificate intended for the domain name server 13.
  • Such a DRemp replacement request 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 creation module 12.
  • the creation module 12 stores in a database that the first certificate CERT1_CPE and the first corresponding certification token CNT1 are suspended and replaced by the second certificate CERT2_CPE and the second certification token CNT2, called CNTbh corresponding.
  • the domain name server 13 extracts all of the information included in the replacement request DRemp, suspends the association of the first certificate CERT1_CPE and the first corresponding certification token CNT1 with the domain name “CNT. example.com” and proceeds to associate the domain name “CNT.example.com” with the second CERT2_CPE certificate and the second corresponding CNT2, CNTbh certification token.
  • 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.
  • a DHCP ACK message includes the second CNT2 certification token, CNTbh.
  • step F5 was implemented by the configuration server 11, then the DHCP ACK message also includes the “black hole” address.
  • 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 Hello client message including the certification token CNT2, CNTbh in a step F9.
  • the server of a service provider 14 On receipt of this Hello TLS client message, the server of a service provider 14 transmits a DNS Query type message including the certification token CNT2, CNTbh to the domain name server 13 in a step F10.
  • the domain name server 13 then checks, during a Fil step, 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 does not offer restricted access to the server resources of a service provider 14.
  • the server of a service provider 14 then sends, in a step F13, 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.
  • the connection established between the equipment 10 and the server of a service provider 14 at the end of step G6 still being in use, the reception by the server of a service provider service 14, during a step F14, of a message transmitted by the equipment 10 and comprising the second certification token CNT2, CNTbh, triggers the transmission, in a step F15, of a DNS Query type message comprising the CNT2, CNTbh certification token intended for domain name server 13.
  • the domain name server 13 then checks, during a step F16, the validity of the certification token CNT2, CNTbh and returns, during a step F17, a message indicating that the certification token CNT2, CNTbh is valid but does not offer restricted access to the server resources of a service provider 14.
  • the server of a service provider 14 then continues to exchange data with the equipment 10 while respecting the access limitations to the resources of the server of a service provider 14 associated with the second certification token CNT2, CNTbh at during a step F18.
  • the scope of the restriction being qualitative or quantitative.
  • FIG. 8 represents equipment 10 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.
  • Equipment 10 may include at least one hardware processor 1001, a storage unit 1002, an interface 1003, and at least one network interface 1004 which are connected together via a bus 1005.
  • the constituent elements of the equipment 10 can be connected by means of a connection other than a bus.
  • the processor 1001 controls the operations of the equipment 10.
  • the storage unit 1002 stores at least one program for the implementation of the different processes which are the subject of the invention to be executed by the processor 1001, and various data, such as parameters used for calculations carried out by the processor 1001, intermediate data of calculations carried out 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.
  • the processor 1001 can be formed by dedicated hardware such as a processing circuit, or by a programmable processing unit such as a Central Processing Unit which executes a program stored in a memory. this one.
  • the storage unit 1002 may be formed by any suitable means capable of storing the program(s) and data in a computer-readable manner.
  • Examples of storage unit 1002 include non-transitory computer-readable storage media such as solid-state memory devices, and magnetic, optical, or magneto-optical recording media loaded into a read and read unit. 'writing.
  • the interface 1003 provides an interface between the equipment 10 and a network address configuration server 11.
  • 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.
  • FIG. 9 represents a creation module 12 capable of implementing the different processes which are the subject of the present invention.
  • a creation 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 together via a bus 1205.
  • the elements constituents of the creation module 12 can be connected by means of a connection other than a bus.
  • the certificate creation module 12 is embedded in the configuration server 11.
  • the processor 1201 controls the operations of the creation module 12.
  • the storage unit 1202 stores at least one program for the implementation of the different processes which are objects of the invention to be executed by the processor 1201, and various data, such as parameters used for calculations carried out by the processor 1201, intermediate data of calculations carried out 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.
  • the processor 1201 can be formed by dedicated hardware such as a processing circuit, or by a programmable processing unit such as a Central Processing Unit which executes a program stored in a memory. this one.
  • 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 storage unit 1202 include non-transitory computer-readable storage media such as solid-state memory devices, and magnetic, optical, or magneto-optical recording media loaded into a read and read unit. 'writing.
  • the interface 1203 provides an interface between the creation module 12 and at least one piece of equipment 10 wishing to connect to a communication network.
  • the network interface 1204 provides a connection between the creation module 12 and a domain name server 13.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne une solution permettant de suspendre un certificat fourni à un équipement dans un environnement de type « edge computing ». Les solutions d'authentification existantes, ne sont pas bien adaptées au contexte du « edge computing » car elles ne peuvent répondre aux besoins que requiert la gestion de ces équipements qui peuvent être déployés dans des infrastructures distribuées mais qui surtout peuvent être reconfigurés, suspendus, supprimés, rétablis, voire réaffectés à un autre nœud maitre en fonctions des besoins à satisfaire. La solution objet de la présente invention, permet, en réutilisant des composants déjà présents dans un réseau de communication, de gérer (suspendre, lever la suspension) un certificat dont l'intégrité ne saurait être remise en cause puisque le tiers de confiance émetteur du certificat est l'opérateur gestionnaire du réseau de communication.

Description

DESCRIPTION
TITRE : Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants
Domaine de l'invention
Le domaine de l'invention est celui de la certification d'un équipement raccordé à un réseau de communication. Plus précisément, l'invention concerne une solution de gestion de la suspension d'un certificat associé à un équipement dans un environnement de type « edge computing » ou informatique en périphérie de réseau.
Art antérieur et ses inconvénients
Une nouvelle étape du développement du « cloud computing », ou informatique en nuage, a vu le jour ces dernières années. Ce nouveau développement est nommé « edge computing » ou informatique en périphérie de réseau et consiste à traiter les données à la périphérie du réseau au plus près de la source des données.
L'« edge computing » permet ainsi de minimiser les besoins en bande passante entre des équipements, tels que des capteurs, et les centres de traitement des données en entreprenant les analyses au plus près des sources de données. Cette approche nécessite la mobilisation de ressources qui peuvent ne pas être connectées en permanence à un réseau, tels que des ordinateurs portables, des smartphones, des tablettes ou des capteurs. L'« edge computing » a aussi une place de choix dans les solutions d'ingestion et de livraison de contenus. A cet égard, de nombreuses architectures de réseaux de livraison de contenus ou CDN (Content Delivery Network) reposent sur des architectures de type « edge computing ».
Une mise en oeuvre connue d'une telle architecture de type « edge computing » est une architecture connue sous l'appellation Kubernetes.
La [Fig. 1] présente de manière simplifiée l'architecture d'une grappe de noeuds 1 conforme à la solution Kubernetes. La grappe de noeuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « workers node », lli, i e {1, N}, N étant un entier naturel.
Le nœud de gestion 10 comprend un contrôleur 101, un module API (Application Programming Interface ou interface de programmation d'applications) 102 et une base de données 103 dite ETCD (nom de la base de données principale de Kubernetes, stockant les configurations des systèmes ou clusters de machines distribués) qui consiste en un registre dynamique de configuration des nœuds de calculs lli.
Un nœud de calcul lli comprend M conteneurs ou « pods » 110j, j e {1, ... , M}, M étant un entier naturel. Chaque conteneur 110j est doté de ressources permettant l'exécution d'une ou de plusieurs tâches. Une tâche lorsqu'elle est exécutée contribue à la mise en œuvre d'un service ou d'une fonction réseau, telle qu'une fonction DHCP (Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple.
Dans un souci de réduction des coûts et d'amélioration de la flexibilité des infrastructures réseaux, les architectures d'« edge computing » sont le plus souvent des architectures multi-sites dans lesquelles les nœuds constitutifs des grappes de nœuds peuvent être non co-localisés. Par exemple un nœud de gestion 10 et deux nœuds de calcul lli, II2 d'une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs II3, II4, Us sont quant à eux situés sur un site B distant. Les solutions d'authentification existantes, telles que le protocole https (HyperText Transfer Protocol Secure ou protocole de transfert hypertextuel sécurisé) qui repose sur l'introduction d'une couche de chiffrement conforme au protocole SSL (Secure Socket Layer ou sécurité de la couche socket) ou sur l'introduction d'une couche de chiffrement conforme au protocole TLS (Transport Layer Security ou sécurité de la couche transport) ne sont pas bien adaptées au contexte du « edge computing ».
Le protocole https permet à un équipement d'un visiteur, tel qu'un ordinateur personnel, de vérifier l'identité d'un site internet auquel le visiteur souhaite accéder à partir de son équipement.
Ainsi, l'équipement vérifie l'identité d'un serveur hébergeant le site internet, grâce à un certificat public d'authentification de type X509 émis par une autorité tierce, réputée fiable, à un serveur fournissant un service. Un tel certificat garantit la confidentialité et l'intégrité des données transmises par le visiteur à destination du serveur fournissant un service.
Un tel mode de fonctionnement, à savoir la vérification de l'identité d'un équipement avec lequel une session de communication est destinée à être établie, ne peut répondre aux besoins que requiert la gestion des noeuds de calculs. En effet une telle gestion s'avère complexe car les noeuds de calculs peuvent être déployés dans des infrastructures distribuées, voire privées ou même mobiles, mais surtout ils peuvent être reconfigurés, suspendus, supprimés, rétablis, voire réaffectés à une autre grappe de noeuds en fonctions des besoins à satisfaire. Chacune de ces opérations peut remettre en cause la validité des certificats associés aux noeuds de calculs.
De plus, les noeuds de calculs correspondent, d'un point de vue protocolaire, à l'équipement visiteur décrit dans l'exemple décrit ci-dessus. On voit, par conséquent, que l'application de la solution https à une architecture de « edge comuting » n'est pas adaptée.
Il existe donc un besoin de proposer une solution de gestion des équipements appartenant à une architecture de type « edge computing » ne présentant pas tout ou partie des inconvénients précités.
Exposé de l'invention
L'invention répond en partie à ce besoin en proposant un procédé de suspension d'un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés à partir d'un condensé d'une adresse physique dudit équipement, d'un certificat associé à un serveur de configuration d'adresses réseau et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d'adresses réseau.
Un tel procédé est particulier en ce qu'il comprend les étapes suivantes mises en oeuvre par ledit module de création de certificats :
- suspension dudit premier jeton de certification déclenchée par l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,
-transmission, à destination d'un serveur de noms de domaines, d'une demande de suspension d'une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine.
La solution objet de la présente invention, permet de ne pas révoquer un certificat de manière systématique lorsque l'équipement est reconfiguré, suspendu, corrompu ou encore, quand il s'agit d'un équipement mobile, lorsqu'il change de réseau d'accès ou de technologie d'accès. La présente solution propose de suspendre un jeton de certification correspondant à un certificat associé à l'équipement au lieu de le révoquer. Il n'est alors plus nécessaire de mettre en oeuvre toutes les étapes nécessaires à l'obtention d'un nouveau certificat. Cela permet de réduire le nombre des échanges relatifs à la gestion de ce certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l'agilité est de rigueur.
Un tel module de création de certificat peut être co-localisé avec le serveur de configuration ou avec le serveur de noms de domaines, dans lequel une association dudit certificat avec au moins un nom de domaine fourni par le serveur de configuration est mémorisée.
Enfin, sachant que l'équipement peut se voir allouer une pluralité d'adresses réseau, ou "pool d'adresses", le premier jeton de certification est associé à tout ou partie de ce pool d'adresses. De la même manière, un même équipement peut disposer simultanément de plusieurs certificats et des jetons de certification correspondant.
Un tel jeton de configuration permet de vérifier l'authenticité et l'intégrité d'un certificat associé à l'équipement et ainsi autoriser l'établissement d'une connexion avec l'équipement. L'établissement d'une telle connexion correspond par exemple à l'intégration de l'équipement dans une architecture Kubernetes en tant que nœud de calcul.
Dans un exemple d'implémentation, le procédé comprend en outre les étapes suivantes :
- levée de suspension dudit premier jeton de certification déclenchée par l'obtention d'une information indiquant que ladite condition de suspension dudit premier jeton de certification n'est plus satisfaite,
-transmission, à destination dudit serveur de noms de domaines, d'une demande de levée de suspension de ladite association établie entre le premier certificat, le premier jeton de certification et ledit au moins un nom de domaine.
Un tel exemple est particulièrement intéressant lorsque l'équipement est un équipement mobile, tel qu'un smartphone, en situation de mobilité. Dans un tel cas de figure, le premier jeton de certification associé à l'équipement est par exemple utilisé lorsque ce dernier est attaché à un réseau domestique. Quand l'équipement quitte la zone de couverture du réseau domestique, le premier jeton de certification est suspendu. Lorsque l'équipement s'attache de nouveau au réseau domestique, comme par exemple lorsque l'utilisateur du smartphone rejoint son foyer, la suspension du premier jeton de certification peut être levée permettant ainsi au smartphone d'accéder au serveur d'un fournisseur de service sans avoir à redemander un certificat.
Dans le cas de figure où l'équipement disposerait d'un deuxième certificat et donc d'un deuxième jeton de certification, lorsque l'équipement quitte la zone de couverture du réseau domestique, le premier jeton de certification est suspendu, et le deuxième jeton de certification, qui lui est destiné à être utilisé lorsque l'équipement est attaché, par exemple, à un réseau radio de cinquième génération ou 5G, est utilisé de manière indépendante par le second réseau.
De façon corollaire, lorsque l'équipement s'attache de nouveau au réseau domestique, la suspension du premier jeton de certification peut être levée et le deuxième jeton de certification est suspendu.
Dans un autre exemple, le procédé comprend en outre les étapes suivantes lorsque la condition de suspension dudit premier jeton de certification est assortie d'une demande de remplacement dudit premier jeton de certification :
- génération d'un deuxième certificat associé audit équipement et d'un deuxième jeton de certification correspondant,
- transmission, à destination dudit serveur de noms de domaines, d'une demande d'association dudit deuxième certificat et dudit deuxième jeton de certification audit nom de domaine précédemment associé au premier certificat et au premier jeton de certification correspondant,
- transmission dudit deuxième jeton de certification à destination dudit équipement. Un tel exemple présente un intérêt quand la validité du jeton de certification arrive à expiration mais aussi lorsque le certificat associé à l'équipement est corrompu ou a été piraté. Dans un tel cas de figure, la connexion établie entre l'équipement et le serveur du fournisseur de service est maintenue et le deuxième jeton de certification est transmis à l'équipement au travers de cette connexion rendant l'opération transparente pour un utilisateur de l'équipement. La génération de ce deuxième jeton de certification en remplacement du premier jeton de certification active un mécanisme spécifique de gestion de la connexion comme la surveillance de l'utilisation de ce deuxième jeton de certification dont le but est de suivre et d'examiner les échanges intervenant entre l'équipement et le serveur du fournisseur de services afin de déterminer le caractère corrompu de la connexion.
Cela se traduit par exemple par un ralentissement des échanges initiés par le serveur au travers de la connexion afin de maintenir celle-ci active plus longtemps afin de pouvoir l'observer sur une durée plus longue.
Toujours dans cet exemple, le deuxième jeton de certification peut également offrir un accès restreint aux ressources du serveur d'un fournisseur de services.
Ainsi, le deuxième jeton de certification contribue à la mise en place d'une « sandbox » en limitant l'accès de l'équipement à certains services ou en isolant le trafic lié à ce service à destination ou en provenance de l'équipement.
Afin d'isoler encore davantage le trafic lié à l'équipement, le procédé comprend en outre une étape d'émission, à destination du serveur de configuration d'adresses réseau, d'une demande de fourniture, audit équipement, d'au moins une adresse réseau pointant vers une machine hôte agissant comme un serveur fictif du fournisseur.
Dans ce cas de figure, l'adresse réseau fournie à l'équipement est une adresse réseau dite « black hole » qui ne permet pas l'acheminement du trafic vers l'équipement ou ne permet pas la transmission du trafic depuis l'équipement vers le serveur du fournisseur de services mais indique à un routeur que ce trafic peut être acheminé vers un autre équipement dédié adapté à traiter des données issues de/destinées à un équipement potentiellement corrompu, ou que ce trafic peut ne pas être acheminé du tout.
Dans un autre exemple, ladite condition de suspension dudit premier jeton de certification appartient à un groupe comprenant :
- une demande de suspension dudit premier jeton de certification, ladite demande de suspension étant émise par l'équipement,
- une demande de suspension dudit premier jeton de certification, ladite demande de suspension étant émise par un équipement du réseau
- une expiration d'une durée d'allocation de l'adresse réseau allouée à l'équipement,
- une expiration d'une durée de vie du premier jeton de certification,
- un conflit d'usage dans un plan d'adressage,
- une information relative à une compromission du premier jeton de certification,
- une information relative à un piratage du premier jeton de certification.
L'invention concerne également un module de création de certificats adapté pour suspendre un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de création de certificats à partir d'un condensé d'une adresse physique dudit équipement, d'un certificat associé à un serveur de configuration d'adresses réseau et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d'adresses réseau, ledit module de création de certificats comprenant au moins un processeur configuré pour : - suspendre ledit premier jeton de certification suite à l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,
-transmettre, à destination d'un serveur de noms de domaines, une demande de suspension d'une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine.
L'invention a encore pour objet un serveur de configuration d'adresses réseau comprenant au moins un module de création de certificats adapté pour suspendre un premier jeton de certification correspondant à un premier certificat, ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement raccordé à au moins un réseau de communication et au moins un serveur d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de création de certificats à partir d'un condensé d'une adresse physique dudit équipement, d'un certificat associé audit serveur de configuration d'adresses réseau et d'au moins une adresse réseau allouée audit équipement par ledit serveur de configuration d'adresses réseau, ledit module de création de certificats comprenant au moins un processeur configuré pour :
- suspendre ledit premier jeton de certification suite à l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,
-transmettre, à destination d'un serveur de noms de domaines, une demande de suspension d'une association établie entre le premier certificat, le premier jeton de certification et au moins un nom de domaine.
L'invention concerne enfin un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé tel que décrit précédemment, lorsqu'il est exécuté par un processeur.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'invention tel que décrit ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.
D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé objet de l'invention précité.
Liste des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
[fig. 1] : cette figure représente de manière simplifiée l'architecture d'une grappe de noeuds
1 conforme à la solution Kubernetes,
[fig. 2] : cette figure représente un système dans lequel la présente solution peut être mise en oeuvre, [fig. 3] : cette figure représente les différentes étapes mises en œuvre lors de l'exécution des procédés objets de la présente invention conduisant à l'obtention du jeton de certification au sein du système de la figure 1,
[fig- 4] : cette figure représente la suite des étapes des procédés relatifs à l'utilisation du jeton de certification CNT par un équipement appartenant au système de la figure 1,
[fig- 5] : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un premier mode de réalisation du procédé de suspension d'un jeton de certification selon l'invention,
[fig- 6] : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un deuxième mode de réalisation du procédé de suspension d'un jeton de certification selon l'invention,
[fig- 7] : cette figure représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un troisième mode de réalisation du procédé de suspension d'un jeton de certification selon l'invention,
[fig- 8] : cette figure représente un équipement apte à mettre en œuvre le procédé d'établissement authentifié d'une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d'un fournisseur de services objet de la présente invention,
[fig- 9] : cette figure représente un module de création apte à mettre en œuvre les différents procédés objets de la présente invention.
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention concerne la gestion d'un certificat, notamment mais non exclusivement, pour un équipement localisé dans un environnement de type « edge computing » ou informatique en périphérie de réseau au cours du fonctionnement dudit équipement. L'invention propose un mécanisme de suspension d'un jeton de certification correspondant à un certificat associé audit équipement. Ce mécanisme de suspension permet d'éviter d'avoir à révoquer un certificat associé à l'équipement de manière temporaire par exemple parce que l'équipement est en situation de mobilité, ou parce qu'il a été reconfiguré, ou encore le temps de vérifier une suspicion de corruption, etc.
Une telle solution présente l'avantage d'être rapide ce qui la rend particulièrement intéressante pour des architectures nécessitant des configurations dynamiques fréquentes. En effet, cela permet de réduire le nombre des échanges et la quantité de traitements relatifs à la gestion de ce certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l'agilité est de rigueur.
On présente désormais, en relation avec la [fig. 2] un système dans lequel la présente solution peut être mise en œuvre.
Un tel système comprend au moins un équipement 10 raccordé à au moins un réseau de communication (non représenté sur les figures), au moins un serveur de configuration d'adresses réseau 11, tel qu'un serveur DHCP (Dynamic Hosts Configuration Protocol ou protocole de configuration dynamique d'hôtes), au moins un module de création de certificats 12, au moins un serveurs de noms de domaines 13 tel qu'un serveur DNS et au moins un serveur d'un fournisseur de services 14 indépendant, ou non, de l'opérateur du réseau de communication.
L'équipement 10 peut aussi bien être un terminal mobile, qu'un serveur, qu'un nœud , ou un conteneur selon la solution Kubernetes, ou encore un capteur. Il peut s'agir également d'un équipement virtualisé. Dans un exemple d'implémentation, le serveur de configuration 11 et le module de création de certificats 12 peuvent être co-localisés dans un même équipement 100 comme représenté sur la figure 2. Dans un autre exemple d'implémentation, le module de création de certificats 12 peut être co-localisé avec le serveur de noms de domaines 13 ou intégré dans celui-ci. Dans encore un autre exemple d'implémentation, le module de création de certificats 12 peut être séparé physiquement du serveur de configuration 11 et du serveur de noms de domaines 13.
En référence au système décrit à la figure 2, on décrit maintenant une première partie du déroulement des procédés conduisant à l'obtention d'un tel jeton de certification puis du procédé de suspension du jeton de certification objet de l'invention. Les différentes étapes mises en oeuvre lors de l'exécution des procédés conduisant à l'obtention du jeton de certification au sein du système précédemment décrit sont représentées sous forme de diagramme dans la [Fig. 3],
Dans une étape El, l'équipement 10 cherche à se connecter à un réseau de communication. A cette fin, l'équipement 10 envoie une requête DHCP Discover à destination du serveur de configuration 11 afin que ce dernier lui alloue une ou plusieurs adresses réseau telle que des adresses IPv4 ou IPv6.
Dans une étape E2, à réception de la requête DHCP Disco ver émise par l'équipement 10, le serveur de configuration 11 propose, de manière classique, une ou plusieurs adresses réseau à l'équipement 10 via l'émission d'un message de type DHCP offer.
Dans un autre exemple, le serveur de configuration 11 peut mettre en oeuvre une méthode de délégation de type ACME-STAR ou une méthode dite "Delegated Credentials” à la réception de la requête DHCP Discover émise par l'équipement 10. Ces méthodes sont décrites dans le document référencé Acme-Star RFC 8739 publié par l'IETF.
Elles permettent ainsi à l'équipement délégataire 10 de recevoir, ici dans un message de type DHCP Offer, un certificat temporaire éventuellement condensé calculé sur la base d'une clé privée du serveur de configuration délégant 11.
Dans une étape E3, l'équipement 10 valide la proposition d'allocation d'adresses réseau reçue au cours de l'étape E2 et transmet, au serveur de configuration 11, une requête DHCP Request validant des adresses réseau parmi celles proposées et comprenant des paramètres relatifs à la création d'un certificat. De tels paramètres comprennent entre autres : une clé publique PUB_KEY_CPE de l'équipement 10, un condensé ou « hash » HASH_CPE d'une adresse physique de l'équipement 10 telle qu'une adresse MAC (Medium Access Control ou contrôle d'accès au support) ainsi qu'un paramètre TYP_HASH sur la manière dont le condensé HASH_CPE est calculé. Ces différents paramètres peuvent être transmis sous forme d'un certificat pouvant être condensé.
A réception de la requête DHCP Request, dans une étape E4, le serveur de configuration 11 traite les informations relatives à l'allocation d'adresses réseau comprises dans cette requête de manière classique. Lors du traitement de cette requête DHCP Request, le serveur de configuration 11 détectant la présence de paramètres relatifs à la création d'un certificat dans un champ de la requête DHCP Request , c'est-à-dire la clé publique PUB_KEY_CPE, le condensé HASH_CPE ou le paramètre TYP_HASH, extrait ces informations et génère une demande de création d'un certificat DCC associé à l'équipement 10.
La demande de création d'un certificat DCC comprend : la clé publique PUB_KEY_CPE de l'équipement 10, le condensé HASH_CPE d'une adresse physique de l'équipement 10, un certificat CertDHCP associé au serveur de configuration 11, au moins une adresse réseau I P_CP E allouée audit équipement 10 par le serveur de configuration 11 au cours de l'étape E4 (ou un pool d'adresses réseau POOL_IP_CPE allouées à l'équipement 10), et enfin le paramètre TYP_HASH sur la manière dont le condensés HASH_CPE est calculé. La demande de création d'un certificat DCC peut aussi comprendre un nom de domaine, par exemple « CNT.example.com », avec lequel le certificat est destiné à être associé. Dans une étape E5, le serveur de configuration transmet la demande de création d'un certificat DCC au module de création de certificats 12.
A réception de la demande de création d'un certificat associé à l'équipement 10, le module de création de certificats 12 génère, au cours d'une étape E6, un certificat CERT_CPE associé à l'équipement 10 à partir des informations comprises dans la demande de création DCC.
Un tel certificat CERT_CPE correspond à une adresse réseau allouée à l'équipement 10. Ainsi, le module de créations de certificats 12 crée autant de certificats CERT_CPE associés à l'équipement 10 que celui-ci a d'adresses réseau. Dans un autre exemple d'implémentation, le module de créations de certificats 12 crée un unique certificat CERT_CPE associé à l'équipement 10 qui s'applique au pool d'adresses réseau POOL_IP_CPE alloué à l'équipement 10. Un tel certificat CERT_CPE inclue les valeurs de l'adresse physique de l'équipement 10 et d'une ou plusieurs adresses réseau choisies au cours de l'étape E3 par l'équipement 10, dans des champs du certificat CERT_CPE tels que les champs Common Name (CN) ou SAN par exemple.
Le module de création de certificats 12 génère également un jeton de certification CNT (Certificat Network Token) correspondant au certificat CERT_CPE associé à la connectivité de l'équipement 10 au réseau de 11. Un tel jeton de certification CNT est une forme compacte du certificat CERT_CPE associé à l'équipement 10. Plus particulièrement, ce jeton de certification CNT comprend entre autres des informations relatives au condensé HASH_CPE de l'adresse physique de l'équipement 10, au condensé HASH_CERT_CPE du certificat CERT_CPE associé à l'équipement 10, et un identifiant CN_CM du module de création de certificats 12.
C'est ce jeton de certification CNT qui sera utilisé par l'équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d'authentification pour accéder à un service. Ce jeton de certification CNT étant une forme compacte du certificat CERT_CPE associé à l'équipement 10, il peut être introduit dans de nombreux messages existant sans augmenter la charge utile de ces derniers de manière préjudiciable. Ainsi, l'implémentation de la solution objet de la présente invention n'introduit pas une charge trop lourde dans un réseau de communication.
Dans une étape E7, le module de créations de certificats 12 transmet une demande d'association DAss du certificat CERT_CPE associé à l'équipement 10 ainsi généré avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE est destiné à être associé à destination du serveur de noms de domaines 13.
Une telle demande d'association DAss comprend : le certificat CERT_CPE associé à l'équipement 10, le jeton de certification CNT correspondant, un condensé HASH_CNT du jeton de certification CNT et un paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Dans un exemple de réalisation, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé peut comprendre une clé publique du module de création de certificats 12.
Dans une étape E8, le serveur de noms de domaines 12 enregistre l'ensemble des informations comprises dans la demande d'association DAss dans une table et les associe au nom de domaine « CNT.example.com ».
Une fois l'association entre l'ensemble des informations comprises dans la demande d'association DAss et le nom de domaine effectuée, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape E9.
A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la création du certificat CERT_CPE associé à l'équipement 10 dans une étape E10. Pour cela, le module de création de certificats 12 transmet au serveur de configuration 11 un message MSG1 comprenant le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. Enfin, le serveur de configuration 11 envoie, dans une étape Eli, un message d'acquittement d'affectation d'une adresse réseau DHCP ack. Dans un champ existant de ce message DHCP ack, l'équipement 10 ajoute le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.
A l'issue de l'étape Eli, l'équipement 10 dispose ainsi d'un jeton de certification CNT qui sera utilisé par l'équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d'authentification pour accéder à un service. On remarquera que l'équipement 10 n'est pas en possession de son certificat CERT_CPE et ne connaît pas le nom de domaine « CNT.example.com » associé à son certificat CERT_CPE. Ces deux informations ne sont mémorisées que dans le serveur de nom de domaines 12.
Maintenant que l'équipement 10 est doté d'un certificat, il peut établir une connexion avec un serveur d'un fournisseur de services 14. La [Fig. 4] représente la suite des étapes des procédés relatifs à l'utilisation du jeton de certification CNT par l'équipement 10.
Dans une étape Gl, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello TLS. Dans un champ existant de ce message client Hello TLS, l'équipement 10 ajoute le jeton de certification CNT, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. En pratique le jeton de certification CNT peut être transporté par tout protocole d'échange sécurisé tel que le protocole QUIC, dans un champ de tout protocole applicatif comme HTTP transporté au-dessous de toute combinaison de protocoles garantissant l'intégrité de l'échange, mais également dans un champ OAM (iOAM) décrit dans https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-17.txt
Dans une étape G2, le serveur d'un fournisseur de services 14 obtient la clé publique PUB_KEY_CM du module de création de certificats 12. La clé publique PUB_KEY_CM est par exemple un champ public du certificat X509 du module de création de certificats 12 obtenu, après l'étape Gl ou préalablement, par exemple à l'établissement d'un tunnel sécurisé établi entre le serveur d'un fournisseur de services 14 et le module de création de certificats 12, ou encore préenregistré dans le serveur.
A l'aide de la clé publique PUB_KEY_CM du module de création de certificats 12, le serveur d'un fournisseur de services 14 procède, dans une étape G3, à la vérification de l'authenticité du jeton de certification CNT au moyen de la clé publique PUB_KEY_CM du module de création de certificats 12 et du condensé HASH_CNT du jeton de certification CNT et des informations TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.
Une fois cette vérification effectuée, le serveur d'un fournisseur de services 14 demande, dans une étape G4, au serveur de noms de domaines de lui fournir le certificat CERT_CPE associé au jeton certification CNT qu'il vient de vérifier. Pour cela, le serveur d'un fournisseur de services 14 émet un message de type DNS Query comprenant, dans un champ existant, le jeton certification CNT.
Dans une étape G5, le serveur de noms de domaines 13 retourne le certificat CERT_CPE correspondant au jeton de certification CNT reçu.
Dans une étape G6, le serveur d'un fournisseur de services 14 vérifie alors que le certificat CERT_CPE correspond à la ou les adresses réseau fournies dans le message client Hello TLS sachant qu'un tel certificat CERT_CPE est délivré pour une ou plusieurs adresses réseau.
Une fois l'équipement 10 authentifié, le serveur d'un fournisseur de services 14 émet un message Server Hello à destination de l'équipement 10 finalisant ainsi l'établissement de la connexion entre ce dernier et le serveur d'un fournisseur de services 14 dans une étape G6. La [Fig. 5] représente les différentes étapes mises en œuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un premier mode de réalisation du procédé de suspension d'un jeton de certification CNT associé à l'équipement 10.
La mise en œuvre de ce procédé de suspension peut ou non intervenir suite à l'exécution de l'étape G6 au cours de laquelle une connexion est établie entre l'équipement 10 et le serveur d'un fournisseur de services 14.
Dans une étape Hl, l'équipement 10 émet, à destination du serveur de configuration 11, un message demandant la libération de la ou des adresses réseaux qui lui sont allouées.
L'envoi d'un tel message à destination du serveur de configuration 11 peut être déclenché lorsque l'équipement 10 quitte la zone de couverture d'un premier nœud d'accès, comme par exemple un nœud d'accès Wi-Fi, pour s'attacher à un deuxième nœud d'accès telle qu'une station de base. Un tel changement de réseau d'accès nécessite la libération de l'adresse réseau allouée à l'équipement 10, entraînant la suspension du jeton de certification associé à l'équipement 10 qui a été généré au moyen de cette adresse réseau.
Dans un premier exemple, un tel message est un message de type DHCP Release comprenant le jeton de certification CNT, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.
Dans un deuxième exemple, l'équipement 10 émet un nouveau type de message, appelé DHCP Suspend. Un tel message DHCP Suspend comprend, lui aussi, le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.
A réception du message DHCP Release ou DHCP Suspend, dans une étape H2, le serveur de configuration 11 traite les informations relatives à la libération des adresses réseau comprises dans cette requête de manière classique.
Lors du traitement du message DHCP Release, le serveur de configuration 11 détectant la présence de paramètres relatifs au certificat CERT_CPE dans un champ du message, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, extrait ces informations et génère une demande de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.
Lors du traitement du message DHCP Suspend, la nature même du message indique au serveur de configuration 11 qu'il doit extraire les paramètres relatifs au certificat CERT_CPE compris dans un champ du message DHCP Suspend, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, et générer une demande de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.
Dans un autre mode la suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE est déclenchée après la détection d'une inactivité de l'équipement 10 par le réseau.
La demande de suspension du jeton de certification CNT comprend : le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé et le certificat CertDHCP associé au serveur de configuration 11. La demande de suspension du jeton de certification CNT peut aussi comprendre le nom de domaine, par exemple « CNT.example.com », avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8.
Dans une étape H3, le serveur de configuration 11 transmet la demande de suspension du jeton de certification CNT au module de création de certificats 12. A réception de la demande de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape H4, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.
Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape H5, une demande de suspension DSusp de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.
Une telle demande de suspension DSusp comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.
Parallèlement, le module de création 12 mémorise dans une base de données que le certificat CERT_CPE et le jeton de certification CNT correspondant sont tous les deux suspendus.
Dans une étape H6, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de suspension DSusp et suspend l'association établie entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine « CNT.example.com ».
Une fois l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine suspendue, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape H7.
A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la suspension de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape H8.
A l'issue de l'étape H8, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello TLS classique, c'est- à-dire ne comprenant pas de jeton de certification CNT puisque celui-ci a été suspendu.
Le serveur d'un fournisseur de services 14 ne trouvant pas de jeton de certification CNT dans le message Hello TLS, il ne peut vérifier la validité d'un quelconque certificat relatif à l'équipement 10.
Le serveur d'un fournisseur de services 14 émet alors un message Server Hello à destination de l'équipement 10 indiquant que le certificat associé à l'équipement 10 n'est pas valide et qu'une connexion ne peut pas être établie avec l'équipement 10.
Ces échanges de messages client Hello TLS classique et Server Hello entre l'équipement 10 et le serveur 14 ne sont pas représentés à la figure 5.
Lorsque l'équipement 10 a besoin de lever la suspension du jeton de certification CNT, par exemple lorsqu'il s'attache de nouveau au nœud d'accès Wi-Fi du premier réseau d'accès, il émet dans une étape H9, à destination du serveur de configuration 11, un message demandant l'allocation d'une ou plusieurs adresses réseaux.
Dans un premier exemple, un tel message est un message de type DHCP Request comprenant le jeton de certification CNT suspendu au cours de l'étape H6, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.
Dans un deuxième exemple, l'équipement 10 émet un nouveau type de message, appelé DHCP Activate. Un tel message DHCP Activate comprend, lui aussi, le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé. A réception du message DHCP Request ou DHCP Activate, dans une étape H10, le serveur de configuration 11 traite les informations relatives à la demande d'allocation des adresses réseau comprises dans cette requête de manière classique.
Lors du traitement du message DHCP Request, le serveur de configuration 11 détectant la présence de paramètres relatifs au certificat CERT_CPE dans un champ du message, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, extrait ces informations et génère une demande de levée de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.
Lors du traitement du message DHCP Activate, la nature même du message indique au serveur de configuration 11 qu'il doit extraire les paramètres relatifs au certificat CERT_CPE compris dans un champ du message DHCP Activate, c'est-à-dire le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT et le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé, et générer une demande de levée de suspension du jeton de certification CNT associé à l'équipement 10 et au certificat CERT_CPE.
La demande de levée de suspension du jeton de certification CNT comprend : le jeton de certification CNT correspondant, le condensé HASH_CNT du jeton de certification CNT, le paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé et le certificat CertDHCP associé au serveur de configuration 11. La demande de levée de suspension du jeton de certification CNT peut aussi comprendre le nom de domaine, par exemple « CNT.example.com », avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8.
Dans une étape Hll, le serveur de configuration 11 transmet la demande de levée de suspension du jeton de certification CNT au module de création de certificats 12.
A réception de la demande de levée de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape H12, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.
Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape H13, une demande de levée de suspension DRéac de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.
Une telle demande de levée de suspension DRéac comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.
Parallèlement, le module de création 12 mémorise dans une base de données que la suspension du certificat CERT_CPE et du jeton de certification CNT correspondant est levée.
Dans une étape H14, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de levée de suspension DRéac et rétablit l'association entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine « CNT.example.com ».
Une fois l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine rétablie, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape H15.
A son tour, le module de création de certificats 12 informe le serveur de configuration 11 du rétablissement de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape H16. A l'issue de l'étape H16, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 met de nouveau en oeuvre les étapes G1 à G6 précédemment décrites.
La [Fig. 6] représente les différentes étapes mises en oeuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un deuxième mode de réalisation du procédé de suspension d'un jeton de certification CNT associé à l'équipement 10.
La mise en oeuvre de ce procédé de suspension peut ou non intervenir suite à l'exécution de l'étape G6 au cours de laquelle une connexion est établie entre l'équipement 10 et le serveur d'un fournisseur de services 14.
Dans une étape SI, l'expiration d'une durée de vie associée à une ou plusieurs adresses réseau allouées à l'équipement 10 déclenche la libération de ces adresses réseau par le serveur de configuration 11. Dans un autre exemple, le serveur de configuration 11 reçoit une demande de libération des adresses réseau allouées à l'équipement 10 suite à une décision de l'opérateur gestionnaire du réseau.
Dans une étape S2, le serveur de configuration 11 transmet une demande de suspension du jeton de certification CNT au module de création de certificats 12. Une telle demande de suspension comprend le jeton de certification CNT et un code indiquant les raisons de cette demande de suspension.
Parallèlement à l'étape S2, le serveur de configuration 11 émet un message DHCP NACK à destination de l'équipement 10 dans une étape S3. Un tel message DHCP NACK indique à l'équipement 10 qu'il n'est plus autorisé à utiliser les adresses réseau qui lui étaient allouées. Le message DHCP NACK comprenant également le jeton de certification CNT, l'équipement 10 comprend également qu'il n'est plus autorisé à utiliser ce jeton de certification CNT.
A réception de la demande de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape S4, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.
Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape S5, une demande de suspension DSusp de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.
Une telle demande de suspension DSusp comprend : le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12. Une telle demande de suspension comprend également le code indiquant les raisons de cette demande de suspension.
Parallèlement, le module de création 12 mémorise dans une base de données que le certificat CERT_CPE et le jeton de certification CNT correspondant sont suspendus.
Dans une étape S6, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de suspension DSusp et suspend l'association du certificat CERT_CPE et du jeton de certification CNT correspondant avec le nom de domaine « CNT.example.com ».
Une fois l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine suspendue, le serveur de noms de domaines 13 en informe le module de création de certificats 12 dans une étape S7.
A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la suspension de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape S8. A l'issue de l'étape S8, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello comprenant le jeton de certification CNT dans une étape S9.
A réception de ce message client Hello TLS, le serveur d'un fournisseur de services 14 transmet un message de type DNS Query comprenant le jeton de certification CNT à destination du serveur de noms de domaines 13 dans une étape S10.
Le serveur de noms de domaines 13 vérifie alors, au cours d'une étape SU, la validité du jeton de certification CNT et revoie, au cours d'une étape S12 un message indiquant que le jeton de certification CNT n'est plus valide. Le message renvoyé comprend également le code indiquant les raisons de cette suspension.
Le serveur d'un fournisseur de services 14 émet enfin, dans une étape S13, un message Server Hello à destination de l'équipement 10 indiquant que le certificat associé à l'équipement 10 n'est pas valide et qu'une connexion ne peut pas être établie avec l'équipement 10 en indiquant les raisons de cette suspension.
Dans une étape S14, le serveur de configuration 11 reçoit une demande de levée de suspension du jeton de certification CNT associé à l'équipement 10 par exemple suite à une décision de l'opérateur gestionnaire du réseau.
Dans une étape S15, le serveur de configuration 11 transmet une demande de levée de suspension du jeton de certification CNT au module de création de certificats 12. Une telle demande de levée de suspension comprend le jeton de certification CNT.
A réception de la demande de levée de suspension du jeton de certification CNT, le module de création de certificats 12 procède de manière optionnelle, dans une étape S16, à la vérification de l'authenticité du jeton de certification CNT au moyen du certificat CertDHCP associé au serveur de configuration 11.
Une fois cette vérification effectuée, le module de création de certificats 12 transmet, dans une étape S17, une demande de levée de suspension DRéac de l'association du certificat CERT_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » avec lequel le certificat CERT_CPE a été associé au cours de l'étape E8 à destination du serveur de noms de domaines 13.
Une telle demande de levée de suspension DRéac comprend le jeton de certification CNT correspondant, le certificat CERT_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.
Parallèlement, le module de création 12 mémorise dans une base de données que la suspension du certificat CERT_CPE et du jeton de certification CNT correspondant est levée.
Dans une étape S18, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de levée de suspension DRéac et rétablit l'association entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine « CNT.example.com ».
Une fois l'association entre d'une part le certificat CERT_CPE et le jeton de certification CNT correspondant et d'autre part le nom de domaine rétablie, le serveur de noms de domaines 12 en informe le module de création de certificats 12 dans une étape S19.
A son tour, le module de création de certificats 12 informe le serveur de configuration 11 de la levée de suspension de l'association entre le certificat CERT_CPE et le jeton de certification CNT correspondant et le nom de domaine dans une étape S20.
A l'issue de l'étape S20, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14 transmet à ce dernier un message client Hello comprenant le jeton de certification CNT dans une étape S21. A réception de ce message client Hello TLS, le serveur d'un fournisseur de services 14 transmet un message de type DNS Query comprenant le jeton de certification CNT à destination du serveur de noms de domaines 13 dans une étape S22.
Le serveur de noms de domaines 13 vérifie alors la validité du jeton de certification CNT et revoie, au cours d'une étape S23 un message indiquant que le jeton de certification CNT est valide.
Le serveur d'un fournisseur de services 14 émet enfin, dans une étape S24, un message Server Hello à destination de l'équipement 10 établissant ainsi une connexion avec l'équipement 10.
La [Fig. 7] représente les différentes étapes mises en oeuvre par les différents équipements constituant le système décrit en référence à la figure 2 dans un troisième mode de réalisation du procédé de suspension d'un jeton de certification CNT associé à l'équipement 10.
La mise en oeuvre de ce procédé de suspension intervient suite à l'exécution de l'étape G6 au cours de laquelle une connexion est établie entre l'équipement 10 et le serveur d'un fournisseur de services 14.
Dans une étape Fl, le module de création 12 reçoit une demande de remplacement d'un premier jeton de certification CNT1 associé à l'équipement 10 en provenance de l'opérateur gestionnaire du réseau. Une telle demande de remplacement peut être émise pour plusieurs raisons : le premier jeton de certification CNT1 est un jeton de certification temporaire qui doit être remplacé car il arrive à expiration, le premier jeton de certification CNT1 est corrompu ou sa corruption est suspectée, le premier jeton de certification CNT1 est piraté ou son piratage est suspecté, etc.
Dans une étape F2, le module de création de certificats 12 suspend le premier jeton de certification CNT1 et le premier certificat CERT1_CPE correspondant.
Dans une étape F3 effectuée avant, après ou concomitamment à l'étape F2, le module de création de certificats 12 génère un deuxième certificat CERT2_CPE associé à l'équipement 10.
Si le deuxième certificat CERT2_CPE est un certificat classique, ce dernier est généré à partir des informations suivantes : la clé publique PUB_KEY_CPE de l'équipement 10, le condensé HASH_CPE d'une adresse physique de l'équipement 10, un certificat CertDHCP associé au serveur de configuration 11, au moins une adresse réseau IP_CPE allouée audit équipement 10 par le serveur de configuration 11 au cours de l'étape E4 (ou un pool d'adresses réseau POOL_IP_CPE allouées à l'équipement 10), et enfin le paramètre TYP_HASH sur la manière dont le condensés HASH_CPE est calculé.
Si le certificat CERT2_CPE est un certificat à accès restreint, ou certificat « black hole », celui-ci est généré à partir d'informations n'ayant pas de lien avec l'équipement 10 afin d'isoler celui-ci.
Quel que soit le type de certificat généré, le module de création de certificats 12 génère également un jeton de certification CNT2 ou CNTbh correspondant au certificat CERT2_CPE associé à l'équipement 10. Un tel jeton de certification CNT2, CNTbh est une forme compacte du certificat CERT2_CPE associé à l'équipement 10.
C'est ce jeton de certification CNT2, CNTbh qui sera dorénavant utilisé par l'équipement 10 dans toutes les situations où ce dernier devra fournir du matériel d'authentification pour accéder à un service.
Pour cela, le module de création 12 transmet, au cours d'une étape F4, le deuxième jeton de certification CNT2, CNTbh à destination du serveur de configuration 11 afin que ce dernier remplace le premier jeton de certification CNT1 associé à l'équipement 10 par le deuxième jeton de certification CNT2, CNTbh. Dans une implémentation particulière, la réception par le serveur de configuration 11 du deuxième jeton de certification CNTbh déclenche, dans une étape F5, l'allocation d'une nouvelle adresse réseau, dite adresse « black hole », à. l'équipement 10. L'utilisation d'une telle adresse « black hole » dans les échanges en provenance ou à destination de l'équipement 10 permet d'isoler les données échangées par l'équipement 10 avec d'autres équipements et particulièrement le serveur d'un fournisseur de service 14. Plus particulièrement, les données transmises depuis ou à destination de l'équipement 10 au moyen de cette adresse « black hole » peuvent dans un premier cas ne pas être livrées ou, dans un second cas être routées vers un équipement dédié afin de les étudier en vue de confirmer la corruption de l'équipement 10.
Parallèlement à l'exécution de l'étape F4, le module de création 12 transmet, dans une étape F6, une demande de remplacement DRemp du certificat CERT1_CPE associé à l'équipement 10 avec le nom de domaine « CNT.example.com » par le deuxième certificat CERT2_CPE à destination du serveur de noms de domaines 13.
Une telle demande de remplacement DRemp comprend : le premier jeton de certification CNT1, le premier certificat CERT1_CPE, le deuxième jeton de certification CNT2, CNTbh, le deuxième certificat CERT2_CPE et la clé publique PUB_KEY_CM du module de création de certificats 12.
Parallèlement, le module de création 12 mémorise dans une base de données que le premier certificat CERT1_CPE et le premier jeton de certification CNT1 correspondant sont suspendus et remplacés par le deuxième certificat CERT2_CPE et le deuxième jeton de certification CNT2, dit CNTbh correspondant.
Dans une étape F7, le serveur de noms de domaines 13 extrait l'ensemble des informations comprises dans la demande de remplacement DRemp, suspend l'association du premier certificat CERT1_CPE et du premier jeton de certification CNT1 correspondant avec le nom de domaine « CNT.example.com » et procède à l'association du nom de domaine « CNT.example.com » avec le deuxième certificat CERT2_CPE et le deuxième jeton de certification CNT2, CNTbh correspondant.
Dans une étape F8 qui peut être mise en oeuvre avant, après ou en même temps que les étapes F6 et F7, le serveur de configuration 11 transmet un message DHCP ACK à destination de l'équipement 10. Un tel message DHCP ACK comprend le deuxième jeton de certification CNT2, CNTbh. Le message DHCP ACK comprenant le deuxième jeton de certification CNT2, CNTbh, l'équipement 10 comprend qu'il n'est plus autorisé à utiliser le premier jeton de certification CNT1 et qu'il doit remplacer celui-ci par le deuxième jeton de certification CNT2, CNTbh. Si l'étape F5 a été mise en oeuvre par le serveur de configuration 11, alors le message DHCP ACK comprend également l'adresse « black hole ».
A l'issue de l'étape F8, l'équipement 10 souhaitant établir une connexion avec le serveur d'un fournisseur de services 14, car la connexion établie à l'issue de l'étape G6 a été interrompue, transmet à ce dernier un message client Hello comprenant le jeton de certification CNT2, CNTbh dans une étape F9.
A réception de ce message client Hello TLS, le serveur d'un fournisseur de services 14 transmet un message de type DNS Query comprenant le jeton de certification CNT2, CNTbh à destination du serveur de noms de domaines 13 dans une étape F10.
Le serveur de noms de domaines 13 vérifie alors, au cours d'une étape Fil, la validité du jeton de certification CNT2, CNTbh et revoie, au cours d'une étape F12 un message indiquant que le jeton de certification CNT2, CNTbh est valide mais qu'il n'offre un accès restreint aux ressources du serveur d'un fournisseur de services 14.
Le serveur d'un fournisseur de services 14 émet ensuite, dans une étape F13, un message Server Hello à destination de l'équipement 10 indiquant que le certificat associé à l'équipement 10 est valide et indiquant que l'accès à ses ressources est restreint, établissant ainsi une connexion avec l'équipement 10. Dans une autre implémentation, la connexion établie entre l'équipement 10 et le serveur d'un fournisseur de services 14 à l'issue de l'étape G6 étant toujours en cours d'utilisation, la réception par le serveur d'un fournisseur de service 14, au cours d'une étape F14, d'un message émis par l'équipement 10 et comprenant le deuxième jeton de certification CNT2, CNTbh, déclenche l'émission, dans une étape F15, un message de type DNS Query comprenant le jeton de certification CNT2, CNTbh à destination du serveur de noms de domaines 13.
Le serveur de noms de domaines 13 vérifie alors, au cours d'une étape F16, la validité du jeton de certification CNT2, CNTbh et revoie, au cours d'une étape F17 un message indiquant que le jeton de certification CNT2, CNTbh est valide mais qu'il n'offre un accès restreint aux ressources du serveur d'un fournisseur de services 14.
Le serveur d'un fournisseur de services 14 continue alors d'échanger des données avec l'équipement 10 dans le respect des limitations d'accès aux ressources du serveur d'un fournisseur de services 14 associées au deuxième jeton de certification CNT2, CNTbh au cours d'une étape F18. La portée de la restriction étant qualitative ou quantitative.
La [Fig. 8] représente un équipement 10 apte à mettre en oeuvre le procédé d'établissement authentifié d'une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d'un fournisseur de services objet de la présente invention.
Un équipement 10 peut comprendre au moins un processeur matériel 1001, une unité de stockage 1002, une interface 1003, et au moins une interface de réseau 1004 qui sont connectés entre eux au travers d'un bus 1005. Bien entendu, les éléments constitutifs de l'équipement 10 peuvent être connectés au moyen d'une connexion autre qu'un bus.
Le processeur 1001 commande les opérations de l'équipement 10. L'unité de stockage 1002 stocke au moins un programme pour la mise en oeuvre des différents procédés objets de l'invention à exécuter par le processeur 1001, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 1001, des données intermédiaires de calculs effectués par le processeur 1001, etc. Le processeur 1001 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 1001 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.
L'unité de stockage 1002 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 1002 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture.
L'interface 1003 fournit une interface entre l'équipement 10 et un serveur de configuration d'adresses réseau 11.
L'interface réseau 1004 fournit quant à elle une connexion entre l'équipement 10 et un au moins un serveur d'un fournisseur de services avec lequel il souhaite établir de manière authentifiée une connexion.
La [Fig. 9] représente un module de création 12 apte à mettre en oeuvre les différents procédés objets de la présente invention.
Un module de création 12 peut comprendre au moins un processeur matériel 1201, une unité de stockage 1202, une interface 1203, et au moins une interface de réseau 1204 qui sont connectés entre eux au travers d'un bus 1205. Bien entendu, les éléments constitutifs du module de création 12 peuvent être connectés au moyen d'une connexion autre qu'un bus. Dans un exemple de réalisation, le module de création de certificats 12 est embarqué dans le serveur de configuration 11.
Le processeur 1201 commande les opérations du module de création 12. L'unité de stockage 1202 stocke au moins un programme pour la mise en oeuvre des différents procédés objets de l'invention à exécuter par le processeur 1201, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 1201, des données intermédiaires de calculs effectués par le processeur 1201, etc. Le processeur 1201 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 1201 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.
L'unité de stockage 1202 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 1202 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture.
L'interface 1203 fournit une interface entre le module de création 12 et au moins un équipement 10 souhaitant se raccorder à un réseau de communication.
L'interface réseau 1204 fournit quant à elle une connexion entre le module de création 12 et un serveur de noms de domaines 13.

Claims

REVENDICATIONS
1. Procédé de suspension d'un premier jeton de certification (CNT1) correspondant à un premier certificat (CERT1_CPE), ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement (10) raccordé à au moins un réseau de communication et au moins un serveur (14) d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés à partir d'un condensé (HASH_CPE) d'une adresse physique dudit équipement, d'un certificat (CertDHCP) associé à un serveur (11) de configuration d'adresses réseau et d'au moins une adresse réseau (IP_CPE) allouée audit équipement par ledit serveur de configuration d'adresses réseau, le procédé comprenant les étapes suivantes mises en oeuvre par un module (12) de création de certificats :
- suspension dudit premier jeton de certification déclenchée par l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification,
-transmission, à destination d'un serveur de noms de domaines (13), d'une demande de suspension (DSusp) d'une association établie entre d'une part le premier certificat et le premier jeton de certification et d'autre part au moins un nom de domaine.
2. Procédé de suspension d'un jeton de certification selon la revendication 1 comprenant en outre les étapes suivantes :
- levée de suspension dudit premier jeton de certification déclenchée par l'obtention d'une information indiquant que ladite condition de suspension dudit premier jeton de certification n'est plus satisfaite,
-transmission, à destination dudit serveur de noms de domaines, d'une demande de levée de suspension de ladite association établie entre le premier certificat, le premier jeton de certification et ledit au moins un nom de domaine.
3. Procédé de suspension d'un jeton de certification selon la revendication 1 comprenant en outre les étapes suivantes lorsque la condition de suspension dudit premier jeton de certification est assortie d'une demande de remplacement dudit premier jeton de certification :
- génération d'un deuxième certificat (CERT2_CPE) associé audit équipement et d'un deuxième jeton de certification (CNT2) correspondant,
- transmission, à destination dudit serveur de noms de domaines, d'une demande d'association entre d'une part ledit deuxième certificat et ledit deuxième jeton de certification et d'autre part ledit nom de domaine précédemment associé au premier certificat et au premier jeton de certification correspondant,
- transmission dudit deuxième jeton de certification à destination dudit équipement.
4. Procédé de suspension d'un jeton de certification selon la revendication 3 dans lequel le deuxième jeton de certification offre un accès restreint aux ressources du serveur d'un fournisseur de services.
5. Procédé de suspension d'un jeton de certification selon la revendication 1 comprenant en outre une étape d'émission, à destination du serveur de configuration d'adresses réseau, d'une demande de fourniture, audit équipement, d'au moins une adresse réseau pointant vers une machine hôte agissant comme un serveur fictif du fournisseur.
6. Procédé de suspension d'un jeton de certification selon l'une quelconque des revendications précédentes dans lequel ladite condition de suspension dudit premier jeton de certification appartient à un groupe comprenant :
- une demande de suspension dudit premier jeton de certification, ladite demande de suspension étant émise par l'équipement,
- une demande de suspension dudit premier jeton de certification, ladite demande de suspension étant émise par un équipement du réseau, - une expiration d'une durée d'allocation de l'adresse réseau allouée à l'équipement,
- une expiration d'une durée de vie du premier jeton de certification,
- un conflit d'usage dans un plan d'adressage,
- une information relative à une compromission du premier jeton de certification,
- une information relative à un piratage du premier jeton de certification.
7. Module (12) de création de certificats adapté pour suspendre un premier jeton de certification (CNT1) correspondant à un premier certificat (CERT1_CPE), ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement (10) raccordé à au moins un réseau de communication et au moins un serveur (14) d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de création de certificats à partir d'un condensé (HASH_CPE) d'une adresse physique dudit équipement, d'un certificat (CertDHCP) associé à un serveur (11) de configuration d'adresses réseau et d'au moins une adresse réseau (IP_CPE) allouée audit équipement par ledit serveur de configuration d'adresses réseau, ledit module de création de certificats comprenant au moins un processeur configuré pour :
- suspendre ledit premier jeton de certification suite à l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,
-transmettre, à destination d'un serveur (13) de noms de domaines, une demande de suspension d'une association établie entre d'une part le premier certificat et le premier jeton de certification et d'autre au moins un nom de domaine.
8. Serveur (11) de configuration d'adresses réseau comprenant au moins un module (12) de création de certificats adapté pour suspendre un premier jeton de certification (CNT1) correspondant à un premier certificat (CERT1_CPE), ledit premier jeton de certification permettant d'authentifier l'établissement d'une connexion entre un équipement (10) raccordé à au moins un réseau de communication et au moins un serveur (14) d'un fournisseur de services, ledit premier jeton de certification et ledit premier certificat étant générés par ledit module de création de certificats à partir d'un condensé (HASH_CPE) d'une adresse physique dudit équipement, d'un certificat (CertDHCP) associé audit serveur de configuration d'adresses réseau et d'au moins une adresse réseau (IP_CPE) allouée audit équipement par ledit serveur de configuration d'adresses réseau, ledit module de création de certificats comprenant au moins un processeur configuré pour :
- suspendre ledit premier jeton de certification suite à l'obtention d'une information relative à une condition de suspension dudit premier jeton de certification ,
-transmettre, à destination d'un serveur (13) de noms de domaines, une demande de suspension d'une association établie entre d'une part le premier certificat et le premier jeton de certification et d'autre part au moins un nom de domaine.
9. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé de suspension d'un premier jeton de certification selon la revendication 1, lorsqu'il est exécuté par un processeur.
EP23734539.2A 2022-06-22 2023-06-19 Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants Pending EP4544740A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2206199A FR3137238A1 (fr) 2022-06-22 2022-06-22 Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
PCT/EP2023/066499 WO2023247459A1 (fr) 2022-06-22 2023-06-19 Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP4544740A1 true EP4544740A1 (fr) 2025-04-30

Family

ID=83594390

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23734539.2A Pending EP4544740A1 (fr) 2022-06-22 2023-06-19 Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants

Country Status (3)

Country Link
EP (1) EP4544740A1 (fr)
FR (1) FR3137238A1 (fr)
WO (1) WO2023247459A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10805291B2 (en) * 2015-09-11 2020-10-13 Comcast Cable Communications, Llc Embedded authentication in a service provider network
US10587605B2 (en) * 2017-06-20 2020-03-10 Citrix Systems, Inc. Certificate pinning in highly secure network environments using public key certificates obtained from a DHCP (dynamic host configuration protocol) server
US11483708B2 (en) * 2019-02-20 2022-10-25 Apple Inc. Network access tokens for accessories

Also Published As

Publication number Publication date
FR3137238A1 (fr) 2023-12-29
WO2023247459A1 (fr) 2023-12-28

Similar Documents

Publication Publication Date Title
EP2415294A1 (fr) Procédé et dispositif de gestion d'une authentification d'un utilisateur
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
EP2936782B1 (fr) Procédé de traitement de requêtes d'accès et navigateur web
EP1965559B1 (fr) Procédé de sécurisation d'un flux de données
EP4268426B1 (fr) Procedes pour la redirection de trafic, terminal, controleur, serveur d'autorisation, serveurs de resolution de noms, et programme d'ordinateur correspondants
FR3113346A1 (fr) Procédé de traitement d’un service de transport de données
FR3103990A1 (fr) Procédés et applications de contrôle d’accès distribué à un réseau de télécommunications
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
WO2018130796A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
CA3100170C (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
WO2023281231A1 (fr) Procede d'etablissement authentifie d'une connexion entre un equipement raccorde a au moins un reseau de communication et un serveur d'un fournisseur de services et dispositifs correspondants
FR3084232A1 (fr) Procede de gestion d'un attachement d'un dispositif de communication a un reseau d'un operateur
WO2022117941A1 (fr) Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants
WO2023247459A1 (fr) Procédé de suspension d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants
EP3991392A1 (fr) Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede
EP4655915A1 (fr) Procédé de révocation d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants
FR3095282A1 (fr) Procédé de fourniture d’attestations mis en œuvre par une plateforme informatique virtualisée.
WO2023232888A1 (fr) Infrastructure de sécurité; procédé et produit programme d'ordinateur associés
EP4420297A1 (fr) Procédé d'établissement d'un jeton de certification d'une instanciation d'une grappe de noeuds
FR3122796A1 (fr) Procédé de défense contre une tentative de déconnexion entre deux entités, système associé
EP4128717B1 (fr) Délégation d'une fonction de résolution d'identifiants de nommage
FR3154272A1 (fr) Procédé de communication avec un ordinateur distant depuis un ordinateur local
WO2015181484A1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
WO2023083769A1 (fr) Procédé de traitement d'au moins un paquet de données, dispositif et système associés.
EP4523104A1 (fr) Procédé, dispositif et système de certification d'une ressource

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20241120

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1