FR2961994A1 - Procede d'allocation securisee d'une adresse ipv6 a un noeud d'un reseau prive - Google Patents

Procede d'allocation securisee d'une adresse ipv6 a un noeud d'un reseau prive Download PDF

Info

Publication number
FR2961994A1
FR2961994A1 FR1055262A FR1055262A FR2961994A1 FR 2961994 A1 FR2961994 A1 FR 2961994A1 FR 1055262 A FR1055262 A FR 1055262A FR 1055262 A FR1055262 A FR 1055262A FR 2961994 A1 FR2961994 A1 FR 2961994A1
Authority
FR
France
Prior art keywords
router
prefix
network
public key
certificate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1055262A
Other languages
English (en)
Inventor
Jean-Michel Combes
Daniel Migault
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR1055262A priority Critical patent/FR2961994A1/fr
Priority to PCT/FR2011/051442 priority patent/WO2012001273A1/fr
Publication of FR2961994A1 publication Critical patent/FR2961994A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5092Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/164Implementing security features at a particular protocol layer at the network layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/618Details of network addresses
    • H04L2101/659Internet protocol version 6 [IPv6] addresses

Landscapes

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

Abstract

L'invention concerne un procédé d'allocation sécurisée d'un préfixe réseau (PFX) dans un réseau privé, le réseau comprenant au moins un routeur (RT) et au moins un nœud réseau (N), le procédé comprenant une étape (16) d'envoi par le routeur vers le nœud réseau d'un message (RA) d'annonce de préfixe, ledit message comprenant : - un certificat numérique d'une clé publique (K ) dont le titulaire est le routeur, - une information signée comprenant au moins un préfixe réseau généré par le routeur, l'information étant signée au moyen d'une clé privée (K ) propre au routeur et associée à la clé publique certifiée.

Description

