FR 2839226 A1 20031031 FR 0304247 A 20030404 La présente invention concerne la formation et l'utilisation de connexions de réseau sécurisées. Elle concerne plus précisément la formation de connexions de réseau explorées et sécurisées sans qu'il soit porté atteinte au secret des communications des utilisateurs. Les réseaux informatiques et en particulier les réseaux à grande distance (WAN), tels que le réseau Internet offrent la possibilité d'un usage impropre et abusif des communications véhiculées par leur intermédiaire. Par exemple, les communications entre deux utilisateurs communiquant par l'intermédiaire d'un WAN peuvent être interceptées et/ou altérées. Un utilisateur peut également se présenter sous une fausse identité à un autre utilisateur. Enfin, un utilisateur peut, par exemple utiliser des ressources de réseau et des communications établies sur un réseau pour perturber ou interrompre le réseau en partie ou en totalité. Il y a donc un besoin de confidentialité et d'authentification entre les utilisateurs d'un WAN qui communiquent entre eux. En d'autres termes, les utilisateurs doivent pouvoir compter sur le fait que leurs transmissions ne seront pas interceptées ou altérées, et que des transmissions émanant de quelqu'un qui se prétend être un utilisateur particulier proviennent effectivement de cet utilisateur. L'un des moyens pour se défendre contre une utilisation malintentionnée d'un réseau à grande distance est un dispositif qui fonctionne à la limite d'un réseau privé, tel qu'une passerelle, un dispositif coupe-feu ou un autre appareil de réseau spécialisé. Ce type de dispositif agit pour filtrer les transmissions entre le réseau privé et le réseau à grande distance et/ou pour protéger les transmissions qui ont effectivement lieu par un cryptage/décryptage (c'est-à-dire, un codage/décodage) de ces transmissions. D'autres types de moyens de défense apparentés agissent en établissant l'identité d'un émetteur et/ou d'un récepteur avant l'émission/réception d'une communication. Il existe encore d'autres moyens de protection qui consistent en l'établissement d'un canal sécurisé entre deux dispositifs de communication. Un protocole conventionnel particulier pour assurer une sécurité entre des dispositifs fonctionnant sur un réseau à Protocole Internet (IP) est connu sous le nom de IPsec. Abréviation de l'expression Protocole Internet Sécurisé, IPsec est en fait un ensemble de protocoles permettant de sécuriser l'échange de paquets de type IP au niveau d'une couche réseau. Deux des protocoles utilisés sont le protocole d'en-tête d'authentification (Authentification Header protocol (AH)) et le protocole de champ de données de sécurité d'encapsulation (Encapsulation Security Payload protocol (ESP)). Le protocole AH est conçu pour assurer que des paquets transmis ne seront pas altérés au cours de leur transit sur le réseau, mais il n'empêche pas que le contenu des paquets puisse être visualisé par d'autres utilisateurs du réseau, c'est-à-dire, qu'il n'empêche pas leur interception par des tiers. Le protocole ESP, en revanche, assure la confidentialité du contenu des paquets. Ce protocole ESP offre un mécanisme d'authentification facultatif. Toutefois, ce mécanisme est uniquement destiné à authentifier le champ de données du paquet (et les en-têtes/terminaisons ESP associés). Le protocole ESP n'authentifie donc pas l'en-tête IP d'un paquet, indiquant une adresse IP originale sur le réseau à partir de laquelle le paquet a été émis. Il est également 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 utilisé pour des communications d'hôte à hôte, c'est-à-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 utilisé dans le cas de communications entre un système protégé par l'IPsec et un autre point terminal, comme par exemple des communications émises à partir d'un réseau privé sur le réseau Internet. En mode tunnel, le champ de données d'un paquet IP sécurisé est porteur d'un autre paquet contenant le champ de données réelles à transmettre. Une utilisation courante du mode tunnel consiste à mettre en oeuvre un réseau privé virtuel (VPN). Les VPN sont des réseaux qui utilisent des ressources de réseau à la disposition du public, telles que les ressources d'Internet, pour construire un réseau accessible uniquement par des utilisateurs sélectionnés. Par exemple, une société peut créer sa propre version d'un réseau local à l'aide du réseau Internet, ou bien une personne pratiquant le télétravail peut être en mesure d'utiliser les ressources dont une société dispose au niveau de son siège principal. Pour mettre en oeuvre les différents protocoles et modes de l'IPsec, tels que ceux décrits ci-dessus, une association de sécurité (SA) est habituellement constituée. Une SA IPsec est essentiellement un contrat ou un accord entre des parties qui définit les conditions selon lesquelles les deux parties vont communiquer. Par exemple, une SA IPsec est habituellement une connexion unidirectionnelle qui définit, entre autres, des algorithmes de cryptage à utiliser au cours d'un échange d'informations. Les associations de sécurité SA sont définies par des paramètres, tels qu'une adresse de destination IP et un identificateur de protocole de sécurité (AM ou ESP, par exemple). Les associations de sécurité SA comprennent habituellement un index de paramètre de sécurité (SPI) qui est un numéro d'identification à 32 bits. Si l'on considère une association de sécurité IPsec comme un contrat ou un accord, on peut alors considérer que les termes de ce contrat ou de cet accord doivent être négociés à l'aide d'un protocole séparé (ou manuellement). Autrement dit, les deux parties communicantes doivent se mettre d'accord sur les opérations qui seront exécutées sur les paquets communiqués, afin de crypter/décrypter ces paquets. L'un de ces protocoles est connu sous le nom de protocole d'association de sécurité et de gestion de codes Internet (Internet Security Association and Key Management Protocol(ISAKMP)), et l'une des formes de mise en oeuvre de l'ISAKMP est connue sous le nom d'échange de code Internet (Internet Key Exchange (IKE)). L'IKE fonctionne habituellement en deux phases. Au cours d'une première phase, les parties se mettent d'accord sur la manière de protéger un trafic négocié ultérieur. Par exemple, l'IKE peut authentifier un émetteur grâce, par exemple, à un cryptage à clé publique également connu sous le nom de cryptage Diffie-Hellman. Dans le cryptage à clé publique, chaque utilisateur génère une clé publique et une clé privée, la clé publique étant ensuite transmise à l'autre partie. Lorsque chaque utilisateur combine sa propre clé privée avec la clé publique de l'autre (et éventuellement des informations supplémentaires), les deux utilisateurs peuvent chacun obtenir une clé secrète identique. Cette clé secrète sert de base à partir de laquelle il est possible de tirer des codes cryptographiques suivants. De cette manière, un premier utilisateur peut crypter un message à l'aide de la clé publique du second utilisateur, après quoi seul le second utilisateur (à l'aide de sa propre clé privée) sera en mesure de décrypter et de recevoir le message. De même, un premier utilisateur peut utiliser sa clé privée pour signer un message, le second utilisateur pouvant, grâce à la clé publique du premier utilisateur, recevoir et authentifier le message transmis. Ainsi, le premier utilisateur est, vis-à-vis du second utilisateur, authentifié comme étant celui qui est à l'origine de la transmission, c'est-à-dire qu'il s'agit d'une "signature numérique". Cette dernière méthodologie est cependant inefficace pour protéger contre le risque qu'un tiers prétende simplement être l'émetteur (c'est-à-dire, le premier utilisateur), lorsque les clés sont générées au départ. C'est pourquoi il existe des autorités de certification (CA) indépendantes et homologuées qui délivrent des certificats numériques vérifiant l'association d'une clé publique et d'un utilisateur particulier, ainsi que d'autres informations d'identification. Il existe deux principaux modes en ce qui concerne la première phase de l'IKE, à savoir, un mode principal et un mode agressif. D'une manière générale, le mode principal constitue une méthode plus complexe, mais plus sûre. Le mode agressif, bien que plus rapide, sacrifie la protection de l'identité. Toutefois, l'utilisation de la méthodologie de cryptage en clé publique qui vient d'être décrite supprime la nécessité de cette caractéristique. Au cours d'une seconde phase, l'IKE négocie la SA IPsec réelle (sur la base de laquelle les véritables échanges de données dans la couche application auront lieu) en établissant les codes de cryptage/authentification pour les protocoles AH et/ou ESP. En particulier, un "mode rapide" négocie les associations de sécurité concernant des communications IPsec d'ordre général. Il convient également de noter qu'habituellement une seule négociation en phase 1 suffit pour plusieurs opérations en phase 2 correspondantes effectuées par plusieurs dispositifs homologues. Ceci permet aux multiples dispositifs homologues de tirer chacun profit des procédures de la phase 1, pour ainsi établir plus rapidement et plus facilement des connexions sécurisées. Comme cela ressort de l'explication ci-dessus, il existe donc différentes solutions pour mettre en oeuvre des communications privées et authentifiées sur un réseau. Cependant, les différentes solutions classiques présentent un certain nombre d'insuffisances. Par exemple, il est fréquent qu'un dispositif participant à une connexion de réseau sécurisée, telle que IPsec, soit localisé derrière une passerelle ou un dispositif pare-feu. Comme cela est connu, ces dispositifs sont situés habituellement à la limite d'un réseau privé, et servent à intercepter et/ou à assurer le routage du flux de trafic entre les dispositifs du réseau privé et d'autres dispositifs, généralement via un réseau public tel que l'Internet. Des pare-feu peuvent être mis en place, par exemple, par des administrateurs de réseau d'entreprise et des fournisseurs d'accès à l'Internet (ISP). De tels dispositifs pare-feu remplissent de manière classique un certain nombre de fonctions; par exemple, ils sont souvent utilisés pour explorer ou filtrer le trafic du réseau afin d'empêcher une entrée de données non autorisées ou de certains types de données dans les réseaux privés. Les pare-feu peuvent ainsi empêcher l'exploration de sites qui ont fait l'objet d'une interdiction par des administrateurs de réseau, tels que des sites de jeux sur l'Internet. Ils peuvent également interdire des données qui sont susceptibles de contenir des virus ou d'autres fichiers qui pourraient s'avérer nocifs pour le réseau. Des pare-feu peuvent également être utilisés en tant que point d'entrée unique dans un réseau privé, à partir de l'extérieur du réseau privé, de telle manière que les administrateurs de réseau peuvent demander une combinaison composée d'un nom d'utilisateur et d'un mot de passe au niveau du pare-feu afin de ne donner l'accès qu'aux seuls utilisateurs autorisés. Les pare-feu classiques ne sont toutefois pas conçus pour fonctionner correctement en association avec les protocoles de sécurité décrits ci-dessus, tels que le protocole IPsec. Par exemple, dans le cas où un dispositif dans un réseau public souhaite communiquer de manière sécurisée avec un dispositif fonctionnant derrière un pare-feu dans un réseau privé, il n'existe aucune solution satisfaisante. Une solution classique dans un tel scénario consiste simplement à laisser passer librement les données cryptées à travers le pare-feu. Cette solution est montrée à la Fig.lA, dans laquelle des dispositifs 100 et 140 (implantés dans des réseaux public et privé 120 et 130, respectivement) communiquent via un pare-feu 110. Cependant, cette solution souffre du problème évident qui est qu'elle ne permet pas au pare-feu de remplir sa fonction d'exploration/filtrage des données, et peut donc tolérer un trafic nocif ou indésirable dans le réseau privé. Une autre solution consisterait à établir un canal sécurisé entre le dispositif distant et le pare-feu. Un décryptage peut alors être implanté au niveau du pare-feu ou avant celui-ci, et, après ce décryptage, les paquets décryptés peuvent être explorés/filtrés et transmis au dispositif destinataire dans le réseau privé. Cette solution souffre toutefois du fait que des opérateurs au niveau du pare-feu auront accès aux informations décryptées destinées au dispositif destinataire. En d'autres termes, habituellement, un pare-feu n'est pas un dispositif client, mais un dispositif de fournisseur d'accès, et, en tant que tel, il n'est nullement sécurisant ni souhaitable (du point de vue du client) d'autoriser un accès à des paquets décryptés à ce niveau là. De plus, s'il est nécessaire d'établir une seconde connexion sécurisée entre le pare-feu et le dispositif dans le réseau privé afin de crypter de nouveau les paquets de données (par exemple, en négociant une seconde SA et en établissant une seconde session IPsec), des ressources de calcul non-négligeables doivent alors être consacrées à cette tâche. Il est donc souhaitable de fournir un procédé et un système pour établir une connexion sécurisée entre un dispositif de réseau privé et un second dispositif, même dans un réseau à grande distance tel que l'Internet, sans autoriser un accès à un contenu de données transmises via la connexion à un opérateur de pare-feu. Dans un premier exemple de forme de réalisation, la présente invention concerne un procédé pour implémenter des communications de réseau sécurisées entre un premier dispositif et un second dispositif, au moins l'un des dispositifs communiquant avec l'autre dispositif via un ordinateur séparé. Un tel procédé peut comprendre l'obtention d'un paramètre de cryptage qui est partagé par le premier dispositif, le second dispositif et l'ordinateur séparé et la copie d'un paquet de données transmis par le premier dispositif, à l'intérieur de l'ordinateur séparé. Par la suite, le procédé peut comprendre un décryptage de la copie du paquet de données à l'intérieur d'une section de l'ordinateur séparé, le contenu de la section étant inaccessible à un opérateur de l'ordinateur séparé. Pour terminer, le procédé peut comprendre une exploration de la copie décryptée du paquet de données pour vérifier une conformité avec un critère prédéterminé associé à l'ordinateur séparé afin d'autoriser des transmissions à travers celui-ci. Dans un second exemple de forme de réalisation, la présente invention concerne un dispositif pare-feu pour arbitrer des communications entre un dispositif de réseau privé et un dispositif externe au réseau privé. Un tel dispositif pare-feu peut comprendre un circuit de détermination de paramètre de cryptage qui peut être activé pour déterminer un paramètre de cryptage qui est connu du dispositif externe et du dispositif de réseau privé, ainsi qu'un dispositif d'exploration de contenu contenant le paramètre de cryptage et qui peut être activé pour décrypter le contenu d'une transmission depuis un dispositif externe pour une exploration, ledit contenu étant crypté avec ledit paramètre de cryptage, ledit contenu décrypté étant inaccessible à un opérateur du dispositif pare-feu. Dans le dispositif pare-feu, le dispositif d'exploration de contenu peut autoriser un envoi de la transmission vers le dispositif de réseau privé lorsqu'il est déterminé que le contenu de la transmission satisfait à un critère prédéterminé du dispositif pare-feu. Dans un troisième exemple de forme de réalisation, la présente invention concerne un article manufacturé, qui comprend un support lisible par ordinateur dans lequel est stocké un programme d'ordinateur mettant en oeuvre un procédé pour explorer le contenu d'un paquet de données crypté. Un tel programme d'ordinateur peut comprendre un premier segment de code pour acquérir un paramètre de cryptage utilisé par des premier et second dispositifs pour crypter un paquet de données qui est transmis à travers ceux-ci via l'article manufacturé, ainsi qu'un second segment de code pour décrypter le paquet de données, en utilisant le paramètre de cryptage. Le programme d'ordinateur peut comprendre également un troisième segment de code pour limiter un accès d'un utilisateur de l'article manufacturé au contenu du paquet de données. Pour terminer, le programme d'ordinateur peut comprendre un quatrième segment de code pour filtrer le paquet de données selon que le contenu est en conformité ou pas avec un critère prédéterminé associé à l'article manufacturé. Dans un quatrième exemple de forme de réalisation, la présente invention concerne un procédé de transmission de données. Un tel procédé peut comprendre la mise en forme d'un premier paramètre de cryptage avec un dispositif pare-feu qui reçoit et envoie un trafic destiné à un dispositif de réseau privé qui lui est associé, et par la suite, la mise en forme avec le dispositif pare-feu, en fonction du premier paramètre de cryptage, d'un second paramètre de cryptage qui a été négocié préalablement entre le dispositif pare-feu et le dispositif de réseau privé. Le procédé peut comprendre également la réception au niveau du dispositif pare-feu d'une transmission qui est cryptée en utilisant le second paramètre de cryptage, et par la suite, l'envoi de la transmission reçue du dispositif pare-feu vers le dispositif de réseau privé. Dans un cinquième exemple de forme de réalisation, la présente invention concerne un procédé de transmission de données. Un tel procédé peut comprendre la mise en forme d'un paramètre de cryptage avec un dispositif destinataire à travers un dispositif pare-feu et le partage du paramètre de cryptage avec le dispositif pare-feu. Le procédé peut comprendre également le cryptage d'une transmission en employant le paramètre de cryptage. Pour terminer, le procédé peut comprendre l'envoi de la transmission au dispositif destinataire via le dispositif pare-feu. Dans un sixième exemple de forme de réalisation, la présente invention concerne un procédé pour filtrer des données cryptées au niveau d'un dispositif pare-feu. Un tel procédé peut comprendre la division d'une section de filtrage du dispositif pare-feu par un opérateur de celuici, le décryptage des données cryptées dans la section de filtrage et l'envoi des données si elles sont en conformité avec au moins une règle de filtrage associée au dispositif pare-feu. Dans un septième exemple de forme de réalisation, la présente invention concerne un dispositif pare-feu. Un tel dispositif pare-feu peut comprendre des moyens pour obtenir un paramètre de cryptage commun au premier dispositif et au second dispositif, des moyens pour décrypter des données cryptées transmises par le premier dispositif en utilisant le paramètre de cryptage et des moyens pour envoyer les données cryptées au second dispositif. Les caractéristiques et avantages de l'invention apparaîtront plus clairement à partir de la description suivante et des dessins annexés. La présente invention est décrite en référence aux dessins annexés. Dans les dessins, les éléments identiques ou fonctionnellement analogues sont indiqués avec le même repère. De plus, le chiffre le plus à gauche d'un repère identifie le dessin dans lequel le repère apparaît pour la première fois. La Fig.lA montre un environnent de réseau de la technique antérieure. La Fig.lB montre un environnement de réseau dans lequel une forme de réalisation de la présente invention est susceptible de fonctionner, incluant un pare-feu opérant à la limite d'un réseau privé et communiquant avec un autre dispositif via un réseau WAN public. La Fig.2 montre une méthodologie pour négocier une paire d'associations SA selon la forme de réalisation de l'invention montrée à la Fig.lB. La Fig.3 décrit une forme de réalisation de l'invention dans laquelle des trafics IPsec de différents types sont relayés par un ordinateur pare-feu dans les deux sens, entre deux dispositifs. Les Figs. 4A, 4B et 4D décrivent des structures d'exemples de paquets IPsec qui peuvent être transportés, conformément à différentes formes de réalisation de l'invention. La Fig.4C décrit un exemple de paquet IPsec qui ne requiert aucune exploration spécialisée relativement à la présente invention. La Fig.5 montre des exemples de composants matériels d'un ordinateur pare-feu selon une forme de réalisation de l'invention. Les Figs.6A à 6D décrivent des exemples de structures de certificat pour chaque type de dispositif lorsque des certificats sont utilisées dans le traitement SA. La Fig.7 montre une méthodologie pour négocier une paire d'associations SA selon une variante de forme de réalisation de l'invention. Bien que la présente invention soit décrite ci-après relativement à différents exemples de formes de réalisation, la présente invention ne se limite pas aux seules formes de réalisation divulguées. D'autres formes de réalisation peuvent être implémentées par les hommes du métier, sans s'écarter pour autant de l'esprit et de la portée de la présente invention. A cet égard, bien que IPsec soit utilisé ici pour montrer un exemple de forme de réalisation de l'invention, il doit être clair que la présente invention peut être utilisée dans le contexte d'autres protocoles de sécurité de réseau classiques, tel que le protocole tunnel de couche 2 (L2TP) et le protocole tunnel pour liaison point- à-point (PPTP), comme cela apparaîtra mieux par la suite. De manière similaire, il existe, outre les cryptages IKE et à clé publique, d'autres protocoles/méthodologies qui sont utiles dans l'implémentation de protocoles de sécurité de réseau, et la présente invention peut également être implémentée dans ces environnements. De plus, il convient de noter, comme cela est connu, que la terminologie et les définitions associées utilisées ici sont l'objet d'une certaine controverse entre les spécialistes du domaine technique. Par exemple, certains hommes du métier décriront IKE comme étant un cas particulier de ISAKMP, tandis que d'autres décriront IKE comme étant la combinaison de ISAKMP avec certains autres protocoles. Ces terminologie et définitions sont utilisées ici de manière ponctuelle, ou régulière, uniquement à des fins de clarté, et il doit donc être clair qu'une telle utilisation sert uniquement à l'explication de la présente invention et n'a pas pour finalité de limiter celle-ci. De manière analogue, des termes tels que "cryptage", "paramètres de cryptage" ou tout autre terme du domaine technique, sauf s'ils sont définis autrement ou limités dans la présente description, ne doivent pas être redéfinis comme ayant ici une signification spéciale, et on doit leur conserver leurs interprétations les plus larges, dans les limites du raisonnable, et tout en restant cohérent avec leurs significations classiques dans le domaine technique. La présente invention, dans un exemple de forme de réalisation, intervient en modifiant la fonction d'un dispositif pare-feu classique opérant à la limite d'un réseau privé et qui communique avec un autre dispositif via un réseau WAN public, tel que l'Internet. Cette configuration est montrée à la fois à la Fig.lA et à la Fig.lB, dans lesquelles le dispositif 140 intervient dans un réseau privé 130 derrière un pare-feu ou un autre appareil de réseau dédié 110, et communique via un réseau WAN 120 (tel que l'Internet) avec le dispositif 100. On notera que le dispositif 100 pourra être un dispositif unique dans le réseau WAN 120, ou pourra fonctionner dans son réseau privé propre ou selon toute autre configuration de réseau classique, comme cela apparaîtra par la suite. Des modifications d'un tel pare-feu 110 selon une forme de réalisation de l'invention sont implémentées dans l'établissement d'une ou plusieurs associations de sécurité (SA) pour une ou plusieurs sessions IPsec impliquant des dispositifs 100 et 140, ainsi que dans un mécanisme d'envoi pour les paquets qui sont échangés conformément à ces paramètres établis. Selon une forme de réalisation de l'invention, le pare-feu 110 acquiert une information telle qu'un ou plusieurs paramètres de cryptage qui sont utilisés par celui-ci pour décrypter (et ensuite explorer) des données entrantes. Cependant, cette information est limitée à une section prédéterminée du pare-feu, telle qu'un seul ensemble de circuits intégrés, d'où elle ne peut être extraite par un opérateur du pare-feu. Ainsi, une copie d'un paquet de données entrant peut être effectuée et transmise à la section prédéterminée telle qu'un seul ensemble de circuits intégrés ; laquelle elle peut être décryptée et explorée pour déterminer une conformité avec des règles du pare-feu. Une réponse affirmative/négative doit seulement être fournie ensuite par l'ensemble de circuits intégrés, et, en fonction de cette réponse, la version originale du paquet de données (qui peut être stockée en mémoire-tampon lors de son entrée dans le pare-feu 110) peut être transmise par le pare-feu 110 au dispositif destinataire 140. Il est ensuite possible d'effacer simplement la copie du paquet de données dans l'ensemble de circuits intégrés où elle a été décryptée. En d'autres termes, dans des connexions sécurisées classiques, les dispositifs 100 et 140 constitueront tous deux des points terminaux de type SA et des points terminaux de type tunnel, comme cela est montré à la Fig.lA. De manière différente, conformément à cette forme de réalisation de la présente invention, les dispositifs 100 et 140 restent finalement des points terminaux de type tunnel, mais tous les dispositifs 100,110 et 140 deviennent des points terminaux de type SA pour deux SA séparées, comme cela est montré à la Fig.lB. Par exemple, comme décrit ci-dessous, une passerelle 110 peut envoyer les paramètres de cryptage du dispositif 100 vers le dispositif 140, et inversement, en faisant appel à une fonction analogue à la fonction NAT classique. Comme autre exemple mentionné ci-dessous, la passerelle 110 peut modifier des certificats numériques des dispositifs 100 et 140 de telle manière que la SA est forcée à travers la passerelle 110, même si les paramètres de cryptage réels des dispositifs sont toujours utilisés. De plus, lorsque la passerelle 110 a assumé un tel rôle dans la négociation d'une SA avec un dispositif homologue distant, elle peut également intercepter et envoyer des paquets plus facilement et efficacement vers les dispositifs dans le réseau privé 130. Par exemple, le dispositif 100 peut communiquer avec plusieurs dispositifs dans le réseau privé 130 après avoir établi seulement une SA avec la passerelle 110. La passerelle 110 peut échanger des en-têtes et modifier éventuellement la signature de chaque paquet à la volée, comme cela sera décrit relativement à la Fig. 5. De plus, une passerelle 110 peut arbitrer une négociation de SA directe entre tous les dispositifs terminaux communiquant à travers elle, afin de commander ainsi toutes les communications sécurisées entre les dispositifs terminaux en autorisant uniquement des tunnels sécurisés (relayés) comme décrits ici. La Fig.2 montre une méthodologie pour négocier une paire d'associations SA selon une forme de réalisation de l'invention. A la Fig.2, le dispositif 100 cherche à initier une SA avec le dispositif 140. Cependant, le dispositif 100 n'a pas accès à une adresse IP du dispositif 140. Comme décrit ci-dessus, une SA décrit des opérations qui devront être appliquées aux futurs paquets de données incluant un procédé d'authentification, un procédé de cryptage (et l'algorithme associé), des clés d'authentification/cryptage et différents autres paramètres (tels que l'index de paramètre de sécurité (SPI), une durée de vie effective de la ou des clé(s), etc.). IKE permet à deux dispositifs de négocier et de s'accorder sur ces opérations, y compris l'établissement des clés. Comme décrit ci-dessus, il existe, de manière classique, deux phases dans la négociation d'une SA employant IKE. Ainsi, à la Fig. 2, le dispositif 100 initie une session de phase 1 (PH1) en envoyant le message. Dans une forme de réalisation de l'invention, comme décrit relativement aux Figs.lB et 2, deux SA séparées et des sessions IPsec associées peuvent être négociées, avec le pare-feu 110 qui envoie des paramètres entre les dispositifs 100 et 140. Dans cette forme de réalisation, les trois dispositifs collaborent pour mettre en forme une clé sécrète commune. Dans une autre forme de réalisation de l'invention, comme décrit relativement à la Fig. 7, une première SA peut être établie entre les dispositifs 100 et 140, et une seconde SA peut être établie entre les dispositifs 110 et 140. Dans ce cas, les dispositifs 100 et 140 établissent d'abord ensemble une clé secrète via la première SA. Le dispositif 140 utilise ensuite une clé publique du parefeu 110 pour passer le cryptage et passer la clé secrète au pare-feu 110, qui seront utilisés de la manière décrite ci-dessus pendant des transmissions IPsec. Dans les deux formes de réalisation, il est supposé pour la commodité de l'explication qu'une adresse IP du dispositif 140 sera en général disponible pour le dispositif 100 dans le réseau public 120. Cependant, si tel n'est pas le cas à cause de la présence du dispositif 140 dans le réseau privé 130 qui limite l'accès à ses adresses de dispositifs membres, alors il peut être nécessaire d'implémenter une ou des mesures supplémentaires pour permettre aux dispositifs 100 et 140 de communiquer en toute sécurité. A la Fig.lB, comme cela vient d'être décrit, un dispositif 100 est montré comme négociant SA1 avec le pare-feu 110. Le pare-feu 110 négocie une seconde SA, SA2, avec le dispositif 140. Par la suite, des tunnels IPsec séparés, 1 et 2, sont implémentés, ce qui permet aux dispositifs 100 et 140 de communiquer entre eux de manière sécurisée. Pendant la négociation de SA1 et SA2, le parefeu 110 obtient l'accès à un paramètre de cryptage qui lui permet de décrypter des informations transmises entre les dispositifs 100 et 140. Cependant, le décryptage des informations intervient seulement dans une section du pare-feu 110 qui est hors de portée d'un opérateur du pare-feu 110. Cette section peut donc acquérir une copie de paquets de données entrants, décrypter la copie, explorer la copie pour déterminer une conformité avec des règles du pare-feu, et autoriser/interdire une entrée du paquet crypté à travers le pare-feu 110 et dans le réseau privé 130. La Fig.2 montre une méthodologie pour négocier une paire d'associations SA selon la forme de réalisation de l'invention montrée à la Fig.lB. A la Fig. 2, le dispositif 100 cherche à initier une SA avec le dispositif 140. On notera que ce dispositif 100 peut lui-même être une passerelle ou un dispositif pare-feu, ou qu'il peut être un dispositif de routage ou simplement un ordinateur hôte connecté au réseau WAN 120. Comme décrit ci-dessus, une SA décrit des opérations qui devront être appliquées aux futurs paquets de données, incluant un procédé d'authentification, un procédé de cryptage (et l'algorithme associé), des clés d'authentification/cryptage et divers autres paramètres (tels que l'index de paramètre de sécurité (SPI), une durée de vie effective de la ou des clés, etc.). IKE permet à deux dispositifs de négocier et de s'accorder sur ces opérations, incluant l'établissement des clés. Comme déjà indiqué ci-dessus, il est supposé pour l'objet de cette description que le dispositif 100 a accès à une adresse de dispositif du dispositif 140, telle que son adresse IP. A la Fig. 2, le dispositif 100 initie une session de phase 1 (PH1) pour la première des deux phases classiques dans la négociation d'une SA employant IKE. Dans cette forme de réalisation, le dispositif 100 transmet un message 210 au pare-feu 110 à une adresse IP F1 du parefeu qui peut être rendue publique sur le réseau WAN 120. Ce message, comme décrit ci-dessus, est de manière générale destiné à protéger un trafic de négociation ultérieur au moyen, par exemple, du mode principal. Comme cela est connu, le mode principal procure une protection pour l'identité des dispositifs impliqués. Il est classiquement divisé en trois ensembles de messages, chaque ensemble contenant deux messages. Les deux premiers messages sont utilisés pour négocier une politique de sécurité pour l'échange, les deux messages suivants sont utilisés pour l'échange de matériels de codage de type Diffie-Hellman et les deux derniers messages sont utilisés pour authentifier les homologues, par exemple, avec des signatures numériques et des certificats numériques facultatifs. Dans une forme de réalisation de l'invention, le dispositif 100 peut être préprogrammé de telle manière qu'il croit que l'adresse F1 est une adresse pour le dispositif 140. Dans ce scénario, le pare-feu 110 peut avoir connaissance lors de la réception de la transmission 210 du dispositif avec lequel il établira ensuite une association SA secondaire, SA2, sans avoir à vérifier les détails de la transmission SA 210. Cette implémentation peut utiliser des adresses de "boucle" dans le pare-feu 110, une pour chaque homologue possible dans le réseau privé 130. En d'autres termes, il y aura une adresse différente F1 associée à chacun des dispositifs du réseau privé. Une autre implémentation utilise une adresse IP F1 unique pour tous les flux IPsec du côté réseau WAN. Dans cette solution, le pare-feu 110 doit examiner la transmission 210 pour déterminer le dispositif du réseau privé qui sera le point terminal de tunnel pour des communications avec le dispositif 100. Cette implémentation présente l'avantage qu'un dispositif 100 peut communiquer avec une pluralité de dispositifs dans le réseau privé 130, alors que lui-même n'a besoin d'établir qu'une SA (ou plusieurs) avec le pare-feu 110 (c'est-àdire, une SA par dispositif destinataire). Dans cette dernière implémentation, il est nécessaire de conserver un nom et une identité au dispositif 100, soit localement au niveau du pare-feu 110, soit au niveau d'un système de nom de domaine/serveur (DNS). Cette information peut être utilisée aussi pour identifier le dispositif 140 comme étant le dispositif recherché. On remarquera que SA2 peut démarrer en utilisant un message analogue 220 lors de la réception par le pare-feu 110 du premier message SA1. Dans les différents scénarios traités ci-dessus, dans des cas où le pare-feu 110 ne connaît pas l'identité du dispositif destinataire 140 par un des procédés définis ci-dessus, il attendra un message SA du dispositif 100 contenant une charge utile d'identification. Dans un tel cas, le pare-feu 110 devra procéder avec une négociation de phase 1 avec le dispositif 100 jusqu'à la réception de ce message. La Fig. 2 décrit seulement soit le cas où l'identité du dispositif 140 est incluse dans le premier message 210, soit le cas où celle-ci est déjà connue par le pare-feu 110. Une limitation lorsque l'identité de destination n'est pas connue est que le pare-feu 110 ne démarrera pas la négociation de paramètres qui peuvent s'avérer être inadaptés pour le dispositif 140; une solution dans ce cas est de définir un ensemble de règles commun qui sera accepté par tous les dispositifs dans le réseau privé 130. En supposant que le pare-feu 110 a connaissance de l'identité du dispositif 140, le pare-feu 110 peut ensuite démarrer un message SA de phase 1 secondaire 220 pour SA2, en employant une autre adresse IP F2 pour le pare-feu 110 qui appartient au réseau privé 130 et pour laquelle le dispositif 140 sera capable de répondre. Le dispositif 140 est maintenant le répondeur SA et il répondra au pare-feu 110 en utilisant un message de type PH1BA 230. En d'autres termes, le dispositif 140 recevra des paramètres associés au dispositif 100 mais ayant l'adresse F2, et répondra avec ses propres paramètres à cette adresse. Par la suite, le pare-feu 110 répond au premier message SA 210 et fournit au dispositif 100 un message PH1FA de réponse 240 analogue. En d'autres termes, les mêmes paramètres sont négociés entre le pare-feu 110 et le dispositif 100, comme entre le pare-feu 110 et le dispositif 140. Les deux associations SA sont donc indépendantes, mais négocieront les mêmes règles et paramètres grâce à l'enchevêtrement des messages SA. A ce stade, le pare-feu 110 fournit ses propres paramètres d'authentification, tels que sa propre clé publique d'authentification, mais utilise l'identité du dispositif 140. Si cette vérification est faite via des certificats, alors les certificats seront définis conformément à la Fig. 6, comme cela est décrit ci-après. On notera que les mécanismes SA entre le dispositif 100 et le pare-feu 110, d'une part, et le dispositif 140 et le pare-feu 110, d'autre part, satisfont pleinement aux règles de protocole et traitement IKE, de façon qu'aucune modification n'est requise dans les dispositifs 100 et 140, qui sont donc transparents dans cette implémentation. Une fois la phase 1 réalisée, un canal authentifié totalement sécurisé, avec possibilité de cryptage, est établi afin de continuer avec la phase 2 SA. La phase 2 autorise la définition de paramètres pour le protocole IPsec lui-même, et utilise de manière générale le mode rapide décrit ci-dessus. Un échange de code de type Diffie-Hellman peut être réalisé afin de garantir le secret de la transmission. En référence à ce qui précède, la méthodologie Diffie-Hellman classique autorise deux utilisateurs à mettre en forme une clé secrète symétrique (une même clé est utilisée pour le cryptage et le décryptage) en utilisant leurs clés privées locales, une clé de DiffieHellman (DU) connue et la clé publique de l'autre dispositif (qui peut être transmise via le pare-feu 110, ou être obtenue à partir d'un certificat). Bien qu'elle soit implémentée de manière classique pour deux utilisateurs, comme cela vient d'être décrit, cette méthodologie peut être étendue à un nombre quelconque d'utilisateurs. Conformément à cette forme de réalisation de la présente invention, une clé partagée secrète peut être développée en utilisant l'algorithme de Diffie-Hellman qui est commun à tous les dispositifs 100, 110 et 140. Par exemple, au début de l'utilisation de l'algorithme de Diffie-Hellman, le dispositif 100 ayant une adresse A génère une clé privée désignée "a". Une clé publique correspondante se présentera sous la forme Ta=ga, dans laquelle le paramètre "g" est un paramètre connu selon l'algorithme de Diffie-Hellman, c'est-à-dire, la clé DH. De manière analogue, le pare-feu 110 aura la clé privée "f" et la clé publique Tf=gf, tandis que le dispositif 140 aura la clé privée "b" et la clé publique Tb = gb. Par la suite, le dispositif 100 peut transmettre la clé publique Ta au pare-feu 110, qui peut ensuite calculer une clé secrète Saf - (Ta)f = gaf. Le pare-feu transmet, de manière analogue, Tf au dispositif 100, qui peut alors calculer la clé secrète Sfa = (Tf)a = gaf = Saf. Les dispositifs 100 et 110 partagent ainsi une clé sécrète commune, désignée ci-après "C". Une fois que les dispositifs 100 et 110 partagent la même clé C, ils peuvent calculer chacun la même clé publique TC = gC. Le dispositif 140 possédant la clé privée "b", calcule en attendant la clé publique Tb = gb, comme cela a déjà été indiqué. Par la suite, le dispositif 140 transmet Tb au parefeu 110, qui peut calculer la clé secrète SbC = (Tb)C = gbC. Le pare-feu transmet de manière analogue TC au dispositif 140, qui peut alors calculer la clé secrète SCb = (TC)b = gCb = SbC. Pour terminer, afin de mettre à jour la clé secrète partagée C avec le dispositif 100, le pare-feu 110 envoie Tb au dispositif 100, et le dispositif 100 peut alors calculer la nouvelle clé secrète de la même manière que cela vient juste d'être réalisé par le pare-feu 110, en employant la clé secrète C qu'il possède déjà depuis une étape antérieure, c'est-à-dire: SbC = (Tb)C = gBC. En résumé, les dispositifs 100 et 110 calculent une clé secrète partagée entre eux. Par la suite, les dispositifs 110 et 140 calculent une seconde clé secrète partagée entre eux, en employant la première clé secrète. Pour terminer, le dispositif 100 est capable de calculer la seconde clé secrète en utilisant la première clé secrète et la clé publique du dispositif 140. Ainsi, les trois dispositifs partagent la (seconde) clé secrète, qui peut être utilisée pour crypter/décrypter les paquets IPsec. Une autre manière de décrire le même procédé est de dire que le dispositif 100 calcule la clé secrète en employant sa clé sécrète commune (C) établie avec le dispositif 110, la clé DH et les clés publiques du dispositif 140, tandis que le dispositif 140 calcule la même clé secrète en utilisant sa propre clé privée locale, la clé DH et la clé publique commune (TC) des dispositifs 100 et 110. La clé sécrète commune (SbC), une fois calculée par le pare-feu 110, devra seulement être mémorisée dans celui-ci, par exemple, dans un ensemble matériel de circuits intégrés qui n'est pas accessible par un administrateur du pare-feu. On notera que dans cette description la clé secrète est calculée deux fois entre les dispositifs 100 et 110. Cependant, le dispositif 140 peut également initier le ou les échanges. Dans les deux cas, seulement l'un des deux dispositifs terminaux devra réaliser le calcul de la clé secrète en deux étapes. Tant que les associations SA entre le dispositif 100 et le pare-feu 110, et entre le pare-feu 110 et le dispositif 140, sont valides, la même clé secrète est valide. Les mêmes paramètres de durée de vie de clé devront habituellement être négociés des deux manières. L'un ou l'autre des dispositifs 100 ou 140 pourra initier l'échange en mode rapide associé aux négociations SA de phase 2. A la Fig. 2, le dispositif 140 est l'initiateur de la seconde phase démarrant avec le message PH2BI 250. Le pare-feu 110 reconstruit un message PH2FI 260 analogue, dans lequel la clé (publique) d'authentification du dispositif 140 est remplacée par un calcul des clés publiques des dispositifs 110 et 140 conjointement (compte-tenu que le dispositif 100 aura besoin du paramètre du dispositif 140 pour le calcul de clé secrète, comme cela vient d'être décrit). Le dispositif 100 répond au pare-feu 110 avec ses propres paramètres dans le message PH2AA 270, et le parefeu 110 envoie le message incluant les mêmes valeurs de paramètre, à l'exception de la clé d'authentification du dispositif 100, qui est échangé pour une combinaison de lui-même et de la clé du pare-feu 110, avec le dispositif 140, dans le message PH2FA 280. On notera qu'un message supplémentaire peut être transmis par le pare-feu 110 pour fournir au dispositif 100 l'adresse IP à utiliser pendant la session IPsec comme adresse pour le dispositif 140, en particulier lorsque l'adresse IP SA pour le dispositif 140 n'est pas la même que celle utilisée pour le trafic IPsec. Un dernier message qui peut être vu comme un acquittement final est également transmis en retour, ceci n'étant pas représenté à la Fig. 2. Un tel message finalise les associations SA pour le trafic IPsec entre les dispositifs 100 et 140. Compte-tenu que les associations SA sont classiquement asymétriques, il peut être nécessaire de répéter le processus décrit ci-dessus dans la direction inverse. Cependant, il peut être nécessaire de réaliser seulement une négociation de phase 2, comme cela est connu. Une fois que toutes les associations SA sont actives, le trafic IPsec peut démarrer dans les deux sens. La Fig.3 décrit un trafic IPsec dans les deux sens entre les dispositifs 100 et 140 à travers le pare-feu 110. A la Fig. 3, seulement un en-tête ESP est utilisé (ce qui signifie, comme décrit ci-dessus, qu'un cryptage est impliqué, mais il n'est pas nécessaire de fournir une authentification de paquet complète). AH peut être utilisé conjointement avec ESP si une authentification de paquet complète est requise, de manière connue ; ce scénario n'est pas montré explicitement à la Fig. 3. Dans le cas où AH est utilisé seul sans cryptage (c'est-à-dire, avec un paquet faisant appel au format montré à la Fig. 4C décrite ci-dessous), le pare-feu 110 peut réaliser simplement un filtrage classique (sachant que la présente invention ne sera pas nécessaire dans un tel scénario). A la Fig. 3, un premier paquet IPsec est transmis du dispositif 100 au pare-feu 110 à l'étape 310. Lorsque le pare-feu 110 reconnaît un paquet ayant F1 comme adresse de destination, il vérifie d'abord un champ de protocole ("PROT") dans le paquet afin de déterminer le traitement à utiliser. Le champ PROT indiquera s'il convient d'utiliser un traitement de flux ESP IPsec ou un flux AH (+ESP ou non). A l'étape 310, le protocole est ESP, et donc, le pare-feu 110 doit copier le paquet, stocker (en mémoire- tampon) l'original, décrypter la charge utile copiée et explorer le contenu de la charge utile copiée. Si le paquet copié est valide, l'original est ensuite envoyé au dispositif 140 ; sinon,le paquet est écarté et un message peut être enregistré pour cela à des fins de gestion du réseau. On notera que le paquet original stocké en mémoire-tampon est envoyé au dispositif 140 ; cette manière, aucun nouveau cryptage n'est réalisé dans le pare-feu 110, et le paquet peut être envoyé facilement et rapidement lors de l'approbation de la version copiée et explorée du paquet. Les Figs.4A, 4B et 4D décrivent des structures d'exemples de paquets IPsec qui peuvent être transportés conformément à différentes formes de réalisation de l'invention. La Fig. 4C décrit un exemple de paquet IPsec qui ne requiert aucune exploration spécialisée relativement à la présente invention. A la Fig. 4A, un paquet 410 représente un paquet IPsec utilisant le mode de tunnel IPsec avec un en-tête ESP 416. La charge utile intérieure 412 et l'en-tête IP 414 sont cryptés, tandis que le paquet complet à l'exception de l'en-tête de tunnel 418 est authentifié (c'est-à-dire, intégré dans la signature de paquet). A la Fig. 4B, un paquet 420représente un paquet IPsec utilisant un mode de transport IPsec avec l'en-tête ESP 428 et un mode de tunnel à encapsulation avec routage générique (GRE). La charge utile intérieure 422 et l'entête IP 424 ainsi que la section GRE 426 sont cryptés, tandis que le paquet complet à l'exception de l'en-tête de tunnel 429 est intégré dans la signature de paquet (c'est- à-dire, authentifié). A la Fig. 4C, un paquet 430 représente un paquet IPsec utilisant un mode de tunnel IPsec avec un en-tête AH 436. Aucun champ n'est crypté, tandis que le paquet complet incluant l'en-tête de tunnel 438 est intégré dans la signature de paquet. Aucun traitement spécial selon la présente invention n'est effectué dans le pare-feu 110 avec de tels paquets. Ils sont justes surveillés au moyen d'une fonction de pare-feu autorisée capable de reconnaître l'en-tête AH afin de localiser correctement l'en-tête IP original et la charge utile. A la Fig. 4D, un paquet 440 représente un paquet IPsec utilisant le mode de tunnel IPsec avec des en-têtes AH et ESP 448 et 446, respectivement. La charge utile intérieure 442 et l'en-tête IP 444 sont cryptés, tandis que le paquet complet incluant l'en-tête de tunnel 449 est intégré dans la signature de paquet. La Fig.5 montre des exemples de composants matériels d'un ordinateur pare-feu 510 selon une forme de réalisation de l'invention. Le pare-feu 510 inclut deux interfaces pour les deux réseaux externes 120 et 130. La première interface INTF A 520 comporte une entrée ENTREE~WAN et une sortie SORTIE~WAN. Lorsqu'un paquet arrive dans l'interface ENTREE~WAN, il est transmis au bloc de traitement d'entrée ENTREE 530 via des fils conducteurs P IN et un bus de données. Ce traitement détermine si le paquet est un paquet de données (qui peut être crypté ou pas), ou s'il s'agit d'un message SA marqué pour être intercepté par le pare-feu 510. Dans ce dernier cas, le paquet est transmis via un fil conducteur SA~A~IN au bloc de négociation SA et de gestion de clé du côté réseau WAN, à savoir, GEST~SA &NEGO~CLE A 570. A ce stade, le traitement décrit à la Fig. 2 est réalisé ; traitement peut impliquer une modification, un codage ou un décodage de message et/ou une ou plusieurs transmissions de réponse destinés au dispositif 100 via un fil conducteur SA~A~OUT. De manière analogue, lorsqu'un message SA est reçu par le dispositif 140 sur INTF B 560, il est reçu sur GEST~SA &NEGO~CLE B 580 via SA~B~IN. Des réponses à un message SA provenant du dispositif 140 sont transmises en utilisant un fil conducteur SA~B~OUT au traitement de sortie SORTIE 550, qui sert à mettre en file d'attente les flux de paquets. Des informations sont transmises par un bloc de gestion SA (570,580) à un autre bloc au moyen du dispositif PONT~SA 595. Le dispositif PONT~SA peut servir à réaliser le calcul de 3ième partie de Diffie-Hellman et la création de clé décrite ci-dessus, en employant une clé publique Tf du pare-feu 510 octroyée aux dispositifs 100 et 140. De plus, la clé publique de cryptage provenant du dispositif 100, Ta, est transmise par le bloc 570 au bloc 590 et, de manière analogue, la clé publique de cryptage provenant de B est transmise par le bloc 580 au bloc 590. Ainsi, le dispositif d'exploration de contenu de pare-feu de sécurité 590 est capable de calculer la clé secrète partagée en employant les clés publiques de cryptage Ta et Tb conjointement avec sa propre clé privée de cryptage "f". La clé secrète reste donc toujours en sécurité dans la puce 590, et n'est jamais visible pour les utilisateurs ou les administrateurs du pare-feu. Il est également impossible de la trouver en employant des moyens matériels d'analyse. Lorsque le paquet est un paquet IP non-crypté classique (ou un paquet utilisant seulement un en-tête AH IPsec, comme montré à la Fig.4C), plutôt qu'un message SA, le paquet est envoyé par le traitement d'entrée ENTREE 530 à une fonction de pare-feu standard STDF 545, qui réalise toutes les opérations nécessaires de filtrage et/ou d'exploration des données. Ensuite, lorsqu'il n'est pas filtré, le paquet est envoyé au traitement de sortie SORTIE 550, en file d'attente, pour une exportation vers l'interface INTF B 560. Le paquet est ensuite transmis dans la liaison de sortie de réseau SORTIE~RESEAU, comme montré. Si le paquet n'est ni un message SA, ni un paquet normal (non-crypté), mais un paquet crypté défini comme "devant être exploré", alors il est stocké dans la mémoire-tampon de paquets 540 en employant des fils conducteurs et un bus de données P-STO. Une commande d'exploration COMD~EXPL est également transmise par le traitement d'entrée ENTREE 530 au dispositif d'exploration de contenu de pare-feu de sécurité 590. La commande d'exploration COMD~EXPL contient un pointeur de paquet, tel qu'un numéro de paquet, qui permet au dispositif d'exploration de contenu de pare-feu de sécurité 590 d'obtenir une copie du paquet pour un décryptage, via un bus P-RD. Une fois décryptée, la copie de paquet est vérifiée en utilisant des règles de pare-feu standard. Le résultat peut être soit une mise à l'écart du paquet original stocké dans la mémoire-tampon de paquets 540, soit une autorisation de sa transmission ; dansles deux cas, le dispositif d'exploration de contenu de pare-feu de sécurité 590 peut par la suite écarter la copie explorée du paquet. De manière différente, une modification du paquet afin de le mettre en conformité avec des règles du parefeu (ou une extraction de seulement les parties qui ne sont pas en conformité avec des règles du pare-feu, et une autorisation de passage pour la partie restante) est également faisable, comme cela apparaîtra clairement à l'homme du métier. Par exemple, cette modification de paquet pourra être implémentée au moyen d'un mécanisme de transmission de données du dispositif d'exploration de contenu de pare-feu de sécurité 590 vers le bloc 550. Le fil conducteur SD AT fournit au traitement de sortie SORTIE 550 une information pour transmettre (SD) le paquet ou pour abandonner (AT) la transmission de paquet. SD~AT peut également inclure un pointeur de paquet, tel qu'un numéro de paquet afin d'identifier le paquet. Une commande d'effacement CL~GT peut ensuite être transmise par le traitement de sortie SORTIE 550 pour effacer ou lire le paquet ci-dessus, en employant le pointeur de paquet. Dans ce dernier cas, le paquet peut être envoyé par une mémoire-tampon TAMPON 540 au traitement de sortie SORTIE 550 en utilisant le bus P-FW. Le paquet peut ensuite être transmis sur la liaison de sortie de réseau SORTIE RESEAU via INTF B 560 et le bus P OUT. Le mécanisme qui vient d'être décrit relativement à la Fig.5 est un mécanisme unidirectionnel, en ce qu'il protège des données transmises du dispositif 100 dans le réseau WAN 120 jusqu'au dispositif 140 dans le réseau privé 130. Cependant, sachant que le traitement de transmission de trafic crypté est asymétrique pour les associations SA, et pour le trafic crypté lui-même (qui peut utiliser différents ensembles de clés et de paramètres), une autre puce de dispositif d'exploration de contenu de pare-feu de sécurité (ou la même si elle est partagée), ainsi qu'un autre ensemble blocs de traitement d'ENTREE et de SORTIE et de mémoire-tampon de paquets, peuvent être implémentés pour explorer des données transmises dans la direction du dispositif 140 vers le dispositif 100. La Fig. 6 décrit des exemples de structures de certificat pour chaque type de dispositif lorsque des certificats sont utilisés dans le traitement SA. Les certificats 600a et 600b pour les dispositifs 100 et 140 aux Figs.6A et 6B peuvent être des certificats de type standard ou "vrai", compte-tenu que tous les paramètres inclus dans le champ de certificat appartiennent réellement à ces dispositifs. Un certificat 600a pour l'adresse de dispositif A, comme à la Fig. 6A, est seulement octroyé à un dispositif situé dans le réseau WAN 120, et un certificat 600b pour l'adresse de dispositif B, comme à la Fig. 6B, est seulement octroyé à un dispositif situé dans le réseau privé 130. Comme montré à la Fig.6A, une portion 610a du certificat 600a peut contenir une identité et une signature d'une autorité de certification (CA), tandis qu'une portion 620a contient diverses informations pour le dispositif 100 ayant l'adresse A, incluant son identité sur le réseau WAN 120, l'adresse IP, la clé publique du dispositif, la clé publique d'authentification IPsec et la clé publique de cryptage IPsec. De manière analogue, comme montré à la Fig.6B, une portion 610b du certificat 600b peut contenir l'identité et la signature de CA, tandis qu'une portion 620b contient diverses information pour le dispositif 140 ayant l'adresse B, incluant son identité dans le réseau privé 130, l'adresse IP, la clé publique du dispositif, la clé publique d'authentification IPsec et la clé publique de cryptage IPsec. La Fig.6C montre un type de certificat 600c qu'un dispositif 140 ayant l'adresse de dispositif B (ou un dispositif localisé de manière analogue) peut recevoir lorsqu'il demande un certificat pour un dispositif tel qu'un dispositif 100 ayant l'adresse de dispositif A (ou un dispositif localisé de manière analogue). Un certificat tel que 600c est un certificat "faux" valide, car il est validé par l'autorité CA même s'il contient certains champs avec des informations erronées pour travailler correctement. Ce qui signifie que si le certificat 600c est considéré comme appartenant au pare-feu 110, alors le pare-feu 110 simule le dispositif 100 ayant une adresse A comme possédant l'identité du dispositif (tant que le réseau privé 130 est concerné) et une clé de cryptage publique qui inclut la clé de cryptage publique du dispositif plus la propre clé de cryptage publique du pare-feu. Des commentaires analogues s'appliquent dans le cas inverse au certificat 600d à la Fig. 6D. Un tel certificat 600d permet au pare-feu 110 de simuler le dispositif 140 ayant l'adresse B, mais présentant sa propre clé publique de dispositif et sa clé publique de cryptage IPsec. La Fig.7 montre une méthodologie pour négocier une paire d'associations SA selon une variante de forme de réalisation de l'invention. A la Fig. 7, une première association SA 710 est établie entre les dispositifs 100 et 140 par l'intermédiaire du pare-feu 110. Une seconde association SA 720 est ensuite établie entre le pare-feu 110 et le dispositif 140. Les dispositifs 100 et 140 conviennent d'abord, dans l'échange 730, d'une clé secrète de cryptage IPsec, Ke. Par la suite, cette clé Ke est cryptée par le dispositif 140 en utilisant une clé publique de cryptage du pare-feu 110, ce qui donne PkF(Ke). La clé Ke cryptée (c'est-à-dire, PkF(Ke)) est envoyée après au pare-feu 110 au moyen du message 740 dans SA2 720. Le pare-feu 110 décrypte PkF(Ke) pour obtenir Ke, et il est alors libre d'utiliser Ke pour décrypter/explorer des paquets de la manière décrite ci-dessus relativement à la Fig. 5. On notera que bien que la Fig.7 décrive le cas où SA2 est établie entre les dispositifs 110 et 140, celle-ci pourrait tout aussi bien être établie entre les dispositifs 100 et 110. De plus, dans cette forme de réalisation, il peut être nécessaire de mettre en forme et d'utiliser des clés séparées pour des transmissions et des réceptions entre les dispositifs 100 et 140. Si un opérateur décide d'utiliser cette caractéristique, alors le dispositif 100 peut être utilisé pour fournir les deux clés, ou bien, le traitement peut être exécuté de telle manière que c'est le dispositif 140 qui fournit la seconde clé. En guise de conclusion, la présente invention a décrit une méthodologie pour explorer des données entrantes sans sacrifier la sécurité des données. En faisant cela, conformément à une forme de réalisation de l'invention, une clé sécrète commune est partagée entre deux dispositifs terminaux et un dispositif pare-feu. Les données sont reçues, stockées en mémoire-tampon et copiées lors de leur entrée dans le pare-feu; la copie des données est décryptée et explorée, en employant la clé sécrète commune, dans une section du pare-feu qui est inaccessible à un opérateur du pare-feu. Lorsque les données ne violent aucune des règles du pare-feu, alors les données originales stockées en mémoire-tampon sont autorisées à passer à travers le pare-feu, tandis que la copie explorée est effacée. Dans le cas inverse, les deux copies peuvent être effacées, et un administrateur de réseau et/ou l'émetteur du message peuvent être informés de l'apparition d'une violation des règles du pare-feu. Bien que différentes formes de réalisation de la présente invention aient été décrites ici de manière détaillée, toutes les caractéristiques et/ou implémentations de l'invention n'ont pas été décrites. Par exemple, bien que le réseau WAN 120ait été principalement décrit comme un réseau public tel que l'Internet, il peut prendre la forme d'un réseau local (LAN), d'un réseau privé, etc. Par ailleurs, deux homologues terminaux sont seulement décrits de manière détaillée dans cette description, car le protocole IPsec est un protocole point-à-point. Cependant, davantage de dispositifs peuvent être interconnectés entre eux par l'intermédiaire d'un pare-feu. Il est également possible d'avoir plusieurs dispositifs situés d'un côté qui établissent une communication sécurisée avec un même dispositif situé de l'autre côté, même si chaque communication IPsec est séparée et requiert sa propre association de sécurité correspondante. Par conséquent, il devra être clair que bien que cette invention ait été décrite à travers différentes formes de réalisation explicatives, d'autres formes de réalisation et variantes peuvent être réalisées par un homme du métier sans sortir pour autant de la portée de l'invention. REVENDICATIONS 1. Procédé pour implémenter des communications de réseau sécurisées entre un premier dispositif et un second dispositif, l'un au moins des dispositifs communiquant avec l'autre dispositif via un ordinateur séparé, caractérisé en ce qu'il comprend les étapes consistant à: obtenir un paramètre de cryptage qui est partagé par le premier dispositif, le second dispositif et l'ordinateur séparé; copier un paquet de données transmis par le premier dispositif, à l'intérieur de l'ordinateur séparé; décrypter la copie du paquet de données dans une section de l'ordinateur séparé, le contenu de la section étant inaccessible à un opérateur de l'ordinateur séparé; et explorer la copie décryptée du paquet de données pour vérifier une conformité avec un critère prédéterminé associé à l'ordinateur séparé pour autoriser des transmissions à travers celui-ci. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend également l'étape consistant à: envoyer le paquet de données au second dispositif si la copie du paquet de données est en conformité avec le critère prédéterminé. 3. Procédé selon la revendication 1, caractérisé en ce qu'il comprend également l'étape consistant à: effacer le paquet de données s'il n'est pas en conformité avec le critère prédéterminé. 4. Procédé selon la revendication 1, caractérisé en ce qu'il comprend également l'étape consistant à: effacer la copie décryptée du paquet de données une fois que celle-ci a été explorée. 5. Procédé selon la revendication 1, caractérisé en ce que la section de l'ordinateur séparé qui est inaccessible à l'opérateur de l'ordinateur séparé est un ensemble matériel de circuits intégrés dans l'ordinateur séparé. 6. Procédé selon la revendication 1, caractérisé en ce que l'étape d'obtention d'un paramètre de cryptage comprend également les sous-étapes consistant à: mettre en forme une première clé secrète avec le premier dispositif pendant une négociation d'une première association de sécurité; mettre en forme une seconde clé secrète, en fonction de la première clé secrète, avec le second dispositif pendant une négociation d'une seconde association de sécurité; communiquer au premier dispositif une information qui autorise le premier dispositif à calculer la seconde clé secrète en utilisant la première clé secrète, la seconde clé secrète étant utilisée comme paramètre de cryptage. 7. Procédé selon la revendication 6, caractérisé en ce que des clés publiques associées au premier dispositif, au second dispositif, ou à l'ordinateur séparé sont authentifiées grâce à leur inclusion dans un certificat numérique. 8. Procédé selon la revendication 6, caractérisé en ce que l'information est la clé publique du second dispositif. 9. Procédé selon la revendication 6, caractérisé en ce que les associations de sécurité sont négociées entre le premier dispositif et une première adresse de l'ordinateur séparé associée au second dispositif, et entre le second dispositif et une seconde adresse de l'ordinateur séparé associée au premier dispositif. 10. Procédé selon la revendication 1, caractérisé en ce que l'étape d'obtention du paramètre de cryptage comprend également les sous-étapes consistant à: négocier, de manière transparente à travers l'ordinateur séparé, une première association de sécurité entre le premier dispositif et le second dispositif; partager le paramètre de cryptage entre les premier et second dispositifs en utilisant la première association de sécurité; négocier une seconde association de sécurité entre le premier dispositif et l'ordinateur séparé ; partager le paramètre de cryptage entre le premier dispositif et l'ordinateur séparé au moyen de la seconde association de sécurité. 11. Dispositif pare-feu pour arbitrer des communications entre un dispositif de réseau privé et un dispositif externe au réseau privé, caractérisé en ce qu'il comprend: un circuit de détermination de paramètre de cryptage qui peut être activé pour déterminer un paramètre de cryptage connu du dispositif externe et du dispositif de réseau privé ; un dispositif d'exploration de contenu contenant le paramètre de cryptage et apte à agir pour décrypter un contenu d'une transmission du dispositif externe pour effectuer une exploration, ledit contenu étant crypté avec ledit paramètre de cryptage, et ledit contenu décrypté étant inaccessible à un opérateur du dispositif pare-feu, et en ce que le dispositif d'exploration de contenu permet un envoi de la transmission au dispositif de réseau privé, lorsqu'il est déterminé que le contenu de la transmission est en conformité avec un critère prédéterminé du dispositif pare-feu. 12. Dispositif pare-feu selon la revendication 11, caractérisé en ce que le dispositif d'exploration de contenu peut agir pour copier la transmission et réaliser un décryptage et une exploration de la copie de la transmission. 13. Dispositif pare-feu selon la revendication 12, caractérisé en ce qu'il comprend également: un tampon pour mémoriser la transmission pendant que la copie de la transmission est décryptée et explorée dans le dispositif d'exploration de contenu. 14. Dispositif pare-feu selon la revendication 11, caractérisé en ce que le circuit de détermination de paramètre de cryptage comprend également: un premier circuit d'association de sécurité apte à agir pour négocier et gérer une association de sécurité avec le dispositif externe ; un second circuit d'association de sécurité apte à agir pour négocier et gérer une association de sécurité avec le dispositif de réseau privé. 15. Dispositif pare-feu selon la revendication 14, caractérisé en ce que le premier circuit d'association de sécurité met en forme une première clé secrète avec le dispositif externe, et le second circuit d'association de sécurité met en forme une seconde clé secrète, en fonction de la première clé secrète, avec le dispositif de réseau privé, et en ce que le premier circuit d'association de sécurité communique au dispositif externe une information qui permet au dispositif externe de mettre en forme la seconde clé secrète, la seconde clé secrète étant ensuite utilisée comme paramètre de cryptage. 16. Dispositif pare-feu selon la revendication 11, caractérisé en ce que ledit circuit de détermination de paramètre de cryptage comprend également: un circuit d'association de sécurité apte à agir pour négocier une association de sécurité avec le dispositif externe ou le dispositif de réseau privé, et en ce que le dispositif pare-feu obtient le paramètre de cryptage comprenant une clé secrète préalablement négociée par le dispositif externe et le dispositif de réseau privé. 17. Dispositif pare-feu selon la revendication 11, caractérisé en ce que le dispositif d'exploration de contenu comprend un ensemble matériel de circuits intégrés. 18. Article manufacturé qui comprend un support lisible par un ordinateur, dans lequel est stocké un programme d'ordinateur mettant en oeuvre un procédé pour explorer un contenu d'un paquet de données crypté, caractérisé en ce que le programme d'ordinateur comprend: un premier segment de code pour acquérir un paramètre de cryptage utilisé par des premier et second dispositifs pour crypter un paquet de données qui est transmis à travers ceux-ci via l'article manufacturé; un second segment de code pour décrypter le paquet de données, en utilisant le paramètre de cryptage; un troisième segment de code pour limiter un accès d'un utilisateur de l'article manufacturé au contenu du paquet de données ; un quatrième segment de code pour filtrer le paquet de données selon que le contenu est en conformité ou pas avec un critère prédéterminé associé à l'article manufacturé. 19. Article manufacturé selon la revendication 18, caractérisé en ce qu'il comprend également: un cinquième segment de code pour copier le paquet de données crypté ; un sixième segment de code pour fournir la copie du paquet de données crypté aux second, troisième et quatrième segments de code. 20. Article manufacturé selon la revendication 19, caractérisé en ce qu'il comprend également: un septième segment de code pour mémoriser le paquet de données crypté pendant une opération des second à sixième segments de code, et en ce que le septième segment de code envoie le paquet de données crypté lorsqu'une information est fournie par le quatrième segment de code pour indiquer que le contenu est en conformité avec le critère prédéterminé. 21. Article manufacturé selon la revendication 18, caractérisé en ce que le paramètre de cryptage est une clé secrète de cryptage négociée conjointement par le premier dispositif, le second dispositif et l'article manufacturé. 22. Article manufacturé selon la revendication 21, caractérisé en ce que le paramètre de cryptage est négocié conjointement en tant que partie de deux associations de sécurité indépendantes, une première association étant négociée entre le premier dispositif et l'article manufacturé, et la seconde association étant négociée entre l'article manufacturé et le second dispositif. 23. Article manufacturé selon la revendication 18, caractérisé en ce que le paramètre de cryptage est une clé secrète de cryptage négociée entre les premier et second dispositifs et partagée ensuite avec l'article manufacturé via une association de sécurité négociée entre l'article manufacturé et l'un des premier et second dispositifs. 24. Article manufacturé selon la revendication 18, caractérisé en ce que les second, troisième et quatrième segments de code résident dans un ensemble matériel de circuits intégrés à l'intérieur de l'article manufacturé. 25. Procédé de transmission de données caractérisé en ce qu'il comprend les étapes consistant à: mettre en forme un premier paramètre de cryptage avec un dispositif pare-feu qui reçoit et envoie un trafic destiné à un dispositif de réseau privé qui lui est associé ; mettre en forme avec le dispositif pare-feu, en fonction du premier paramètre de cryptage, un second paramètre de cryptage qui a été négocié préalablement entre le dispositif pare-feu et le dispositif de réseau privé; recevoir au niveau du dispositif pare-feu une transmission qui est cryptée en utilisant le second paramètre de cryptage ; envoyer la transmission reçue du dispositif pare-feu vers le dispositif de réseau privé. 26. Procédé selon la revendication 25, caractérisé en ce que l'étape de partage d'un premier paramètre de cryptage avec un dispositif pare-feu comprend également les sous- étapes consistant à: négocier une association de sécurité avec le dispositif pare-feu ; mettre en forme une première clé secrète de cryptage avec le dispositif pare-feu pendant l'association de sécurité. 27. Procédé selon la revendication 26, caractérisé en ce qu'il comprend également une étape de mise en forme d'une seconde clé secrète de cryptage avec le dispositif parefeu pendant l'association de sécurité, la seconde clé secrète de cryptage étant basée sur la première clé secrète de cryptage. 28. Procédé de transmission de données, caractérisé en ce qu'il comprend les étapes consistant à: mettre en forme un paramètre de cryptage avec un dispositif destinataire à travers un dispositif pare-feu; partager le paramètre de cryptage avec le dispositif pare-feu; crypter une transmission en employant le paramètre de cryptage ; et envoyer la transmission au dispositif destinataire via le dispositif pare-feu. 29. Procédé selon la revendication 28, caractérisé en ce que l'étape de mise en forme d'un paramètre de cryptage comprend également la sous-étape consistant à: mettre en forme une clé secrète de cryptage pendant une première négociation d'association de sécurité, et en ce que ladite étape de partage de la clé secrète avec le dispositif pare-feu comprend également la sous-étape consistant à: communiquer le clé secrète de cryptage au dispositif pare-feu pendant une seconde négociation d'association de sécurité. 30. Procédé de filtrage de données cryptées au niveau d'un dispositif pare-feu, caractérisé en ce qu'il comprend les étapes consistant à: séparer une section de filtrage du dispositif parefeu vis-à-vis d'un opérateur de celui-ci; décrypter les données cryptées à l'intérieur de la section de filtrage ; envoyer les données si elles sont en conformité avec au moins une règle de filtrage associée au dispositif pare-feu. 31. Procédé selon la revendication 30, caractérisé en ce qu'il comprend également l'étape consistant à: négocier un paramètre de cryptage commun à un dispositif de transmission et à un dispositif de réception des données cryptées, et en ce que le paramètre de cryptage est utilisé par le dispositif de transmission pour crypter des données pour une transmission et par la section de filtrage pour décrypter la portion cryptée. 32. Procédé selon la revendication 30, caractérisé en ce que l'étape de décryptage des données cryptées comprend également les sous-étapes consistant à: copier les données cryptées dans la section de filtrage ; décrypter la copie des données cryptées ; signaler à une section d'envoi du dispositif pare-feu si la copie décryptée est en conformité ou pas avec au moins une règle de filtrage. 33. Dispositif pare-feu, caractérisé en ce qu'il comprend: des moyens pour obtenir un paramètre de cryptage commun à un premier dispositif et à un second dispositif; des moyens pour décrypter des données cryptées transmises par le premier dispositif en utilisant le paramètre de cryptage ; des moyens pour envoyer les données cryptées au second dispositif.