WO2023281231A1 - 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 - Google Patents

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 Download PDF

Info

Publication number
WO2023281231A1
WO2023281231A1 PCT/FR2022/051376 FR2022051376W WO2023281231A1 WO 2023281231 A1 WO2023281231 A1 WO 2023281231A1 FR 2022051376 W FR2022051376 W FR 2022051376W WO 2023281231 A1 WO2023281231 A1 WO 2023281231A1
Authority
WO
WIPO (PCT)
Prior art keywords
equipment
certificate
server
digest
certification token
Prior art date
Application number
PCT/FR2022/051376
Other languages
English (en)
Inventor
Romuald CORBEL
Emile Stephan
Gaël FROMENTOUX
Frédéric FIEAU
Original Assignee
Orange
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 filed Critical Orange
Priority to US18/577,490 priority Critical patent/US20240275776A1/en
Priority to EP22754900.3A priority patent/EP4367831A1/fr
Priority to CN202280048378.1A priority patent/CN117643014A/zh
Publication of WO2023281231A1 publication Critical patent/WO2023281231A1/fr

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
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • TITLE Process for authenticated establishment of a connection between equipment connected to at least one communication network and a server of a service provider and corresponding devices.
  • the field of the invention is that of the certification of equipment connected to a communication network. More specifically, the invention relates to a solution making it possible to provide a certificate to equipment in an “edge computing” type environment or computing at the edge of the network.
  • 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 data sources. This approach requires the mobilization of resources that may not be permanently connected to a network, such as laptops, smartphones, tablets or sensors. Edge computing also has a prominent place in content ingestion and delivery solutions. In this regard, many architectures of content delivery networks or CDN (Content Delivery Network) are based on architectures of the “edge computing” type.
  • CDN Content Delivery Network
  • a known implementation of such an “edge computing” type architecture is an architecture known by the name Kubernetes.
  • the [Fig. 1] presents in a simplified manner the architecture of a cluster of nodes 1 conforming to the Kubernetes solution.
  • the cluster of nodes 1 comprises a first node 10 called the management node, or “Kubernetes master”, and N computing nodes, or “worker nodes”, lli, i e ⁇ l,...,N ⁇ , N being an integer natural.
  • the management node 10 comprises a controller 101, an API module (Application Programming Interface or application programming interface) 102 and a so-called ETCD database 103 which consists of a dynamic register for configuring the calculation nodes lli.
  • API module Application Programming Interface or application programming interface
  • ETCD database 103 which consists of a dynamic register for configuring the calculation nodes lli.
  • a calculation node lli comprises M containers or “pods” HOj, j e ⁇ l,...,M ⁇ , M being a natural integer.
  • Each HOj container is endowed 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 Dynamic Host Configuration Protocol (DHCP) function for example.
  • DHCP Dynamic Host Configuration Protocol
  • edge computing architectures are most often multi-site architectures in which the nodes making up clusters of nodes can be non-co-located.
  • a management node 10 and two calculation nodes 111, 112 of a cluster of nodes 1 are located on a site A while three other calculation nodes 113, 114, 115 are located on a remote site B .
  • the https protocol allows a visitor's equipment, such as a personal computer, to verify the identity of a website to which the visitor wishes to access from his equipment.
  • the equipment accesses, thanks to a public authentication certificate of the X509 type issued by a third-party authority, reputed to be reliable, to a server providing a service.
  • a public authentication certificate of the X509 type issued by a third-party authority, reputed to be reliable.
  • Such a certificate guarantees the confidentiality and integrity of the data transmitted by the visitor via its destination to the server providing a service.
  • Such a mode of operation cannot meet the needs required by the management of the calculation nodes. Indeed, such management is complex because the computing nodes can be deployed in distributed, even private or even mobile infrastructures, but above all they can be reconfigured, suspended, deleted, reactivated, or even reassigned to another master node in functions needs to be satisfied.
  • calculation nodes correspond, from a protocol point of view, to the visitor equipment described in the example described above. We see, therefore, that the application of the https solution to an “edge switching” architecture is not suitable.
  • the invention meets this need by proposing a system comprising at least one piece of equipment connected to at least one communication network, at least one network address configuration server, at least one certificate creation module, at least one domain names and at least one server from a service provider.
  • Such a system is particular in that:
  • the equipment sends, to the configuration server, a request for allocation of at least one network address comprising at least a digest of a physical address of said equipment,
  • the configuration server generates a request to create a certificate associated with said equipment comprising the digest of a physical address of said equipment, a certificate associated with said configuration server and at least one network address allocated to said equipment by said configuration server,
  • the configuration server transmits said creation request to the certificate creation module
  • the certificate creation module generates, from the information included in the creation request, a certificate associated with said equipment and a certification token corresponding to said certificate,
  • the certificate creation module transmits, to the domain name server, a request to associate said certificate, said certification token and the digest of said certification token with at least one domain name,
  • the domain name server associates, with at least one domain name, the certificate associated with said equipment, the corresponding certification token and the digest of said certification token,
  • the equipment receives the certification token and the digest of said certification token from the configuration server.
  • the solution that is the subject of the present invention makes it possible, by reusing components already present in a communication network, to authenticate with certainty equipment connected to a network. network but which is not managed by the operator managing the communication network in question by providing it with a certificate whose integrity cannot be called into question since the trusted third party issuing the certificate is the operator managing the network Communication.
  • the solution consists in taking advantage of the transmission of a network address allocation request by a device seeking to connect to a communication network to introduce into this request a request to obtain a certificate. .
  • a request results in the introduction into the allocation request of a digest or “hash” in English of a physical address of the equipment.
  • a configuration server detecting the presence of this digest of a physical address of the equipment in a network address allocation request understands that the equipment wishes to obtain a certificate and then triggers a procedure for creating a certificate with a certificate creation module.
  • 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 certificate created is associated with this address pool.
  • the service provider's server can simply, from the configuration token, verify the authenticity and integrity of the certificate associated with the equipment and thus authorize the establishment of a connection with the equipment.
  • the establishment of such a connection corresponds for example to the integration of the equipment into a Kubernetes architecture as a computing node.
  • the server of a service provider can carry out a double certification of the equipment as is the case for connections of the https type.
  • An object of the present invention relates more particularly to a method for authenticated establishment of a connection between equipment connected to at least one communication network and a server of a service provider, said method comprising the following steps implemented by said equipment:
  • the configuration server is involved in the supply process makes it possible to use the messages exchanged with the equipment during the renewal of the allocation of network addresses to transmit, intended for the certificate creation module, a request for maintenance in force of the certificate associated with said equipment, said maintenance in force request comprising said certificate token and said certificate associated with said configuration server.
  • Such a method for authenticated establishment of a connection further comprises the following steps:
  • the invention also relates to a method for supplying a certification token associated with equipment connected to at least one communication network for the authenticated establishment of a connection between said equipment and a server of a service provider, said method comprising the following steps implemented by a network address configuration server:
  • this method further comprises a step of generating the certificate associated with said equipment and the certification token corresponding to said certificate from the digest of a physical address of said equipment, a certificate associated with said server configuration and at least one network address allocated to said equipment by said configuration server.
  • Such a method of providing a certification token further comprises the following steps:
  • the configuration server notifies the certificate creation module of the fact that it must maintain in force the association of said certificate, said certification token and the digest of said certification token at least one domain name.
  • the invention finally relates to computer program products comprising program code instructions for implementing the methods as described previously, when they are executed by a processor.
  • the invention also relates to a recording medium readable by a computer on which are recorded computer programs comprising program code instructions for the execution of the steps of the methods according to the invention as described above.
  • Such recording medium can be any entity or device capable of storing the programs.
  • 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 can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the programs computers it contains are executable remotely.
  • the programs according to the invention can in particular be downloaded from a network, for example the Internet network.
  • the recording medium may be an integrated circuit in which the programs are incorporated, the circuit being suitable for executing or for being used in the execution of the aforementioned methods which are objects of the invention.
  • FIG. 1 this figure represents in a simplified way the architecture of a cluster of nodes 1 conforming to the Kubernetes solution
  • FIG. 5 this figure represents equipment capable of implementing the method for 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
  • FIG. 6 a configuration server capable of implementing the various methods which are the subject of the present invention.
  • the general principle of the invention is based on obtaining a certificate for equipment located in an environment of the “edge computing” type or computing at the edge of the network.
  • the data necessary to obtain such a certificate are exchanged via messages usually used when an item of equipment seeks to connect to a communication network.
  • the necessary information is entered in existing fields of these messages.
  • Such a solution makes it possible not to increase the load on the network because it does not require the transmission of additional messages. Since the data exchanged is introduced into existing fields of existing messages, they are also not too voluminous, which further contributes to not increasing the load on the network.
  • Such a solution also has the advantage of being fast, which makes it particularly interesting for architectures requiring frequent dynamic configurations. Indeed, the present solution transmits data necessary for the creation of a certificate from the first message.
  • 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 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 of a service provider 14 independent or not, of the communication network operator.
  • network address configuration server 11 such as a DHCP server (Dynamic Hosts Configuration Protocol or 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 dynamic host configuration
  • the equipment 10 can equally well be a mobile terminal, a server or a node, or a container according to the Kubernetes solution, or even a sensor. It can also be virtualized equipment.
  • the configuration server 11 and the certificate creation module 12 can be co-located in the same equipment 100 as represented in FIG. 2.
  • the certificate creation module certificates 12 can be co-located with the domain name server 13 or integrated into it.
  • the certificate creation module 12 can be physically separated from the configuration server 11 and from the domain name server 13.
  • the equipment 10 seeks to connect to a communication network. To this end, the equipment 10 sends a DHCP Discover request to the configuration server 11 so that the latter allocates one or more network addresses to it, such as IPv4 or IPv6 addresses.
  • a step E2 upon receipt of the DHCP Discover request sent by the equipment 10, the configuration server 11 offers, in a conventional manner, one or more network addresses to the equipment 10 via the transmission of a message of the type DHCP offers.
  • the configuration server 11 can implement an ACME-STAR type delegation method or a so-called “Delegated Credentials” method upon receipt of the DHCP Discover request sent by the equipment 10. These methods are described in the referenced document Acme-Star RFC 8739 published by the IETF.
  • 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 request validating network addresses among those proposed and comprising parameters relating to the creation of a certificate.
  • the equipment 10 adds parameters intended to be used for the generation of a certificate associated with the equipment 10.
  • parameters are: 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 media access control) as well as a TYP_HASH parameter on the way in which the HASH_CPE digest is calculated .
  • These various parameters can, in another example, be transmitted in the form of a certificate which can be condensed.
  • the HASH_CPE digest of a physical address of the equipment 10 can be transmitted from step E1 in the DHCP Discover request.
  • the configuration server 11 Upon receipt of the DHCP Request, in a step E4, the configuration server 11 processes the information relating to the allocation of network addresses included in this request in a conventional manner. During the processing of this DHCP Request request, the configuration server 11 detecting the presence of parameters relating to the creation of a certificate in a field of the DHCP Request 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 to create a DCC certificate associated with 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 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 to create a DCC certificate associated with 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 IP_CPE allocated to said equipment 10 by the configuration server 11 during step E4 (or a pool of network addresses POOL_IP_CPE allocated to the equipment 10), and finally the TYP_HASH parameter on the way in which the digests HASH_CPE is calculated.
  • the request to create a DCC certificate can 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 for creation of a DCC certificate to the certificate creation module 12.
  • the certificate creation module 12 Upon receipt of the request for creation of a certificate associated with the equipment 10, the certificate creation module 12 generates, during a step E6, a certificate CERT_CPE associated with the equipment 10 from the information included in the DCC creation request.
  • Such a certificate CERT_CPE corresponds to a network address allocated to the equipment 10.
  • the certificate creation module 12 creates as many certificates CERT_CPE associated with the equipment 10 as the latter has network addresses.
  • the certificate creation module 12 creates a single certificate CERT_CPE associated with the equipment 10 which applies to the pool of network addresses POOL_IP_CPE allocated to the equipment 10.
  • Such a certificate CERT_CPE 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 certification token CNT (Certificate Network Token) corresponding to the certificate CERT_CPE associated with the connectivity of the equipment 10 to the network of 11.
  • a certification token CNT is a compact form of the certificate CERT_CPE associated with the equipment 10. More particularly, this certification token CNT comprises 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 an identifier CN_CM of the certificate creation module 12.
  • This certification token CNT which will be used by the equipment 10 in all the situations where the latter must provide authentication material to access a service.
  • This certification token CNT being a compact form of the certificate CERT_CPE 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 that is the subject of the present patent application 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 for be associated with the destination of the domain name server 13.
  • Such a DAss association request comprises: the CERT_CPE certificate associated with the equipment 10, the corresponding certification token CNT, a digest HASH_CNT of the certification token CNT and a parameter TYP_HASH_CNT on the way in which the digest HASH_CNT is calculated.
  • the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated may include a public key from the certificate creation module 12.
  • the domain name server 12 can, if it wishes, verify the identity of the configuration server 11 by requesting a certificate corresponding to the configuration server 11 from the certificate creation module 12. Such a step is not shown in Figure 3.
  • the domain name server 12 saves 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 12 informs the certificate creation module 12 of this in a step E9.
  • the certificate creation module 12 informs the configuration server 11 of the creation of the certificate CERT_CPE associated with the equipment 10 in a step E10.
  • the certificate creation module 12 transmits to the configuration server 11 a message MSG1 comprising the corresponding certification token CNT, the digest HASH_CNT of the certification token CNT and the parameter TYP_HASH_CNT on the way in which the digest HASH_CNT is calculated.
  • the configuration server 11 sends, in a step Eli, an assignment acknowledgment message of a network address DHCP ack.
  • 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 the way in which 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.
  • the 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.
  • the equipment 10 when in a step E12 the equipment 10 sends a DHCP Request 2 message, requesting the extension of the allocation of its network address to the configuration server 11, it adds in an existing field of this DHCP Request 2 message the token of corresponding CNT certification, 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 Request 2 message, in a step E13, the configuration server 11 processes the information relating to the renewal of the allocation of network addresses in the conventional manner. During the processing of this DHCP Request 2 message, the configuration server 11 detecting the presence of parameters relating to the maintenance in force of the CERT_CPE certificate in a field of the DHCP Request 2 message, that is to say the token CNT, the digest HASH_CNT or the TYP_HASH_CNT parameter extracts this information and generates a CERT_CPE certificate maintenance request.
  • the DMV maintenance request for the CERT_CPE certificate includes: the 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 possibly information relating to a deadline for the processing of the DMV maintenance request of the request and the CERT_DHCP certificate of the configuration server 11.
  • the configuration server transmits the DMV request to maintain the certificate CERT_CPE in force to the certificate creation module 12.
  • the certificate creation module 12 verifies the identity of the configuration server 11 from the certificate CERT_DHCP of the configuration server 11 and verifies the authenticity of the certification token CNT from the digest HASH_CNT of the certification token CNT, and the TYP_HASH_CNT parameter on how the HASH_CNT digest is calculated.
  • the certificate creation module 12 transmits to the domain name server 13, in a step E16, a request for extension of the association of the certificate CERT_CPE corresponding to the certification token CNT, with the domain name “CNT.example.com”.
  • Such an extension request includes: the CERT_CPE certificate, 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 domain name server 13 extends the association of the certificate CERT_CPE corresponding to the certification token CNT, with the domain name “CNT.example.com”.
  • a confirmation message that the certificate CERT_CPE remains in force is transmitted in cascade from the domain name server 13 through the certificate creation module 12, then from the configuration server 11 to the equipment 10.
  • FIG. 4 represents the sequence of steps of the methods which are the subject of the present invention.
  • a step G1 the equipment 10 wishing to establish a connection with the server of a service provider 14 transmits to the latter a Hello TLS client message.
  • the equipment 10 adds the certification token CNT, the digest HASH_CNT of the certification token CNT and the parameter TYP_HASH_CNT on the way in which the digest H ASH_CNT 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 ln-situ OAM (iOAM) field 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 KEY_PUB_CM from the certificate creation module 12.
  • the public key KEY_PUB_CM is for example a public field of the certificate X509 from the certificate creation module 12 obtained, after step Gl or previously, for example through a secure tunnel established between the server of a service provider 14 and the certificate creation module 12.
  • the server of a service provider 14 proceeds, in a step G3, to the verification of the authenticity of the certification token CNT 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 the 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 certificate CERT_CPE associated with the certification token CNT that it has just verified. For this, the server of a service provider 14 sends a DNS Query type message comprising, in an existing field, the certification token CNT.
  • the domain name server 13 returns the certificate CRT_CPE corresponding to the certification token CNT received.
  • the server of a service provider 14 then verifies that the certificate CERT_CPE corresponds to the network address(es) provided in the Hello TLS client message knowing that such a certificate CERT_CPE is issued for one or more network addresses.
  • the server of a service provider 14 sends a Server Hello message to the equipment 10 thus finalizing the establishment of the connection between the latter and the server of a service provider 14 in a step G6.
  • FIG. 5 represents an item of equipment 10 capable of implementing the method for authenticated establishment of a connection between an item of equipment connected to at least one communication network and a server of a service provider which is the subject of the present invention.
  • a piece of equipment 10 can comprise at least one hardware processor 501, one storage unit 502, one interface 503, and at least one network interface 504 which are connected together through a bus 505.
  • the processor 501 controls the operations of the equipment 10.
  • the storage unit 502 stores at least one program for the implementation of the various methods which are the subject of the invention to be executed by the processor 501, and various data, such as parameters used for calculations performed by the processor 501, intermediate data of calculations performed by the processor 501, etc.
  • Processor 501 may be any known and suitable hardware or software, or a combination of hardware and software.
  • the processor 801 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 of this one.
  • Storage unit 502 may be formed by any suitable means capable of storing the program or programs and data in a computer readable manner. Examples of storage unit 502 include non-transitory computer-readable storage media such as semiconductor memory devices, and magnetic, optical, or magneto-optical recording media loaded into a read and write unit. 'writing.
  • Interface 503 provides an interface between equipment 10 and a network address configuration server.
  • the network interface 504 for its part provides a connection between the equipment 10 and at least one server of a service provider with which it wishes to establish a connection in an authenticated manner.
  • the [Fig. 6] represents a configuration server 11 capable of implementing the various methods which are the subject of the present invention.
  • a configuration server 11 can comprise at least one hardware processor 601, one storage unit 602, one interface 603, and at least one network interface 604 which are connected to each other through a bus 605.
  • the configuration server further comprises a certificate creation module 12.
  • the constituent elements of the configuration server 11 can be connected by means of a connection other than a bus.
  • the processor 601 controls the operations of the configuration server 11.
  • the storage unit 602 stores at least one program for the implementation of the various methods which are the subject of the invention to be executed by the processor 601, and various data, such as parameters used for calculations performed by the processor 601, intermediate data of calculations performed by the processor 601, etc.
  • Processor 601 may be any known and suitable hardware or software, or a combination of hardware and software.
  • the processor 601 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 of this one.
  • Storage unit 602 may be formed by any suitable means capable of storing the program or programs and data in a computer readable manner. Examples of storage unit 602 include non-transitory computer-readable storage media such as semiconductor memory devices, and magnetic, optical, or magneto-optical recording media loaded into a read-and-write unit. 'writing.
  • Interface 603 provides an interface between configuration server 11 and at least one device 10 wishing to connect to a communication network.
  • the network interface 604 provides a connection between the configuration server 11 and a domain name server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

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 et dispositifs correspondants. L'invention concerne une solution permettant de fournir un certificat à 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éactivés, 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, d'authentifier de manière certaine un tel équipement en lui fournissant 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é 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 et dispositifs 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 permettant de fournir un certificat à 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{l,...,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 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 » HOj, j e{l,...,M}, M étant un entier naturel. Chaque conteneur HOj 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 111, 112 d'une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs 113, 114, 115 sont quant à eux situés sur un site B distant.
Les solutions d'authentification existantes, telle 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 au protocole TLS (Transport Layer Security ou sécurité de la couche transport) dans le protocole http (HyperText Transfer Protocol ou protocole de transfert hypertextuel ) 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 accède, grâce à un certificat public d'authentification de type X509 émis par une autorité tierce, réputé fiable, à un serveur fournissant un service. Un tel certificat garantit la confidentialité et l'intégrité des données transmises par le visiteur via son à destination du serveur fournissant un service.
Un tel mode de fonctionnement 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éactivés, voire réaffectés à un autre nœud maître en fonctions des besoins à satisfaire.
De plus, les nœuds 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 à ce besoin en proposant un système comprenant au moins un équipement raccordé à au moins un réseau de communication, au moins un serveur de configuration d'adresses réseau, au moins un module de création de certificats, au moins un serveur de noms de domaines et au moins un serveur d'un fournisseur de services.
Un tel système est particulier en ce que :
- l'équipement émet, à destination du serveur de configuration, une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement,
- le serveur de configuration génère une demande de création d'un certificat associé audit équipement comprenant le condensé d'une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration,
- le serveur de configuration transmet ladite demande de création à destination du module de création de certificats,
- le module de création de certificats génère, à partir des informations comprises dans la demande de création, un certificat associé audit équipement et d'un jeton de certification correspondant audit certificat,
- le module de création de certificats transmet, à destination du serveur de noms de domaines, d'une demande d'association dudit certificat, dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine,
- le serveur de noms de domaines associe, à au moins un nom de domaine, le certificat associé audit équipement, le jeton de certification correspondant et le condensé dudit jeton de certification,
-suite à l'acquittement de l'association à un nom de domaine, l'équipement reçoit le jeton de certification et le condensé dudit jeton de certification en provenance du serveur de configuration.
La solution objet de la présente invention, permet, en réutilisant des composants déjà présents dans un réseau de communication, d'authentifier de manière certaine un équipement raccordé à un réseau de communication mais qui n'est pas géré par l'opérateur gestionnaire du réseau de communication en question en lui fournissant 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.
Une telle solution permet également de réduire le nombre des échanges nécessaires à l'obtention d'un certificat pour un tel équipement ce qui est particulièrement intéressant dans un contexte de « edge computing » où l'agilité est de rigueur puisque le premier message émis par l'équipement permet déjà de déclencher les opérations conduisant à la création d'un certificat. De même, le fait d'utiliser des messages déjà existants permet de limiter la charge du réseau.
Pour permettre tout cela, la solution consiste à profiter de l'émission d'une demande d'allocation d'adresse réseau par un équipement cherchant à se connecter à un réseau de communication pour introduire dans cette demande une requête en obtention d'un certificat. Une telle requête se traduit par l'introduction dans la demande d'allocation d'un condensé ou « hash » en anglais d'une adresse physique de l'équipement.
Un serveur de configuration détectant la présence de ce condensé d'une adresse physique de l'équipement dans une demande d'allocation d'adresse réseau comprend que l'équipement souhaite obtenir un certificat et déclenche alors une procédure de création d'un certificat auprès d'un module de création de certificats. Un tel module 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é.
Enfin, sachant que le serveur de configuration peut allouer une pluralité d'adresses réseau, ou "pool d’adresses", à un même équipement, le certificat créé est associé à ce pool d'adresses.
Enfin, le serveur du fournisseur de service peut simplement, à partir du jeton de configuration, vérifier l'authenticité et l'intégrité du 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.
Ainsi, le serveur d'un fournisseur de service peut procéder à une double certification de l'équipement comme cela est le cas pour les connexions de type https.
Un objet de la présente invention concerne plus particulièrement un 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, ledit procédé comprenant les étapes suivantes mises en œuvre par ledit équipement :
- émission, à destination d'un serveur de configuration d'adresses réseau, d'une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement,
- réception d'un jeton de certification correspondant à certificat créé par un module de création de certificats à partir d'au moins ledit condensé d'une adresse physique dudit équipement, et un condensé dudit jeton de certification
- émission d'une demande d'établissement d'une connexion avec ledit serveur d'un fournisseur de services comprenant au moins ledit jeton de certification correspondant et ledit condensé dudit jeton de certification.
Le fait que le serveur de configuration soit impliqué dans le processus de fourniture permet d'utiliser les messages échangés avec l'équipement lors du renouvellement de l'allocation des adresses réseau pour transmettre, à destination du module de création de certificats, une demande de maintien en vigueur du certificat associé audit équipement, ladite demande de maintien en vigueur comprenant ledit jeton de certificat et ledit certificat associé audit serveur de configuration. Ainsi, il n'est pas nécessaire d'échanger des messages supplémentaires ce qui contribue à la réactivité des échanges et à limiter la charge dans le réseau.
Un tel procédé d'établissement authentifié d'une connexion comprend en outre les étapes suivantes :
- en réponse à l'authentification dudit équipement par ledit serveur d'un fournisseur de services à partir dudit jeton de certification et dudit condensé dudit jeton de certification, réception d'un message d'acquittement de l'établissement de ladite connexion avec ledit serveur d'un fournisseur de services.
L'invention concerne encore un procédé de fourniture d'un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l'établissement authentifié d'une connexion entre ledit équipement et un serveur d'un fournisseur de services, ledit procédé comprenant les étapes suivantes mises en oeuvre par un serveur de configuration d'adresses réseau :
- réception d'une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement,
- obtention d'un certificat associé audit équipement et d'un jeton de certification correspondant audit certificat à partir du condensé d'une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration,
- transmission dudit jeton de certification et du condensé dudit jeton de certification à destination dudit équipement.
Dans un exemple de réalisation particulier, ce procédé comprend en outre une étape de génération du certificat associé audit équipement et du jeton de certification correspondant audit certificat à partir à partir du condensé d'une adresse physique dudit équipement, d’un certificat associé audit serveur de configuration et d’au moins une adresse réseau allouée audit équipement par ledit serveur de configuration.
Un tel procédé de fourniture d'un jeton de certification comprend en outre les étapes suivantes :
-transmission, à destination d'un serveur de noms de domaines, d'une demande d'association dudit certificat, dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine.
Dans le cadre du renouvellement de l'allocation des adresses réseau, le serveur de configuration notifie le module de création de certificats du fait qu'il doit maintenir en vigueur l'association dudit certificat, dudit jeton de certification et du condensé dudit jeton de certification audit moins un nom de domaine.
L'invention concerne enfin des produits programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre des procédés tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tels que décrits ci-dessus.
Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker les programmes. 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 les programmes d'ordinateur qu'il contient sont exécutables à distance. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés objets de l'invention précités.
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 une première partie du déroulement des procédés objets de l'invention,
[fig. 4] : cette figure représente la suite des étapes des procédés objets de la présente invention,
[fig. 5] : cette figure représente un équipement 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,
[fig. 6] : un serveur de configuration apte à mettre en oeuvre 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 repose sur l'obtention d'un certificat pour un équipement localisé dans un environnement de type « edge computing » ou informatique en périphérie de réseau. Les données nécessaires à l'obtention d'un tel certificat sont échangées via des messages habituellement utilisés lorsqu'un équipement cherche à se raccorder à un réseau de communication. Les informations nécessaires sont introduites dans des champs existants de ces messages. Une telle solution permet de ne pas augmenter la charge du réseau car elle ne nécessite pas la transmission de messages supplémentaires. Les données échangées étant introduites dans des champs existants de messages existant, elles ne sont pas non plus trop volumineuses, ce qui contribue encore à ne pas augmenter la charge du réseau.
Une telle solution présente également 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, la présente solution transmet des données nécessaires à la création d'un certificat dès le premier message.
On présente désormais, en relation avec la [fig. 2] un système dans lequel la présente solution peut être mise en oeuvre.
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 objets de l'invention. Les différentes étapes mises en oeuvre lors de l'exécution de ces procédés 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 Discover é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. Dans un champ existant de cette requête DHCP Request, l'équipement 10 ajoute des paramètres destinés à être utilisés pour la génération d'un certificat associé à l'équipement 10. De tels paramètres sont : 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, dans un autre exemple, être transmis sous forme d'un certificat pouvant être condensé.
Dans un exemple de réalisation, le condensé HASH_CPE d'une adresse physique de l'équipement 10 peut être transmis dès l'étape El dans la requête DHCP Discover.
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 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é. 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 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 demande de brevet 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éations de certificats 12.
A réception de la demande d'association DAss, le serveur de noms de domaines 12 peut, s'il le souhaite, vérifier l'identité du serveur de configuration 11 en demandant un certificat correspondant au serveur de configuration 11 au module de création de certificats 12. Une telle étape n'est pas représentée à la figure 3.
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 12 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 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.
Dans le protocole DHCP, il est prévu de renouveler les allocations d'adresse réseau, ou bail DHCP, de manière régulière. Dans la présente solution, les messages échangés entre les différents éléments du système de la figure 2 sont utilisés pour maintenir en vigueur le certificat CERT_CPE.
Ainsi, lorsque dans une étape E12 l'équipement 10 envoie un message DHCP Request 2, demandant la prolongation de l'allocation de son adresse réseau au serveur de configuration 11, il ajoute dans un champ existant de ce message DHCP Request 2 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 2, dans une étape E13, le serveur de configuration 11 traite les informations relatives au renouvellement de l'allocation d'adresses réseau de manière classique. Lors du traitement de ce message DHCP Request 2, le serveur de configuration 11 détectant la présence de paramètres relatifs au maintien en vigueur du certificat CERT_CPE dans un champ du message DHCP Request 2, c'est-à-dire le jeton CNT, le condensé HASH_CNT ou le paramètre TYP_HASH_CNT, extrait ces informations et génère une demande de maintien en vigueur du certificat CERT_CPE.
La demande de maintien en vigueur DMV du certificat CERT_CPE comprend : le jeton de certification CNT, 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 éventuellement une information relative à un horaire limite pour le traitement de la demande de maintien en vigueur DMV de la requête et le certificat CERT_DHCP du serveur de configuration 11.
Dans une étape E14, le serveur de configuration transmet la demande de maintien en vigueur DMV du certificat CERT_CPE au module de création de certificats 12.
Dans une étape E15, le module de création de certificats 12 vérifie l'identité du serveur de configuration 11 à partir du certificat CERT_DHCP du serveur de configuration 11 et vérifie l'authenticité du jeton de certification CNT à partir du condensé HASH_CNT du jeton de certification CNT, et du paramètre TYP_HASH_CNT sur la manière dont le condensé HASH_CNT est calculé.
Une fois ces vérifications effectuées, le module de création de certificats 12 transmet au serveur de noms de domaines 13, dans une étape E16, une demande de prolongation de l'association du certificat CERT_CPE correspondant au jeton de certification CNT, avec le nom de domaine « CNT.example.com ». Une telle demande de prolongation comprend : le certificat CERT_CPE, 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 une étape E17, le serveur de noms de domaines 13 prolonge l'association du certificat CERT_CPE correspondant au jeton de certification CNT, avec le nom de domaine « CNT.example.com ».
Dans une étape E18, un message de confirmation du maintien en vigueur du certificat CERT_CPE est transmis en cascade depuis le serveur de noms de domaines 13 au travers du module de création de certificats 12, puis du serveur de configuration 11 jusqu'à l'équipement 10.
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 objets de la présente invention.
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é H ASH_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 ln-situ 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 KEY_PUB_CM du module de création de certificats 12. La clé publique KEY_PUB_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 au travers d'un tunnel sécurisé établi entre le serveur d'un fournisseur de services 14 et le module de création de certificats 12.
A l'aide de la clé publique KEY_PUB_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 CRT_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 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 501, une unité de stockage 502, une interface 503, et au moins une interface de réseau 504 qui sont connectés entre eux au travers d'un bus 505. 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 501 commande les opérations de l'équipement 10. L’unité de stockage 502 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 501, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 501, des données intermédiaires de calculs effectués par le processeur 501, etc. Le processeur 501 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 801 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 502 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 502 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 503 fournit une interface entre l'équipement 10 et un serveur de configuration d'adresses réseau.
L'interface réseau 504 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. 6] représente un serveur de configuration 11 apte à mettre en oeuvre les différents procédés objets de la présente invention.
Un serveur de configuration 11 peut comprendre au moins un processeur matériel 601, une unité de stockage 602, une interface 603, et au moins une interface de réseau 604 qui sont connectés entre eux au travers d'un bus 605. Dans un exemple de réalisation, le serveur de configuration comprend en outre un module de création de certificats 12. Bien entendu, les éléments constitutifs du serveur de configuration 11 peuvent être connectés au moyen d'une connexion autre qu'un bus.
Le processeur 601 commande les opérations du serveur de configuration 11. L’unité de stockage 602 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 601, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 601, des données intermédiaires de calculs effectués par le processeur 601, etc. Le processeur 601 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 601 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 602 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 602 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 603 fournit une interface entre serveur de configuration 11 et au moins un équipement 10 souhaitant se raccorder à un réseau de communication.
L'interface réseau 604 fournit quant à elle une connexion entre le serveur de configuration 11 et un serveur de noms de domaines.

Claims

REVENDICATIONS
1. 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, ledit procédé comprenant les étapes suivantes mises en oeuvre par ledit équipement :
- émission, à destination d'un serveur de configuration d'adresses réseau, d'une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement,
- réception d'un message comprenant un jeton de certification généré à partir d'au moins ledit condensé d'une adresse physique dudit équipement, et un condensé dudit jeton de certification,
- émission d'une demande d'établissement d'une connexion avec ledit serveur d'un fournisseur de services comprenant au moins ledit jeton de certification et ledit condensé dudit jeton de certification.
2. Procédé selon la revendication 1 comprenant en outre les étapes suivantes :
- en réponse à l'authentification dudit équipement par ledit serveur d'un fournisseur de services à partir dudit jeton de certification et dudit condensé dudit jeton de certification, réception d'un message d'acquittement de l'établissement de ladite connexion avec ledit serveur d'un fournisseur de services.
3. Procédé de fourniture d'un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l'établissement authentifié d'une connexion entre ledit équipement et un serveur d'un fournisseur de services, ledit procédé comprenant les étapes suivantes mises en oeuvre par un serveur de configuration d'adresses réseau :
- réception d'une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement,
- obtention d'un certificat associé audit équipement et d'un jeton de certification correspondant audit certificat, le certificat et le jeton étant générés à partir du condensé d'une adresse physique dudit équipement, d’un certificat associé audit serveur de configuration et d’au moins une adresse réseau allouée audit équipement par ledit serveur de configuration,
- transmission dudit jeton de certification et du condensé dudit jeton de certification à destination dudit équipement.
4. Procédé selon la revendication 3 comprenant en outre les étapes suivantes :
- transmission, à destination d'un serveur de noms de domaines, d'une demande d'une association dudit certificat, dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine.
5. Procédé selon la revendication 4 comprenant en outre, en réponse à une demande de prolongation de l'allocation de ladite adresse réseau allouée audit équipement, une étape de transmission d'une demande de prolongation de l'association dudit certificat.
6. Procédé selon l’une des revendications 3 à 5, comprenant en outre une étape de génération du certificat associé audit équipement et du jeton de certification correspondant audit certificat à partir du condensé d'une adresse physique dudit équipement, d’un certificat associé audit serveur de configuration et d’au moins une adresse réseau allouée audit équipement par ledit serveur de configuration.
7. Système comprenant au moins un équipement raccordé à au moins un réseau de communication, au moins un serveur de configuration d'adresses réseau, au moins un module de création de certificats, au moins un serveur de noms de domaines et au moins un serveur d'un fournisseur de services, dans lequel :
- l'équipement est configuré pour émettre, à destination du serveur de configuration, une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement,
- le serveur de configuration est configuré pour générer une demande de création d'un certificat associé audit équipement, la demande comprenant le condensé d'une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration,
- le serveur de configuration est configuré pour transmettre ladite demande de création à destination du module de création de certificats,
- le module de création de certificats est configuré pour générer, à partir des informations comprises dans la demande de création, un certificat associé audit équipement, et un jeton de certification correspondant audit certificat,
- le module de création de certificats est configuré pour transmettre, à destination du serveur de noms de domaines, d'une demande d'association dudit certificat, dudit jeton de certification et du condensé dudit jeton de certification à au moins un nom de domaine,
- le serveur de noms de domaines est configuré pour associer, à au moins un nom de domaine, le certificat associé audit équipement, le jeton de certification correspondant et le condensé dudit jeton de certification,
-suite à l'acquittement de l'association à un nom de domaine, l'équipement est configuré pour recevoir le jeton de certification et le condensé dudit jeton de certification en provenance du serveur de configuration.
8. Système selon la revendication 7 dans lequel :
- l'équipement est configuré pour émettre une demande d'établissement d'une connexion avec un serveur d'un fournisseur de services comprenant au moins ledit jeton de certification correspondant et ledit condensé dudit jeton de certification,
- le serveur d'un fournisseur de services est configuré pour vérifier le jeton de certification à l’aide dudit condensé dudit jeton de certification et d'une clé cryptographique associée audit module de création de certificats,
- le serveur d'un fournisseur de services est configuré pour vérifier le nom de domaine associé audit jeton de certification à l’aide dudit condensé dudit jeton de certification et dudit certificat associé audit équipement,
- en réponse à cette double vérification, le serveur d'un fournisseur de services est configuré pour transmettre un message d'acquittement de l'établissement de ladite connexion avec ledit équipement.
9. Système selon l’une des revendications 7 à 8 dans lequel le module de création de certificats est compris dans le serveur de configuration d'adresses réseau.
10. Équipement raccordé à au moins un réseau de communication capable d'établir de manière authentifiée une connexion avec un serveur d'un fournisseur de services, ledit équipement comprenant au moins un processeur configuré pour :
- émettre, à destination d'un serveur de configuration d'adresses réseau, une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement, - recevoir un jeton de certification correspondant à un certificat créé par un module de création de certificats à partir d'au moins ledit condensé d'une adresse physique dudit équipement, et un condensé dudit jeton de certification
- émettre une demande d'établissement d'une connexion avec ledit serveur d'un fournisseur de services comprenant au moins ledit jeton de certification correspondant et ledit condensé dudit jeton de certification.
11. Serveur de configuration d'adresses réseau capable de fournir un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l'établissement authentifié d'une connexion entre ledit équipement et un serveur d'un fournisseur de services, ledit serveur de configuration d'adresses réseau comprenant au moins un processeur configuré pour :
- recevoir une demande d'allocation d'au moins une adresse réseau comprenant au moins un condensé d'une adresse physique dudit équipement,
- obtenir un certificat associé audit équipement et un jeton de certification correspondant audit certificat, le certificat et le jeton étant générés à partir du condensé d'une adresse physique dudit équipement, un certificat associé audit serveur de configuration et au moins une adresse réseau allouée audit équipement par ledit serveur de configuration,
- transmettre ledit jeton de certification et le condensé dudit jeton de certification à destination dudit équipement.
12. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un 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 selon la revendication 1, lorsqu'il est exécuté par un processeur.
13. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé de fourniture d'un jeton de certification associé à un équipement raccordé à au moins un réseau de communication pour l'établissement authentifié d'une connexion entre ledit équipement et un serveur d'un fournisseur de services selon la revendication 3, lorsqu'il est exécuté par un processeur.
PCT/FR2022/051376 2021-07-09 2022-07-08 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 WO2023281231A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US18/577,490 US20240275776A1 (en) 2021-07-09 2022-07-08 Method for the authenticated establishment of a connection between an equipment connected to at least one communication network and a server of a service provider, and corresponding devices
EP22754900.3A EP4367831A1 (fr) 2021-07-09 2022-07-08 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
CN202280048378.1A CN117643014A (zh) 2021-07-09 2022-07-08 用于在连接到至少一个通信网络的装备和服务提供商的服务器之间的连接的认证建立的方法、以及相应的设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2107523A FR3125191A1 (fr) 2021-07-09 2021-07-09 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 et dispositifs correspondants.
FRFR2107523 2021-07-09

Publications (1)

Publication Number Publication Date
WO2023281231A1 true WO2023281231A1 (fr) 2023-01-12

Family

ID=78649352

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2022/051376 WO2023281231A1 (fr) 2021-07-09 2022-07-08 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

Country Status (5)

Country Link
US (1) US20240275776A1 (fr)
EP (1) EP4367831A1 (fr)
CN (1) CN117643014A (fr)
FR (1) FR3125191A1 (fr)
WO (1) WO2023281231A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3145253A1 (fr) * 2023-01-25 2024-07-26 Orange 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

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823454B1 (en) * 1999-11-08 2004-11-23 International Business Machines Corporation Using device certificates to authenticate servers before automatic address assignment
US20210144517A1 (en) * 2019-04-30 2021-05-13 Intel Corporation Multi-entity resource, security, and service management in edge computing deployments

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823454B1 (en) * 1999-11-08 2004-11-23 International Business Machines Corporation Using device certificates to authenticate servers before automatic address assignment
US20210144517A1 (en) * 2019-04-30 2021-05-13 Intel Corporation Multi-entity resource, security, and service management in edge computing deployments

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YVES IGOR JERSCHOW ET AL: "CLL: A Cryptographic Link Layer for Local Area Networks", 10 September 2008, SECURITY AND CRYPTOGRAPHY FOR NETWORKS; [LECTURE NOTES IN COMPUTER SCIENCE], SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 21 - 38, ISBN: 978-3-540-85854-6, XP019104387 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3145253A1 (fr) * 2023-01-25 2024-07-26 Orange 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
WO2024156613A1 (fr) * 2023-01-25 2024-08-02 Orange 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

Also Published As

Publication number Publication date
EP4367831A1 (fr) 2024-05-15
US20240275776A1 (en) 2024-08-15
CN117643014A (zh) 2024-03-01
FR3125191A1 (fr) 2023-01-13

Similar Documents

Publication Publication Date Title
US9912644B2 (en) System and method to communicate sensitive information via one or more untrusted intermediate nodes with resilience to disconnected network topology
US7127613B2 (en) Secured peer-to-peer network data exchange
WO2019178942A1 (fr) Procédé et système d'exécution de négociation ssl
FR2847752A1 (fr) Methode et systeme pour gerer l'echange de fichiers joints a des courriers electroniques
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
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
CA3100170C (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
CN117640765A (zh) 云环境服务访问方法及系统
EP3824676A1 (fr) Dispositifs et procedes de gestion d'un attachement d'un dispositif de communication a un reseau d'un operateur
US11888898B2 (en) Network configuration security using encrypted transport
WO2024156613A1 (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
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
EP3149902B1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
EP3991380A1 (fr) Procedes et dispositifs de securisation d'un reseau de peripherie a acces multiple
FR2975518A1 (fr) Procede de securisation d'une architecture d'authentification, dispositifs materiels et logiciels correspondants
WO2023066708A1 (fr) Procédé d'établissement d'un jeton de certification d'une instanciation d'une grappe de nœuds
WO2021191536A1 (fr) Délégation d'une fonction de résolution d'identifiants de nommage
WO2024083694A1 (fr) Procédé de traitement d'une requête en résolution d'au moins un identifiant de nommage, dispositif et programme d'ordinateur correspondants
WO2023232888A1 (fr) Infrastructure de sécurité; procédé et produit programme d'ordinateur associés
FR3093882A1 (fr) Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.
WO2006056687A2 (fr) Procede d'authentification de la decouverte de voisinage de l'environnement reseau ip d'un terminal candidat a un acces reseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22754900

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280048378.1

Country of ref document: CN

Ref document number: 18577490

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2022754900

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022754900

Country of ref document: EP

Effective date: 20240209