Procédé d'allocation sécurisée d'une adresse IPv6 à un noeud d'un réseau privé
L'invention concerne une technique d'allocation sécurisée d'adresses IPv6 dans un réseau privé, et plus précisément une technique d'allocation sécurisée de préfixes réseau.
IPv6 est une nouvelle version du protocole réseau de l'Internet. Une des caractéristiques d'lPv6 est d'offrir un adressage sur 128 bits, au lieu des 32 bits dans la version 4 du protocole réseau IP. Les adresses IPv6 ont une structure déterminée. Toute adresse IPv6 comprend une première et une deuxième parties de 64 bits. La première partie, appelée préfixe réseau, est utilisée pour le routage dans le réseau. La deuxième partie correspond à un identifiant d'interface.
Le protocole IPv6 offre une procédure d'auto-configuration qui permet à un noeud d'un réseau, public ou privé, de générer sa propre adresse, ce qui évite une procédure de saisie manuelle d'adresse au niveau du noeud, ou une procédure de configuration via un serveur de type « DHCP » (de l'anglais «Dynamic Host Configuration Protocol ») adapté pour attribuer une adresse à un noeud de manière automatique moyennant un paramétrage initial adapté. De telles procédures, pour un particulier qui supervise un sous-réseau, par exemple un réseau privé tel qu'un réseau domestique, peuvent être fastidieuses, voire compliquées. Ainsi, avec la procédure d'auto-configuration, un routeur adapté pour assurer le routage des paquets dans un réseau envoie régulièrement, ou à la demande, sur un lien réseau sur lequel il se situe des messages d'annonce notés « RA » pour « Router Advertisement » paramétrés par un préfixe correspondant au préfixe réseau associé au routeur. Une fois le préfixe du routeur obtenu par le noeud, celui-ci peut générer sa propre adresse IPv6 en concaténant le préfixe annoncé par le routeur à un identifiant d'interface qui lui est propre, et qui comprend par exemple un haché de sa propre adresse MAC. Une sécurisation de ce mécanisme d'auto-configuration dans un réseau public est prévue afin d'éviter qu'un routeur malveillant ne perpètre des attaques par déni de service sur des noeuds du lien. Au cours d'une telle attaque, le routeur malveillant peut par exemple envoyer dans un message d'annonce RA un préfixe valide, associé à un routeur légitime, en précisant que le durée de validité de ce préfixe est égale à 0. En d'autres termes, ce message indique que le préfixe réseau annoncé n'est plus valable. Le noeud est alors incapable d'utiliser son adresse W. Le routeur malveillant peut également envoyer un préfixe erroné, ce qui conduit le noeud à générer une adresse erronée. Le mécanisme de sécurisation de l'auto-configuration dans un réseau public et en cours de standardisation à 1«< IETF » (« Internet Engineering Task Force ») repose sur l'utilisation d'un mécanisme appelé « SEND » (de l'anglais « Secure Neighbor Discovery »), décrit dans la RFC 3971. Le mécanisme de sécurisation est basé sur l'utilisation de certificats X.509 et repose sur une infrastructure de type « RPKI » (pour « Resource Public Key Infrastructure »). La RPKI est conforme à l'infrastructure de gestion des adresses IPv6, en l'espèce 1«< IANA » (« Internet Assigned Number Authority ») qui est l'organisation en charge de la gestion de l'espace d'adressage IP de l'Internet et autres ressources partagées de numérotation requises dans les réseaux IP. Avec cette RPKI, un couple de clés privée/publique et un certificat X.509v3 sont attribués à un routeur par une Autorité de Certification reconnue par l'IANA, en Europe il s'agit de « RIPE » (pour «Réseaux IP Européens »). Le certificat certifie la clé publique associée à la clé privée. Un préfixe de routeur qui est ensuite distribué dans un message d'annonce RA est signé par le routeur au moyen de sa clé privée. Ainsi, un noeud qui reçoit un message d'annonce RA vérifie que l'adresse IPv6 du routeur est valide. A cette fin : il vérifie la signature reçue au moyen de la clé publique associée au routeur et 10 présente dans le certificat ; puis, il vérifie que le routeur a bien le droit d'annoncer le préfixe qu'il annonce par vérification du certificat. Le certificat est utilisé afin de certifier que le titulaire du certificat, en l'espèce le routeur qui annonce un préfixe est bien un routeur, et qu'il est bien autorisé à annoncer ce préfixe. 15 Ce mécanisme est prévu pour certifier une clé publique de routeur dans un réseau public afin de sécuriser l'annonce d'un préfixe dans le réseau public. Par contre, il est inadapté pour annoncer un préfixe dans un réseau privé et ne permet donc pas à des noeuds du réseau privé de générer leur adresse IPv6. En effet, il est connu que dans le cas d'un réseau privé, il est dédié une plage d'adresses, comprise entre une première valeur et une deuxième valeur. Un administrateur du 20 réseau privé, par exemple un Fournisseur d'Accès Internet maîtrise alors les adresses comprises entre ces deux valeurs et les alloue pour les clients de son réseau selon une politique qui lui est propre. Ainsi, deux administrateurs différents, par exemple deux Fournisseurs d'Accès Internet qui gèrent deux réseaux privés respectifs et qui administrent un routeur respectif peuvent choisir 25 indépendamment l'un de l'autre un même préfixe réseau pour les routeurs respectifs de leur réseau privé respectif. Ainsi, il se peut qu'ensuite, à partir de ce préfixe de routeur identique dans les deux réseaux privés, un noeud du premier réseau et un noeud du deuxième réseau génèrent la même adresse IPv6. Ce n'est pas problématique en termes de collision puisque les adresses des noeuds de chacun des réseaux ne sont pas routées dans l'Internet global. Cependant, il apparaît avec évidence 30 que le mécanisme de sécurisation tel que décrit précédemment ne peut être mis en oeuvre. En effet, une Autorité de Certification telle que IANA ou RIPE, ne peut allouer et signer des certificats à des entités différentes, en l'espèce les routeurs respectifs des deux réseaux, car il y a un risque d'avoir plusieurs adresses identiques dans des réseaux administrativement disjoints. Ainsi, il n'est pas possible, dans un réseau privé de certifier les préfixes de routeur de la 35 même façon qu'en adressage public, c'est-à-dire au moyen d'un certificat alloué par une Autorité de Certification reconnue. Il n'est donc pas possible de sécuriser l'adressage dans un réseau privé IPv6. Ainsi il devient possible pour un routeur malveillant de perpétrer des attaques de déni de service sur des noeuds dans un réseau privé.
L'invention remédie au problème évoqué ci-dessus en proposant un procédé d'allocation sécurisée d'un préfixe réseau dans un réseau privé, le réseau comprenant au moins un routeur et au moins un noeud réseau, le procédé comprenant une étape d'envoi par le routeur vers le noeud réseau d'un message d'annonce de préfixe, ledit message comprenant : - un certificat numérique d'une clé publique (Kp e) dont le titulaire est le routeur, - une information signée comprenant au moins un préfixe réseau généré par le routeur, l'information étant signée au moyen d'une clé privée (Kp,;,,) propre au routeur et associée à la clé publique certifiée. Le procédé de l'invention permet ainsi de sécuriser l'auto-configuration de noeuds dans un réseau privé, ce qui n'était pas possible jusqu'à présent. En effet, un routeur transmet sur un lien de ce réseau un message d'annonce du préfixe réseau à utiliser, ainsi que des informations qui permettent de vérifier que le routeur qui annonce le préfixe est bien un routeur, et qu'il est bien autorisé à annoncer ce préfixe. Cette vérification est possible car le message d'annonce comprend, outre le préfixe généré par le routeur, toutes les données qui permettent de recalculer le préfixe et donc de vérifier que le préfixe reçu est bien celui attendu. D'autre part, ces données sont certifiées : la clé publique utilisée dans le calcul du préfixe est certifiée par le certificat numérique qui est transmis, et l'information qui comprend au moins le préfixe est signée. Ainsi, l'authenticité de l'information et de la clé publique sont garanties et vérifiables. Ainsi, il n'est pas possible pour un routeur malveillant de perpétrer une attaque par déni de service sur des noeuds du réseau privé en envoyant un message d'annonce de préfixe qui comprend le préfixe du routeur valide et un paramètre qui précise comme durée de vie de ce préfixe une valeur nulle. En effet, seul le routeur valide est apte à signer l'information au moyen de la clé secrète associée à la clé publique certifiée par le certificat transmis. Selon un mode de réalisation de l'invention, le procédé d'allocation comprend : - une étape de calcul d'un haché d'une donnée comprenant la clé publique, - une étape de formation du préfixe réseau par concaténation d'une valeur prédéfinie propre à un réseau privé et d'une pluralité de bits extraits du haché calculé. Les premiers bits du préfixe d'une adresse IPv6 dans un réseau privé étant prédéfinis, l'invention permet de compléter à 64 bits un préfixe de telle manière qu'un noeud qui reçoit ce préfixe dans un message d'annonce peut vérifier que le préfixe est bien annoncé par un routeur et que le routeur est bien autorisé à annoncer ce préfixe. En effet, la vérification se fait sur les 56 derniers bits du préfixe, les 8 premiers bits étant composés de valeurs prédéfinies fixées pour un réseau privé. Selon un mode de réalisation de l'invention, le procédé d'allocation comprend en outre : - une étape de génération par le routeur du certificat numérique de la clé publique, et de signature du certificat par le routeur au moyen de la clé privée. Dans ce mode de réalisation un certificat propre au routeur est généré par le routeur et signé par le routeur. Il s'agit donc d'un certificat auto-signé valable à l'intérieur du réseau privé pour sécuriser l'auto-configuration d'adresses IPv6 par des noeuds situés à l'intérieur du réseau privé. Plus précisément, les noeuds pour lesquels l'auto-configuration est sécurisée, sont situés sur le même lien réseau que le routeur et peuvent générer une adresse IPv6 à partir du préfixe annoncé par le routeur. En utilisant des certificats auto-signés, il devient possible de mettre en place une sécurisation et une vérification de l'adressage IPv6 dans un réseau privé sans qu'il soit nécessaire de déployer une infrastructure de type RPKI. Ainsi, l'invention permet de mettre en place des réseaux à adressage privé de façon relativement simple. Cet aspect est intéressant pour des réseaux d'entreprise, ou des réseaux ad-hoc. Dans un exemple de réalisation de l'invention, le procédé d'allocation comprend aussi une étape de génération par le routeur d'un couple de clés comprenant la clé privée et la clé publique associée. L'invention concerne aussi un procédé pour générer une adresse IPv6 par un noeud dans un réseau privé, le réseau comprenant au moins un routeur, le procédé comprenant : - une étape de réception en provenance du routeur d'un message d'annonce de préfixe comprenant un certificat numérique d'une clé publique et de titulaire le routeur, et une information signée au moyen d'une clé privée propre au routeur et associée à la clé publique certifiée, l'information comprenant au moins un préfixe généré par le routeur, - une étape de calcul d'un deuxième préfixe à partir de la clé publique du certificat, - une étape de comparaison du préfixe reçu et du deuxième préfixe calculé, - une étape de vérification de la signature de l'information au moyen de la clé publique certifiée par le certificat. Un noeud sur un lien réseau qui reçoit le message RA d'annonce de préfixe du routeur, peut à partir de ce message vérifier que le préfixe reçu est bien valide, en recalculant ce même préfixe à partir des paramètres reçus et du certificat. Il peut en outre vérifier que le routeur est bien autorisé à émettre ce préfixe, en vérifiant la signature de l'information reçue. Avantageusement, l'étape de vérification de la signature du procédé pour générer une adresse lPv6 n'est réalisée que si le préfixe reçu du routeur est égal au deuxième préfixe calculé. En effet, l'opération de vérification de signature étant coûteuse en termes de ressources de calcul pour le noeud réseau, celui-ci n'effectue la vérification de signature que si le préfixe reçu correspond effectivement au préfixe calculé à partir des paramètres et du certificat transmis. De manière avantageuse, le procédé pour générer une adresse IPv6 comprend en outre une étape de concaténation du préfixe reçu avec un identifiant d'interface propre au noeud.
Le noeud réseau qui reçoit et vérifie un préfixe conformément au procédé de l'invention peut forger sa propre adresse IPv6 à partir d'un identifiant d'interface qui lui est propre en ayant la garantie que son adresse est authentique. L'invention concerne aussi un certificat numérique X.509v3 de clé publique destiné au routeur, comprenant un champ « ExtendedKeyUsage » adapté pour indiquer un usage associé à la clé publique, caractérisé en ce que le champ comprend une valeur indiquant que la clé publique est destinée à être utilisée pour mettre en oeuvre le procédé d'allocation sécurisée d'un préfixe réseau selon l'invention. L'invention porte également sur un routeur dans un réseau privé comprenant au moins un 10 noeud réseau, le routeur comprenant : - des moyens d'envoi, agencés pour envoyer vers le noeud réseau un message d'annonce de préfixe comprenant un certificat numérique d'une clé publique dont le titulaire est le routeur, ainsi qu'une information signée comprenant au moins un préfixe réseau généré par le routeur, l'information étant signée au moyen d'une clé privée propre au routeur et associée à la clé publique 15 certifiée. Dans un exemple de réalisation de l'invention, le routeur comprend en outre : - des moyens de calcul, agencés pour calculer un haché d'une donnée comprenant la clé publique certifiée, - des moyens de formation d'un préfixe, agencés pour former un préfixe réseau associé au 20 routeur par concaténation d'une valeur prédéfinie propre à un réseau privé et d'une pluralité de bits extraits du haché calculé, - des moyens de génération et de signature d'un certificat, agencés pour générer et signer au moyen de la clé privée le certificat de la clé publique. L'invention concerne aussi un noeud dans un réseau privé IPv6 comprenant au moins un 25 routeur, le noeud comprenant : - des moyens de réception, agencés pour recevoir en provenance du routeur un message d'annonce de préfixe comprenant un certificat numérique d'une clé publique et de titulaire le routeur, et une information signée au moyen d'une clé privée propre au routeur et associée à la clé publique certifiée, l'information comprenant au moins un préfixe généré par le routeur, 30 - des moyens de calcul, agencés pour calculer un deuxième préfixe à partir de la clé publique du certificat, - des moyens de comparaison, agencés pour comparer le préfixe annoncé et le deuxième préfixe, - des moyens de vérification de signature, agencés pour vérifier la signature de 35 l'information signée au moyen de la clé publique certifiée par le certificat. Avantageusement, l'invention porte aussi sur un réseau privé IPv6 comprenant : - au moins un routeur selon l'invention, et - au moins un noeud selon l'invention. Un tel réseau est par exemple un réseau privé d'entreprise, ou un réseau ad-hoc. Dans le cadre de l'invention les entités de ces réseaux, en l'espèce des routeurs et des noeuds réseau selon l'invention peuvent mettre en place leur plan d'adressage privé facilement et de manière sécurisée.
L'invention concerne aussi un programme d'ordinateur destiné à être installé dans une mémoire d'un routeur, comprenant des instructions pour la mise en oeuvre des étapes du procédé d'allocation sécurisée d'un préfixe réseau selon l'invention, lorsque le programme est exécuté par un processeur. L'invention porte également sur un programme d'ordinateur destiné à être installé dans une mémoire d'un noeud réseau, comprenant des instructions pour la mise en oeuvre des étapes du procédé pour générer une adresse IPv6 selon l'invention lorsque le programme est exécuté par un processeur.
De nombreux détails et avantages de l'invention seront mieux compris à la lecture de la 15 description d'un mode particulier de réalisation en référence aux schémas annexés donnés à titre non limitatif et dans lesquels : - la figure 1 représente les étapes du procédé d'allocation sécurisée d'une adresse IPv6 à un noeud dans un réseau privé, selon un premier mode de réalisation de l'invention ; - la figure 2 représente un premier exemple de réalisation d'un routeur selon l'invention ; 20 - la figure 3 représente un exemple de réalisation d'un noeud réseau selon l'invention.
Les étapes d'un exemple de réalisation du procédé d'allocation sécurisée d'une adresse IPv6 à un noeud d'un réseau privé vont maintenant être décrites en relation avec la figure 1. Un noeud N dans un réseau privé (non représenté) est adapté pour générer une adresse 25 conforme au protocole IPv6 selon un mécanisme d'auto-configuration. Le réseau privé comprend également un routeur RT situé sur un même lien réseau que le noeud N. Il est connu que selon le protocole IPv6, une adresse IP de 128 bits comprend dans une première partie de 64 bits un préfixe réseau, et dans une deuxième partie de 64 bits un identifiant d'interface. Il est connu également que des entités d'un réseau privé, comme par exemple le noeud N et le routeur RT, ont un préfixe réseau 30 qui débute par une valeur prédéfinie de 8 bits, comprenant un champ appelé « Prefix » de 7 bits et un champ nommé « L » de 1 bit. Le champ « Prefix » a comme valeur « FC00 ::/7 » et le champ « L » vaut « 1 », conformément à la RFC 4193. Ces 8 bits sont réservés pour préfixer toute adresse dans un réseau privé. De telles adresses sont qualifiées d'adresses locales et ne sont pas destinées à être routées dans le réseau Internet global. 35 Dans une étape initiale 10, le routeur RT génère un couple de clés privée/publique conformément à un algorithme de cryptographie asymétrique, par exemple «RSA» (du nom de leurs auteurs « Rivest, Shamir et Adleman »). Notons ce couple de clés (Kpr, Kpub). Dans un autre exemple de réalisation, il se voit attribuer un tel couple de manière sécurisée par une entité adaptée pour générer et délivrer des couples de clés. Dans une étape 11 de création d'une donnée pour la génération d'un préfixe, le routeur RT concatène la valeur de la clé publique Kpub avec un ensemble de paramètres choisis par le routeur pour la génération courante de préfixe réseau. Des exemples de paramètres sont la date de génération du préfixe, un aléa (ou « Nonce »), l'adresse «MAC» du routeur RT (de l'anglais « Media Access Control »), un identifiant d'interface du routeur RT. Les paramètres concaténés à la clé publique sont destinés à éviter que lors d'une nouvelle génération de préfixe par le routeur à partir du même couple de clés privée/publique, le nouveau préfixe généré soit identique au préfixe précédemment généré. Les paramètres participent à la fabrication du préfixe réseau. La donnée créée à l'étape 11 est le résultat de la concaténation de la clé publique avec l'ensemble des paramètres. Dans une étape 12 de hachage, le routeur RT procède au hachage de la donnée obtenue à l'étape précédente. Il utilise par exemple la fonction « SHA-1 » (« Secure Hash Algorithm ») qui fournit une empreinte de 160 bits. Dans une étape 13 d'extraction de bits, le routeur RT applique une fonction F au haché obtenu précédemment afin d'obtenir 56 bits. La fonction F peut prendre plusieurs formes. Par exemple, elle peut consister à extraire du haché les 56 bits de poids fort, ou les 56 bits de poids faible, ou les 56 premiers bits pairs, ou les 56 premiers bits impairs. La fonction F n'est bien sûr pas limitée à ces exemples. Dans une étape 14 d'obtention d'un préfixe, le routeur RT concatène les 8 premiers bits de la valeur prédéfinie réservée pour désigner qu'une adresse IPv6 correspond à une adresse dans un réseau privé, aux 56 bits obtenus au cours de l'étape précédente. La donnée résultante de 64 bits définit le préfixe du routeur RT dans le réseau privé. Le préfixe obtenu au terme de cette étape 14 est noté PFX. Ainsi, le préfixe PFX obtenu est la concaténation des 7 bits du champ « Prefix » de valeur «FC00 ::/7 », avec le bit « L » de valeur « 1 » et avec les 56 bits obtenus au cours de l'étape 13. Dans une étape 15 de génération et de signature d'un certificat, le routeur RT génère un certificat, ici au format X.509 version 3, adapté pour certifier la clé publique Kpib du routeur RT.
Le certificat X.509v3 est une structure de données comprenant plusieurs champs, parmi lesquels figurent : l'identité du titulaire du certificat (champ « subject »), la valeur de la clé publique certifiée, le préfixe généré, afin de lier celui-ci au titulaire du certificat, l'identité de l'autorité de certification qui signe le certificat et donc qui certifie l'authenticité de la clé publique, et une signature numérique de l'ensemble des champs.
Dans l'exemple de réalisation décrit ici, le titulaire du certificat est le routeur RT désigné par son adresse IP, et l'Autorité de Certification qui certifie la clé publique est le routeur RT. Ainsi, le certificat généré par le routeur RT est qualifié de certificat auto-signé puisque c'est le routeur RT, titulaire du certificat, qui certifie l'authenticité de la clé publique en signant l'ensemble des champs du certificat au moyen de la clé privée Kp,;,, associée à la clé publique Kpub qui figure dans le certificat. Dans une étape 16 d'envoi, le routeur RT envoie sur le lien réseau un message RA d'annonce du préfixe PFX généré au cours des étapes précédentes. Plus précisément, le message RA comprend une information signée par le routeur RT au moyen de la clé privée Kp,;v, et le certificat généré et auto-signé par le routeur RT au cours de l'étape 15. L'information comprend le préfixe PFX obtenu à l'étape 14, l'ensemble des paramètres choisis par le routeur au cours de l'étape 11 de création d'une donnée pour la génération d'un préfixe, et une durée de vie indiquant combien de temps les adresses IPv6 créées à partir du préfixe PFX sont valables. La durée de vie est un paramètre habituellement envoyé dans un message d'annonce RA. On remarque que la clé publique certifiée par le certificat et l'ensemble des paramètres qui sont transmis dans le message d'annonce permettent de recalculer le préfixe PFX. Le message RA d'annonce du préfixe est envoyé par le routeur RT sur le lien réseau sur lequel il se situe à intervalle régulier. Dans un autre exemple de réalisation (non représenté), le message d'annonce RA est envoyé suite à une sollicitation du noeud N.
Dans une étape 17 de réception, le noeud N reçoit le message d'annonce RA. Dans une étape 18 de calcul d'un deuxième préfixe PFX', le noeud N calcule un deuxième préfixe à partir du message d'annonce reçu. A cette fin, dans une sous-étape 18-1 de création d'une donnée pour générer le deuxième préfixe, le noeud N extrait du certificat reçu dans le message RA la clé publique Kpub certifiée. Il extrait également de l'information reçue dans le message d'annonce RA l'ensemble des paramètres qui, concaténés à la clé publique Kpub à l'étape 11, ont permis d'obtenir la donnée utilisée pour générer le préfixe. Puis dans une sous-étape 18-2 de calcul d'un haché, le noeud N applique une fonction de hachage à la donnée obtenue à la sous-étape 18-1 précédente. La fonction de hachage est la même fonction que celle utilisée par le routeur RT au cours de l'étape 12 de hachage, SHA-1 dans l'exemple décrit ici. Dans une sous-étape 18-3 d'extraction de bits, le noeud N extrait 56 bits du haché calculé à la sous-étape 18-2. Les bits sont extraits de la même manière que par le routeur RT au cours de l'étape 13 : en appliquant le même fonction F au haché calculé à la sous-étape 18-2. Puis, dans une sous-étape 18-4 d'obtention du deuxième préfixe, le noeud N concatène les 8 bits de la valeur prédéfmie réservée pour désigner qu'une adresse IPv6 correspond à un adresse dans un réseau privé aux 56 bits obtenus au cours de la sous-étape 18-3. Au terme de la sous-étape 18-4, le noeud N a construit un deuxième préfixe PFX' de 64 bits.
Dans une étape 19 de comparaison, le noeud N compare le préfixe PFX reçu du routeur RT dans le message d'annonce RA au cours de l'étape 17 au deuxième préfixe PFX' calculé par le noeud N au cours de l'étape 18. Si les préfixes comparés à l'étape 19 sont égaux, alors dans une étape suivante 20 de vérification de signature, le noeud N vérifie la signature de l'information reçue dans le message d'annonce RA. Cette vérification est effectuée au moyen de la clé publique Kpub extraite du certificat. La vérification de signature n'est effectuée que si les préfixes sont identiques. En effet, cette vérification est coûteuse en termes de ressources de calcul et est inutile si les préfixes ne sont pas identiques. En effet, dans ce cas, cela signifie que le préfixe PFX reçu du routeur RT n'a pas été calculé à partir de la clé publique certifiée extraite du certificat reçu et de l'ensemble de paramètres reçus. Si la vérification de signature effectuée au cours de l'étape 20 est positive, alors cela signifie que le routeur RT qui a envoyé le message d'annonce RA est bien légitime pour annoncer le préfixe PFX puisqu'il possède la clé secrète qui a été utilisée pour signer l'information reçue.
Dans une étape suivante 21 de formation d'une adresse lPv6, le noeud N génère sa propre adresse Il'v6 dans le réseau privé en concaténant le préfixe PFX reçu du routeur RT avec un identifiant d'interface IID qui lui est propre. Il obtient cet identifiant d'interface par exemple à partir d'un haché de son adresse MAC. Les étapes 11 à 15 sont exécutées par le routeur RT chaque fois que le préfixe de celui-ci doit être renouvelé. Une telle procédure est rare et est à l'initiative d'un administrateur du réseau. Dans une variante de réalisation du renouvellement de préfixe, l'étape 10 est également exécutée. Dans une variante de réalisation du procédé d'allocation sécurisée d'une adresse IPv6 dans un réseau privé, aucun paramètre n'est concaténé à la clé publique Kp'b au cours de l'étape 11 de création d'une donnée pour la génération d'un préfixe. Ainsi, seule la clé publique du routeur est utilisée pour la génération du préfixe. Cette variante est envisageable lorsque le routeur utilise un nouveau couple de clés privée/publique lors d'une génération d'un nouveau préfixe. En effet, dans ce cas, le nouveau préfixe généré est nécessairement différent du précédent préfixe, puisque la clé publique utilisée comme paramètre de la fonction de hachage est différente. L'invention n'est pas limitée à la fonction de hachage SHA-1 pour le calcul du haché par le routeur RT au cours de l'étape 12, et par le noeud N au cours de la sous-étape 18-2. D'autres fonctions de hachage peuvent être utilisées, comme par exemple MD-5 (« Message Digest ») qui génère une empreinte de 128 bits, ou SHA-256 qui génère une empreinte de 256 bits. Il est par contre nécessaire que le routeur RT et le noeud N utilisent la même fonction de hachage.
Dans l'exemple de réalisation décrit ici, un certificat X.509 est utilisé. Quelques champs d'un certificat X.509 ont été présentés ci-avant. La RFC 2459 fournit une description détaillée des certificats X.509 et la RFC 3779 présente des extensions utilisées pour les adresses IP et apparues dans la version 3 de X.509. Un certificat X.509 est une structure de données qui comprend une pluralité de champs. En particulier, le certificat comprend : - un numéro de version ; v3 est la version adaptée pour l'invention, - un numéro de série, - l'identité de l'Autorité de Certification émettrice du certificat, en l'espèce le routeur RT, désigné par son adresse W, - le nom de l'algorithme de signature utilisé par l'Autorité de Certification pour signer le certificat, - une période de validité du certificat, - le nom du titulaire du certificat (correspondant au champ «subject »), en l'espèce le routeur RT désigné par son adresse IP ; - des informations sur la clé publique : - algorithme à utiliser avec la clé publique, - la clé publique proprement dite, - des informations optionnelles, apparues selon la version de la norme et relatives au détenteur et/ou au signataire et/ou à des extensions, et - la signature du certificat par l'Autorité de Certification, ici, le routeur RT. Parmi les informations optionnelles apparues dans la version 3 des certificats X.509, un premier champ, appelé « KeyUsage » caractérise l'usage qui peut être fait de la clé publique. Par exemple il est précisé que la clé publique certifiée (et donc la clé privée associée) est destinée à être utilisée pour de la signature, du chiffrement, de la signature de certificat. Un deuxième champ, appelé « ExtendedKeyUsage » est adapté pour indiquer un ou plusieurs usages de la clé publique certifiée en plus, ou en remplacement de l'usage précisé dans le champ précédent. Un tel champ peut être précisé selon des besoins propres d'une organisation. Ainsi, ce champ est adapté pour préciser, dans le cadre de l'invention, que la clé publique certifiée peut être utilisée pour générer un préfixe réseau. Par ailleurs, une extension définie dans le RFC 3779 introduit un champ qui permet de lier une adresse W, tel qu'un préfixe à un titulaire de certificat. Ce champ désigné « addressesOrRange » est utilisé dans l'invention pour lier le préfixe généré au routeur RT.
Un routeur RT selon un exemple de réalisation de l'invention va maintenant être décrit en relation avec la figure 2. Un routeur RT selon l'invention assure une fonction de base d'un routeur : le routage de paquets. En tant que routeur, il permet à des noeuds qui sont sur le même lien réseau que lui d'accéder à d'autres noeuds du même lien ou d'un autre lien du même réseau. Il permet également à ces noeuds d'accéder à un ou plusieurs autres réseaux. Pour que le routage de paquets soit possible, le routeur RT annonce un préfixe réseau sur le lien réseau sur lequel il se situe, afin que des noeuds situés sur ce lien génèrent une adresse réseau qui leur est propre et qui les associe, pour le routage, au routeur RT. Le routeur annonce le préfixe régulièrement ou sur sollicitation d'un noeud. Le réseau RT comprend : - un microprocesseur 201, ou "CPU" (de l'anglais "Central Processing Unit") qui est une unité de traitement ; - une mémoire vive 202 qui permet d'effectuer des calculs tels que par exemple calculer un haché, une signature, générer un certificat, le signer. La mémoire permet également de charger des instructions logicielles correspondant aux étapes du procédé d'allocation sécurisée d'un préfixe réseau dans un réseau privé décrites précédemment, et de les faire exécuter par le processeur 201 ; - une mémoire de stockage 203, par exemple une mémoire de type « ROM » (de l'anglais « Read Only Memory »), adaptée pour stocker par exemple un certificat auto-signé généré par le routeur et dont le titulaire est le routeur RT, un couple clé privée/clé publique. Dans une variante, la mémoire peut contenir une zone sécurisée adaptée pour stocker de manière sécurisée la clé secrète du routeur ; - des interfaces réseau 204, adaptées pour permettre à des entités telles que des noeuds du réseau privé, ou un autre routeur du réseau privé, ou des routeurs d'un autre réseau de communiquer avec le routeur RT. Elles permettent d'autre part au routeur RT d'accéder à un ou plusieurs réseaux, par exemple le réseau Internet, et de fournir ainsi l'accès au réseau aux noeuds du réseau privé qui s'appuient sur lui pour router leurs paquets ; - des moyens 205 de génération d'un couple de clés privée/publique propre au routeur RT. Ces moyens comprennent par exemple une fonction RSA et des moyens de choisir des nombres premiers. Une fois généré, le couple de clés peut être mémorisé dans la mémoire de stockage 203. Les moyens 205 mettent en oeuvre l'étape 10 du procédé d'allocation sécurisée décrite précédemment ; - des moyens 206 de génération d'un certificat, par exemple un certificat X.509v3 adapté pour certifier la clé publique du couple clé privée/clé publique généré par les moyens 205. Ces moyens 206 de génération sont agencés pour compléter des champs d'un certificat X.509v3. Par exemple, ces moyens remplissent les champs titulaire et signataire du certificat avec l'adresse IP du routeur. C'est en effet pour le routeur RT que le certificat est généré et c'est le routeur RT qui signe le certificat en tant qu'Autorité de Certification. Les moyens 206 de génération précisent également dans une extension X.509v3 appelée « addressesOrRange » le préfixe réseau généré par le routeur ; cette extension est destinée à lier le préfixe réseau au titulaire du certificat. Ces moyens 206 précisent également dans un champ « ExtendedKeyUsage » une valeur indiquant que le procédé d'allocation sécurisée d'un préfixe réseau selon l'invention est mis en oeuvre. Ce champ est destiné à préciser un usage de la clé publique certifiée.; - des moyens 207 de signature, agencés pour signer le certificat généré par les moyens 206 au moyen de la clé privée du couple clé privée/clé publique. Les moyens 206 de génération et les moyens 207 de signature mettent en oeuvre l'étape 15 du procédé d'allocation précédemment décrit; - des moyens de calcul 208, agencés pour calculer un haché d'une donnée comprenant la clé publique associée à la clé privée propre au routeur. Ces moyens 208 de calcul comprennent une fonction de hachage, par exemple SHA-1. Les moyens 208 de calcul mettent en oeuvre l'étape 12 de concaténation et l'étape 12 de hachage du procédé d'allocation précédemment décrite ; - des moyens 209 de formation d'un préfixe réseau, agencés pour concaténer une valeur prédéfinie propre à un réseau privé et une pluralité de bits extraits du haché calculé par les moyens de calcul 208. Les moyens 209 de formation d'un préfixe réseau mettent en oeuvre l'étape 13 d'extraction de bits et l'étape 14 du procédé d'allocation précédemment décrit ; - des moyens 210 d'envoi d'un message d'annonce, agencés pour envoyer vers le ou les noeuds réseau situés sur le même lien réseau que le routeur un message d'annonce de préfixe comprenant le certificat numérique associé à la clé publique, ainsi qu'une information signée comprenant au moins le préfixe formé par le routeur, l'information étant signée au moyen de la clé privée. Les moyens d'envoi 210 coopèrent avec les interfaces réseau 204 pour envoyer le message d'annonce sur le lien réseau. Les moyens d'envoi 210 mettent en oeuvre l'étape 16 d'envoi du procédé d'allocation précédemment décrit. Les interfaces réseau 204, les moyens 205 de génération d'un couple de clés, les moyens 206 de génération d'un certificat X.509v3, les moyens 207 de signature, les moyens 208 de calcul du haché, les moyens 209 de formation d'un préfixe réseau et les moyens 210 d'envoi d'un message d'annonce sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé d'allocation sécurisée d'un préfixe réseau précédemment décrit, mises en oeuvre par le processeur d'un routeur. L'invention concerne donc aussi : - un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé d'allocation sécurisée d'un préfixe réseau tel que décrit précédemment lorsque ce programme est exécuté par un processeur ; - un support d'enregistrement lisible par un routeur sur lequel est enregistré le programme d'ordinateur décrit ci-dessus.
Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau de télécommunication.
Un noeud réseau N selon un exemple de réalisation de l'invention va maintenant être décrit en relation avec la figure 3.
Un tel noeud peut être toute machine informatique telle qu'un terminal utilisateur, ou un serveur, utilisés dans un réseau privé. Un tel noeud est apte à communiquer avec d'autres entités, telles que le routeur RT ou un autre noeud du réseau privé. Il est également apte à communiquer avec des entités d'un autre réseau, via le réseau Internet. Les paquets qu'il émet ou reçoit sont routés par le routeur RT. Le noeud N comprend : - un microprocesseur 301, ou "CPU" (de l'anglais "Central Processing Unit") qui est une unité de traitement ; - une mémoire vive 302 qui permet d'effectuer des calculs tels que par exemple calculer des hachés, vérifier des signatures, faire des comparaisons, des concaténations. La mémoire permet également de charger des instructions logicielles correspondant aux étapes du procédé pour générer une adresse IPv6 dans un réseau privé décrites précédemment, et de les faire exécuter par le processeur 301 ; - une mémoire de stockage 303, par exemple une mémoire ROM, adaptée pour stocker par exemple le préfixe réseau, le certificat reçu d'un routeur, la clé publique ; - des interfaces réseau 304, adaptées pour permettre à d'autres entités du réseau privé, par exemple le routeur RT (non représenté) de communiquer avec le noeud N et au noeud N de communiquer avec ces autres entités. Elles permettent également d'accéder aux entités d'un autre réseau via Internet, par le biais du routeur RT qui a en charge le routage de paquets en provenance et à destination du noeud N ; - des moyens 305 de réception, agencés pour recevoir en provenance d'un routeur situé sur le même lien réseau un message RA d'annonce de préfixe comprenant un certificat numérique, adapté pour certifier une clé publique associée à une clé privée propre à ce routeur, et une information signée, l'information comprenant au moins un préfixe généré par le routeur. Les moyens 305 de réception coopèrent avec les interfaces réseau 304. Les moyens 305 de réception mettent en oeuvre l'étape 17 du procédé pour générer une adresse IPv6, décrite précédemment ; - des moyens 306 de calcul, agencés pour calculer un deuxième préfixe PFX' à partir de la clé publique certifié par le certificat et reçu par les moyens 305 de réception. Les moyens 306 de calcul mettent en oeuvre l'étape 18 de calcul d'un deuxième préfixe du procédé pour générer un deuxième préfixe décrit précédemment. Plus précisément, les moyens 306 de calcul mettent en oeuvre les sous-étapes 18-1 de concaténation, 18-2 de calcul d'un haché, 18-3 d'extraction et 18-4 d'obtention d'un préfixe ; - des moyens 307 de comparaison, agencés pour comparer le préfixe annoncé reçu dans le message d'annonce par les moyens de réception 305 et le deuxième préfixe calculé par les moyens 306 de calcul. Les moyens 307 de comparaison mettent en oeuvre l'étape 19 de comparaison du procédé pour forger une adresse lPv6, décrite précédemment ; - des moyens 308 de vérification de signature, agencés pour vérifier la signature de l'information signée reçue dans le message d'annonce par les moyens 305 de réception. Les moyens de vérification 308 utilisent la clé publique certifiée par le certificat. Les moyens 308 de vérification de signature mettent en oeuvre l'étape 20 de vérification du procédé pour forger une adresse IPv6, décrite précédemment ; - le noeud N comprend également des moyens 309 de concaténation, agencés pour concaténer un préfixe généré par le routeur et reçu par les moyens 305 de réception avec un identifiant d'interface propre au noeud. Les moyens de concaténation 309 comprennent des moyens de calcul de l'identifiant d'interface, obtenu par exemple en appliquant une fonction de hachage à l'adresse MAC du noeud N. Les moyens 309 de concaténation mettent en oeuvre l'étape 21 de formation d'une adresse lPv6 du procédé pour forger une adresse IPv6, décrite précédemment.
Les interfaces réseau 304, les moyens 305 de réception, les moyens 306 de calcul, les moyens 307 de comparaison, les moyens 308 de vérification de signature et les moyens 309 de concaténation pour former une adresse IPv6 sont de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé pour forger une adresse IPv6 précédemment décrit, mises en oeuvre par le processeur d'un noeud réseau.
L'invention concerne donc aussi : - un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé pour générer une adresse IPv6 tel que décrit précédemment lorsque ce programme est exécuté par un processeur; - un support d'enregistrement lisible par un routeur sur lequel est enregistré le programme d'ordinateur décrit ci-dessus. Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau de télécommunication.
L'invention concerne également un réseau privé comprenant au moins un routeur selon l'invention et au moins un noeud réseau selon l'invention. Le noeud réseau est situé sur un même lien réseau que le routeur.

Claims (5)

  1. REVENDICATIONS1. L Procédé d'allocation sécurisée d'un préfixe réseau REVENDICATIONS1. L Procédé d'allocation sécurisée d'un préfixe réseau (PFX) dans un réseau privé, le réseau comprenant au moins un routeur (RT) et au moins un noeud réseau (N), le procédé comprenant une étape (16) d'envoi par le routeur vers le noeud réseau d'un message (RA) d'annonce de préfixe, ledit message comprenant : - un certificat numérique d'une clé publique (Kpub) dont le titulaire est le routeur, - une information signée comprenant au moins un préfixe réseau généré par le routeur, l'information étant signée au moyen d'une clé privée (Kp,;,,) propre au routeur et associée à la clé publique certifiée.
  2. 2. Procédé selon la revendication 1, comprenant : - une étape (12) de calcul d'un haché d'une donnée comprenant la clé publique, 15 - une étape (14) de formation du préfixe réseau par concaténation d'une valeur prédéfinie propre à un réseau privé et d'une pluralité de bits extraits du haché calculé.
  3. 3. Procédé selon la revendication 2, comprenant en outre : - une étape (15) de génération par le routeur du certificat numérique de la clé publique, et 20 de signature du certificat par le routeur au moyen de la clé privée.
  4. 4. Procédé selon la revendication 3, comprenant une étape (10) de génération par le routeur d'un couple de clés comprenant la clé privée et la clé publique associée. 25
  5. 5. Procédé pour générer une adresse IPv6 par un noeud dans un réseau privé, le réseau comprenant au moins un routeur, le procédé comprenant : - une étape (17) de réception en provenance du routeur d'un message (RA) d'annonce de préfixe comprenant un certificat numérique d'une clé publique et de titulaire le routeur, et une information signée au moyen d'une clé privée propre au routeur et associée à la clé publique 30 certifiée, l'information comprenant au moins un préfixe généré par le routeur, - une étape (18) de calcul d'un deuxième préfixe (PFX') à partir de la clé publique du certificat, - une étape (19) de comparaison du préfixe reçu et du deuxième préfixe calculé, - une étape (20) de vérification de la signature de l'information au moyen de la clé publique 35 certifiée par le certificat., Procédé selon la revendication 5, dans lequel l'étape de vérification de la signature n'est réalisée que si le préfixe reçu du routeur est égal au deuxième préfixe calculé. 7. Procédé selon la revendication 5, comprenant en outre une étape (21) de concaténation du préfixe reçu avec un identifiant d'interface propre au noeud. 8. Certificat numérique X.509v3 de clé publique destiné au routeur, comprenant un champ « ExtendedKeyUsage » adapté pour indiquer un usage associé à la clé publique, caractérisé en ce que le champ comprend une valeur indiquant que la clé publique est destinée à être utilisée pour mettre en oeuvre le procédé selon la revendication 1. 9. Routeur (RT) dans un réseau privé comprenant au moins un noeud réseau, le routeur comprenant : - des moyens (210) d'envoi, agencés pour envoyer vers le noeud réseau un message d'annonce de préfixe comprenant un certificat numérique d'une clé publique dont le titulaire est le routeur, ainsi qu'une information signée comprenant au moins un préfixe réseau généré par le routeur, l'information étant signée au moyen d'une clé privée propre au routeur et associée à la clé publique certifiée. 10. Routeur selon la revendication 9 comprenant en outre : - des moyens (208) de calcul, agencés pour calculer un haché d'une donnée comprenant la clé publique certifiée, - des moyens (209) de formation d'un préfixe, agencés pour former un préfixe réseau associé au routeur par concaténation d'une valeur prédéfinie propre à un réseau privé et d'une pluralité de bits extraits du haché calculé, - des moyens (206, 207) de génération et de signature d'un certificat, agencés pour générer et signer au moyen de la clé privée le certificat de la clé publique. 11. Noeud (N) dans un réseau privé lPv6 comprenant au moins un routeur, le noeud 30 comprenant : - des moyens (305) de réception, agencés pour recevoir en provenance du routeur un message d'annonce de préfixe comprenant un certificat numérique d'une clé publique dont le titulaire est le routeur, et une information signée au moyen d'une clé privée propre au routeur et associée à la clé publique certifiée, l'information comprenant au moins un préfixe généré par le 35 routeur, - des moyens (306) de calcul, agencés pour calculer un deuxième préfixe à partir de la clé publique du certificat,- des moyens (307) de comparaison, agencés pour comparer le préfixe annoncé et le deuxième préfixe, - des moyens (308) de vérification de signature, agencés pour vérifier la signature de l'information signée au moyen de la clé publique certifiée par le certificat. 12. Réseau privé IPv6 comprenant : - au moins un routeur selon la revendication 9, et - au moins un noeud selon la revendication 11. 10 13. Programme d'ordinateur destiné à être installé dans une mémoire d'un routeur, comprenant des instructions pour la mise en oeuvre des étapes du procédé d'allocation sécurisée d'un préfixe réseau selon l'une des revendications 1 à 4, lorsque le programme est exécuté par un processeur. 15 14. Support de données sur lequel est enregistré le programme d'ordinateur selon la revendication 13. 15. Programme d'ordinateur destiné à être installé dans une mémoire d'un noeud réseau, comprenant des instructions pour la mise en oeuvre des étapes du procédé pour générer une adresse 20 IPv6 selon l'une des revendications 5 à 7 lorsque le programme est exécuté par un processeur. 16. Support de données sur lequel est enregistré le programme d'ordinateur selon la revendication 15.5
FR1055262A 2010-06-29 2010-06-29 Procede d'allocation securisee d'une adresse ipv6 a un noeud d'un reseau prive Pending FR2961994A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1055262A FR2961994A1 (fr) 2010-06-29 2010-06-29 Procede d'allocation securisee d'une adresse ipv6 a un noeud d'un reseau prive
PCT/FR2011/051442 WO2012001273A1 (fr) 2010-06-29 2011-06-23 PROCEDE D'ALLOCATION SECURISEE D'UNE ADRESSE IPv6 A UN NŒUD D'UN RESEAU PRIVE

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1055262A FR2961994A1 (fr) 2010-06-29 2010-06-29 Procede d'allocation securisee d'une adresse ipv6 a un noeud d'un reseau prive

Publications (1)

Publication Number Publication Date
FR2961994A1 true FR2961994A1 (fr) 2011-12-30

Family

ID=43333303

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1055262A Pending FR2961994A1 (fr) 2010-06-29 2010-06-29 Procede d'allocation securisee d'une adresse ipv6 a un noeud d'un reseau prive

Country Status (2)

Country Link
FR (1) FR2961994A1 (fr)
WO (1) WO2012001273A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106453651B (zh) * 2016-11-30 2020-01-31 中国互联网络信息中心 一种rpki资料库及数据同步方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009109221A1 (fr) * 2008-03-04 2009-09-11 Telefonaktiebolaget Lm Ericsson (Publ) Délégation d'adresse ip

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009109221A1 (fr) * 2008-03-04 2009-09-11 Telefonaktiebolaget Lm Ericsson (Publ) Délégation d'adresse ip

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MYUNG-EUN KIM ET AL: "The study on secure auto-configuration technology in IPv6", ADVANCED COMMUNICATION TECHNOLOGY, 2005, ICACT 2005. THE 7TH INTERNATI ONAL CONFERENCE ON PHOENIX PARK, KOREA FEB. 21-23, 2005, PISCATAWAY, NJ, USA,IEEE, vol. 1, 21 February 2005 (2005-02-21), pages 85 - 88, XP010813565, ISBN: 978-89-5519-123-3 *

Also Published As

Publication number Publication date
WO2012001273A1 (fr) 2012-01-05

Similar Documents

Publication Publication Date Title
US8843740B2 (en) Derived certificate based on changing identity
US8098823B2 (en) Multi-key cryptographically generated address
JP5215476B2 (ja) 分散された記憶ネットワークにおけるデータ許可のためのシステムおよび方法
US8843751B2 (en) IP address delegation
US11728999B2 (en) Secure router authentication
CN109714447B (zh) 基于区块链域名系统的域名生成方法和系统
CN113661683B (zh) 在分布式网络中存储表示资产转移的交易的方法及其程序
CN113382002B (zh) 数据请求方法、请求应答方法、数据通信系统及存储介质
EP2186252B1 (fr) Procede de distribution de cles cryptographiques dans un reseau de communication
CN111314269B (zh) 一种地址自动分配协议安全认证方法及设备
WO2019165330A1 (fr) Système et procédés de preuve d&#39;un élément de réseau
CN115580498B (zh) 融合网络中的跨网通信方法及融合网络系统
FR2961994A1 (fr) Procede d&#39;allocation securisee d&#39;une adresse ipv6 a un noeud d&#39;un reseau prive
EP3211826B1 (fr) Méthode de gestion de certificats implicites au moyen d&#39;une infrastructure à clés publiques distribuée
CA2795420C (fr) Certificat remanie en fonction de l&#39;identite changeante
Su et al. Secure DHCPv6 that uses RSA authentication integrated with self-certified address
CN115883088B (zh) 基于bgp路由的自治域安全参数更新方法
KR20150040174A (ko) 컨텐츠 검증 방법 및 장치
KR100917392B1 (ko) IPv6 네트워크에서 인접 노드의 탐색 메시지를송수신하는 방법
FR2900523A1 (fr) Identification de noeuds dans un reseau
Perrig et al. Configuration File Formats
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
Roelofs Ad-hoc trust associations with Trust Anchor Repositories
FR2900776A1 (fr) Procede de securisation de donnees