FR 2838897 A1 20031024 FR 0304246 A 20030404 dispositif par une adresse du troisieme dispositif. La presente invention concerne la formation et l'utilisation de connexions de reseau securisees. Wile concerne plus precisement la formation de connexions de reseau modulables securisees pour de multiples dispositifs, et en particulier un procede pour mettre en muvre des communications securisees, ainsi qu'un servour multipoint pour etablir des connexions securisees entre les dispositifs d'un reseau. Les reseaux informatiques et en particulier les reseaux a grande distance (WAN), tels que le reseau Internet, offrent la possibilite d'un usage impropre et abusif des communications vehiculees par leur intermediaire. Par exemple, les communications entre deux utilisateurs communiquant par l'intermediaire d'un WAN peuvent etre interceptees et/ou alterees. Un utilisateur peut egalement se presenter sous une fausse identite a un autre utilisateur. Enfin, un utilisateur peut, par exemple, utiliser des ressources de reseau et des communications etablies sur un reseau pour perturber ou interrompre le reseau en partie ou en totalite. Il y a done un besoin de confidentialite et d'authentification entre les utilisateurs d'un WAN qui communiquent les uns avec les autres. En d'autres termes, les utilisateurs doivent pouvoir compter sur le fait que leurs transmissions ne seront pas interceptees ou alterees, et que des transmissions emanant de quelqutun qui se pretend etre un utilisateur particulier proviennent effectivement de cet utilisateur. L'un des moyens pour se defendre contre une utilisation malintentionnee d'un reseau a grande distance est un dispositif qui fonctionne a la limite d'un reseau prive, tel qu'une passerelle, un dispositif s coupe-feu ou un autre appareil de reseau specialise. Ce type de dispositif agit pour filtrer les transmissions entre le reseau prive et le reseau a grande distance et/ou pour proteger les transmissions qui ont effectivement lieu par un cryptage/decryptage (c'est-a dire un codage/decodage) de ces transmissions. D'autres types de moyens de defense apparentes agissent en etablissant l'identite d'un emetteur et/ou d'un recepteur avant ['emission/reception d'une communication. I1 existe encore d'autres moyens de protection qui consistent en l'etablissement d'un canal securise entre deux dispositifs de communication. Un protocole conventionnel part iculier pour as surer une securite entre des dispositifs fonctionnant sur un reseau a Protocole Internet (IP) est connu sous le nom de IPsec. Abreviation de ['expression securite selon IP, IPsec est en fait un ensemble de protocoles permettant de securiser l'echange de paquets de type IP au niveau d'une couche reseau. Deux des protocoles utilises vent le protocole d' en-tete d' authentification (Authentification Header protocol (AH)) et le protocole de champ de donnees de securite d' encapsulation (Encapsulation Security Payload protocol (ESP)). Le protocole AH est concu pour assurer que des paquets transmis ne seront pas alteres au cours de leur transit sur le reseau, mais il ntempeche pas que le contenu des paquets puisse etre visualise par d'autres utilisateurs du reseau, c'est-a-dire qu'il n'empeche pas leur interception par des tiers. Le protocole ESP, en revanche, assure la confidentialite du contenu des paquets. Ce protocole ESP offre un mecanisme d'authentification facultatif. Toutefois, ce mecanisme est uniquement destine a authentifier le champ de donnees du paquet (et les en-tetes/terminaisons ESP associes). Le protocole ESP n'authentifie done pas lten-tete IP d'un paquet, indiquant une adresse IP d'origine sur le reseau a partir de laquelle le paquet a ete emis. I1 est egalement possible d'utiliser les protocoles AH et ESP en combinaison l'un avec l'autre, afin d'obtenir les avantages des deux protocoles. Que ce soit dans le cas de l'utilisation du protocole AH ou du protocole ESP, l'IPsec fonctionne soit en mode transport soit en mode tunnel. Le mode transport est souvent utilise pour des communications dthote a hose, c'est-a-dire lorsque les dispositifs pairs ou homologues constituent les points terminaux d'une communication. Le mode transport est plus utile dans un environnement IPsec global comprenant les deux points terminaux. Le mode tunnel est habituellement ut il i se dans le cas de communications ent re un systeme protege par l'IPsec et un autre point terminal, comme par exemple des communications emises a partir d'un reseau prive sur le reseau Internet. En mode tunnel, le 2s champ de donnees d'un paquet IP securise est porteur d'un autre paquet contenant le champ de donnees reelles a transmettre. Une utilisation courante du mode tunnel consiste a mettre en uvre un reseau prive virtuel (VPN). Les VPN vent des reseaux qui utilisent des ressources de reseau a la disposition du public, telles que les ressources d'Internet, pour construire un reseau accessible uniquement par des utilisateurs selectionnes. Par exemple, une societe peut creer sa propre version d'un reseau local a l' aide du reseau Internet, ou bien une pers onne pratiquant le tel et rava i l peut etre en mesure d'utiliser les ressources dont une societe dispose au niveau de son siege principal. Pour mettre en muvre les differents protocoles et modes de l'IPsec, tels que ceux decrits ci-dessus, une association de securite (SA) est habituellement constituee. Une SA IPsec est essentiellement un contrat ou un accord entre des parties qui definit les conditions selon lesquelles les deux parties vont communiquer. Par exemple, une SA IPsec est habituellement une connexion unidlrectionnelle qui definit, entre autres, des algorithmes de cryptage a utiliser au cours d'un echange dtinformations. Les associations de securite vent definies par des parametres, tels qu'une adresse de destination IP et un identificateur de protocole de securite (AH ou ESP, par exemple). Les associations de securite comprennent habituellement un index de parametre de securite (SPI) qui est un numero d/identification a 32 bits. Si l' on considere une association de securite IPsec comme un contrat ou un accord, on peut alors considerer que les termes de ce contrat ou de cet accord doivent etre negocies a ['aide d'un protocole separe (ou manuellement). Autrement dit, les deux parties communicantes doivent se mettre d' accord sur les operations qui seront executees sur les paquets communiques, afin de crypter/decrypter ces paquets. L'un de ces protocoles est connu sous le nom de protocole d' association de securite et de gestion de codes Internet (Internet Security Association and Key Management Protocol (ISAKMP)), et l'une des formes de mise en muvre de l'ISAKMP est connue sous le nom d'echange de codes Internet (Internet Key Exchange (IKE)). L' IKE fonctionne habituellement en deux phases. Au cours d'une premiere phase, les parties se mettent d' accord sur la maniere de proteger un trafic negocie ulterieur. Par exemple, l'IKE peut authentifier un emetteur grace, par exemple, a un cryptage en code public egalement connu sous le nom de cryptage Diffie Hellman. En cryptage en code public, chaque utilisateur genere un code public et un code prive, le code public etant ensuite transmis a l'autre partie. Lorsque chaque utilisateur combine son propre code prive avec le code public de l'autre (et eventuellement des informations supplementaires), les deux utilisateurs peuvent chacun obtenir un code secret identique. Ce code secret sert de base a partir de laquelle il est possible de firer des codes cryptographiques suivants. De cette maniere, un premier utilisateur peut crypter un message a ['aide du code public du second utilisateur, apres quoi seul le second utilisateur (a ['aide de son propre code prive) sera en mesure de decrypter et de recevoir le message. De meme, un premier utilisateur peut utiliser son code prive pour signer un message, le second utilisateur pouvant, grace au code public du premier utilisateur, recevoir et authentifier le message transmis. Ainsi, le premier utilisateur est. vis-a-vis du second utilisateur, authentifie comme etant celui qui est a ltorigine de la transmission, c'est-a-dire qu'il s'agit d'une >. Cette derriere methodologie est cependant inefficace pour proteger contre le risque qu'un tiers pretende simplement etre l'emetteur (c'est-a-dire le premier utilisateur), lorsque les codes vent generes au depart. C'est pourquoi il existe des autorites de certification (CA) independantes et homologuees qui delivrent des certificate numeriques verifiant l' association d'un code public et d'un utilisateur particulier, ainsi que d'autres informations d' identification. I1 existe deux principaux modes en ce qui concerne la premiere phase de 1'IKE, a savoir, un mode principal et un mode agressif. D'une maniere generale, le mode principal constitue une methode plus complexe, mais plus sure. Le mode agressif, bien que plus rapide, sacrifie la protection de l'identite. Toutefois, l'utilisation de la methodologie de cryptage en code public qui vient d'etre decrite supprime la necessite de cette caracteristique. Au cours d'une seconde phase, 1'IKE negocie la SA IPsec reelle (sur la base de laquelle les veritables echanges de donnees dans la couche application auront lieu) en etablissant les codes de cryptage/ authentification pour les protocoles AH et/ou ESP. En particulier, un > negocie les associations de securite concernant des communications 2s IPsec d'ordre general. I1 convient egalement de noter qu'habituellement un seule negociation en phase 1 suffit pour plusieurs operations en phase 2 correspondantes effectuees par plusieurs dispositifs homologues. Ceci permet aux multiples dispositifs homologues de firer chacun profit des procedures de la phase 1, pour ainsi etablir plus rapidement et plus facilement des connexions securisees. Comme cela ressort de lt explication ci-dessus, il existe done differentes solutions pour mettre en uvre des communications privees et authentifiees sur un reseau. Cependant, toutes les methodologies decrites ci-dessus vent traditionnellement mises en uvre sur la base d'un systeme posse a posse ou point a point. Ces methodologies ne peuvent malheureusement pas etre facilement etendues a une mise en reseau a diffusion multiple (c'est a dire multiposte a multiposte). En d'autres termes, si les membres d'un groupe de dispositifs homologues souhaitent chacun avoir la possibilite de diriger des communications vers chacun des autres membres du groupe (y compris simultanement), il leur faut etablir des associations de securite et des tunnels IPsec entre chaque padre de dispositifs du groupe. Le nombre d' associations de securite et de tunnels IPsec necessaires dans ce cas pour mettre en muvre une tel. le configuration de mai l lage complet peut etre represente par ['Equation (1) suivante: [k!(,n - k)!] (1) L' Equation (1) est une loi combinatoire bien connue dans laque l le > represente le nombre de di spos it i fs qui font partie du groupe de dispositifs, > = 2, puisque seules des connexions de posse a posse vent envisagees, et C(n,k) represente le nombre de connexions necessaires. Par consequent, pour sept dispositifs, il faut vingt-et-une connexions de posse a posse. En outre, ce nombre correspond a quarante-deux associations de securite, puisque les associations de securite IPsec sont, de maniere caracteristique, unidirectionnelles et doivent etre etablies individuellement dans les deux directions entre deux posses donnes. La creation et la gestion de ce nombre de connexions, qui augmente rapidement lorsque davantage de dispositifs vent inclus, deviennent impraticables. En particulier, la creation d'un nombre aussi important d' associations de securite coute cher a la fois en termes de temps et de ressources informatiques, et la gestion/mise en uvre de tunnels IPsec correspondents aux associations de securite est egalement difficile. Certains protocoles traditionnels tentent de mettre en muvre une connexion totalement maillee au niveau de la couche reseau. Par exemple, le service de commutation de references multiprotocolaires (Multi- Protocol Label Switching (MPLS)) offre aux administrateurs de reseaux une grande souplesse de gestion du flux de donnees a travers les reseaux en permettant le deroutement des donnees pour contourner des encombrements et des embouteillages. Toutefois, ces structures de reseaux mailles conventionnelles n'apportent pas, en soi, une solution adequate aux problemes de securite. En outre, elles ne vent pas compatibles avec des approches de type posse a posse, telles que celles employees par le protocole IPsec et d'autres protocoles de securite. On a par consequent besoin d'une methodologie pour mettre en muvre un reseau prive securise dont la creation et la gestion soient faciles et peu onereuses, qui permette une diffusion multiple entre des membres et qui soit facilement modulable pour permettre d' augmenter le nombre de membres. La presente invention a precisement pour but de repondre a ce besoin. Pour atteindre ce but, et selon un premier aspect de la presente invention, il est propose un procede pour mettre en muvre des communications securisees entre de multiples dispositifs, caracterise en ce qu'il comprend les etapes qui consistent a fournir au moins un parametre de cryptage commun a chacun des multiples dispositifs; a identifier les multiples dispositifs les uns vis-a-vis des autres; et a etablir une connexion de point a point securisee entre deux au moins des multiples dispositifs. Selon un deuxieme aspect de la presente invention, il est en outre propose un dispositif serveur pour mettre en uvre une connexion de reseau securisee entre de multiples dispositifs, caracterise en ce qu'il comprend des moyens pour distribuer de maniere sure des informations de connexions a chacun des multiples dispositifs; et des moyens pour permettre une communication de point a point securisee entre deux quelconques des multiples dispositifs sur la base des informations de connexions. Selon un troisieme aspect de la presente invention, il est egalement propose un produit manufacture comprenant un support risible par un ordinateur et dans lequel est stocke un programme informatique executant un procede pour mettre en uvre un reseau prive virtue!, caracterise en ce que le programme informatique comprend un premier segment de code pour authentifier des dispositifs membres du reseau prive virtuel; un deuxieme segment de code pour fournir un parametre de cryptage secret a chacun des dispositifs membres authentifies cherchant a etablir des communications actives au sein du reseau prive virtuel; et un troisieme segment de code pour s distribuer une liste de chacun des dispositifs membres authentifies aux autres dispositifs membres. Selon un quatrieme aspect de ['invention, il est aussi propose un procede d'utilisation d'un reseau prive virtue!, caracterise en ce qu'il comprend les etapes qui consistent a contacter un dispositif serveur administrant le reseau prive virtuel; a recevoir des informations authentifiant le dispositif servour et chacun de multiples membres du reseau prive virtuel; a recevoir du dispositif servour un parametre de cryptage qui peut etre obtenu en commun par tous les membres du reseau prive virtuel; et a recevoir une liste de tous les membres du reseau prive virtue!. Selon un cinquieme aspect de ['invention, il est finalement propose un procede d' activation de premier et second dispositifs au sein d'un reseau prive virtuel (VPN) gere par un serveur, caracterise en ce qu'il comprend les etapes qui consistent a negocier une premiere association de securite entre le serveur et le premier dispositif; a determiner, en tent que partie de la premiere association de securite, un code secret de cryptage avec le premier dispositif i a negocier une seconde association de securite entre le serveur et le second dispositif; a communiquer, en tent que partie de la seconde association de securite, le code secret de cryptage au second dispositif i et a etablir une session IPsec entre les premier et second dispositifs sur la base du code secret de cryptage. Ce qui precede, ainsi que d'autres buts, caracteristiques et avantages de la presente invention, ressortira plus clairement de la description detaillee suivante de plus ieurs modes de real isat ion donnee a s titre d'exemple nullement limitatif en reference aux dessins annexes dans lesquels: la figure 1A represente un environnement de reseau propose a titre d'exemple et dans lequel la presente invention peut etre mise en muvre; la figure 1B represente differentes connexions d' associations de securite et de type IPsec pouvant etre utilisees pour initier, activer et utiliser un mode de realisation de la presente invention; la figure 2 represente une methodologie proposee a titre d'exemple pour negocier une association de securite entre un dispositif serveur multipoint et un dispositif membre, selon l'un des modes de realisation de l' invention; la figure 3 represente une methodologie proposee a titre d'exemple pour etablir un trafic IPsec entre deux dispositifs membres, selon l'un des modes de realisation de l' invention; les figures 4A a 4D representent des structures de paquets IPsec proposes a titre d'exemple, pouvant etre 2s transportes selon differents modes de realisation de l' invention; les figures 5A a 5F representent des structures de certificate proposees a titre d'exemple pour chaque type de dispositif, lorsque des certificate vent utilises au sein d'un reseau prive virtuel mettant en uvre l'un des modes de realisation de la presente invention; les figures 6A et 6B representent des tables d'informations utilisees pour mettre en muvre des sessions de reseau prive virtuel a diffusion multiple, selon l'un des modes de realisation de l' invention;et les figures 7A et 7B representent a titre d'exemple des etapes d'une procedure d' association de securite et d'une gestion de messages a l'interieur d'un serveur multipoint, selon l'un des modes de realisation de ['invention. La presente invention va maintenant etre decrite en details en relation avec differents modes de realisation et en reference aux dessins annexes. A cet egard, il convient de signaler que dans les dessins les memes numeros de reference designent des elements identiques ou similaires du point de vue fonctionnel. En outre, le chiffre situe le plus a gauche dans un numero de reference identifie la figure sur laquelle ce numero de reference apparait pour la premiere foist Les differents modes de realisation decrits ici vent proposes a titre d'exemple. A cet egard, bien qutun protocole IPsec soit utilise ici pour expliquer un mode de realisation exemplaire de l' invention, on comprendra que celle-cl peut etre mise en muvre dans le contexte d'autres protocoles de securite de reseau 2s conventionnels, tels que le protocole de mise en tunnel de couche 2 (L2TP) et le protocole de mise en tunnel point a point (PPTP), comme le lecteur pourra s'en rendre compte. De meme, il existe des protocoles/methodologies autres que IKE et un cryptage de code public, pouvant etre utiles pour mettre en muvre des protocoles de securite de reseaux, et la presente invention peut etre mise en uvre dans ces environnements egalement. D'autre part, il convient de rappeler que la terminologie et les definitions associees utilisees ici vent ['objet de desaccords dans la profession, comme cela est connu. Par exemple, certains decrivent l'IKE s comme un exemple du protocole ISAKMP, tandis que d'autres le decrivent comme la combinaison du protocole ISAKMP avec d'autres protocoles. Cette terminologie et ces definitions vent employees de maniere particuliere et coherente dans la presente description, uniquement dans un souci de clarte. On comprendra done que cet emploi est simplement destine a expliquer et non a limiter la presente invention. De meme, les termes tels que >, > ou tout autre terme de la technique ne vent pas, sauf indication contraire, censes etre redefinis pour avoir une signification particuliere ici et doivent etre consideres dans leur acception raisonnable la plus large, conformement a l' interpretation qui en est traditionnellement faite dans la technique. Dans l'un de ces modes de realisation proposes a titre d'exemple, la presente invention met en uvre un dispositif serveur multipoint (MPS) qui a la charge de negocier une association de securite (SA) avec cheque dispositif membre d'un reseau prive virtuel (VPN). Le 2s dispositif serveur a pour fonction de partager au moins un parametre de cryptage commun a tous les membres du reseau VPN. De cette maniere, chaque membre du reseau VPN peut etablir une session (un tunnel) IPsec avec chacun des autres membres. Ainsi, les reseaux VPN conventionnels vent perfectionnes au moins en ce qui concerne les aspects suivants. Premierement, le nombre d' associations de securite a negocier et a gerer pour chaque reseau VPN est reduit d'un nombre potentiellement tres eleve a une SA par paire de MPS- dispositif membre. Deuxiemement, bien qu'il faille creer et gerer le meme nombre de tunnels IPsec que dans les reseaux VPN conventionnels, ces taches sont considerablement simplifiees a l'aide d'au moins un parametre de cryptage commun, tel qu'un code secret de cryptage commun. Le dispositif serveur multipoint peut etre n'importe quel dispositif de securite. Des exemples de dispositifs pouvant 8tre utilises pour le serveur multipoint comprennent des routeurs, des dispositifs coupe-feu ou des passerelles, tels que ceux susceptibles d'etre mis en muvre par un prestataire de services Internet (ISP). Le MPS peut etre inclus dans un nud de reseau existant ou mis en muvre dans un dispositif separe. Le MPS peut, bien que cela ne soit pas une necessite, etre situe sur un chemin des donnees communiquees par les membres du reseau VPN. Dans l'un des modes de realisation de l' invention, le serveur multipoint (MPS) negocie une association de securite (SA) individuellement avec chaque dispositif membre du reseau VPN. La SA sert a fournir a chaque dispositif membre un parametre de cryptage commun, tel qu'un code secret de cryptage commun, et une liste de dispositifs qui sont actuellement membres actifs du reseau VPN et/ou de dispositifs autorises a faire partie du reseau VPN. En ce qui concerne cette liste de dispositifs membres (potentiels) le MPS peut authentifier les dispositifs en joignant, par exemple, leurs codes publics d'authentification a la liste. De cette maniere, toutes les informations necessaires pour etablir et/ou rejoindre le reseau VPN peuvent etre communiquees aux dispositifs actuels et potentials par l'intermediaire de l' association de securite. A titre de variante, certaines au moins des informations decrites ci-dessus peuvent egalement etre communiquees aux dispositifs par l'intermediaire de certificate numeriques. En outre, les dispositifs qui souhaitent faire partie du reseau VPN peuvent localiser le serveur MPS a ['aide des certificate numeriques. L'utilisation de certificate numeriques dans ce contexte sera decrite plus en details ci-apres. Ainsi, la presente invention offre de nombreux avantages en ce qui concerne la creation et la gestion d'un reseau VPN. Il convient de noter que la presente invention est particulierement avantageuse lorsqutelle est utilisee en association avec des services offrant un environnement maille a diffusion multiple, comme par exemple la commutation de references multiprotocolaires (MPLS) mentionnee precedemment, pour permettre des communications de point a point securisees, telles qu'un trafic IPsec, dans un environnement de ce type. Les perfectionnements proposes par la presente invention concernent a la fois la creation et l'utilisation des associations de securite, ainsi que l' expedition de paquets entre les dispositifs membres d'un reseau VPN, une fois que les sessions IPsec ont 2s ete etablies. Par exemple, grace a la presente invention, il est possible d'aj outer facilement un nouveau dispositif a un reseau VPN deja cree et operationnel. Ces caracteristiques avantageuses et bien d'autres seront decrites plus en details ci-apres en relation avec les modes de realisation proposes a titre d'exemple de l' invention et representes sur les figures l a 7. La figure 1A represente un environnement de reseau exemplaire dans lequel la presente invention peut etre mise en muvre. Sur la figure 1A, un dispositif 100 peut etre un routeur, une passerelle ou un dispositif hote relic a un reseau a grande distance (WAN) 130. Le reseau WAN 130 peut etre un reseau public, tel que le reseau Internet, ou un reseau privet D'autres dispositifs terminaux 110 et 120 representent des membres potentials d'un reseau prive virtuel (VPN). Vn dispositif 150 represente une autorite de certification (CA) a laquelle le reseau WAN 130 peut egalement avoir acces. Un dispositif 140 represente un serveur multipoint (MPS) selon l'un des modes de realisation de la presente invention, qui est charge de gerer une association de securite (SA) avec chaque dispositif de point terminal. Bien que trots dispositifs membres 100, et 120 seulement soient representes sur la figure 1A, un reseau VPN beaucoup plus important peut egalement etre supporte par la presente invention. De meme, bien qutun seul MPS 140 soit represente, il est possible de prevoir plusieurs dispositifs MPS dont chacun prend en charge son propre reseau VPN. Il est egalement possible de prevoir un dispositif MPS de secours en cas de defaillance d'un MPS principal. La figure 1B represente differentes connexions de types SA et IPsec pouvant etre utilisees pour initier, activer et utiliser un mode de realisation de la presente invention. Comme cela a deja ete explique, les formes de mise en uvre d'IPsec conventionnelles exigent que chacun des dispositifs 100 a 120 forme une SA separee avec chacun des autres dispositifs, apres quoi des sessions IPsec entre chaque padre de dispositifs peuvent etre etablies sur la base des differentes associations de securite. Toutefois, conformement a un mode de realisation de la presente invention, il suffit que chacun des dispositifs 100 a 120 forme une association de securite entre lui et le dispositif MPS 140. Plus precisement, comme cela est represente, le dispositif forme une association de securite AS, le dispositif forme une association de securite BS et le dispositif 120 forme une association de securite CS. Une fois que les SA ont ete negociees, les dispositifs 100 a 120 peuvent etablir de multiples sessions IPsec sur le base de celles-ci. Dans ltexemple represente sur la figure 1B, les dispositifs forment trots sessions bidirectionnelles representees sous la forme d'une IPsec AC entre les dispositifs 100 et 120, d'une IPsec AB entre les dispositifs 100 et 110 et d'une IPsec BC entre les dispositifs 110 et 120 par l'intermediaire desquelles des paquets IPsec peuvent etre transmis. Une fois que ces sessions IPsec ont ete etablies, des communications de point a point sures peuvent avoir lieu entre tous les dispositifs, y compris des communications a diffusion multiple dans lesquelles l'un des dispositifs s'adresse simultanement aux deux autres dispositifs. La figure 2 represente une methodologie exemplaire pour negocier une association de securite entre le serveur MPS et un dispositif membre, selon l'un des modes de realisation de ['invention. Sur la figure 2, le dispositif 100 cherche a prendre part a une session IPsec de communication a diffusion multiple sur le reseau VPN. Par consequent, le dispositif 100 initie une association de securite a former, association de securite qui est designee par la reference SAT, en envoyant une transmission 210 au serveur MPS 140. On comprendra que des procedures similaires vent applicables en ce qui concerne les dispositifs 110 et 120,ainsi que d'autres dispositifs (non representes). Pour participer a cette session, le dispositif 100 doit appartenir au reseau VPN approprie. Le fait que le dispositif 100 appartient au reseau VPN peut etre verifie de differentes manieres. Par exemple, le dispositif 100 peut etre preconfigure pour contenir une adresse > predefinie du dispositif servour MPS 140 et un code d'authentification de dispositif, code d'authentification qui comprend un code public correspondent a ce dispositif, lequel code public est egalement memorise prealablement a l'interieur du serveur MPS 140. Par consequent, le MPS 140 peut ensuite verifier l'appartenance du dispositif 100 au reseau VPN en verifiant une table interne, comme cela sera decrit plus en details en relation avec la figure 6. Une seconde methodologie exemplaire consiste a definir pour le dispositif 100 un certificat (qui sera decrit plus en details en reference a la figure 6) destine a etre stocke dans la memoire de l'autorite de certification 150. Ce certificat peut alors contenir la verification que le dispositif 100 est membre du reseau VPN en question, ainsi qu'un code public d'authentification du dispositif 100. Le certificat de dispositif et le certificat de reseau VPN seront decrits plus en details en reference a la figure 5. La transmission 210 commence par une session de phase 1 (PH1AI) entre le dispositif 100 et le servour MPS 140. Ainsi, en reference a ce qui a ete indique precedemment, la transmission 210 sert a proteger un trafic negocie ulterieur a ['aide du mode principal. Comme cela est connu, le mode principal assure une protection en ce qui concerne l'identite des s dispositifs concernes. Il est habituellement divise en trots groupes de messages, chaque groupe contenant deux messages. Les deux premiers messages servent a negocier une politique de securite en ce qui concerne l'echange, les deux messages suivants servent a l'echange de code Diffie-Hellman et les deux derniers messages servent a authentifier les pairs ou dispositifs homologues a ['aide, par exemple, de signatures numeriques et de certificate numeriques facultatifs. Le servour MPS 140 repond a la transmission 210 par un message standard, tel qu'une transmission PH1SA 240. A l'interieur de ce message, le MPS 140 fournit ses propres parametres d'authentification, y compris son propre code public d'authentification. Comme cela est connu, les codes utilises au cours de la phase 1 servent habituellement a des fins d'authentification dans le cadre de la negociation d'une association de securite. Toutefois, il peuvent egalement servir a crypter des messages de SA, par exemple pendant la phase 2 des negociations de la SA. 2s Une fois la phase 1 terminee, un canal authentifie et totalement securise avec possibilite de cryptage est etabli pour passer a la phase 2 de l' association de securite. La phase 2 permet la definition de parametres concernant le protocole IPsec proprement dit et utilise de maniere generale le mode rapide decrit precedemment. Un echange de code Di ffie-Hellman peut etre real i se pour permettre d'obtenir une confidentialite des envois. Sur la figure 2, le MPS 140 joue le rdle de l'initiateur de la phase 2. Il n'est pas necessaire que le MPS 140 initie la phase 2, mais cela est preferable dans la mesure ou la plupart des informations fournies a ce stade vont etre transferees du serveur MPS 140 au dispositif 100. Au cours de la phase 2, le serveur MPS va fournir au dispositif 100, a l' aide de messages, tels qu'une transmission 260, une liste d'autres dispositifs membres du meme reseau VPN, y compris leur etat actuel (actif ou inactif, par exemple), ainsi que leurs codes publics d' identification. Cette liste peut etre contenue dans une table prevue a l'interieur du serveur MPS 140, comme cela est egalement represente sur la figure 6 et comme cela sera decrit en reference a cette figure. De plus, ltetat du dispositif 100 sur la liste peut a ce stade etre modifie pour passer de l'etat non connecte (NC) a l'etat en cours de connexion (en attente), ce qui signale aux autres dispositifs ltetat du dispositif 100 et permet a ce dernier de terminer la procedure de negociation de SA une fois qutil l'a commencee, sans avoir a recommencer lors, par exemple, d'un changement d'etat d'un autre dispositif au cours de la procedure. Au cours de la phase 2, le serveur MPS 140 peut fournir au dispositif 100 un code secret de cryptage IPsec qui est. ou sera, commun a tous les dispositifs appartenant au reseau VPN pendant la duree de l' association de securite. Le code secret ( >) peut etre crypte par le MPS 140 pour assurer une livraison securisee au dispositif 100 a l' aide d'un code public du dispositif 100 ( >), tel que le code public du dispositif 100, prealablement utilise au cours de la phase 1. La combinaison PkA(Ke) du code public PkA du dispositif 100 et du code secret commun Ke peut ainsi etre communiquee au dispositif 100 pendant la phase 2 de l' association de securite. De cette maniere, le dispositif 100 pourra obtenir le code secret Ke en le decryptant a partir des codes combines a ['aide de son propre code secret privet D'autres parametres legues au dispositif 100 par le MPS 140 peuvent comprendre, par exemple, une duree de la SA, des types d'en-tetes pour l'IPsec qui seront utilises (tels que ceux indiques sur les figures 4A a 4D) et differents autres parametres qui seront evidents pour l'homme de ['art. Au cours d'une phase finale d' activation de l' association de securite, le dispositif 100 envoie une transmission 270 au servour MPS 140, une fois qu'il a recu de celui-ci tous les parametres necessaires. A ce moment-la, le servour MPS 140 peut changer un etat du dispositif 100 en etat ACTIF (voir figure 6). Une fois que l' association de securite est active, un trafic IPsec peut commencer dans les deux directions entre le dispositif 100 et l'un quelconque ou la totalite des membres dea actifs du reseau VPN. A cet egard, il convient de signaler qutil n'est pas necessaire de suivre en sens inverse la procedure 2s representee sur la figure 2, c' est-adire d' etablir une SA secondaire entre le MPS 140 et le dispositif 100, initiee par le MPS 140. Bien que cette procedure soit traditionnellement requise comme cela a ete decrit precedemment, le fait qu'un seul code secret est partage entre tous les dispositifs 100 a 120 pour le cryptage de donnees et que le meme code d'authentification est utilise pour toutes les connexions supprime cette necessite et offre done des ameliorations supplementaires en termes de cout, de commodite et de modulabilite de mise en muvre de la presente invention. La figure 3 represente une methodologie exemplaire pour etablir un trafic IPsec entre deux dispositifs membres, selon l'un des modes de realisation de ['invention. Ce trafic peut etre etabli de maniere transparente du dispositif 100 vers le dispositif 110 (transmission 310, par exemple) ou du dispositif 110 vers le dispositif 100 (transmission 320, par exemple). Lorsque le protocole AH seul est utilise, il n'est pas necessaire d'avoir un code secret au cours de la negociation de l' association de securite, puisqu' aucun cryptage ne sera defini. Toutefois, dans le cas de l'utilisation du protocole ESP, un code secret de cryptage sera distribue, comme indique precedemment. Dans ce dernier cas, une authentification supplementaire peut egalement etre realisee a l' aide de codes d/identification IPsec. Meme si des paquets envoyes dans le cadre d'une session IPsec vent authentifies et cryptes, si un tiers parvient a la fois a intercepter les paquets et a avoir connaissance des touches frappees par l'emetteur (par exemple en surveillant le clavier de ltemetteur a 2s ['aide d'un logiciel) , ce tiers peut alors comparer les frappes de touches avec le trafic de donnees et finir par deduire une partie au moins du contenu d'un paquet particulier. Par exemple, ce tiers peut deduire qu'un paquet particulier contient une instruction, telle que >, puis renvoyer ce paquet ulterieurement. Ceci porte traditionnellement le nom d' >. Pour se proteger contre une attaque par reproduction, lors de la formation d'une association de securite, les dispositifs conviennent souvent d'un > connu de la seule padre emetteur/recepteur et qui stincremente a chaque nouveau paquet. De cette maniere, un dispositif recepteur peut distinguer au moins cette difference entre des paquets entrants et rejeter un paquet comportant un numero d'ordre deja utilise. Si une reinitialisation automatique est prevue pour le numero d'ordre (au bout d'un certain temps expire, par exemple), un dispositif, tel que le dispositif 110, peut alors prendre contact avec le servour MPS 140 afin qu'un code secret secondaire puisse etre distribue par ce dernier. Cette distribution peut habituellement s'effectuer dans un message de SA de la phase 2, c'est- a-dire a ['aide des parametres de la phase 1 negocies prealablement. En cas de non-concordance du numero d'ordre (ou d'utilisation d'un nouveau code) entre les dispositifs, une SA entierement nouvelle peut etre recommencee par les dispositifs concernes, c'est-a-dire par les dispositifs de la pane emetteur/recepteur impliquee dans la session IPsec. Souvent, un seul dispositif aura detecte l'erreur, et c'est ce dispositif qui va initier la nouvelle SA avec le serveur MPS 140 dans un message 330 (visible sur la figure 3) et avertir l'autre dispositif implique dans la transmission. A ce moment-la, le MPS 140 peut redemarrer la session IPsec a ['aide d'un code secret en cours, sans que cela ait un impact sur le reste du trafic du reseau VPN (y compris le trafic entre l'un ou l'autre des dispositifs concernes et les autres membres du reseau VPN). Ceci peut s'effectuer par l'intermediaire d'un message de > 340 de phase 2, comme cela est egalement indique sur la figure 3. Il faut egalement noter que des changements normaux a la fin de la SA peuvent etre inities par le MPS 140 qui peut anticiper la fin de celle-ci et fournir des comptes-rendus d'etats et un nouveau code secret de cryptage a chaque dispositif, d'une maniere preetablie. Dans ce cas, le numero d'ordre est reinitialise selon le protocole AH ou ESP par chaque dispositif emetteur d'une connexion IPsec, pour ainsi identifier les paquets sur lesquels le nouveau code de cryptage doit etre utilise. Conformement a l'un des modes de realisation de l' invention, senls les dispositifs classes actifs peuvent participer a une transmission de paquets IPsec. Si un dispositif 100 actif souhaite entrer en contact avec un dispositif 120 inactif ou non connecte, le dispositif 100 peut alors envoyer un demande par l'intermediaire du serveur MPS 140 qui peut collecter toutes les demandes de ce type et repondre par un message de > precisant tous les changements d'etat qui ont eu lieu dans le reseau VPN depuis le dernier message de mise a jour. Etant donne 2s que la session IPsec selon ce mode de realisation de l' invention sera, de maniere caracteristique, pratiquement permanente, l'etat des differents dispositifs sera relativement stable. Le nombre de messages de mise a j our a envoyer sera done souvent limite. Neanmoins, l'utilisation de ces messages de mise a j our peut etre tres utile en ce sens qutils permettent d'ajouter de maniere dynamique des dispositifs a une session Ipsec a diffusion multiple en cours. Les figures 4A a 4D representent des structures de paquets IPsec proposes a titre d'exemple et pouvant s etre transportes conformement a differents modes de realisation de ['invention. Sur la figure 4A, un paquet 410 represente un paquet IPsec utilisant un mode tunnel IPsec et comportant un en-fete ESP 416. Le champ de donnees interne 412 et l'en-tete IP 414 vent codes, ltensemble du paquet a l' exception de l'en-tete de tunnel 418 etant authentifie (c'est-a-dire integre dans la signature du paquet). Sur la figure 4B, un paquet 420 represente un paquet IPsec utilisant un mode transport IPsec et comportant un en-fete ESP 428 et une mise en tunnel par encapsulation de routage generique (GRE). Le champ de donnees interne 422 et l'en-tete IP 424 ainsi que la partie GRE 426 vent cryptes, ltensemble du paquet a l' exception de lten-tete de tunnel 429 etant integre dans la signature du paquet (c'est-a-dire authentifie). Sur la figure 4C un paquet 430 represente un paquet IPsec utilisant un mode tunnel IPsec avec un en-fete AH 436. Aucune zone n'est cryptee, ['ensemble du paquet, y 2s compris l'en-tete de tunnel 438, etant integre dans la signature du paquet. Ce mode peut etre utilise pour authentifier des flux au sein d'un reseau VPN et pour assurer une integrite lorsqutun cryptage n'est pas necessaire ou pas approprie. Il peut etre utilise lorsqu'un cryptage est realise au niveau d'une application. Sur la figure 4D, un paquet 440 represente un paquet IPsec utilisant un mode tunnel IPsec avec des en-fetes AH et ESP 448 et 446, respectivement. Le champ de donnees interne 442 et l'en-tete IP 444 vent cryptes, ltensemble du paquet y compris l'en-tete de tunnel 449 etant integre dans la signature du paquet. Les figures 5A a 5F representent des structures de certificate proposes a titre d'exemple pour chaque type de dispositif, lorsque des certificate vent utilises au sein d'un reseau VPN mettant en uvre l'un des modes de realisation de la presente invention. En particulier, on peut voir sur les figures 5A a E des certificate 500a a 500e destines aux dispositifs , 110, 120 et 140 comportant respectivement des adresses de dispositif A, B. C et S. qui vent des certificate tout a fait standards habituellement emis pour ces dispositifs. Des champs 510a a 510e contiennent des informations relatives a l'autorite de certification 150 et comprenant, de maniere classique, l'identite de l'autorite de certification et la signature du certificat. Des champs 520a a 520e contiennent differents elements conventionnels d'informations concernant les dispositifs proprement dits, y compris leurs identites WAN, leurs adresses IP et leurs codes publics respectifs. Les champs 520a a 520e contiennent egalement des 2s informations supplementaires non standards. Par exemple, un champ d'identite de groupe peut contenir une liste des reseaux VPN geres par un serveur MPS particulier. Cette liste peut etre utile, par exemple, si un nombre relativement important de reseaux VPN est defini, de sorte que le MPS en question est susceptible d'avoir des difficultes a gerer tous les VPN, lorsqu'un pourcentage important des dispositifs est actif. Ainsi, le dispositif 100 peut etre en mesure de determiner si un nombre predetermine de dispositifs/reseaux VPN est gere de maniere active par un MPS particulier, en examinant le champ d'identite du groupe. Ce mecanisme permet un partage des taches de gestion des VPN, en fonction des besoins, entre de multiples serveurs MPS (dans le cas ou il existe plusieurs serveurs de ce type). Il est a noter que les identites de VPN vent des valeurs fixes correspondent a des clients, tandis que les identites de groupe vent des valeurs flexibles utilisees par les prestataires de services de reseaux et qui peuvent etre modifiees pour optimiser les ressources, sans consequences pour les clients. Une ou des identites de groupe et une ou des identites de reseau VPN particulieres peuvent etre regroupees pour etre utilisees dans un petit reseau. De plus, l'identite de groupe peut servir a identifier un ensemble de serveurs MPS optimises pour des techniques de cryptage specialisees predeterminees. En outre, un champ d' identification de VPN peut etre prevu pour identifier le reseau VPN auquel le dispositif particulier appartient au sein du groupe defini ci-dessus de reseaux VPN. Il faut noter que le champ d' identification de groupe peut ne pas etre necessaire si un nombre limite seulement de reseaux VPN est mis en muvre par le servour en question. Lorsqu'un serveur est identifie par une identite de groupe, il peut etre partage par ['ensemble du groupe, c'est-a-dire par tous les reseaux VPN appartenant a ce groupe auquel cas un certificat special, tel qutun certificat 500d, peut etre utilise. A titre de variante, le serveur peut etre utilise pour gerer une partie seulement des reseaux VPN du groupe. Dans ce cas, un certificat de serveur partage, tel qutun certlficat 500e, peut etre utilise pour definir les reseaux VPN inclus dans le groupe. Un serveur MPS peut egalement etre dedie a un reseau VPN ou a un client particulier, pour offrir une plus grande securite. s D'autre part, un type nouveau de certificat 500f est defini conformement a l'un des modes de realisation de l' invention et est represente sur la figure 5F. Le certificat 500f est destine a lier entre eux les dispositifs membres d'un reseau VPN en groupes a diffusion multiple. Ils vent utiles pour la recuperation des certificate dispositif/serveur necessaires pour etablir la session a diffusion multiple. Le certificat 500f est identifie a la fois par l'identite de groupe et l'identite de VPN, et identifie tous les serveurs, tels que les serveurs Sl et S2 (serveurs principal et auxiliaire) pour le reseau VPN et tous les membres potentials. Une methodologie d' association de securite particuliere et des parametres IPsec particuliers peuvent egalement etre definis dans le certificat en commun pour tous les membres. Les informations contenues dans le certificat 500f permettent au serveur MPS 140 d'etablir une table (voir figure 6) mettant en correlation les membres du reseau VPN avec le ou les serveurs appropries, afin que ce certificat suffise a chaque dispositif membre pour commencer une SA avec le servour. Une fois que la SA a ete initiee/negociee, le serveur en question sera en mesure d'obtenir les certificate de dispositifs, tels que les certificate 500a a 500c. En outre, un certificat d'identite de groupe (non represente) peut etre etabli pour fournir au moins l'identite des serveurs MPS et une liste des reseaux VPN associes. Un tel certificat peut etre plus utile a des fins de gestion quta des fins operationnelles. A titre de variante, au lieu que ce soit au servour d'obtenir des informations, comme cela a ete decrit precedemment, chacun des dispositifs individuals peut demander les certificate de ses voisins. Cependant, pour un grand nombre de dispositifs, cette methodologie peut s'averer difficile ou impossible a mettre en muvre. Il convient de noter que les certificate utilises par la presente invention peuvent egalement comprendre differents autres champs, comme par exemple une date d' expiration du certificat. Cependant, ces champs vent connus traditionnellement et ne vent pas mentionnes pour plus de clarte. Les figures 6A et 6B representent des tables dtinformations utilisees pour mettre en uvre des sessions de VPN a diffusion multiple conformement a l'un des modes de realisation de ['invention. Sur la figure 6A, on peut voir une table globale 610 appelee >. Wile est habituellement situee dans un serveur multipoint, tel que le serveur MPS 140, et contient les codes publics, le nom et l'adresse IP de chacun des dispositifs appartenant a un VPN/groupe defini. Ici, les dispositifs 100 a 120 respectivement designee par A, B et C vent indiques sur les lignes 620 a 640. Le nom d'un dispositif peut, par exemple etre un nom de reseau designe par un serveur de noms de domaine (DNS), le cas echeant, ou un autre nom, tel qu'un nom de connexion. Sur la figure 6A, code pub 1 represente le code public pour la phase 1 d'une association de securite, qui peut etre utilise pour authentifier un dispositif et crypter des messages de SA; code pub 2 represente le code public d'authentification utilise dans les sessions IPsec; et code pub 3 represente un code de cryptage facultatif destine a etre utilise pour transmettre le code secret du servour MPS 140 a un dispositif membre donne du reseau VPN. Pour le code pub 3, il est egalement possible d'utiliser le code public du dispositif (code pub 1). Il peut toutefois etre preferable d'utiliser un code plus long/plus sophistique que celui-ci pour crypter le code secret. La figure 6B represente une seconde table 660 appelee >. Dans la table 660, chacun des dispositifs 100 a 120 possede une rangee 670-690 correspondante qui contient des informations concernant le ou les autres dispositifs susceptibles d'etre membres du meme reseau VPN. La table 660 fournit, entre autres, le nom du dispositif (A, B ou C, par exemple) et l'adresse IP des dispositifs du reseau VPN. Il est a noter que l'adresse du dispositif n'est pas necessaire mais peut etre utile en particulier dans le cas ou des adresses IP dynamiques vent utilisees. La table 660 contient egalement les codes d'authentification des dispositifs pairs ou homologues, comme cela a ete explique precedemment en reference a la figure 2. La table 660 contient aussi une indication d'un etat de chaque dispositif, a savoir si le dispositif est actif, non connecte (NC) ou en cours de connexion (en attente). Les tables 610 et 660 vent mises a j our regulierement et au moins avant la date d' expiration du certificat utilise pour les etablir. Une procedure d'annulation par un serveur d'annulation de certificate conventionnel peut etre ut i l i see pour effacer le s tables de maniere dynamique. Les figures 7A et 7B representent les etapes d'une procedure SA et d'une gestion de messages exemplaires au sein d' un serveur multipoint, selon l' un des modes de realisation de ['invention. Sur la figure 7A, le serveur MPS 140 recoit au cours de l'etape 710 un message de demande de SA phase 1 a partir d'un dispositif, tel que l'un des dispositifs 100 a 120. Au cours de l'etape 712, le MPS controle l'identite du dispositif et le reseau VPN a ['aide du code public de dispositif fourni. Une verification a l' aide d'un certificat du dispositif peut etre effectuee si la table 610 ne contient pas d'informations valides pour le dispositif correspondent. Si le dispositif est valide et appartient a un reseau VPN gere par le serveur MPS 140, ce qui est determine au cours de l'etape 714, la phase 2 de la negociation SA peut alors commencer a l'etape 716, sinon, la SA sera refusee a l'etape 725 au cours de laquelle le dispositif sera informe du defaut, et un journal pourra etre cree pour les besoins de gestion du reseau. Si la negociation SA se pour-quit, le code secret commun est alors envoye au dispositif au cours de l'etape 718 et la table de repartition VPN 660 est transmisse au cours de l'etape 720. Sur la figure 7B, au cours de l'etape 730, un message de demande de SA phase 2 est recu au niveau du serveur MPS 140 a partir d'un dispositif qui est normalement actif. Habituellement, ce scenario intervient lors de la detection d'une erreur par le dispositif emetteur. A ['aide des informations fournies, le serveur MPS 140 doit etre en mesure, au cours de l'etape 735, d' identifier la source du message ainsi que le dispositif homologue IPsec pour lequel le s dispositif emetteur a detecte un probleme. Ensuite, une procedure de mise a j our peut etre demarree a l'etape 740, procedure de mise a j our qui correspond a la procedure decrite precedemment en relation avec la figure 3, c'est-a-dire que le code secret commun est renvoye aux deux dispositifs, au cours de l'etape 745, et que la table de repartition VPN 660 est elle aussi renvoyee au cours de l'etape 750, table 660 qui ne contient que les dispositifs (habituellement un seul) qui se vent averes impliques dans le probleme particulier detecte. A chaque fois qu'un dispositif recoit cette mise a jour, et meme si les valeurs vent les memes que celles precedent la mise a jour, il doit recommencer ses sessions IPsec avec les documents de la liste. Si cette procedure ne permet pas de resoudre le probleme, un second message d'erreur peut etre recu du ou des memes dispositifs, c'est-a-dire que l'etape 730 est repetee, apres quoi l' association de securite en cours peut etre abandonnee, c'est-a-dire qu'un message d' abandon peut etre transmis par le serveur MPS 140 a tous les dispositifs du reseau VPN, la procedure etant recommencee a l'etape 710 pour ['ensemble des dispositifs. En conclusion, la presente invention propose une methodologie pour creer des reseaux prives virtuels a diffusion multiple et maillage complet securises qui est facile et peu onereuse a mettre en oeuvre et a gerer. Grace a cette methodologie, au lieu que chaque dispositif membre negocie une association de securite avec chacun des autres dispositifs membres du reseau VPN, un servour multipoint negocie l'association de securite avec chacun des dispositifs membres du VPN. Au cours de la negociation, un parametre commun est alors distribue a tous les dispositifs membres du reseau VPN qui cherchent a devenir actifs sur le reseau, de meme qu'une liste des autres dispositifs membres du reseau. De cette maniere, tout dispositif membre du reseau VPN, lo designe comme actif par le serveur peut mener une session IPsec avec tous les autres dispositifs membres de ce reseau. Bien que la description precedente ait porte sur plusieurs modes de realisation de la presente invention, celle-ci n'est bien entendu pas limitee aux exemples particuliers decrits et illustres ici, et l'homme de l'art comprendra aisement qu'il est possible d'y apporter de nombreuses autres variantes et modifications sans pour autant sortir du cadre de l' invention. REVENDICATIONS 1- Procede pour mettre en muvre des communications securisees entre de multiples dispositifs, caracterise en ce qu'il comprend les etapes qui consistent a: fournir au moins un parametre de cryptage commun a chacun des multiples dispositifs (100, 110, 120); identifier les multiples dispositifs les uns vis-a vis des autres; et etablir une connexion de point a point securisee entre deux au moins des multiples dispositifs. 2- Procede selon la revendication 1, caracterise en ce qu'il comprend egalement l'etape qui consiste a etablir des connexions de point a point securisees entre tous les multiples dispositifs (100, 110, 120). 3- Procede selon la revendication 2, caracterise en ce que l'etape de fourniture d' au moins un parametre de cryptage commun a chacun des multiples dispositifs comprend egalement la negociation d'une association de securite (SA) avec chacun des multiples dispositifs. 2s 4- Procede selon la revendication 3, caracterise en ce que l'etape d' identification des multiples dispositifs les uns vis-a-vis des autres comprend egalement la fourniture d'une adresse IP et d'un code d' identification de chaque dispositif a chacun des autres dispositifs. - Procede selon la revendication 3, caracterise en ce que l'etape d'etablissement d'une connexion de point a point securisee entre deux au moins des multiples dispositifs (100, 110, 120) comprend egalement l'etablissement d'une session IPsec sur la base du parametre de cryptage commun. 6- Procede selon la revendication 5, caracterise en ce qu'il comprend egalement l'etape qui consiste a: authentifier chaque dispositif en tent que membre d'un reseau prive virtuel (VPN) predefini au cours de la negociation de l' association de securite (SA), sur la base d'un code public d'authentification du dispositif et d'une liste prealablement memorisee de dispositifs membres. 7- Procede selon la revendication 5, caracterise en ce qu'il comprend egalement les etapes qui consistent a: obtenir d'une autorite de certification (150) des informations de certificat concernant chacun des multiples dispositifs et un reseau prive virtuel (VPN) predefini constitue des multiples dispositifs (100, , 120); authentifier chaque dispositif en tent que membre du reseau prive virtuel sur la base des informations de certificat i et etablir la session IPsec sur la base des informations de certificat. 8- Procede selon la revendication 5, caracterise en ce qu'il comprend egalement l'etape qui consiste a: redemarrer la session IPsec lors de la detection d'une erreur de transmission par l'un des multiples dispositifs participant a la session IPsec. 9- Procede selon la revendication 2, caracterise en ce qu'il comprend egalement ltetape qui consiste a: fournir aux multiples dispositifs une mise a j our periodique identifiant un etat actuel des autres dispositifs comme etant actif, inactif ou en cours de lo connexion. - Dispositif serveur pour mettre en uvre une connexion de reseau securisee entre de multiples dispositifs, caracterise en ce qu'il comprend: des moyens pour distribuer de maniere sure des informations de connexion a chacun des multiples dispositifs (100, 110, 120) i et des moyens pour permettre une communication de point a point s ecuri see entre deux quel conques de s multiples dispositifs sur la base des informations de connexion (100, 110, 120). 11- Dispositif serveur selon la revendication 10, caracteri s e en ce que le s informat ions de connexion 2s comprennent un code de cryptage secret utilise par chaque padre de dispositifs pour etablir des sessions IPsec entre eux. 12- Dispositif servour selon la revendication 10, caracteri se en ce que les informat ions de connexion comprennent une liste identifiant chacun des multiples dispositifs (100, 110, 120) et leur etat actuel en tent que membres d'un reseau prive virtuel (VPN). 13- Dispositif serveur selon la revendication 10, caracterise en ce qutil comprend egalement: des moyens pour mettre a j our des informations d'etat de chacun des multiples dispositifs (100, 110, 120) en tent que membres d'un reseau prive virtuel (VPN); et des moyens pour communiquer les informations d'etat a chacun des multiples dispositifs. 14- Dispositif serveur selon la revendication 10, caracterise en ce qutil comprend egalement: des moyens pour redemarrer la communication de point a point securisee entre deux quelconques des multiples dispositifs lors de la detection d'une erreur IS dans celle-ci par l'un quelconque des multiples dispositifs. - Produit manufacture comprenant un support risible par un ordinateur et dans lequel est stocke un programme informatique executant un procede pour mettre en uvre un reseau prive virtuel (VPN), caracterise en ce que le programme informatique comprend: un premier segment de code pour authentifier des dispositifs membres (100, 110, 120) du reseau prive 2s virtuel (VPN); un deuxieme segment de code pour fournir un parametre de cryptage secret a chacun des dispositifs membres authentifies cherchant a etablir des communications actives au sein du reseau prive virtuel; et un troisieme segment de code pour distribuer une liste de chacun des dispositifs membres authentifies aux autres dispositifs membres. 16- Produit selon la revendication 15, caracterise en ce qu'il comprend egalement: un quatrieme segment de code pour administrer le reseau prive virtuel (VPN), le quatrieme segment de s code etant apte a agir pour reconnecter un dispositif membre apres la detection d'une erreur par celui-ci, pour rallier un nouveau dispositif membre au cours d'une session active du reseau prive virtue!, et pour fournir a chacun des dispositifs membres des messages de mise a j our precisant un etat actuel de chacun des autres dispositifs membres. 17- Produit selon la revendication 15, caracterise en ce que le premier segment de code est apte a agir pour obtenir d'une autorite de certification (150) des informations de certificat afin d'authentifier les dispositifs membres. 18- Produit selon la revendication 15, caracterise en ce que le troisieme segment de code est apte a agir pour fournir des informations de certificat identifiant ladite liste ainsi que des parametres de communication permettant une communication entre deux quelconques des dispositifs membres. 19- Produit selon la revendication 15, caracterise en ce qu'il comprend egalement: un quatrieme segment de code pour memoriser une premiere table listant chacun des dispositifs membres et un premier groupe de parametres associes, le quatrieme segment de code etant apte a agir conjointement avec le premier segment de code pour authentifier les dispositifs membres en tent que membres du reseau prive virtuel (VPN); et un cinquieme segment de code pour memoriser une seconde table listant chacun des dispositifs membres et un second groupe de parametres associes, le cinquieme segment de code etant apte a agir conjointement avec le troisieme segment de code pour distribuer ladite liste. 20- Procede d'utilisation d'un reseau prive virtue!, caracterise en ce qu'il comprend les etapes qui consistent a: contacter un dispositif serveur (140) administrant le reseau prive virtuel (VPN); recevoir des informations authentifiant le dispositif serveur et chacun de multiples membres (100, , 120) du reseau prive virtuel; recevoir du dispositif serveur un parametre de cryptage pouvant etre obtenu en commun par tous les membres du reseau prive virtuel; et recevoir une liste de tous les membres du reseau prive virtue!. 21- Procede selon la revendication 20, caracterise en 2s ce qu'il comprend egalement l'etape qui consiste a: etablir une connexion de point a point avec l'un au moins des multiples membres actuels sur la base du parametre de cryptage. 22- Procede selon la revendication 20, caracterise en ce que la liste et les informations d'authentification vent recues du dispositif serveur (140), en tent que parties d'une association de securite negociee avec celui-ci. 23- Procede selon la revendication 20, caracterise en ce qu'il comprend egalement les etapes qui consistent a: detecter une erreur dans une transmission faisant partie de la connexion de point a point; mettre fin a la connexion de point a point; contacter le dispositif servour (140) ; et redemarrer la connexion de point a point sur la base d'informations mises a j our recues du dispositif serveur. 24- Procede selon la revendication 20, caracterise en ce qu'il comprend egalement l'etape qui consiste a: contacter une autorite de certification (150) pour obtenir la liste et les informations d'authentification, par l'intermediaire d'un certificat numerique. - Procede d' activation de premier et second dispositifs au sein d'un reseau prive virtuel (VPN) gere par un serveur, caracterise en ce qutil comprend les etapes qui consistent a: negocier une premiere association de securite (SA) entre le serveur (140) et le premier dispositif; determiner en tent que partie de la premiere association de securite, un code secret de cryptage avec le premier dispositif; negocier une seconde association de securite (SA) entre le serveur (140) et le second dispositif; communiquer, en tent que partie de la seconde association de securite, le code secret de cryptage au second dispositif; et etablir une session IPsec entre les premiers et S second dispositifs sur la base du code secret de cryptage. 26- Procede selon la revendication 25, caracterise en ce que l'etape de communication du code secret de cryptage comprend egalement: l' identification du premier dispositif vis-a-vis du second dispositif, en tent que membre actif du VPN. 27- Procede selon la revendication 25, caracterise en ce que le VPN est constitue de multiples dispositifs participants actifs (100, 110, 120) et en ce qutil comprend egalement les etapes qui consistent a: communiquer au premier dispositif une liste des multiples dispositifs pendant la negociation de la premiere association de securite; et communiquer au second dispositif une liste comprenant les multiples dispositifs et le premier dispositif pendant la negociation de la seconde association de securite.