WO2006056687A2 - Procede d'authentification de la decouverte de voisinage de l'environnement reseau ip d'un terminal candidat a un acces reseau - Google Patents

Procede d'authentification de la decouverte de voisinage de l'environnement reseau ip d'un terminal candidat a un acces reseau Download PDF

Info

Publication number
WO2006056687A2
WO2006056687A2 PCT/FR2005/002911 FR2005002911W WO2006056687A2 WO 2006056687 A2 WO2006056687 A2 WO 2006056687A2 FR 2005002911 W FR2005002911 W FR 2005002911W WO 2006056687 A2 WO2006056687 A2 WO 2006056687A2
Authority
WO
WIPO (PCT)
Prior art keywords
dns
parent
zone
value
public key
Prior art date
Application number
PCT/FR2005/002911
Other languages
English (en)
Other versions
WO2006056687A3 (fr
WO2006056687B1 (fr
Inventor
Sarah Nataf
Melaine Broudic
Olivier Charles
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2006056687A2 publication Critical patent/WO2006056687A2/fr
Publication of WO2006056687A3 publication Critical patent/WO2006056687A3/fr
Publication of WO2006056687B1 publication Critical patent/WO2006056687B1/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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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

Definitions

  • the invention relates to a method for authenticating the neighborhood discovery of the IP network environment of a terminal. candidate for network access.
  • IP network in particular the Internet
  • the latter is brought to enter into communication with the network equipment for routinely routing the digital data carrier of the transaction.
  • IPv6 protocol In current IP networks, managed by the IPv6 protocol, this protocol makes it possible to manage the mobility of nomadic terminals that can connect to them.
  • IPv6 IP Version 6 edited by T. Narten, E. Nordmark and W. Simpson, December 1998.
  • candidate terminal it allows in particular the terminal, mobile or fixed, candidate for access, hereinafter designated candidate terminal, to collect information, such as network prefix on the local link, available router address or others, which will allow it to auto -configure to automatically execute the connection.
  • the candidate terminal decodes the network prefix type information, contained in the announcement messages sent in the access network to which access is requested. It also stores the IP address of the sending router, network access router RA, and thus updates its communication paths to maintain the IP sessions in progress, by taking this new route.
  • the above procedure, as currently established, is not secure. In particular, there is no procedure for verifying the authorization of the routers, particularly the access router, to execute their routing function. In fact, it is by no means possible, at present, for the above-mentioned candidate terminal to discover with certainty which network equipment, in particular routers, are authorized to route the data on the access network. that is, receiving and forwarding to the appropriate network node the data packets of the terminals that the visiting network hosts.
  • the user of the candidate terminal can not, under any circumstances, be protected from malicious or hacker devices that are in particular likely to be connected to the network of visits, in order to usurp the quality of legitimate or authorized equipment and to divert the data traffic, to allow the theft of information or to modify the data traffic.
  • Secu ⁇ ng Neighbor Discovery a development recommended by the IETF working group called Secu ⁇ ng Neighbor Discovery was the subject of a text of standardization called SEND, for SEcure Neighbor Discovery, referenced draft-ietf-send-ndopt-06, draft IETF, published by J. Arkko, J. Kempf, B. Sommerfeld, B. ZiII and P. Nikander.
  • PKI key management infrastructure
  • the above-mentioned standardization text introduces the use of X 509 certificates and specifies that the access router sends the candidate terminal a certificate that proves that the prospective access router is allowed to route the data packets for a prefix. given network.
  • the validation of the routing authorization granted to the prospective access router via a chain of certificates poses the following delicate technical problems in many cases. -
  • the network routers must all be configured with a key pair and a certificate from at least one CA.
  • the candidate terminal does not know the root certificate of the chain of certificates constituting a chain of trust, sent by the access router, which makes the proposed solution inoperative.
  • the candidate terminal In order for the candidate terminal to validly verify the aforementioned chain of trust, it appears necessary that it has all the root certificates of all the network operators, such as telecommunications operators, access providers, public or private hot spots. or others.
  • the possibilities of connectivity are too great because of the diversity of the types of networks and the operators actors encountered during a connection for the aforementioned mobile candidate terminal to be able to store all the possible root certificates.
  • One solution to the aforementioned major constraint could be to have all network operators adopt the same certification authority. Such a solution is highly unlikely.
  • the candidate terminal In the absence of verification of the aforementioned chain of trust, the candidate terminal has no certainty as to the authenticity and legitimacy of the routing function exerted by the prospective router.
  • the present invention aims to overcome the disadvantages of the techniques and developments of the prior art.
  • an object of the present invention is the implementation of an authentication method for verifying the legitimacy of a device, such as a router, to perform the data packet routing functions from the domain name infrastructure associated with the IP network, in the absence of
  • Another object of the present invention is also the implementation of a method for authenticating or verifying the legitimacy of a device, such as a router, by taking advantage of the DNS architecture of the servers.
  • DNS managing the DNS zones of the IP network, allowing to certify and verify the authorization of the routers on the access networks.
  • Another object of the present invention is also the communication, real or virtual, by a prospective access router, of the chain of trust represented by the routing authorization issued to this prospective access router, to any candidate terminal for acceptance.
  • Another object of the present invention is finally the implementation of a method for authenticating or verifying the legitimacy of a device, such as a router, by taking advantage of the DNS architecture of the DNS servers managing the DNS zones of IP networks, allowing any prospective access router to register for authentication with any DNS server with which it is hierarchically submitted.
  • the method for authenticating the neighborhood discovery of the IP network environment of a candidate terminal for network access applies to any IP network managed by a plurality of DNS zones formed by a server.
  • DNS root and by intermediate DNS servers each DNS zone being associated with one of the DNS servers, these zones and DNS servers being configured according to a tree of parent DNS zones and girls DNS zones between a root DNS zone and a zone DNS access girl, from which this candidate terminal performs this access by connecting to the IP network.
  • each DNS zone, parent respectively daughter is allocated a specific private cryptographic value, each private cryptographic value allocated to a daughter DNS zone being capable of being authenticated via the private cryptographic value associated with the DNS zone. parent immediately superior to this tree structure. It is remarkable in that, on the first access request to the network
  • IP by connection of a candidate terminal to a router of the DNS access girl zone, this router constituting an access router, it also consists in launching from the access router to at least one of the servers DNS of a DNS zone is a parenting procedure for registering routing authorization, allowing generating and transmitting to the access router a routing authorization certificate issued by the parent DNS zone server and consisting of a signature value of parameters specific to this access router, this signature value being obtained from the private cryptographic value allocated to the parent DNS zone, then, to launch via the access router a procedure for authenticating the routing authorization certificate by verifying the signature value according to the private cryptographic value allocated to the parent DNS zone.
  • the specific private cryptographic value is constituted by a secret key held by the parent DNS zone and the server
  • this secret key being used to electronically sign the DNS resource information and obtain the signature value of the DNS resource information, and by a public key associated with this secret key and freely available, this public key being used to electronically verify the signature value of DNS resources.
  • the method that is the subject of the present invention finds application in the securing of transactions or protocols for exchanging data in an IP network for any type of terminal accessing, on connection, to such networks.
  • FIG. 1 represents, by way of illustration, a flowchart of the essential steps for implementing the method that is the subject of the present invention
  • FIG. 2a represents, by way of illustration, a graphical representation of the step of allocating to each DNS zone, parent or daughter, a specific private cryptographic value, represented in FIG. 1;
  • FIG. 2b represents, by way of illustration, a detailed flowchart of the steps for implementing the routing registration procedure represented in FIG. 1;
  • FIG. 2c represents, by way of illustration, a detailed flowchart of the steps for implementing the authentication procedure of the routing authorization certificate represented in FIG. 1;
  • FIG. 2d represents, by way of illustration, a public key authentication process associated with the private key held by each DNS server
  • FIG. 3 represents, by way of illustration, a flowchart of the essential steps of preferential implementation of the method which is the subject of the invention in an optimized version of the point of view of the volume of traffic necessary for the implementation of the latter on the IP network visited
  • FIG. 4a represents, by way of illustration, a particular network configuration and an elementary data structure of authentication request declaration of a routing DNS resource, in accordance with the method that is the subject of the present invention
  • FIG. 4b represents, by way of illustration, a declaration data structure of a routing DNS resource stored in memory of a DNS server comprising elementary data structures for defining a given DNS zone, in particular a structure basic DNS authentication request declaration data set as shown in FIG. 4a;
  • FIG. 5 represents, by way of illustration, a flowchart of a preferential, nonlimiting internal protocol for verifying the routing authorization certificate implemented by a candidate terminal, in accordance with the subject of the present invention.
  • the IP network is managed by a plurality of DNS zones formed by a root DNS server and by intermediate DNS servers, each DNS zone being associated with one of the DNS servers. All DNS zones and servers
  • DNS zones and DNS servers are configured according to a tree of parent DNS zones and girls DNS zones between a zone
  • the candidate terminal T executing this access by connecting to the IP network.
  • the connection to the IP network of the candidate terminal T is carried out via a router R.
  • the DNS servers are noted as a simplification S 0 for the root server and S i for any server of hierarchical rank I represented for the convenience of representation in FIG. 2a on the same line.
  • index k representing a DNS server identifier under the authority of a DNS server noted SM 1 k .
  • any DNS zone Zi -1 , k associated with a DNS server denoted SM, k, is a parent DNS zone, Z D NS P , of a daughter DNS zone, Z D NS C , associated with a noted DNS server. If 1 k-
  • A is allocated a specific private cryptographic value, denoted CV P for the specific private cryptographic value allocated to any DNS zone and to any DNS server.
  • parent respectively denoted CV C for any specific private cryptographic value allocated to any child server associated with a daughter DNS zone.
  • each private cryptographic value allocated to a daughter DNS zone is capable of being authenticated via the private cryptographic value CV P associated with the immediately higher parent DNS zone of the structure. tree.
  • This allocation operation carried out in step A is represented by the symbolic relation (2)
  • each of the DNS servers of the tree structure represented in FIG. 2a thus constitutes a network of confidence allowing, in particular to actually or implicitly reconstruct a chain of trust in controlling the routing of the data packets by successive checks of the different DNS zones via the parent and child DNS servers, as will be described later in the description.
  • the allocation to each parent DNS zone respectively daughter of a specific private cryptographic value is performed only once per network configuration, subject to a cryptographic value change process intended to enhance the network security, as well as it will be described later in the description, to ensure a high level of immunity to any malicious attack for example.
  • the method which is the subject of the present invention then consists, on first access request to the IP network for connection of a candidate terminal T to a router R of the access girl DNS zone, this daughter DNS zone.
  • access can of course be totally any of the DNS zones defined by the tree represented in FIG. 2a, consists in launching from the router R constituting a prospective access router RA, because of the attempt to connect the terminal T to the latter, to launch via the access router RA to at least one of the DNS servers of a parent DNS zone a routing authorization registration procedure represented in step B of FIG. generating and transmitting to the access router RA a routing authorization certificate issued by the parent DNS zone server.
  • the routing authorization certificate consists of a signature value of parameters specific to the access router RA.
  • the value of signature is obtained from the private cryptographic value allocated to the parent DNS zone.
  • connection request sent by the candidate terminal to the router R is denoted a_r (T) and the signature operation for issuing the routing authorization certificate is noted by relation (3)
  • RA Cert
  • step B is then followed by a step C consisting in launching, from the access router RA, a procedure for authenticating the routing authorization certificate by verifying the aforementioned signature value in function.
  • step C consisting in launching, from the access router RA, a procedure for authenticating the routing authorization certificate by verifying the aforementioned signature value in function. the private cryptographic value CVp allocated to the zone
  • the routing authorization registration procedure may consist, at least advantageously, of transmitting in a step B1 to the DNS server of the parent zone an authorization registration request.
  • routing system comprising at least one DNS resource information field associating at least one IP address representative of the IP address of the access router RA and a network path reference to the aforementioned RA access router.
  • step Bi the transmission operation of the authorization registration request is represented by the symbolic relation (5)
  • k designates the anticipated access router that has received the access request from the terminal T, the anticipated access router RA being deemed to be in a DNS access girl zone to which is associated a noted DNS server If 1 k in relation to Figure 2a;
  • - ar_r denotes the routing authorization registration request as such; - S ⁇ -i. k denotes the DNS server of the parent zone Zi -1 , k according to the representation of FIG. 2a.
  • the parameters specific to the router RAP may comprise, as mentioned in the preceding symbolic relation, the IP address representative of the IP address of the access router, address noted RA_ @ IP, and the network path reference to this access router RA, this reference being noted for convenience PATH_RA.
  • Step Bi is then followed by a step B 2 of electronically signing DNA resource information from the private cryptographic value allocated to the parent DNS zone to generate a signature value of the aforementioned DNS resource information.
  • the electronic signature step performed in step B 2 is represented by the symbolic relation (6)
  • RAP denotes the signature value of the DNS resource information, according to the value assigned to it according to the preceding relation (5);
  • CV i- I denotes the actual electronic signature operation of the aforementioned DNS resource information from the private cryptographic value CVn allocated to the parent DNS zone associated with the parent DNS server of hierarchical position 1-1.
  • step B 2 is then followed by a step B 3 of transmitting the signature value of the aforementioned DNS resource information to the aforementioned access router RA mentioned above.
  • SM, k denotes the parent DNS server associated with the parent DNS zone holding the private cryptographic value CVn which made it possible to execute the signature operation in step B2 previously described.
  • the authentication procedure of the routing authorization certificate of step C of FIG. 1 may advantageously consist of transmitting at least one step Ci through the access router to the candidate terminal T the DNS resource information noted RAP and, of course, the signature value of the information of DNS resources, the aforementioned signature value being denoted SV (RAP), all of this information constituting in fact the certificate of authorization of routing.
  • step Ci The transmission operation of step Ci is represented by the symbolic relation (8)
  • step C 1 is then followed by a step C 2 of electronically verifying the signature value of the DNS resources as a function of the private cryptographic value allocated to the parent DNS zone.
  • step C 2 the signature verification operation of step C 2 is represented by the symbolic relation (9)
  • V (CVM ) VKP 1-1 , k )
  • V (cv ⁇ - 1) (SV (RAP)) refers to the signature verification operation of the SV signature value (RAP) as a function of the cryptographic value CV 1 - 1 used to execute the signature operation in step B 2 of FIG. 2b.
  • the signature operation executed in step B 2 of FIG. 2b previously mentioned is carried out directly from the private cryptographic value CVn while the signature verification operation carried out at step C 2 is performed according to this private cryptographic value, as will be described later in the description.
  • the previously mentioned private cryptographic value can be used for the signature verification or signature verification operations previously described in the description as part of a symmetric encryption-decryption process, for example.
  • the use of a symmetric encryption-decryption process implies a management of the transmission of the encryption keys - decryption, that is to say the aforementioned private cryptographic value relatively heavy, this process of managing keys requiring in particular the transmission of the key values in encrypted form.
  • the method that is the subject of the present invention can instead be implemented, in a preferred embodiment, by means of a private cryptographic value specific and constituted by a secret key held by the parent DNS zone and the DNS server associated therewith.
  • the private cryptographic value CVM is then constituted by a secret key KSM, k , this secret key being held in a secure zone of the parent DNS server and used to electronically sign the DNS resource information to obtain the signature value of the DNS resource information.
  • the private cryptographic value is also constituted by a public key associated with the aforementioned secret key and freely available.
  • the public key associated with the aforementioned secret key is denoted KPM 1k and is used to electronically verify the signature value DNS resource.
  • the secret and public keys allocated to each DNS server and associated with each DNS zone may, in a particularly advantageous manner, correspond to the secret and public keys allocated to these servers as part of the RFC 3008 (IETF) recommendation "Domain Name System Security Signing Authority "(OHSsec), B. Wellington, 2000.
  • step C 2 of FIG. 2c the signature verification operation as a function of the previously mentioned private cryptographic value is then noted.
  • This public key is then advantageously used to electronically verify the signature value of the aforementioned DNS resources.
  • the implementation of a private cryptographic value constituted by a secret key to which a public key is associated thus makes it possible to reduce the process of management of the cryptographic values mentioned above and in particular public keys, which, by definition, are available freely and can of course be freely transmitted.
  • the key management process is thus greatly simplified because it is then substantially limited to a time change program secret keys allocated to each of the DNS servers associated with each parent DNS zone or corresponding daughter.
  • signature signature verification or execution operations performed for the implementation of the method that is the subject of the present invention can then be performed from a signature verification or signature verification process executed by means of the RSA algorithms.
  • RSA algorithms for example, Rivest Shamir and Adleman algorithms or via the DSA algorithm for Digital Signature Algorithm.
  • Rivest Shamir and Adleman algorithms or via the DSA algorithm for Digital Signature Algorithm.
  • the aforementioned algorithms are software-driven algorithms known in the state of the art which, for this reason, will not be described in detail.
  • the implementation of the method that is the subject of the present invention by means of a signature-verification process of signature from asymmetric keys, secret keys and public keys appears particularly advantageous insofar as, prior to each operation signature verification, as represented in FIG. 2d, by means of the public key associated with the private key associated with each daughter or parent DNS zone, a procedure for authentication of the public key by a signature request of this public key to the means of the parent private key, to the DNS server managing the parent DNS zone and holding the parent private key, and then checking by the candidate terminal T of the signed value of this public key by means of the parent public key, can, in a manner advantageous, to be realized.
  • Such a process is described in connection with FIG.
  • the operation C 22 can then be followed, after transmission of the aforementioned signature value to the candidate terminal, of an operation C 23 for verifying the signature value of this public key by means of the parent public key, this operation of verification being executed by the candidate terminal T which, of course, holds the aforementioned public key.
  • step C 23 of FIG. 2d This operation is represented in step C 23 of FIG. 2d by the symbolic relation (11) k ))
  • the method which is the subject of the present invention can be implemented, on the first connection and access attempt of a candidate terminal T, by the prospective access router RA, which then transmits the DNS resource information from the corresponding parent DNS server as previously described in the description.
  • the routing authorization registration request can be made once and for all when the router is inserted on the network. When a terminal subsequently connects to this router, the latter simply transmits an access request to these registration data for example.
  • the implementation of the method that is the subject of the present invention is not limited to the implementation example mentioned above.
  • the authentication process can be directly implemented from the candidate terminal T, the signing operation of the DNS resources of the prospective access router RA can then be executed on the initiative of the terminal T, the router simply passing the DNS resource information specific to it to the DNS server associated with the access girl DNS zone.
  • the method that is the subject of the invention can then be implemented from the latter and from the DNS server associated with it.
  • the public key authentication process as described in connection with FIG. 2d can then be implemented vis-à-vis the parent DNS server of the parent DNS zone associated with the daughter DNS zone. corresponding access.
  • the relationship or chain of trust is established between the candidate terminal T and any intermediate DNS server, where appropriate the root server, because of the issuance of the certificate of authorization of routing, which constitutes an authorization by any intermediary parent DNS server, including, where appropriate, the root server, for any access router R likely to constitute a prospective access router RA among a set of routers intended to exercise their routing function.
  • Any prospective access router is then able to obtain from any intermediate DNS server or from the root DNS server a routing authorization certificate, which is then authenticated under the authority of the root DNS server by the candidate terminal T.
  • the method that is the subject of the invention consists in transmitting from the access router to a parent DNS server a single request for registration of routing authorization.
  • the above-mentioned step corresponds to step Bi of FIG. 2b, the corresponding operation being represented by the symbolic relation (5), it being specified however that the single request is denoted uar_r (RAP).
  • step B 2 i is then followed by a step B 22 of transmitting, from the parent DNS server to any hierarchically superior parent DNS server to the parent DNS server mentioned above, to the parent root DNS server, for example, requests successive communication of the public key and the separate signature value of this public key by means of the secret key associated with and respectively held by each of the hierarchically higher intermediate parent DNS servers.
  • FIG. 3 shows, by way of non-limiting example, the operations of successive transmission of the communication requests of the public key, a request designated ukp_r (*) between any DNS server of a DNS access girl zone, denoted Si -1, k , and any hierarchically higher intermediate parent server of rank m and noted for this reason S m , k , this successive communication request being followed by a response denoted aukp_r (KP m , k ; SV (KP m , k )) -
  • the communication request transmission operations of the public key and the separate signature value of this public response key allowing the communication of these values are represented by the symbolic relation (12)
  • a test step B 222 is then executed on the count variable of the rank m, the transmission of the key communication requests being continued via the test B 222 for comparing the count value m to the value 0 by comparison.
  • KP m _ k represents the public key associated to the DNS server including the hierarchical position corresponds to the counting variable m and SV (KP m, k) designates the signature value of this public key using the private key of the aforementioned DNS server.
  • a step B 23 is carried out. a process of aggregating, in a single message, the value of the public keys received and the public key of the parent DNS server and the corresponding signature values SV (KP m , k ).
  • parent DNS server is the DNS server that manages the RA access router.
  • the aggregation operation consists, for example, in an operation of constituting a list of received public key values, this operation being represented symbolically by the relation (13)
  • Operation B 23 is followed by operation B 24 of calculating the signature value of the DNS resource information by means of the secret key associated with the DNS zone. parent and of course the parent DNS server
  • the aforementioned signature operation corresponds to that carried out in step B 2 of FIG. 2b from the secret key KSi _ 1, k associated with the DNS server S ⁇ _i, k.
  • Step B 24 above can then be followed by a step B 25 substantially corresponding to the step B3 of Figure 2b described above.
  • the aforementioned step B 25 consists in transmitting to the candidate terminal T the value of the aggregated public keys via the unique message UM ( " ), the separate signature value of each of the aggregated public keys, these signature values being noted [SV (KP m , k )] as well as, of course, the signature value of DNS resource information, SV (RAP).
  • the previously mentioned signature values constitute the routing authorization certificate made available to the preselected terminal T.
  • step B 25 The operation performed in step B 25 is represented by the symbolic relationship (14)
  • step B2 5 it is indicated that the aforementioned transmission is performed to the candidate terminal T via the access router RA sensed.
  • the candidate terminal T After receiving the routing certificate by the candidate terminal T, that is to say subsequent to step B 25 above, the candidate terminal T then proceeds to check each of the separate signature values each transmitted public key, in step C21.
  • the operation is performed by a test step represented symbolically by the relation (15)
  • the value of the public key associated with the parent DNS zone and the parent server S ⁇ 1, k , as well as implicitly the value of the secret key held by the parent DNS server, and of course any intermediate public key to the public key associated with the root DNS server are authenticated under the authority of the latter.
  • the root DNS server S 0 is of course invested, by definition, the maximum confidence for any candidate terminal performing an access attempt. This trust is of course justified inasmuch as it is almost certain that the root DNS server is a general network management server which, as such, has the strongest protections and the maximum guarantee of legitimacy and security. integrity of the performance of its functions.
  • the root DNS server makes it possible, of course, to authenticate all the branches of the trusted network represented in FIG. 2a, and in particular any router managed by the intermediary DNS servers previously described in the description. As all the meshes of the aforementioned network are thus secured, any chain of trust involving any path from the routing branches managed by the corresponding intermediate DNS servers is therefore authenticated under the authority of the root DNS server.
  • step C 24 of FIG. 3 corresponds globally to the actual execution of the authentication of the certificate Cert (RA) represented in FIG.
  • a return to the step Bi can be executed for communication or new communication of this key.
  • security in number of communication requests for a parent DNS server of a given hierarchical rank can be introduced in order to limit the corresponding attempts.
  • the DNS servers conforming to the subject of the present invention are BIND type servers, such servers having software modules and being most commonly used for the deployment of DNS architectures on the IP network, especially on the Internet.
  • Such DNS servers and corresponding software have tools that meet the DNSsec recommendation to regulate security module developments for DNS architectures.
  • the configuration of the latter is performed from routing DNS resource declaration data structures stored in the memory areas of the DNS server.
  • These data structures, files, comprise data structures elementary definition of a given DNS domain according to the representation of the table below.
  • the access router RA presenti can address any DNS server with which it has a relationship of trust.
  • the relationship of trust means a frequent relationship by successive transactions and verification of the public key value by authentication of the public key associated with the aforementioned DNS server, as shown in connection with FIG. 2d for example.
  • the RA server may transmit a request using a RR type DNS field for "Resource Record" in English which contains the list of prefix network prefixes 2, ie the value PATH_RA of Figure 2b for example, network prefixes for which it is authorized to legitimately perform its function of routing data packets.
  • the DNS server Su, k signs the corresponding DNS resource information and sends back to the router RA the signature of this information using a RR SIG field with or without the public key value, depending on whether the access router knows or not. the value of the latter.
  • the routing authorization notification is saved in a zone
  • DNS determined. Depending on the DNS server Sn 1k , it may be registered in a pre-existing zone or in a specific zone in which the server registers all the routing permissions.
  • the authentication request declaration of a registered routing DNS resource for executing this declaration on a DNS server such as the SM server 1 k of FIG. 4a comprises a data elementary structure comprising a first data field representative of the IP address of the routing DNS resource, address @ IP2 in FIG. 4a and in FIG.
  • FI field a second field coding the type of registration required for this DNS resource, that is to say the type arbitrarily designated by PX in field F2 of FIG. 4b coding the type of record, type designating a registration request d routing authorization for the DNS resource at the address specified in field F 1 and a third field F 3 field representative of network access address information of DNS routing resource allowing the routing of the data packets by the routing function legitimately executed by the routing DNS resource, that is to say the router RA 2 .
  • the address information is designated prefix 2 in Figure 4a and Figure 4b.
  • the declaration data structure of a routing DNS resource stored in the memory zone of a DNS server indicated in the aforementioned table naturally includes the basic data structures for defining the domain.
  • the aforementioned DNS, as well as specific elementary data structures comprising at least the request authentication request elementary declaration data structure of a DNS resource according to FIG. 4b.
  • This data structure is represented in the aforementioned figure, which of course contains the elementary data structure of the DNS routing resource authentication request declaration of FIG. 4a.
  • the aforementioned data structure further comprises specific elementary data structures comprising at least one elementary data structure of address and a data structure of junction of definitions of the DNS zones. , these data structures characterized by their field F 2 corresponding to the SIG field, respectively NXT for the aforementioned junction data structure.
  • the program product Upon reception by the candidate terminal T of the DNS resource information noted RAP and the signature value of the latter noted SV (RAP) in step 100 of FIG. 5, the program product comprises at least one sub-module.
  • SP1 program discriminates the knowledge by the candidate terminal of the public key of the DNS zone and the parent DNS server that has executed the calculation operation of the signature value of these DNS resources. This operation of discriminating the knowledge of the aforementioned public key is represented by a test 101 verifying the relation (16) KP m , k ⁇ 0?
  • a module SP 2 subprogram is called, which allows to ensure the transmission to the parent DNS server previously cited of a communication request message of any public key accompanied by a signature value of this public key by means of the secret key held by the parent DNS server.
  • the aforementioned step 102 is a step similar to step B22 of FIG. 3, the public key communication request messages ukp_r ( " ) and the response to this public key communication request aukp_r ( " ) being able to present the same form as in the case of the implementation of step B2 2 of Figure 3 above.
  • an SP3 program module follows reception of the public key and the signature value of this corresponding public key, an SP3 program module makes it possible to check the signature value of any public key received in the previous step 102, including the public key associated with the DNS access girl zone due to the fact that the protocol is driven by the terminal T.
  • step 103 of FIG. 5 the verification operation of the signature value is noted according to the same relationship as that indicated previously in the description in step C 21 of FIG. 3.
  • a procedure similar to that described above in the description in connection with FIG. 2d can be executed, it being specified that the public key KPM 1 R has been authenticated, either on particular knowledge of the value of this public key and sufficient confidence of the candidate terminal in negative response to test 101 previously described.
  • the public key KPi. k can then be authenticated from the secret key KS M , k of the DNS server associated with the corresponding access girl DNS zone, as described previously with FIG. 2d.
  • the terminal T further comprises a subroutine module SP 4 verification of the signature value of DNS resources with the key associated with the parent DNS server and the parent DNS zone, SM, k .
  • the subroutine module SP 4 makes it possible to carry out a signature verification operation represented symbolically by the same relation as the relation of the step C 23 of FIG. 2d, for example.
  • step 106 is provided with an authenticated Cert (RA) certificate.
  • RA Cert
  • the terminal T then has a subroutine module SP 5 for confirming the access router RA as the default access router for the connection and access of the candidate terminal T to the IP network.
  • step 107 of FIG. 5 the confirmation relation of the access router selected RA as the default access router is represented by the symbolic relation.
  • the subroutine module SP 4 allows the call of a display module SP 6 to display on the candidate terminal T a warning message WM informing the user.
  • the user of the candidate terminal T risks due to the non-compliance of the transmission of data to the security criteria of the transaction.

Abstract

L'invention concerne un procédé d'authentification de la découverte de voisinage réseau IP d'un terminal (T). On alloue (A) à chaque zone DNS parente respectivement fille une valeur cryptographique privée spécifique (CVP, CV0) chaque valeur (CVC) d'une zone DNS fille pouvant être authentifiée par la valeur (CVp) de la zone DNS parente. Sur première requête d'accès d'un terminal (T) au réseau IP on lance (B) à partir du routeur d'accès (RA) de la zone d'accès fille une procédure d'enregistrement d'autorisation de routage permettant de délivrer par le serveur DNS de zone DNS parente un certificat de routage (Cert(RA)) et on lance (C) à partir du routeur d'accès (RA) une procédure d'authentification du certificat de routage ?(Cert(RA)), en fonction de la valeur cryptographique privée allouée à la zone DNS parente. Application à la sécurisation des connexions de terminaux fixes ou mobiles sur le réseau IP ou Internet.

Description

Procédé d'authentification de la découverte de voisinage de l'environnement réseau IP d'un terminal candidat à un accès réseau L'invention est relative à un procédé d'authentification de la découverte de voisinage de l'environnement réseau IP d'un terminal candidat à un accès réseau.
Lorsqu'un terminal, mobile ou fixe, se connecte sur un réseau IP, en particulier le réseau Internet, ce dernier est amené à entrer en communication avec les équipements réseau permettant d'acheminer par routage les données numériques support de la transaction. Dans les réseaux IP actuels, gérés par le protocole IPv6, ce protocole permet de gérer la mobilité des terminaux nomades susceptibles de se connecter à ces derniers.
Lorsque, en particulier, un terminal mobile ou fixe change de point d'attachement, ce dernier, dans le cadre du protocole précité, met en œuvre une procédure de découverte de réseau sur le lien local, procédure désignée par procédure de découverte de voisinage de l'environnement, appelée "Neighbor
Discovery" en anglais.
La procédure précitée fait l'objet de la recommandation IETF référencée RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) éditée par T. Narten, E. Nordmark et W. Simpson, décembre 1998.
La procédure précitée s'applique aussi bien à tout terminal nomade, encore désigné nœud mobile, en visite sur un réseau de visite qu'à des terminaux fixes qui se connectent sur ce réseau.
Elle permet notamment au terminal, mobile ou fixe, candidat à un accès, ci-après désigné terminal candidat, de collecter des informations, telles que préfixe réseau sur le lien local, adresse de routeur disponible ou autres, qui lui permettront de s'auto-configurer en vue d'exécuter automatiquement la connexion.
Dans ce but, le terminal candidat décode les informations de type préfixe réseau, contenues dans des messages d'annonces émis dans le réseau de visite auprès duquel l'accès est sollicité. Il mémorise en outre l'adresse IP du routeur émetteur, routeur RA d'accès au réseau, et met ainsi à jour ses chemins de communication pour maintenir les sessions IP en cours, en empruntant cette nouvelle route. La procédure précitée, telle qu'elle est établie à l'heure actuelle, n'est pas sécurisée. En particulier, aucune procédure de vérification d'habilitation des routeurs, notamment du routeur d'accès, à exécuter leur fonction de routage n'est prévue. De fait, il n'est aucunement envisageable, actuellement, au terminal candidat précité de découvrir avec un caractère de certitude quels sont les équipements réseaux, en particulier les routeurs, qui sont autorisés à router les données sur le réseau de visite, c'est-à-dire à recevoir et acheminer vers le noeud de réseau adéquat les paquets de données des terminaux que le réseau de visite accueille.
L'utilisateur du terminal candidat ne peut donc, en aucun cas, être protégé des équipements malveillants ou pirates qui sont en particulier susceptibles d'être connectés sur le réseau de visite, dans le but d'usurper la qualité d'équipement légitime ou autorisé et de dérouter le trafic des données, afin de permettre le vol d'information ou de modifier le trafic de données.
Dans le but de remédier à l'inconvénient précité, par vérification de l'habilitation et de la légitimité du routeur d'accès, un développement préconisé par le groupe de travail IETF appelé Secuήng Neighbor Discovery a fait l'objet d'un texte de normalisation appelé SEND, pour SEcure Neighbor Discovery, référencé draft-ietf-send-ndopt-06, draft IETF, publié par J. Arkko, J. Kempf, B. Sommerfeld, B. ZiII et P. Nikander.
Le développement précité tente de sécuriser ces échanges en utilisant une infrastructure de gestion de clé (PKI).
En particulier, le texte de normalisation précité introduit l'utilisation de certificats X 509 et spécifie que le routeur d'accès envoie au terminal candidat un certificat qui prouve que le routeur d'accès pressenti est autorisé à router les paquets de données pour un préfixe réseau donné.
Pour que le terminal candidat soit lui-même en mesure de vérifier ce certificat, il est toutefois nécessaire que le routeur d'accès transmette à ce dernier une chaîne de certificats.
La validation de l'autorisation de routage accordée au routeur d'accès pressenti par l'intermédiaire d'une chaîne de certificats pose les problèmes techniques délicats ci-après, dans de nombreux cas. - Les routeurs du réseau de visite doivent tous être configurés avec une paire de clés et un certificat provenant d'au moins une autorité de certification.
- Dans le cas général, le terminal candidat ne connaît pas le certificat racine de la chaîne de certificats constituant une chaîne de confiance, envoyée par le routeur d'accès, ce qui rend la solution proposée inopérante. Pour que le terminal candidat puisse valablement vérifier la chaîne de confiance précitée, il apparaît en effet nécessaire qu'il dispose de tous les certificats racines de tous les opérateurs réseau, tels que opérateurs de télécommunications, fournisseurs d'accès, hot spots publics ou privés ou autres. En particulier, dans le cas de terminaux candidats mobiles, les possibilités de connectivité sont trop importantes en raison de la diversité des types de réseaux et des opérateurs acteurs rencontrés lors d'une connexion pour que le terminal candidat mobile précité soit en mesure de stocker tous les certificats racines possibles. Une solution à la contrainte majeure précitée pourrait consister à obtenir que tous les opérateurs réseau adoptent la même autorité de certification. Une telle solution est hautement improbable.
Enfin, si le terminal candidat ne dispose que d'une seule interface de connexion active mais s'il ne dispose pas du certificat racine, tous les paquets de données passent par le routeur non authentifié dont le terminal candidat ne peut solliciter valablement la vérification, car les résultats peuvent être modifiés ou altérés par ce routeur si celui-ci est un routeur malveillant.
En l'absence de vérification de la chaîne de confiance précitée, le terminal candidat ne dispose d'aucune certitude quant à l'authenticité et à la légitimité de la fonction de routage exercée par le routeur pressenti.
La présente invention a pour objet de remédier aux inconvénients des techniques et développements de l'art antérieur.
En particulier, un objet de la présente invention est la mise en œuvre d'un procédé d'authentification de vérification de la légitimité d'un équipement, tel qu'un routeur, à assurer les fonctions de routage de paquets de données à partir de l'infrastructure de nom de domaines associée au réseau IP, en l'absence
- d'introduction de toute modification du terminal candidat ;
- de contrainte, pour chacun des routeurs, de posséder un certificat émanant d'une autorité de certification. Un autre objet de la présente invention est également la mise en œuvre d'un procédé d'authentification ou de vérification de la légitimité d'un équipement, tel qu'un routeur, en tirant parti de l'architecture DNS des serveurs
DNS gérant les zones DNS du réseau IP, permettant de certifier et vérifier les autorisations des routeurs sur les réseaux d'accès.
Un autre objet de la présente invention est également la communication, réelle ou virtuelle, par un routeur d'accès pressenti, de la chaîne de confiance représentée par l'autorisation de routage délivrée à ce routeur d'accès pressenti, à tout terminal candidat pour acceptation. Un autre objet de la présente invention est enfin la mise en œuvre d'un procédé d'authentification ou de vérification de la légitimité d'un équipement, tel qu'un routeur, en tirant parti de l'architecture DNS des serveurs DNS gérant les zones DNS des réseaux IP, permettant à tout routeur d'accès pressenti de s'enregistrer pour authentification auprès de tout serveur DNS auprès duquel il est hiérarchiquement soumis.
Le procédé d'authentification de la découverte de voisinage de l'environnement réseau IP d'un terminal candidat à un accès réseau, objet de la présente invention, s'applique à tout réseau IP géré par une pluralité de zones DNS formées par un serveur DNS racine et par des serveurs DNS intermédiaires, chaque zone DNS étant associée à l'un des serveurs DNS, ces zones et ces serveurs DNS étant configurés selon une arborescence de zones DNS parentes et de zones DNS filles entre une zone DNS racine et une zone DNS fille d'accès, à partir de laquelle ce terminal candidat exécute cet accès par connexion au réseau IP. En outre, à chaque zone DNS, parente respectivement fille, est allouée une valeur cryptographique privée spécifique, chaque valeur cryptographique privée allouée à une zone DNS fille étant susceptible d'être authentifiée par l'intermédiaire de la valeur cryptographique privée associée à la zone DNS parente immédiatement supérieure de cette structure arborescente. II est remarquable en ce que, sur première requête d'accès au réseau
IP par connexion d'un terminal candidat à un routeur de la zone DNS fille d'accès, ce routeur constituant un routeur d'accès, il consiste en outre à lancer à partir du routeur d'accès vers l'un au moins des serveurs DNS d'une zone DNS parente une procédure d'enregistrement d'autorisation de routage, permettant d'engendrer et transmettre au routeur d'accès un certificat d'autorisation de routage délivré par le serveur de zone DNS parente et consistant en une valeur de signature de paramètres spécifiques à ce routeur d'accès, cette valeur de signature étant obtenue à partir de la valeur cryptographique privée allouée à la zone DNS parente, puis, à lancer via le routeur d'accès une procédure d'authentification du certificat d'autorisation de routage par vérification de la valeur de signature en fonction de la valeur cryptographique privée allouée à la zone DNS parente.
De préférence, la valeur cryptographique privée spécifique est constituée par une clé secrète détenue par la zone DNS parente et le serveur
DNS associé à celle-ci, cette clé secrète étant utilisée pour signer électroniquement les informations de ressource DNS et obtenir la valeur de signature des informations de ressources DNS, et par une clé publique associée à cette clé secrète et librement disponible, cette clé publique étant utilisée pour vérifier électroniquement la valeur de signature des ressources DNS.
Le procédé objet de la présente invention trouve application à la sécurisation des transactions ou protocoles d'échange de données en réseau IP pour tout type de terminal accédant, sur connexion, à de tels réseaux.
Il sera mieux compris à la lecture de la description et à l'observation des dessins ci-après, dans lesquels :
- la figure 1 représente, à titre illustratif, un organigramme des étapes essentielles de mise en œuvre du procédé objet de la présente invention ;
- la figure 2a représente, à titre illustratif, une représentation graphique de l'étape d'allocation à chaque zone DNS, parente ou fille, d'une valeur cryptographique privée spécifique, représentée en figure 1 ;
- la figure 2b représente, à titre illustratif, un organigramme détaillé des étapes de mise en oeuvre de la procédure d'enregistrement de routage représentée en figure 1 ;
- la figure 2c représente, à titre illustratif, un organigramme détaillé des étapes de mise en oeuvre de la procédure d'authentification du certificat d'autorisation de routage représentée en figure 1 ;
- la figure 2d représente, à titre illustratif, un processus d'authenti¬ fication de clé publique associée à la clé privée détenue par chaque serveur DNS ; - la figure 3 représente, à titre illustratif, un organigramme des étapes essentielles de mise en oeuvre préférentiel du procédé objet de l'invention dans une version optimisée du point de vue du volume de trafic nécessaire à la mise en oeuvre de ce dernier sur le réseau IP visité ; - la figure 4a représente, à titre illustratif, une configuration réseau particulier et une structure de données élémentaire de déclaration de requête d'authentification d'une ressource DNS de routage, conformément au procédé objet de la présente invention ;
- la figure 4b représente, à titre illustratif, une structure de données de déclaration d'une ressource DNS de routage enregistrée en mémoire d'un serveur DNS comportant des structures de données élémentaires de définition d'une zone DNS donnée, en particulier une structure de données élémentaire de déclaration de requête d'authentification d'une ressource DNS telle qu'illustrée en figure 4a ; - la figure 5 représente, à titre illustratif, un organigramme d'un protocole interne préférentiel, non limitatif, de vérification du certificat d'autorisation de routage mis en œuvre par un terminal candidat, conformément à l'objet de la présente invention.
Une description plus détaillée du procédé d'authentification de la découverte de voisinage de l'environnement réseau IP d'un terminal candidat à un accès réseau, conforme à l'objet de la présente invention, sera maintenant donnée en liaison avec la figure 1 et les figures suivantes.
D'une manière générale, en référence avec la figure 2a, on rappelle que Ie réseau IP est géré par une pluralité de zones DNS formées par un serveur DNS racine et par des serveurs DNS intermédiaires, chaque zone DNS étant associée à l'un des serveurs DNS. L'ensemble des zones DNS et des serveurs
DNS est noté (1)
[Z DNS1 SDNS 1 J o
Les zones DNS et les serveurs DNS sont configurés selon une arborescence de zones DNS parentes et de zones DNS filles entre une zone
DNS racine et une zone DNS fille d'accès du terminal candidat, le terminal candidat T exécutant cet accès par connexion au réseau IP. La connexion au réseau IP du terminal candidat T est effectuée par l'intermédiaire d'un routeur R. En référence à la figure 2a, on indique que les serveurs DNS sont notés à titre de simplification S0 pour le serveur racine et S^ pour tout serveur de rang hiérarchique I représenté par commodité de représentation sur la figure 2a sur une même ligne, l'indice k représentant un identifiant de serveur DNS sous l'autorité d'un serveur DNS noté SM 1 k.
Ainsi, toute zone DNS Zi-1, k, associée à un serveur DNS noté SM, k, est une zone DNS parente, ZDNSP, d'une zone DNS fille, ZDNSC, associée à un serveur DNS noté Si1 k-
La notation précédente est valable quel que soit le rang hiérarchique du serveur DNS considéré et de la zone DNS associée à ce dernier.
En outre, à chaque zone DNS parente respectivement fille, zone ZDNSP respectivement ZDNSC, est allouée, A, une valeur cryptographique privée spécifique, notée CVP pour la valeur cryptographique privée spécifique allouée à toute zone DNS et à tout serveur DNS parent, respectivement notée CVC pour toute valeur cryptographique privée spécifique allouée à tout serveur fils associé à une zone DNS fille.
Ainsi, en relation avec les figures 1 et 2a, on indique que : CVp = CVM , k CVc = CVi, k. Selon un aspect remarquable du procédé objet de la présente invention, chaque valeur cryptographique privée allouée à une zone DNS fille est susceptible d'être authentifiée par l'intermédiaire de la valeur cryptographique privée CVP associée à la zone DNS parente immédiatement supérieure de la structure arborescente. Cette opération d'allocation réalisée à l'étape A est représentée par la relation symbolique (2)
(ZDNSPI ZDNSC) ^""^ (CVp, CV0)
^cvP (CVc) = vraie
Dans la relation précédente, on indique que l'égalité ^cvP (CVC) = vraie désigne l'opération d'authentification réussie de chaque valeur cryptographique privée allouée à une zone DNS fille par l'intermédiaire de la valeur cryptographique privée associée à la zone DNS parente immédiatement supérieure de la structure arborescente. Le processus d'authentification précité représenté par l'égalité précédente peut, de manière avantageuse, être mis en œuvre à partir de tout processus de signature, vérification de signature par exemple de la valeur cryptographique fille CV0 au moyen d'un algorithme de signature, vérification de signature paramétré par la valeur cryptographique privée CVP associée à la zone DNS et au serveur DNS parent.
En raison de l'allocation de chaque valeur cryptographique privée spécifique, chacun des serveurs DNS de la structure arborescente représentée en figure 2a, selon un aspect particulièrement remarquable du procédé objet de la présente invention, on constitue ainsi un réseau de confiance permettant, en particulier, de reconstituer réellement ou implicitement une chaîne de confiance dans le contrôle du routage des paquets de données par contrôles successifs des différentes zones DNS par l'intermédiaire des serveurs DNS parents et fils, ainsi qu'il sera décrit ultérieurement dans la description. Bien entendu, l'allocation à chaque zone DNS parente respectivement fille d'une valeur cryptographique privée spécifique est réalisée une seule fois par configuration réseau, sous réserve d'un processus de changement de valeur cryptographique destiné à renforcer la sécurité réseau, ainsi qu'il sera décrit ultérieurement dans la description, afin d'assurer une immunité de haut niveau à toute attaque malveillante par exemple.
Compte tenu des éléments précités, le procédé objet de la présente invention consiste alors, sur première requête d'accès au réseau IP pour connexion d'un terminal candidat T à un routeur R de la zone DNS fille d'accès, cette zone DNS fille d'accès pouvant bien entendu être totalement quelconque parmi les zones DNS définies par l'arborescence représentée en figure 2a, consiste à lancer à partir du routeur R constituant un routeur d'accès pressenti RA, du fait de la tentative de connexion du terminal T à ce dernier, à lancer via le routeur d'accès RA vers l'un au moins des serveurs DNS d'une zone DNS parente une procédure d'enregistrement d'autorisation de routage représentée à l'étape B de la figure 1 , afin d'engendrer et transmettre au routeur d'accès RA un certificat d'autorisation de routage délivré par le serveur de zone DNS parente.
Selon un aspect particulièrement remarquable du procédé objet de la présente invention, le certificat d'autorisation de routage consiste en une valeur de signature de paramètres spécifiques au routeur d'accès RA. La valeur de signature est obtenue à partir de la valeur cryptographique privée allouée à la zone DNS parente.
Sur la figure 1 à l'étape B de celle-ci, la requête de connexion lancée par le terminal candidat auprès du routeur R est notée a_r(T) et l'opération de signature permettant de délivrer le certificat d'autorisation de routage est notée par la relation (3)
Cert(RA) = SCvP(RAP)
Dans cette relation,
- RAP désigne les paramètres spécifiques au routeur d'accès RA ; - Scvp désigne l'opération de signature proprement dite de ces paramètres ;
- Cert(RA) désigne le certificat d'autorisation de routage obtenu par l'opération de signature précitée.
L'opération de l'étape B est alors suivie par une étape C consistant à lancer, à partir du routeur d'accès RA, une procédure d'authentification du certificat d'autorisation de routage par vérification de la valeur de signature précitée en fonction de la valeur cryptographique privée CVp allouée à la zone
DNS parente.
L'opération d'authentification du certificat d'autorisation de routage, est représentée par la relation symbolique (4) JZL(Cert (RA)) = T(S0Vp (RAP)) Dans la relation précédente :
- 'V(5cvp(RAP)) désigne l'opération de vérification de la valeur de signature précitée ; - Λ(Cert(RA)) désigne l'opération d'authentification du certificat d'autorisation de routage.
On comprend, en particulier, que, sur authentification réussie du certificat d'autorisation de routage précité, la connexion du terminal T au routeur d'accès RA peut être validée en toute sécurité, ainsi qu'il sera décrit ultérieurement dans la description.
Une description plus détaillée des procédures d'enregistrement de routage respectivement d'authentification du certificat d'autorisation de routage des étapes B et C de la figure 1 sera maintenant donnée en liaison avec les figures 2b, 2c et 2d.
En référence à la figure 2b, on indique que la procédure d'enregistrement d'autorisation de routage peut consister au moins, de manière avantageuse, à transmettre en une étape B1 au serveur DNS de la zone parente une requête d'enregistrement d'autorisation de routage comportant au moins un champ d'information de ressources DNS associant au moins une adresse IP représentative de l'adresse IP du routeur d'accès RA et une référence de chemin d'accès réseau au routeur d'accès RA précité. A l'étape Bi, l'opération de transmission de la requête d'enregistrement d'autorisation est représentée par la relation symbolique (5)
PJ "r _r (RAP) „
^U k > ύl-l, k
RAP = RA _@IP, PATH _RA Dans la relation précédente, on indique que :
- RAi, k désigne le routeur d'accès pressenti qui a reçu la demande d'accès du terminal T, le routeur d'accès RA pressenti étant réputé se trouver dans une zone DNS fille d'accès à laquelle est associé un serveur DNS noté Si1 k en relation avec la figure 2a ;
- ar_r(RAP) désigne la requête d'enregistrement d'autorisation de routage en tant que telle ; - Sμ-i. k désigne le serveur DNS de la zone parente Zi-1, k selon la représentation de la figure 2a.
D'une manière générale, on indique que les paramètres spécifiques au routeur RAP peuvent comprendre, ainsi que mentionné dans la relation symbolique précédente, l'adresse IP représentative de l'adresse IP du routeur d'accès, adresse notée RA_@IP, et la référence de chemin d'accès réseau à ce routeur d'accès RA, cette référence étant notée par commodité PATH_RA.
En ce qui concerne la référence de chemin d'accès réseau au routeur d'accès RA, on indique que cette référence de chemin d'accès peut avantageusement consister en la collection de toutes les adresses d'accès au routeur d'accès RA connectées en réseau et permettant à ce dernier d'exécuter sa fonction légitime de routage, ainsi qu'il sera décrit ultérieurement dans la description. L'étape Bi est alors suivie d'une étape B2 consistant à signer électroniquement des informations de ressources DNA à partir de la valeur cryptographique privée allouée à la zone DNS parente, pour engendrer une valeur de signature des informations de ressources DNS précitées. L'étape de signature électronique réalisée à l'étape B2 est représentée par la relation symbolique (6)
Scγι _j (RA _@ IP, PATH _ RA) > SV{RAP)
I*? - <?
VCVl-I ~ KSl-I, k
Dans la relation symbolique précédente on indique que :
- SV(RAP) désigne la valeur de signature des informations de ressources DNS, selon la valeur attribuée à celle-ci selon la relation (5) précédente ;
- 51 CVi-I désigne l'opération proprement dite de signature électronique des informations de ressources DNS précitées à partir de la valeur cryptographique privée CVn allouée à la zone DNS parente associée au serveur DNS parent de position hiérarchique 1-1.
Enfin, l'étape B2 est alors suivie d'une étape B3 consistant à transmettre la valeur de signature des informations de ressources DNS précitées au routeur d'accès pressenti RA précédemment cité.
Cette opération est représentée à la figure 2b par la relation symbolique (7)
SV(RAP) v SM1 k ~~ * RA
Dans la relation précédente, SM, k désigne le serveur DNS parent associé à la zone DNS parente titulaire de la valeur cryptographique privée CVn qui a permis d'exécuter l'opération de signature à l'étape B2 précédemment décrite.
En référence à la figure 2c on indique que la procédure d'authentification du certificat d'autorisation de routage de l'étape C de la figure 1 peut avantageusement consister au moins à transmettre en une étape Ci, via le routeur d'accès, au terminal candidat T les informations de ressources DNS notées RAP et, bien entendu, la valeur de signature des informations de ressources DNS, la valeur de signature précitée étant notée SV(RAP), l'ensemble de ces informations constituant en fait le certificat d'autorisation de routage.
L'opération de transmission de l'étape Ci est représentée par la relation symbolique (8)
^ RAP9 SV(RAP)) > τ
Cert(RA) = (RAP, SV(RAP))
L'étape C1 précitée est alors suivie d'une étape C2 consistant à vérifier électroniquement la valeur de signature des ressources DNS en fonction de la valeur cryptographique privée allouée à la zone DNS parente.
Sur la figure 2c, l'opération de vérification de signature de l'étape C2 est représentée par la relation symbolique (9)
(V(CVM) = VKP1-1, k) Dans la relation précédente, V(cvι-1) (SV(RAP)) désigne l'opération de vérification de signature de la valeur de signature SV(RAP) en fonction de la valeur cryptographique CV1-1 utilisée pour exécuter l'opération de signature à l'étape B2 de la figure 2b.
D'une manière plus spécifique, on indique que l'opération de signature exécutée à l'étape B2 de la figure 2b précédemment mentionnée est réalisée directement à partir de la valeur cryptographique privée CVn alors que l'opération de vérification de signature réalisée à l'étape C2 est réalisée en fonction de cette valeur cryptographique privée, ainsi qu'il sera décrit ultérieurement dans la description. En particulier, on indique que la valeur cryptographique privée précédemment citée peut être utilisée pour les opérations de signature respectivement de vérification de signature précédemment décrite dans la description dans le cadre d'un processus de chiffrement - déchiffrement symétrique, par exemple. Dans cette hypothèse, toutefois, on indique que l'utilisation d'un processus de chiffrement - déchiffrement symétrique implique une gestion de la transmission des clés de chiffrement - déchiffrement, c'est-à-dire de la valeur cryptographique privée précitée relativement lourde, ce processus de gestion de clés nécessitant en particulier la transmission des valeurs de clés sous forme chiffrée.
Afin d'éviter un processus de gestion de clés trop lourd et nécessitant le développement d'un protocole de gestion de clés adapté, le procédé objet de la présente invention peut au contraire être mis en œuvre, dans un mode de réalisation préférentiel, au moyen d'une valeur cryptographique privée spécifique et constituée par une clé secrète détenue par la zone DNS parente et le serveur DNS associé à celle-ci. Dans le cas précité, la mise en œuvre de l'étape B2 de la figure 2b, la valeur cryptographique privée CVM est alors constituée par une clé secrète KSM, k, cette clé secrète étant détenue dans une zone sécurisée du serveur DNS parent et utilisée pour signer électroniquement les informations de ressources DNS afin d'obtenir la valeur de signature des informations de ressources DNS. Dans ce mode de mise en œuvre, l'opération de signature de l'étape B2 est notée 5cvn = Sκsι-1, k- La valeur cryptographique privée est également constituée par une clé publique associée à la clé secrète précitée et librement disponible. La clé publique associée à la clé secrète précédemment mentionnée est notée KPM1 k et est utilisée pour vérifier électroniquement la valeur de signature des ressources DNS. Les clés secrète et publique allouées à chaque serveur DNS et associées à chaque zone DNS peuvent, de manière particulièrement avantageuse, correspondre aux clés secrète et publique allouées à ces serveurs dans le cadre de la recommandation RFC 3008 (IETF) "Domain Name System Security Signing Authority" (OHSsec), B. Wellington, 2000.
A l'étape C2 de la figure 2c, l'opération de vérification de signature en fonction de la valeur cryptographique privée précédemment mentionnée est alors notée
Figure imgf000015_0001
k-
Cette clé publique est alors utilisée avantageusement pour vérifier électroniquement la valeur de signature des ressources DNS précitée. La mise en œuvre d'une valeur cryptographique privée constituée par une clé secrète à laquelle est associée une clé publique permet ainsi de réduire le processus de gestion des valeurs cryptographiques précitées et en particulier des clés publiques, celles-ci, par définition, étant disponibles librement et pouvant bien entendu être transmises librement. Le processus de gestion de clés est ainsi grandement simplifié car il se limite alors sensiblement à un programme de changement temporel des clés secrètes allouées à chacun des serveurs DNS associé à chaque zone DNS parente ou fille correspondante.
La mise en œuvre du procédé objet de l'invention à l'aide de jeux de clés secrète respectivement publique allouée respectivement associée à chacun des serveurs DNS et la structure arborescente représentée en figure 2a, est alors particulièrement avantageuse dans la mesure où chaque zone DNS et, finalement, chaque serveur DNS est ainsi caractérisé dans le réseau de confiance ainsi constitué uniquement par sa seule clé publique, étant entendu que chaque serveur DNS détient la clé secrète correspondante.
En particulier, les opérations de signature respectivement de vérification de signature exécutées pour la mise en œuvre du procédé objet de la présente invention peuvent alors être effectuées à partir d'un processus de signature respectivement de vérification de signature exécuté par l'intermédiaire des algorithmes RSA par exemple, algorithmes de Rivest Shamir et Adleman ou par l'intermédiaire de l'algorithme DSA pour Digital Signature Algorithm. Les algorithmes précités sont des algorithmes conduits par voie logicielle, connus de l'état de la technique, lesquels, pour cette raison, ne seront pas décrits en détail.
En particulier, la mise en œuvre du procédé objet de la présente invention au moyen d'un processus de signature-vérification de signature à partir de clés dissymétriques, clés secrètes et clés publiques, apparaît particulièrement avantageuse dans la mesure où, préalablement à chaque opération de vérification de signature, ainsi que représenté en figure 2d, au moyen de la clé publique associée à la clé privée associée à chaque zone DNS fille ou parente, une procédure d'authentification de la clé publique par requête de signature de cette clé publique au moyen de la clé privée parente, auprès du serveur DNS gérant la zone DNS parente et détenant la clé privée parente, puis vérification par le terminal candidat T de la valeur signée de cette clé publique au moyen de la clé publique parente, peut, de manière avantageuse, être réalisée. Un tel processus est décrit en liaison avec la figure 2d où C21 désigne la transmission d'une requête de vérification de la clé publique, requête notée v_key_r(KPn, k), c'est-à-dire la requête de signature de la clé publique KPM | k transmise au serveur DNS SM1 k pour signature à l'étape C22 de la figure 2d au moyen de la clé privée parente KSM, k- Cette opération est notée par la relation symbolique (10)
Sκsι-i, k(KPι-i, k) -> SV(KPM, k) Dans la relation précédente : - SV(KPn, k) désigne la valeur de signature de la clé publique KPM, k ;
- Sκs\-1, k(KPι-i, k) désigne l'opération de signature de la clé publique précitée au moyen de clé privée KSM, k-
L'opération C22 peut alors être suivie, après transmission de la valeur de signature précitée au terminal candidat, d'une opération C23 de vérification de la valeur de signature de cette clé publique au moyen de la clé publique parente, cette opération de vérification étant exécutée par le terminal candidat T qui, bien entendu, détient la clé publique précitée.
Cette opération est représentée à l'étape C23 de la figure 2d par la relation symbolique (11)
Figure imgf000017_0001
k))
D'une manière générale, on indique que le procédé objet de la présente invention peut être mis en œuvre, sur première tentative de connexion et d'accès d'un terminal candidat T, par le routeur d'accès pressenti RA, lequel transmet alors les informations de ressources DNS auprès du serveur DNS parent correspondant ainsi que décrit précédemment dans la description. En particulier, on indique que la requête d'enregistrement d'autorisation de routage peut être effectuée une fois pour toutes lorsque le routeur est inséré sur le réseau. Lorsqu'un terminal se connecte ultérieurement à ce routeur, ce dernier transmet simplement une requête d'accès à ces données d'enregistrement par exemple.
Toutefois, la mise en œuvre du procédé objet de la présente invention n'est pas limitée à l'exemple de mise en œuvre précédemment cité. En effet, le processus d'authentification peut être directement mis en œuvre à partir du terminal candidat T, l'opération de signature des ressources DNS du routeur d'accès pressenti RA pouvant alors être exécutée à l'initiative du terminal T, le routeur transmettant simplement les informations de ressources DNS qui lui sont propres auprès du serveur DNS associé à la zone DNS fille d'accès. Le procédé objet de l'invention peut alors être mis en œuvre à partir de cette dernière et du serveur DNS associé à celle-ci. On comprend, en particulier, que le processus d'authentification de clé publique tel que décrit en liaison avec la figue 2d peut alors être mis en œuvre vis-à-vis du serveur DNS parent de la zone DNS parente associée à la zone DNS fille d'accès correspondante. D'une manière plus spécifique, on indique que dans tous les cas la relation ou chaîne de confiance est établie entre le terminal candidat T et tout serveur DNS intermédiaire, le cas échéant le serveur racine, en raison de la délivrance du certificat d'autorisation de routage, lequel constitue une habilitation par tout serveur DNS parent intermédiaire, y compris, le cas échéant, le serveur racine, pour tout routeur d'accès R susceptible de constituer un routeur d'accès pressenti RA parmi un ensemble de routeurs destinés à exercer leur fonction de routage. Tout routeur d'accès pressenti est alors en mesure d'obtenir de tout serveur DNS intermédiaire ou du serveur DNS racine un certificat d'autorisation de routage, lequel est ensuite authentifié sous l'autorité du serveur DNS racine par le terminal candidat T.
Une description plus détaillée du procédé objet de la présente invention dans un mode de mise en œuvre préférentiel pour exécuter une mise en œuvre optimisée en termes de flux de données sur le réseau IP visité sera maintenant décrite en liaison avec la figure 3. Le procédé objet de la présente invention, dans le mode de mise en œuvre représenté en figure 3 précité, apparaît du plus grand intérêt en particulier en raison de la variabilité des réseaux visités, lorsque, notamment, les requêtes d'accès sont émises par un terminal nomade ou par un terminal fixe ou mobile connecté à un réseau mobile par exemple, la configuration réseau pouvant être modifiée régulièrement et de façon peu prévisible dans ce dernier cas notamment.
Ainsi que représenté sur la figure 3 précitée, dans le mode de mise en œuvre préférentiel mentionné, le procédé objet de l'invention consiste à transmettre du routeur d'accès vers un serveur DNS parent une requête unique d'enregistrement d'autorisation de routage. L'étape précitée correspond à l'étape Bi de la figure 2b, l'opération correspondante étant représentée par la relation symbolique (5), étant toutefois précisé que la requête unique est notée uar_r(RAP). L'étape B2i précitée est alors suivie d'une étape B22 consistant à transmettre, du serveur DNS parent vers tout serveur DNS parent intermédiaire hiérarchiquement supérieur au serveur DNS parent précité, jusqu'au serveur DNS parent racine par exemple, des requêtes successives de communication de la clé publique et de la valeur de signature séparée de cette clé publique au moyen de la clé secrète associée à et respectivement détenue par chacun des serveurs DNS parents intermédiaires hiérarchiquement supérieurs.
Sur la figure 3 on a représenté, à titre d'exemple non limitatif, les opérations de transmission successive des requêtes de communication de la clé publique, requête désignée ukp_r(*) entre tout serveur DNS d'une zone DNS fille d'accès, noté Si-1, k, et tout serveur parent intermédiaire hiérarchiquement supérieur de rang m et noté pour cette raison Sm, k, cette requête successive de communication étant suivie d'une réponse notée aukp_r(KPm, k ; SV(KPm, k))- Les opérations de transmission de requête de communication de la clé publique et de la valeur de signature séparée de cette clé publique de réponse permettant la communication de ces valeurs sont représentées par la relation symbolique (12)
Figure imgf000019_0001
„ aukp_r (KPm, k;SV (KPm, k) q
/-1, k m, k
Une étape de test B222 est alors exécutée sur la variable de comptage du rang m, la transmission des requêtes de communication de clés étant poursuivie par l'intermédiaire du test B222 de comparaison de la valeur de comptage m à la valeur 0 par comparaison négative poursuivie par l'étape de décrémentation m = m - 1 à l'étape B223 et retour, bien entendu, à l'appel de l'opération de transmission de requête de communication et de réponse de communication de la valeur de clé publique et de la valeur de signature de cette clé publique pour le serveur DNS hiérarchiquement supérieur, représenté par la décrémentation m = m - 1 , jusqu'au serveur DNS racine S0, ainsi que représenté conventionnellement en figure 2a.
On comprend, en particulier, que dans la relation symbolique précitée KPm_k représente la clé publique associée au serveur DNS dont la position hiérarchique correspond à la variable de comptage m et SV(KPm,k) désigne la valeur de signature de cette clé publique au moyen de la clé privée du serveur DNS précité.
Sur réponse positive au test B222, le serveur DNS racine ayant été atteint et la valeur de clé publique ainsi que la valeur de signature de cette clé publique associée au serveur racine précité ayant été obtenues, l'on procède à une étape B23 à un processus dit d'agrégation, dans un message unique, de la valeur des clés publiques reçues et de la clé publique du serveur DNS parent ainsi que des valeurs de signature correspondantes SV(KPm,k). On rappelle que la notion de serveur DNS parent correspond au serveur DNS qui assure la gestion du routeur d'accès pressenti RA.
L'opération d'agrégation consiste, par exemple, en une opération de constitution d'une liste des valeurs de clé publique reçues, cette opération étant représentée symboliquement par la relation (13)
Dans la relation précédente, on indique que le message unique est m = 1—1 noté UM(KPm, R) _ . L'agrégation peut en effet être constituée par la mise
sous forme d'une liste par exemple de la valeur des clés publiques reçues précitées et des valeurs de signature de ces clés publiques.
L'opération B23 est suivie d'une opération B24 consistant à calculer la valeur de signature des informations de ressources DNS au moyen de la clé secrète associée à la zone DNS. parente et bien entendu au serveur DNS parent
Sι - i, k-
L'opération de signature précitée correspond à celle qui est réalisée à l'étape B2 de la figure 2b à partir de la clé secrète KSi _ 1, k associée au serveur DNS Sι_i, k.
L'étape B24 précitée peut alors être suivie d'une étape B25 correspondant sensiblement à l'étape B3 de la figure 2b précédemment décrite.
L'étape B25 précitée consiste à transmettre au terminal candidat T la valeur des clés publiques agrégées par l'intermédiaire du message unique UM(«), la valeur de signature séparée de chacune des clés publiques agrégées, ces valeurs de signature étant notées [SV(KPm, k)] ainsi que, bien entendu, la
Figure imgf000021_0001
valeur de signature des informations de ressources DNS, SV(RAP).
Dans cette situation, les valeurs de signature précédemment mentionnées constituent le certificat d'autorisation de routage mis à disposition du terminal candidat pressenti T.
L'opération réalisée à l'étape B25 est représentée par la relation symbolique (14)
Figure imgf000021_0002
A l'étape B25 on indique que la transmission précitée est réalisée vers le terminal candidat T par l'intermédiaire du routeur d'accès pressenti RA.
Après réception du certificat de routage par le terminal candidat T, c'est-à-dire suite à l'étape B25 précitée, le terminal candidat T procède alors à une vérification de chacune des valeurs de signature séparée de chaque clé publique communiquée, à l'étape C21. L'opération est réalisée par une étape de test représentée symboliquement par la relation (15)
[Tκpm, k (SV(KPm, k)] * = ' ~ l = vraie ? m ≈ U
Dans la relation précédente : m = / — 1
['Vkpm, k (SV(KPm1 k)] = vraie ? désigne la vérification successive m = 0 à la valeur vraie de chaque valeur de signature SV de la clé publique KPm, k pour m = 1-1 à m = 0 de chacun des serveurs DNS intermédiaires jusqu'au serveur DNS racine So, y compris le serveur DNS parent précédemment mentionné dans la description.
Sur vérification à la valeur vraie de chacune des valeurs de signature séparée de chaque clé publique, la valeur de la clé publique associée à la zone DNS parente et au serveur parent Sμ 1, k, ainsi qu'implicitement la valeur de la clé secrète détenue par le serveur DNS parent, ainsi que bien entendu toute clé publique intermédiaire jusqu'à la clé publique associée au serveur DNS racine sont authentifiées sous l'autorité de ce dernier. On comprend bien sûr que le serveur DNS racine S0 est bien entendu investi, par définition, de la confiance maximale pour tout terminal candidat exécutant une tentative d'accès. Cette confiance est bien entendu justifiée dans la mesure où il est quasi certain que le serveur DNS racine est un serveur d'administration générale des réseaux lequel, à ce titre, dispose des protections les plus fortes et de la garantie maximale de légitimité et d'intégrité de l'exécution de ses fonctions.
On comprend aussi que le serveur DNS racine permet, bien entendu, d'authentifier toutes les branches du réseau de confiance représenté en figure 2a, et en particulier tout routeur géré par les serveurs DNS intermédiaires précédemment décrits dans la description. L'ensemble des mailles du réseau précité étant ainsi sécurisées, toute chaîne de confiance mettant en jeu un trajet quelconque à partir des branches de routage gérées par les serveurs DNS intermédiaires correspondants est donc authentifié sous l'autorité du serveur DNS racine.
Bien entendu, ceci permet de rétablir la chaîne de confiance d'authentification du routeur d'accès pressenti RA à partir du seul paramètre de clé publique du serveur DNS parent SM1 k au bénéfice du terminal candidat.
Sur réponse positive au test C21, en particulier toutes les clés ayant été authentifiées, on dispose aux étapes C22, C23 de la valeur de la clé publique
KPM, k authentifiée. Le terminal T disposant de cette clé authentifiée peut alors procéder à l'opération de vérification électronique de la valeur de signature des ressources DNS, conduite à partir de la seule clé publique authentifiée. Cette opération est réalisée à l'étape C24 de la figue 3 laquelle correspond globalement à l'exécution proprement dite de l'authentification du certificat Cert(RA) représentée en figure 1.
Au contraire, sur réponse négative au test C2i, l'une des clés par exemple n'ayant pas été authentifiée par vérification de la valeur de signature de cette dernière, un retour à l'étape Bi peut être exécuté pour communication ou nouvelle communication de cette clé. Bien entendu, des sécurités en nombre de requêtes de communication pour un serveur DNS parent de rang hiérarchique déterminé peuvent être introduites afin de limiter les tentatives correspondantes.
D'une manière générale, on indique que les serveurs DNS conformes à l'objet de la présente invention sont des serveurs de type BIND, de tels serveurs comportant des modules logiciels et étant le plus couramment utilisés pour le déploiement des architectures DNS sur le réseau IP, en particulier sur l'Internet. De tels serveurs DNS et les logiciels correspondants comportent des outils satisfaisant à la recommandation DNSsec visant à réguler les développements de modules de sécurité pour les architectures DNS.
Dans les serveurs DNS précités, la configuration de ces derniers est effectuée à partir de structures de données de déclaration de ressources DNS de routage enregistrées dans les zones mémoires du serveur DNS.
Ces structures de données, fichiers, comportent des structures de données élémentaires de définition d'un domaine DNS donné selon la représentation du tableau ci-après.
TABLEAU
domaine.com. SOA domaine.com. SIG SOA ... domaine.com. SIG AXFR domaine.com. NS domaine.com. SIG NS domaine.com. KEY domaine.com. SIG KEY ... domaine.com. NXT a.domaine.com. SOA AXFR NS KEY SIG domaine.com. SIG NXT ... a.domaine.com. A a.domaine.com. SIG A ... a.domaine.com. NXT d. domaine.com. A SIG a.domaine.com. SIG NXT ...
Les structures de données élémentaires précitées font l'objet de la normalisation selon la norme DNSsec précédemment citée.
En référence à la figure 4a, on indique que le routeur d'accès pressenti RA peut s'adresser à tout serveur DNS avec lequel il entretient une relation de confiance. La relation de confiance s'entend d'une relation fréquente par transactions successives et vérification de la valeur de clé publique par authentification de la clé publique associée au serveur DNS précité, ainsi que représenté en liaison avec la figure 2d par exemple. Pour exécuter l'opération d'enregistrement de routage, le serveur RA peut transmettre une requête en utilisant un champ DNS de type RR pour "Resource Record" en anglais qui contient la liste des préfixes réseaux préfixe 2, c'est-à-dire la valeur PATH_RA de la figure 2b par exemple, préfixes réseau pour lesquels il est autorisé à exécuter légitimement sa fonction de routage des paquets de données. Le serveur DNS Su, k signe l'information de ressource DNS correspondante et renvoie au routeur RA la signature de cette information en utilisant un champ SIG RR accompagné ou non de la valeur de clé publique, selon que le routeur d'accès connaît ou non la valeur de cette dernière. La notification d'autorisation de routage est enregistrée dans une zone
DNS déterminée. Selon le serveur DNS Sn1 k, elle est peut être enregistrée dans une zone préexistante ou dans une zone spécifique dans laquelle le serveur enregistre toutes les autorisations de routage.
En supposant que le routeur RA s'enregistre auprès de la zone DNS associée au serveur DNS du domaine, désignée domaine.com sur le tableau précité dans cet exemple, le fichier de la zone DNS sur le serveur de noms de domaine, domaine.com précité, c'est-à-dire le serveur Sn,k se présente sous la forme et au format donné dans le tableau introduit précédemment. Après enregistrement des nouveaux préfixes diffusés par le routeur RA2, selon un aspect remarquable du procédé objet de l'invention, la déclaration de requête d'authentification d'une ressource DNS de routage enregistrée pour exécution de cette déclaration sur un serveur DNS tel que le serveur SM1 k de la figure 4a comporte une structure de données élémentaires comprenant un premier champ de données représentatif de l'adresse IP de la ressource DNS de routage, adresse @IP2 sur la figure 4a et sur la figure 4b, champ Fi, un deuxième champ codant le type d'enregistrement requis pour cette ressource DNS, c'est-à-dire le type désigné arbitrairement par PX au champ F2 de la figure 4b codant le type d'enregistrement, type désignant une requête d'enregistrement d'autorisation de routage pour la ressource DNS à l'adresse précisée au champ F1, et un troisième champ, champ F3, représentatif d'informations d'adresses d'accès réseau de la ressource DNS de routage autorisant l'acheminement des paquets de données par la fonction de routage légitimement exécutée par la ressource DNS de routage, c'est-à-dire le routeur RA2. Les informations d'adresse sont désignées préfixe 2 sur la figure 4a et la figure 4b. On comprend ainsi, en référence à la figure 4b, que la structure de données de déclaration d'une ressource DNS de routage enregistrée en zone mémoire d'un serveur DNS indiqué au tableau précité comporte bien sûr les structures de données élémentaires de définition du domaine DNS précitées, ainsi que des structures de données élémentaires spécifiques comprenant au moins la structure de données élémentaire de déclaration de requête d'authentification de requête d'une ressource DNS selon la figure 4b. Cette structure de données est représentée sur la figure précitée où l'on retrouve bien entendu la structure de données élémentaire de déclaration de requête d'authentification de ressources DNS de routage de la figure 4a.
Enfin, en référence à la même figure 4b, on indique que la structure de données précitée comporte en outre des structures de données élémentaires spécifiques comprenant au moins une structure de données élémentaire d'adresse et une structure de données de jonction de définitions des zones DNS, ces structures de données caractérisées par leur champ F2 correspondant au champ SIG, respectivement NXT pour la structure de données de jonction précitée.
Une description plus détaillée des fonctions et étapes successives mises en oeuvre par un produit de programme enregistré sur un support de mémorisation pour exécution, par un terminal candidat à un accès réseau IP, d'une authentification de la découverte de voisinage de l'environnement réseau IP de ce terminal candidat, lors de la connexion de ce dernier à ce réseau, sera maintenant décrite en liaison avec la figure 5, lorsque l'authentification de la découverte de voisinage est mise en œuvre conformément au procédé objet de la présente invention décrit précédemment en liaison avec les figures 1 à 4b précédentes.
Sur réception par le terminal candidat T des informations de ressources DNS notées RAP et de la valeur de signature de ces dernières notées SV(RAP) à l'étape 100 de la figure 5, le produit de programme comporte au moins un module de sous-programme SP1 de discrimination de la connaissance par le terminal candidat de la clé publique de la zone DNS et du serveur DNS parent qui a exécuté l'opération de calcul de la valeur de signature de ces ressources DNS. Cette opération de discrimination de la connaissance de la clé publique précitée est représentée par un test 101 vérifiant la relation (16) KPm, k ≡ 0 ?
Le test précité revient à vérifier, par exemple, l'existence d'une valeur non vide pour la clé publique KPm,k, avec m = I - 1 , selon les conventions précédemment mentionnées dans la description pour le serveur DNS parent Sn1 k.
Sur discrimination de l'absence de connaissance de la clé publique précitée, c'est-à-dire en réponse positive au test 101 précédemment mentionné, un module SP2 de sous-programme est appelé, lequel permet d'assurer la transmission auprès du serveur DNS parent précédemment cité d'un message de requête de communication de toute clé publique accompagné d'une valeur de signature de cette clé publique au moyen de la clé secrète détenue par le serveur DNS parent. L'étape 102 précitée est une étape semblable à l'étape B22 de la figure 3, les messages de demande de communication de clé publique ukp_r(«) et de réponse à cette requête de communication de clé publique aukp_r(«) pouvant présenter la même forme que dans le cas de la mise en œuvre de l'étape B22 de la figure 3 précitée.
Suite à la réception de la clé publique et de la valeur de signature de cette clé publique correspondante, un module de programme SP3 permet de vérifier la valeur de signature de toute clé publique reçue à l'étape précédente 102, y compris de la clé publique associée à la zone DNS fille d'accès en raison du fait que le protocole est conduit par le terminal T.
A l'étape 103 de la figure 5, l'opération de vérification de la valeur de signature est notée selon la même relation que celle indiquée précédemment dans la description à l'étape C21 de la figure 3. Pour la vérification ou authentification de la clé publique KPι,ι< associée à la zone DNS du serveur d'accès fille Si, R, une procédure semblable à celle décrite précédemment dans la description en liaison avec la figure 2d peut être exécutée, étant précisé que la clé publique KPM1R a été authentifiée, soit sur connaissance particulière de la valeur de cette clé publique et confiance suffisante du terminal candidat en réponse négative au test 101 précédemment décrit. La clé publique KPi.k peut alors être authentifiée à partir de la clé secrète KSM,k du serveur DNS associé à la zone DNS fille d'accès correspondante, ainsi que décrite précédemment avec la figure 2d. En tout état de cause, sur réponse négative au test 101 de la figure 5 ou sur réponse positive à ce même test, mais après exécution des modules de sous-programmes SP2 et SP3, étape 102 et test 103, à l'étape 104, on dispose de clés publiques authentifiées KPn ,k et KPι,k ainsi que représenté à la figure 5. Le terminal T comporte en outre un module de sous-programme SP4 de vérification de la valeur de signature des ressources DNS avec la clé publique associée au serveur DNS parent et à la zone DNS parente, SM ,k. Le module de sous-programme SP4 permet d'effectuer une opération de vérification de signature représentée symboliquement par la même relation que la relation de l'étape C23 de la figure 2d, par exemple.
Sur réponse positive au test 105 précité, on dispose à l'étape 106 d'un certificat Cert(RA) authentifié.
Le terminal T dispose alors d'un module de sous-programme SP5 de confirmation du routeur d'accès pressenti RA comme routeur d'accès par défaut pour la connexion et l'accès du terminal candidat T au réseau IP.
A l'étape 107 de la figure 5, la relation de confirmation du routeur d'accès pressenti RA comme routeur d'accès par défaut est représentée par la relation symbolique
T «--> RA défaut. Au contraire, sur réponse négative au test 105, le module de sous- programme SP4 permet l'appel d'un module de sous-programme SP6 d'affichage sur le terminal candidat T d'un message d'avertissement WM informant l'utilisateur du terminal candidat T des risques dus à la non-conformité de la transmission des données aux critères de sécurité de la transaction.

Claims

REVENDICATIONS
1. Procédé d'authentification de la découverte de voisinage de l'environnement réseau IP d'un terminal candidat à un accès réseau, ledit réseau IP étant géré par une pluralité de zones DNS formées par un serveur DNS racine et par des serveurs DNS intermédiaires, chaque zone DNS étant associée à l'un des serveurs DNS1 lesdites zones DNS et lesdits serveurs DNS étant configurés selon une arborescence de zones DNS parentes et de zones DNS filles entre une zone DNS racine et une zone DNS fille d'accès, à partir de laquelle ledit terminal candidat exécute cet accès par connexion au réseau IP, à chaque zone DNS, parente respectivement fille étant allouée une valeur cryptographique privée spécifique, chaque valeur cryptographique privée allouée à une zone DNS fille étant susceptible d'être authentifiée par l'intermédiaire de la valeur cryptographique privée associée à la zone DNS parente immédiatement supérieure de ladite structure arborescente, caractérisé en ce que, sur requête d'accès au réseau IP par connexion d'un terminal candidat à un routeur de ladite zone DNS fille d'accès, ledit routeur constituant un routeur d'accès, ledit procédé consiste au moins à :
- lancer à partir dudit routeur d'accès, vers l'un au moins des serveurs DNS d'une zone DNS parente, une procédure d'enregistrement d'autorisation de routage à partir d'une requête d'enregistrement d'autorisation de routage, permettant d'engendrer et transmettre audit routeur d'accès un certificat d'autorisation de routage délivré par ledit serveur de zone DNS parente et consistant en une valeur de signature de paramètres spécifiques audit routeur d'accès, ladite valeur de signature étant obtenue à partir de la valeur cryptographique privée allouée à ladite zone DNS parente ;
- lancer via le routeur d'accès une procédure d'authentification dudit certificat d'autorisation de routage par vérification de ladite valeur de signature en fonction de la valeur cryptographique privée allouée à ladite zone DNS parente.
2. Procédé selon la revendication 1 , caractérisé en ce que ladite procédure d'enregistrement d'autorisation de routage consiste au moins à :
- transmettre au serveur DNS de la zone parente une requête d'enregistrement d'autorisation de routage, comportant au moins un champ d'information de ressources DNS associant au moins une adresse IP représentative de l'adresse IP dudit routeur d'accès et une référence de chemin d'accès réseau à ce routeur d'accès ;
- signer électroniquement les informations de ressources DNS à partir de la valeur cryptographique privée allouée à ladite zone DNS parente pour engendrer une valeur de signature des informations de ressources DNS ;
- transmettre ladite valeur de signature des informations de ressources DNS audit routeur d'accès.
3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que ladite procédure d'authentification du certificat d'autorisation de routage consiste au moins à :
- transmettre via ledit routeur d'accès audit terminal candidat les informations de ressources DNS et la valeur de signature des informations de ressources DNS, constituant le certificat d'autorisation de routage ;
- vérifier électroniquement la valeur de signature des ressources DNS, en fonction de la valeur cryptographique privée allouée à ladite zone DNS parente.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que ladite valeur cryptographique privée spécifique est constituée par :
- une clé secrète détenue par la zone DNS parente et le serveur DNS associé à celle-ci, ladite clé secrète étant utilisée pour signer électroniquement les informations de ressource DNS et obtenir la valeur de signature des informations de ressource DNS ;
- une clé publique associée à ladite clé secrète et librement disponible, ladite clé publique étant utilisée pour vérifier électroniquement la valeur de signature des ressources DNS.
5. Procédé selon la revendication 4, caractérisé en ce que celui-ci comporte en outre, préalablement à chaque opération de vérification de signature, au moyen de la clé publique associée à la clé privée associée à chaque zone DNS fille ou parente, une procédure d'authentification de ladite clé publique par requête de signature de cette clé publique au moyen de la clé privée parente, auprès du serveur DNS gérant la zone DNS parente et détenant la dite clé privée parente, puis vérification de la valeur signée de cette clé publique au moyen de ladite clé publique parente par ledit terminal candidat.
6. Procédé selon l'une des revendications 4 ou 5, caractérisé en ce que pour une mise en œuvre optimisée en termes de flux de données sur le réseau IP visité, celui-ci consiste à : a) transmettre dudit routeur d'accès vers un serveur DNS parent une requête unique d'enregistrement d'autorisation de routage ; b) transmettre dudit serveur DNS parent vers tout serveur DNS parent intermédiaire, hiérarchiquement supérieur audit serveur DNS parent, jusqu'au serveur DNS parent racine, des requêtes successives de communication de la clé publique et de la valeur de signature séparée de cette clé publique, au moyen de la clé secrète associée à respectivement détenue par chacun des serveurs DNS parents intermédiaires hiérarchiquement supérieurs ; et au niveau dudit serveur DNS parent, après réception successive desdites clés publiques et de leur valeur de signature ; c) agréger dans un message unique la valeur desdites clés publiques reçues et de la clé publique dudit serveur DNS parent et les valeurs de signature de clé publique correspondantes ; d) calculer la valeur de signature des informations de ressources DNS au moyen de la clé secrète associée à ladite zone DNS parente et audit serveur DNS parent ; e) transmettre audit terminal candidat la valeur desdites clés publiques agrégées, la valeur de signature séparée de chacune des clés publiques agrégées et la valeur de signature des informations de ressources DNS, lesdites valeurs de signature constituant ledit certificat d'autorisation de routage.
7. Procédé selon la revendication 6, caractérisé en ce que sur vérification à la valeur vraie de chacune des valeurs de signature séparée de chacune des clés publiques, la valeur de la clé publique associée audit serveur et à ladite zone DNS parente, la valeur de la clé secrète détenue par ledit serveur DNS parent sont authentifiées, sous l'autorité du serveur DNS racine, ce qui permet de rétablir la chaîne de confiance d'authentification dudit routeur d'accès à partir du seul paramètre de clé publique dudit serveur DNS parent au bénéfice dudit terminal candidat.
8. Procédé selon la revendication 7, caractérisé en ce que, suite à l'authentification de la clé publique associée audit serveur et à ladite zone DNS parente et de la valeur de la clé secrète détenue par ledit serveur et la zone DNS parente, l'opération de vérification électronique de la valeur de signature des ressources DNS est conduite à partir de ladite seule clé publique authentifiée.
9. Structure de données élémentaire de requête d'enregistrement d'autorisation de routage d'une ressource DNS de routage enregistrée pour exécution de cette déclaration sur un serveur DNS, caractérisée en ce qu'elle comporte :
- un premier champ de données représentatif de l'adresse IP de ladite ressource DNS de routage ;
- un deuxième champ codant le type d'enregistrement requis pour cette ressource DNS ;
- un troisième champ représentatif d'informations d'adresse d'accès réseau de ladite ressource DNS de routage, autorisant l'acheminement des paquets de données par la fonction de routage légitimement exécutée par ladite ressource DNS de routage.
10. Structure de données de déclaration d'une ressource DNS de routage enregistrée auprès d'un serveur DNS, comportant des structures de données élémentaires de définition d'un domaine DNS donné, caractérisée en ce qu'elle comporte en outre des structures de données élémentaires spécifiques comprenant au moins une structure de données élémentaire selon la revendication 9.
11. Structure de données selon la revendication 10, caractérisée en ce que lesdites structures de données élémentaires spécifiques comportent en outre au moins une structure de données d'adresse et une structure de données de jonction de définition des zones DNS.
12. Produit de programme comprenant des instructions de code de programme, enregistré sur un support lisible par un ordinateur, pour exécution, par un terminal candidat à un accès réseau IP, d'une authentification de la découverte de voisinage de l'environnement réseau IP de ce terminal candidat lors de la connexion de ce dernier à ce réseau, conformément au procédé selon l'une des revendications 1 à 8, caractérisé en ce que, sur réception par ledit terminal candidat des informations de ressources DNS et de la valeur de signature de ces ressources DNS ledit produit de programme comprend au moins : - des moyens de programmation lisibles par ordinateur pour effectuer l'étape de discrimination de la connaissance, par ledit terminal candidat, de la clé publique de la zone DNS et du serveur DNS parent qui a exécuté l'opération de calcul de la valeur de signature de ces ressources DNS ; et, sur discrimination de l'absence de connaissance de ladite clé publique ;
- • des moyens de programmation lisibles par ordinateur pour effectuer l'étape de transmission, auprès du serveur DNS parent, d'un message de requête de communication de toute clé publique, accompagnée d'une valeur de signature de cette clé publique, au moyen de la clé secrète détenue par ledit serveur DNS parent ; et, sur réception de ladite clé publique et de ladite valeur de signature de cette clé publique,
- • des moyens de programmation lisibles par ordinateur pour effectuer l'étape de vérification de ladite valeur de signature de toute clé publique, y compris de la clé publique associée à ladite zone DNS fille d'accès ; et, sur vérification à respectivement connaissance préalable de la valeur vraie de ladite valeur de signature de cette clé publique,
- • des moyens de programmation lisibles par ordinateur pour effectuer l'étape de vérification de la valeur de signature de ces ressources DNS avec la clé publique associée audit serveur DNS parent et à ladite zone DNS parente ; et, sur vérification à la valeur vraie de la valeur de signature de ces ressources DNS, le certificat d'autorisation de routage étant authentifié,
- • des moyens de programmation lisibles par ordinateur pour effectuer l'étape de confirmation dudit routeur d'accès comme routeur d'accès par défaut pour la connexion et l'accès dudit terminal candidat audit réseau IP ; sinon, sur absence de vérification à la valeur vraie de la valeur de signature de ces ressources DNS, le certificat d'autorisation de routage n'étant pas authentifié,
- des moyens de programmation lisibles par ordinateur pour effectuer l'étape d'affichage, sur le terminal candidat, d'un message d'avertissement informant l'utilisateur de ce dernier des risques dus à la non-conformité de la transmission des données aux critères de sécurité de la transaction, lorsque ledit programme fonctionne sur un ordinateur.
PCT/FR2005/002911 2004-11-26 2005-11-23 Procede d'authentification de la decouverte de voisinage de l'environnement reseau ip d'un terminal candidat a un acces reseau WO2006056687A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0412596A FR2878671A1 (fr) 2004-11-26 2004-11-26 Procede d'authentification de la decouverte de voisinage de l'environnement reseau ip d'un terminal candidat a un acces reseau
FR0412596 2004-11-26

Publications (3)

Publication Number Publication Date
WO2006056687A2 true WO2006056687A2 (fr) 2006-06-01
WO2006056687A3 WO2006056687A3 (fr) 2006-12-07
WO2006056687B1 WO2006056687B1 (fr) 2007-01-04

Family

ID=35219338

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/002911 WO2006056687A2 (fr) 2004-11-26 2005-11-23 Procede d'authentification de la decouverte de voisinage de l'environnement reseau ip d'un terminal candidat a un acces reseau

Country Status (2)

Country Link
FR (1) FR2878671A1 (fr)
WO (1) WO2006056687A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113179524A (zh) * 2020-08-27 2021-07-27 几维通信技术(深圳)有限公司 网络优化方法及计算机可读存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004040762A (ja) * 2002-02-19 2004-02-05 Docomo Communications Laboratories Usa Inc アドレスに基づく鍵を使用することによる近隣発見の保護

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004040762A (ja) * 2002-02-19 2004-02-05 Docomo Communications Laboratories Usa Inc アドレスに基づく鍵を使用することによる近隣発見の保護

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ARKKO ERICSSON J KEMPF DOCOMO COMMUNICATIONS LABS USA B SOMMERFELD SUN MICROSYSTEMS B ZILL MICROSOFT P NIKANDER ERICSSON J: "SEcure Neighbor Discovery (SEND)" IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. send, no. 6, 17 juillet 2004 (2004-07-17), XP015027377 ISSN: 0000-0004 cité dans la demande *
EUNSOO SHIM ET AL: "Secure candidate access router discovery" WIRELESS COMMUNICATIONS AND NETWORKING, 2003. WCNC 2003. 2003 IEEE 16-20 MARCH 2003, PISCATAWAY, NJ, USA,IEEE, vol. 3, 16 mars 2003 (2003-03-16), pages 1819-1824, XP010640046 ISBN: 0-7803-7700-1 *
MOLVA R: "Internet security architecture" COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 31, no. 8, 23 avril 1999 (1999-04-23), pages 787-804, XP004304518 ISSN: 1389-1286 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113179524A (zh) * 2020-08-27 2021-07-27 几维通信技术(深圳)有限公司 网络优化方法及计算机可读存储介质
CN113179524B (zh) * 2020-08-27 2023-09-12 几维通信技术(深圳)有限公司 网络优化方法及计算机可读存储介质

Also Published As

Publication number Publication date
WO2006056687A3 (fr) 2006-12-07
FR2878671A1 (fr) 2006-06-02
WO2006056687B1 (fr) 2007-01-04

Similar Documents

Publication Publication Date Title
US7899185B2 (en) Real privacy management authentication system
US20030014629A1 (en) Root certificate management system and method
EP1753173B1 (fr) Contrôle d&#39;accès d&#39;un équipement mobile à un réseau de communication IP par modification dynamique des politiques d&#39;accès
EP2294850B1 (fr) Procede pour securiser des echanges entre un noeud demandeur et un noeud destinataire
FR3081654A1 (fr) Procede, dispositif et serveur de distribution securisee d&#39;une configuration a un terminal
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d&#39;une délégation de diffusion de contenus chiffrés
CN115580498B (zh) 融合网络中的跨网通信方法及融合网络系统
JP4409377B2 (ja) 通信システム及びサービス提供方法
CA3100170C (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
WO2006056687A2 (fr) Procede d&#39;authentification de la decouverte de voisinage de l&#39;environnement reseau ip d&#39;un terminal candidat a un acces reseau
CN113169953B (zh) 用于验证设备或用户的方法和装置
CN114265815A (zh) 交通媒体数据存储方法、服务器、存储介质及系统
CN114006724A (zh) 一种加密dns解析器发现及认证的方法与系统
EP3900306A1 (fr) Procédé de détermination d&#39;une chaîne de délégation associée à une résolution d&#39;un nom de domaine dans un réseau de communication
WO2021074412A1 (fr) Procede de connexion d&#39;un noeud de communication, et noeud de communication correspondant
EP3149902B1 (fr) Technique d&#39;obtention d&#39;une politique de routage de requêtes émises par un module logiciel s&#39;exécutant sur un dispositif client
EP2710779A1 (fr) Procede de securisation d&#39;une platforme d&#39;authentification, dispositifs materiels et logiciels correspondants
CN115883088B (zh) 基于bgp路由的自治域安全参数更新方法
WO2024047128A1 (fr) Procédé, dispositif et système de contrôle de la validité d&#39;un message
CN117579285A (zh) 一种服务化网络中流量转发方法、装置、设备及存储介质
WO2012001273A1 (fr) PROCEDE D&#39;ALLOCATION SECURISEE D&#39;UNE ADRESSE IPv6 A UN NŒUD D&#39;UN RESEAU PRIVE
CN117501671A (zh) 使用路由来源授权(ROA)进行边界网关协议(BGP)FlowSpec发起授权
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.
FR2985402A1 (fr) Procede de connexion a un reseau local d&#39;un terminal mettant en oeuvre un protocole de type eap et systeme de communication associe
FR3116133A1 (fr) Procédé de délégation d’accès à une chaîne de blocs

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05822916

Country of ref document: EP

Kind code of ref document: A2