FR2838896A1 - Procedes et dispositifs pour former des connexions de reseau securisee sur un reseau prive - Google Patents

Abstract

L'invention concerne des procédés et systèmes pour établir des connexions de réseau sécurisées. Lorsqu'un dispositif (140) réside dans un réseau privé (130) tel que son adresse n'est normalement pas disponible pour d'autres dispositifs (100) via un réseau public (120), une passerelle ou un coupe-feu (110), peut être utilisé pour garder secrète l'adresse du dispositif du réseau privé tout en permettant une connexion de bout en bout sécurisée entre les dispositifs (100, 140). La passerelle (110) peut négocier des connexions sécurisées séparées, telles que des associations de sécurité, avec chacun des dispositifs des deux réseaux. Ainsi, les paramètres de cryptage de ces deux dispositifs peuvent être échangés même si chacun d'eux ignore l'adresse de l'autre. En outre, la passerelle peut remplir cette fonction sans avoir lui-même accès au contenu transmis entre les dispositifs du réseau public et du réseau privé.

Description

<Desc/Clms Page number 1>

Domaine de l'invention
La présente invention concerne la formation et l'utilisation de connexions de réseau sécurisées. Plus spécifiquement, la présente invention la formation de connexions de réseau sécurisées pour dispositifs au sein d'un réseau privé.

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 les uns avec les autres. 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

<Desc/Clms Page number 2>

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 sécurité selon IP, 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

<Desc/Clms Page number 3>

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 d'origine 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 #uvre 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

<Desc/Clms Page number 4>

d'utiliser les ressources dont une société dispose au niveau de son siège principal.

Pour mettre en #uvre 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é sont définies par des paramètres, tels qu'une adresse de destination IP et un identificateur de protocole de sécurité (AH ou ESP, par exemple). Les associations de sécurité 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 #uvre de l'ISAKMP est connue sous le nom d'échange de codes Internet (Internet Key Exchange (IKE)).

<Desc/Clms Page number 5>

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 en code public également connu sous le nom de cryptage DiffieHellman. En cryptage en code public, chaque utilisateur génère un code public et un code privé, le code public étant ensuite transmis à l'autre partie. Lorsque chaque utilisateur combine son propre code privé avec le code public de l'autre (et éventuellement des informations supplémentaires), les deux utilisateurs peuvent chacun obtenir un code secret identique. Ce code secret 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 du code public du second utilisateur, après quoi seul le second utilisateur (à l'aide de son propre code privé) sera en mesure de décrypter et de recevoir le message.

De même, un premier utilisateur peut utiliser son code privé pour signer un message, le second utilisateur pouvant, grâce au code public 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 codes sont générés au départ. C'est pourquoi il existe des autorités de

<Desc/Clms Page number 6>

certification (CA) indépendantes et homologuées qui délivrent des certificats numériques vérifiant l'association d'un code public 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 code public 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 un 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 la discussion précitée, il existe donc diverses solutions pour mettre en #uvre des communications privées et authentifiées sur un réseau.

Dans ces solutions, par exemple, un protocole, tel que

<Desc/Clms Page number 7>

le IPsec, exige que les dispositifs entre lesquels une connexion sécurisée sera établie soient disponibles dans un environnement IP. En d'autres termes, les dispositifs doivent avoir leurs adresses IP disponibles sous la forme d'une adresse enregistrée acheminable.

Cependant, il se pose fréquemment le cas qu'une adresse IP d'un dispositif ne soit pas disponible pour le WAN entier. Par exemple, un dispositif peut être localisé dans un réseau privé et protégé par une passerelle ou un coupe-feu externe, qui pourrait être contenu(e) dans un fournisseur de services Internet (ISP) ou un sponsor commercial du dispositif. Bien que beaucoup de ces passerelles aient une fonction de traduction d'adresses de réseau (NAT) qui fait la différence entre une adresse interne et une adresse externe de chaque dispositif dans le réseau privé, cette fonction n'offre pas de moyen à un dispositif éloigné d'accéder à une adresse IP réelle d'un dispositif membre du réseau privé via la passerelle.

Bien que certaines solutions courantes de ce scénario utilisant les technologies précitées soient disponibles, aucune d'entre elles ne convient complètement. Par exemple, comme montré sur la Fig. 1A (où aucune NAT n'est mise en #uvre), il est possible simplement de désactiver l'appareil filtrant d'un coupe-feu par rapport à l'ensemble de dispositifs en question. Sur la Fig. 1A, le dispositif 100 sur le WAN 120 est pourvu d'une adresse du dispositif 140 (et un accès à celui-ci) dans le réseau privé 130. En conséquence, les dispositifs 100 et 140 peuvent établir une SA et une connexion en tunnel comme montré, c'est- à-dire que ces dispositifs ont tous deux des points

<Desc/Clms Page number 8>

terminaux SA et des points terminaux tunnel et peuvent communiquer l'un avec l'autre de manière sécurisée.

Cependant, cette solution a l'inconvénient manifeste de créer un trou dans la sécurité du réseau.

Par exemple, une fois qu'un accès au dispositif 140 est fourni aux utilisateurs du WAN 120, n'importe quel utilisateur du WAN 120 peut accéder à ce dispositif.

Cet accès peut alors mener à divers problèmes de protection du dispositif 140 ou de n'importe quel dispositif du réseau privé 130.

Un autre exemple de solution classique est d'établir un canal sécurisé entre le dispositif éloigné et la passerelle (dont l'adresse est disponible dans le public). Ensuite, un décryptage peut se produire dans la passerelle, après quoi les paquets décryptés peuvent être acheminés au dispositif récepteur dans le réseau privé. Cependant, cette solution souffre du fait que les opérateurs de la passerelle auront accès aux informations décryptées destinées au dispositif récepteur. En d'autres termes, cette solution peut être utilisée conjointement avec une passerelle NAT, mais ce dispositif n'est pas un dispositif client ; un dispositif fournisseur de services et, en tant que tel, il n'est typiquement pas sûr ou souhaitable (du point de vue du client) de lui permettre d'accéder à des paquets décryptés.

En conséquence, il existe un besoin d'un système et d'un procédé pour établir une connexion sécurisée gérable entre un dispositif de réseau privé et un deuxième dispositif, même via un WAN tel que l'Internet.

<Desc/Clms Page number 9>

Résumé de l'invention
Une forme de réalisation de la présente invention concerne un procédé pour mettre en #uvre des communications de réseau sécurisées entre un premier dispositif et un deuxième dispositif, où au moins l'un des dispositifs communique avec un réseau public via un ordinateur séparé. Le procédé comprend la réception d'une demande d'une première connexion sécurisée en provenance du premier dispositif, le masquage d'une adresse du premier dispositif par rapport au deuxième dispositif et le lancement d'une deuxième connexion sécurisée entre l'ordinateur séparé et le deuxième dispositif. Selon ce procédé, la première et la deuxième connexion sécurisées permettent des communications de réseau sécurisées entre le premier et le deuxième dispositif.

Une autre forme de réalisation de la présente invention concerne un dispositif de liaison virtuel pour mettre en #uvre une connexion de réseau sécurisée entre un premier et un deuxième dispositif, où au moins l'un des dispositifs est un dispositif de réseau privé communiquant avec un réseau public via le dispositif de liaison virtuel. Dans cette forme de réalisation, le dispositif de liaison virtuel comprend des moyens pour recevoir une demande pour une première connexion du premier dispositif, des moyens pour demander une deuxième connexion avec le deuxième dispositif, des moyens pour acheminer des paramètres de cryptage entre les deux dispositifs afin d'établir ainsi la première et la deuxième connexions et des moyens pour établir la connexion sécurisée basée sur la première et la deuxième connexion.

<Desc/Clms Page number 10>

Une autre forme de réalisation de l'invention concerne un article de fabrication comprenant un support lisible en ordinateur dans lequel est stocké un programme d'ordinateur réalisant un procédé pour mettre en #uvre une connexion sécurisée entre deux dispositifs. Dans cette forme de réalisation, le programme d'ordinateur comprend un premier segment de code pour établir une adresse de dispositif associée à l'article de fabrication, un deuxième segment de code pour établir une première liaison entre un premier dispositif et l'adresse de dispositif, un troisième segment de code pour établir une deuxième liaison entre un deuxième dispositif et l'adresse de dispositif, un quatrième segment de code pour échanger des paramètres de cryptage associées à chacun des premier et deuxième dispositif via la première et la deuxième liaison, et un cinquième segment de code pour établir la connexion sécurisée basée sur les paramètres de cryptage.

Une autre forme de réalisation de l'invention vise un procédé de transmission de données. Ce procédé comprend la négociation d'une première association de sécurité entre un premier dispositif et un deuxième dispositif, la négociation d'une deuxième association de sécurité entre un deuxième dispositif et un troisième dispositif qui est indépendante de la première association de sécurité et la transmission de données inaccessible audit deuxième dispositif entre le premier et le troisième dispositif, via le deuxième dispositif.

Les caractéristiques et avantages de l'invention apparaîtront dans les dessins et la description qui suivent.

<Desc/Clms Page number 11>

Brève description des dessins
La présente invention est décrite en se référant aux dessins ci-annexés. Sur les dessins, des notations de référence similaires indiquent des éléments identiques ou à fonctions similaires. En outre, le ou les chiffres les plus à gauche d'une notation de référence identifie le dessin où la notation de référence apparaît pour la première fois.

La Fig. 1A montre un environnement de réseau de la technique antérieure.

La Fig. 1B montre un environnement de réseau dans lequel une forme de réalisation de la présente invention pourrait opérer, notamment un ordinateur passerelle opérant sur le bord d'un réseau privé et communiquant avec un autre dispositif via un WAN public.

La Fig. 2 présente une méthodologie pour négocier une paire d'associations de sécurité (SA) selon une forme de réalisation de l'invention.

La Fig. 3 décrit une forme de réalisation de l'invention dans laquelle divers types de trafic IPsec sont relayés via un ordinateur passerelle dans les deux sens entre une paire de dispositifs.

Les Fig. 4A-4D décrivent des structures d'exemples de paquets IPsec qui peuvent être transportés selon diverses formes de réalisation de l'invention.

Les Fig. 5A-5C montrent diverses vues simplifiées de structures de paquets d'en-tête IP pour des parties de tête tunnel telles que celles illustrées sur les Fig. 4A-4D.

Les Fig. 6A-6D décrivent des exemples de structures de certificats pour chaque type de

<Desc/Clms Page number 12>

dispositif lorsque des certificats sont utilisés dans le procédé SA.

La Fig. 7 montre des exemples d'étapes de procédé effectuées par un ordinateur passerelle au cours d'une première phase de l'établissement d'une SA.

La Fig. 8 présente des exemples d'étapes de traitement effectuées par un ordinateur passerelle au cours d'une deuxième phase d'établissement d'une SA.

Description détaillée
Bien que la présente invention soit décrite cidessus en se référant à divers exemples de formes de réalisation, l'invention n'est pas limitée uniquement aux formes de réalisation qui sont décrites. D'autres formes de réalisation peuvent être mises en #uvre par les hommes de l'art sans sortir de l'esprit et du cadre de l'invention.

Sous ce rapport, bien que l'IPsec soit utilisé dans la présente demande pour désigner un exemple de forme de réalisation de l'invention, il est bien entendu que la présente invention peut être utilisée dans le contexte d'autres protocoles classiques de sécurité de réseau, tels que le protocole de tunnelage en couche 2 (L2TP) et le protocole de tunnelage point à point (PPTP), comme cela sera manifeste. De mnière similaire, il existe d'autres protocoles/méthodologies, en dehors de l'IKE et du cryptage en codes publics, qui sont utiles dans la mise en #uvre de protocoles de sécurité de réseau et la présente invention peut être mise en #uvre dans ces environnements également.

En outre, il est à noter que la terminologie et les définitions associées utilisées dans la présente demande font l'objet d'un certain niveau de désaccord dans la technique, comme cela est connu. Par exemple,

<Desc/Clms Page number 13>

certains hommes de l'art décriront l'IKE comme une option de l'ISAKMP, tandis que d'autres décriront l'IKE comme la combinaison de l'ISAKMP avec certains autres protocoles. Cette terminologie et ces définitions sont utilisées ici de manière singulière et consistante uniquement à des fins de clarté ; conséquence, il est bien entendu que cet usage est destiné seulement à expliquer et non pas à limiter la présente invention.

De la même manière, les termes tels que "cryptage", "paramètres de cryptage" ou tout autre terme de la technique, sauf spécification contraire ou limitation dans la présente demande, ne sont pas censés être redéfinis pour avoir une signification particulière et on leur donnera leurs interprétations raisonnables les plus larges compatibles avec une compréhension classique dans la technique.

La présente invention, dans un exemple de réalisation, opère en modifiant la fonctionnalité d'une passerelle classique de traduction d'adresses du réseau (NAT) sur le bord d'un réseau privé et communiquant avec un autre dispositif via un WAN public, tel que l'Internet. Cette configuration est illustrée sur les deux Fig. 1A et 1B, où le dispositif 140 opère sur un réseau privé 130 situé derrière la passerelle ou un autre appareil de réseau spécialisé 110, et communique via le WAN 120 (tel que l'Internet) via le dispositif 100. Il est à noter que le dispositif 100 pourrait être un seul dispositif sur le WAN 120 ou pourrait opérer sur son propre réseau privé ou selon une autre configuration de réseau classique, comme cela sera manifeste. Il est également à noter que, du fait de son emplacement sur un réseau privé 130, l'adresse IP du

<Desc/Clms Page number 14>

dispositif 140 ne sera typiquement pas disponible pour le dispositif 100.

Des variantes de cette passerelle 110 selon une forme de réalisation sont mises en #uvre dans l'établissement d'une association de sécurité (SA) pour une session IPsec entre les dispositifs 100 et 140, tout comme dans un mécanisme d'acheminement pour que les paquets soient échangés selon ces paramètres établis.

Selon une forme de réalisation de la présente invention, une première SA est établie entre le dispositif 100 et la passerelle 110. Une deuxième SA est établie entre la passerelle 110 et le dispositif 140. De cette manière la passerelle 110 joue le rôle d'un dispositif de liaison virtuel pour les deux dispositifs 100 et 140 et permet au dispositif 100 d'établir une liaison avec la passerelle 110 tout en pensant que la liaison est réellement établie avec le dispositif 140.

Il est bien entendu que la passerelle 110 n'établit pas seulement une liaison avec le dispositif 100, mais qu'elle décrypte également les informations qu'elle reçoit via celle-ci et recrypte les informations pour une transmission via une liaison séparée avec le dispositif 140. Cette solution souffrirait encore du problème mentionné ci-dessus qu'un opérateur de la passerelle 110 aurait accès aux informations contenues dans la transmission au cours d'un intervalle compris entre le décryptage et le recryptage. En lieu et place, des paramètres de cryptage réels des dispositifs 100 et 140 sont utilisés l'un par l'autre dans la négociation d'une connexion

<Desc/Clms Page number 15>

sécurisée (par exemple un tunnel) entre eux ; cette négociation a lieu via la passerelle 110.

En d'autres termes, dans des connexions sécurisées classiques, les dispositifs 110 et 140 seraient tous deux des points terminaux SA et des points terminaux tunnel, comme montré sur la Fig. 1A. Par contre, selon cette forme de réalisation de la présente invention, les dispositifs 100 et 140 restent finalement des points terminaux tunnel, mais tous les dispositifs 110,110 et 140 devinent des points terminaux SA pour deux SA séparées, comme montré sur la Fig. 1B.

Par exemple, comme cela sera discuté, la passerelle 110 peut acheminer les paramètres de cryptage du dispositif 100 au dispositif 140 et vice versa en utilisant une fonctionnalité similaire à la fonctionnalité NAT classique. Comme autre exemple mentionné ci-dessous, la passerelle 110 peut modifier des certificats numériques des dispositifs 100 et 140 d'une manière que la SA soit imposée par la passerelle 110, même si les paramètres de cryptage réels des dispositifs sont encore utilisés.

En outre, une fois que la passerelle 110 a assumé ce rôle de négociation d'une SA avec un dispositif de liaison éloigné, elle peut également intercepter et acheminer des paquets plus aisément et plus efficacement à des dispositifs du réseau privé 130. Par exemple, le dispositif 100 peut communiquer avec plusieurs dispositifs sur le réseau privé 130 après établissement de seulement une SA avec la passerelle 110. La passerelle 110 peut permuter des en-têtes et éventuellement modifier la signature de chaque paquet sur le champ, comme cela discuté en se référant à la

<Desc/Clms Page number 16>

Fig. 5. En outre, la passerelle 110 peut médier une négociation directe de SA entre toust les dispositifs terminaux communiquant via celle-ci, commandant de la sorte toutes les communications sécurisées entre les dispositifs terminaux en n'autorisant que des tunnels sécurisés (relayés) comme discuté ici.

La Fig. 2 présente une méthodologie pour négocier une paire de SA selon une forme de réalisation de l'invention. Sur la Fig. 2, le dispositif 100 demande à initier une SA avec le dispositif 140. Cependant, le dispositif 100 n'a pas accès à une adresse IP du dispositif 140. Comme discuté ci-dessus, une SA décrit des opérations qui devront être appliquées aux paquets de données futurs, notamment une méthode d'authentification, une méthode de cryptage (et un algorithme associé) des codes d'authentification/cryptage et divers autres paramètres (tels que l'index de paramètres de sécurité (SPI), une durée d'utilisation efficace de ou des codes, etc.) L'IKE permet à deux dispositifs de négocier et de se mettre d'accord sur ces opérations, notamment l'établissement des codes.

Comme discuté ci-dessus, il y a typiquement deux phases de négociation d'une SA en utilisant l'IKE.

Ainsi, sur la Fig. 2, le dispositif 100 initie une session de phase 1 (PH1) en envoyant un message 210 à la passerelle 110 à une adresse IP Gl de la passerelle 110 qui peut être rendue publique via le WAN 120.

Dans une forme de réalisation de l'invention, le dispositif 100 peut être préétabli de sorte qu'il pense que l'adresse Gl est une adresse pour le dispositif 140. Dans ce scénario, la passerelle 110 peut, dès la réception de la transmission 210, savoir avec quel

<Desc/Clms Page number 17>

dispositif elle établira une SA secondaire, SA2, sans devoir inspecter les détails de la transmission 210 de la SA. Cette mise en #uvre peut utiliser des adresses "de rebouclage" sur la passerelle 110, une pour chaque homologue possible du réseau privé 103. En d'autres termes, il y aura une adresse différente Gl associée à chacun des dispositifs du réseau privé.

Une autre mise en #uvre utilise une seule adresse IP Gl pour tous les flux de IPsec du côté WAN. Dans cette solution, la passerelle 110 doit examiner la transmission 210 pour déterminer quel dispositif du réseau privé sera le point terminal tunnel pour des communications avec le dispositif 100. Cette mise en #uvre a cet avantage qu'un dispositif 100 peut communiquer avec une pluralité de dispositifs (points terminaux tunnel) sur le réseau privé 130, ce qui est nécessaire en soi uniquement pour établir une SA (avec la passerelle 110).

Dans cette dernière mise en #uvre, il existe un besoin de maintenir un nom et une identité du dispositif 100, localement sur la passerelle 110 ou dans un système/serveur de nom de domaine (DNS). Ces informations peuvent également être utilisées pour identifier le dispositif 140 comme dispositif de point terminal tunnel recherché, comme cela sera discuté en se référant à la Fig. 5.

En tout cas, le message 210 de phase 1 est envoyé du dispositif 100 à la passerelle 110 à l'adresse Gl.

Ce message, comme discuté ci-dessus, est généralement destiné à protéger encore le trafic de négociation au moyen, par exemple, du mode principal. Comme cela est connu, le mode principal offre une protection pour l'identité des dispositifs impliqués. Il est

<Desc/Clms Page number 18>

typiquement divisé en trois ensembles de messages, chaque ensemble contenant deux messages. Les deux premiers messages sont utilisés pour négocier une police de sécurité pour l'échange, les deux messages suivants sont utilisés pour l'échange du matériau de cryptage Diffie-Hellman et les deux derniers messages sont utilisés pour l'authentification des homologues, notamment avec des signatures numériques et des certificats numériques facultatifs.

Il est à noter que le message SA2 peut commencer en utilisant un message similaire 220 lors de la réception par la passerelle 110 du premier message SA1.

Dans les divers scénarios discutés ci-dessus, dans les cas où la passerelle 110 ne connaît pas l'identité du dispositif de destination 140 par l'un des procédés définis ci-dessus, elle attendra un message SA du dispositif 100 contenant une charge d'identification.

Dans ce cas, la passerelle 110 commencera par une négociation en phase 1 avec ce dispositif 100 jusqu'à ce que ce message soit reçu.

La Fig. 2 décrit uniquement le cas où l'identité du dispositif 140 est incluse dans le premier message 210 ou est déjà connu de la passerelle 110. Une limitation lorsque l'identité de destination n'est pas connue est que la passerelle 110 ne doit pas commencer à négocier des paramètres qui pourraient se révéler inappropriés pour le dispositif 140; une solution dans ce cas est de définir un ensemble commun de règles qui seront acceptées par tous les dispositifs du réseau privé 130.

En supposant que la passerelle 110 connaisse l'identité du dispositif 140, la passerelle 110 peut démarrer un message secondaire SA 220 de phase 1 pour

<Desc/Clms Page number 19>

la SA2 en utilisant une autre adresse IP G2 pour la passerelle 110, qui appartient au réseau privé 130 et auquel le dispositif 140 sera à même de répondre. Le dispositif 140 est à présent le répondeur de la SA et répondra à la passerelle 110 en utilisant un message 230 du type PH1BA. En d'autres termes, le dispositif 140 recevra des paramètres associés au dispositif 100, mais ayant l'adresse G2, et répondra avec ses propres paramètres à cette adresse.

Ensuite, la passerelle 110 répond au premier message SA 210 et fournit un message de réponse PH1GA similaire au dispositif 100. En d'autres termes, on négocie entre la passerelle 110 et le dispositif 100 les mêmes paramètres qu'entre la passerelle 110 et le dispositif 140. Les deux SA sont donc indépendants, mais négocieront les mêmes règles et paramètres en raison de l'intercalage des messages SA.

A ce stade, la passerelle 110 fournit ses propres paramètres d'authentification, tels que son propre code public d'authentification, mais utilise l'identité du dispositif 140. Si ce contrôle est effectué via des certificats, les certificats seront définis selon la Fig. 6, comme cela sera discuté. Des codes partagés (c'est-à-dire les codes, sur lesquells il y a un accord préalable, conçus pour être maintenus à l'état confidentiel) peuvent également être utilisés à ce stade, mais n'offrent pas un niveau de sécurité aussi élevé que le cryptage de codes publics.

Il est à noter que les mécanismes des SA entre le dispositif 100 et la passerelle 110, d'un côté, et le dispositif 140 et la passerelle 110, d'un autre côté, répondent pleinement aux règles et procédés de protocoles IKE, si bien qu'aucun changement n'est

<Desc/Clms Page number 20>

nécessaire sur les dispositifs 100 ou 140, qui sont donc transparents dans cette mise en #uvre.

Une fois que la phase 1 est atteinte, un canal authentifié complètement sécurisé avec un cryptage éventuel est établi pour passer à la phase 2 de la SA.

La phase 2 permet la définition de paramètres pour le protocole IPsec lui-même et fait généralement usage du mode rapide discuté ci-dessus. Un échange de codes Diffie-Hellman peut donc être réalisé pour obtenir la confidentialité de l'expédition.

Comme mentionné ci-dessus, la méthodologie Diffie-Hellman permet au dispositif 100 d'aménager un code secret symétrique (le même code est utilisé pour le cryptage et le décryptage) grâce à son code local privé, à un code Diffie-Hellman (DH) connu et au code public du dispositif 140 qui peut être transmis par le dispositif 140 au dispositif 100 via la passerelle 110 ou est obtenu à partir d'un certificat comme décrit sur la Fig. 6. De la même manière, le dispositif 140 aménage le même code secret symétrique grâce à son code local privé, au code DH et au code public du dispositif 100. Aussi longtemps que les SA entre le dispositif 100 et la passerelle 110 et entre la passerelle 110 et le dispositif 140 sont valables, le même code secret est valable. En conséquence, les mêmes paramètres de durée d'utilisation de codes seront typiquement négociés dans les deux sens.

L'un des dispositifs 100 ou 140 peut lancer l'échange en mode rapide. Sur la Fig. 2, le dispositif 140 est l'initiateur de la deuxième phase démarrant par le message PH2B1 250. La passerelle 110 réaménage un message similaire PH2G1 260, où le code (public)

<Desc/Clms Page number 21>

d'authentification appartient à la passerelle 110 et le message est envoyé au dispositif 100.

Le dispositif 100 répond avec ses propres paramètres dans le message PH2A1 270 à la passerelle 110 et la passerelle 110 achemine le message, comprenant les mêmes valeurs paramétriques, à l'exception du code d'authentification du dispositif 100 qui est échangé avec le code de la passerelle 110, au dispositif 140 via le message PH2GA 280. Le code d'authentification pour la passerelle 110 délivré aux deux dispositifs 100 et 140 est principalement utilisé lorsque l'en-tête AH est utilisée dans un flux IPsec pour permettre à la passerelle 110 de modifier l'entête IP et réaménager la signature des paquets, comme décrit plus en détail sur les Fig. 3 et 4.

Un dernier message qui peut être considéré comme un accusé de réception final est également renvoyé; il n'est pas illustré sur la Fig. 2. Ce message termine la ou les SA pour le trafic IPsec entre les dispositifs 100 et 140. Comme les SA sont typiquement asymétriques, il peut être nécessaire de répéter le processus décrit ci-dessus dans le sens inverse. Cependant, il peut être nécessaire d'effectuer seulement une négociation de phase 2, comme cela est connu. Une fois que toutes les SA sont actives, le trafic IPsec peut démarrer dans les deux sens. Un tunnel a donc été établi pour de futurs flux de données, ayant des points terminaux des dispositifs 100 et 140, même si les points terminaux des SA comprenait la passerelle 110.

La Fig. 3 décrit le trafic IPsec dans les deux sens entre les dispositifs 100 et 140 via la passerelle 110. Comme on vient de le décrire, la passerelle 110 agit essentiellement comme un relais pour le trafic

<Desc/Clms Page number 22>

envoyé entre les dispositifs 100 et 140. Cette fonction de relais peut se présenter de diverses manières en fonction, par exemple, des termes des SA précédemment négociés. Par exemple, le ou les procédés de relais effectués dans la passerelle 110 peuvent dépendre des en-têtes de tunnelage et de protocoles IPsec utilisés selon les SA négociées.

Deux exemples de scénarios sont représentés sur la Fig. 3 : un premier scénario où seule un en-tête ESP est utilisée (c'est-à-dire, comme expliqué ci-dessus, qu'un cryptage est impliqué, mais qu'une authentification totale des paquets n'est pas nécessairement fournie) et un second scénario où à la fois AH et ESP sont utilisés (c'est-à-dire lorsqu'une première en-tête IPsec est un en-tête AH et qu'une seconde en-tête est un en-tête ESP). Comme déjà noté, AH peut également être utilisé seul sans cryptage; cependant, comme son comportement est similaire au cas le plus complexe où la fois AH et SP sont utilisés, il ne sera pas discuté en détail ici.

Sur la Fig. 3, un premier paquet IPsec est envoyé par le dispositif 100 à la passerelle 110 à l'étape 310. Comme décrit déjà, le dispositif 100 pense qu'il envoie un paquet au dispositif 140, mais l'adresse de destination dans un en-tête IP du paquet est Gl.

Lorsque la passerelle 110 reconnaît un paquet ayant Gl comme adresse de destination, elle contrôle tout d'abord une zone de protocole ("PROT") décrite sur la Fig. 5 afin de savoir quel procédé utiliser. Le PROT indiquera s'il faut utiliser un flux ESP de l'IPsec ou un flux AH (+ESP ou non) de l'IPsec. A l'étape 310, le protocole est ESP et, par suite, la passerelle 110 doit seulement remplacer les zones d'adresse de source et de

<Desc/Clms Page number 23>

destination avant d'acheminer la trame au dispositif 140 à l'étape 315. Ce procédé est détaillé sur la Fig. 5.

Un procédé similaire est utilisé lorsqu'un paquet ESP de lIPsec est envoyé par le dispositif 140 au dispositif 100 à l'étape 320, ce qui nécessite un remplacement d'en-tête dans la passerelle 110 et un acheminement ensuite du paquet modifie au dispositif 100 à l'étape 325.

Lorsque le type de protocole est identifié comme AH dans un premier en-tête de protocole IPsec, le processus est plus complexe. Ce scénario est décrit en commençant à l'étape 350 avec un paquet ayant un entête AH IPsec avec une adresse de destination IPG1.

Lorsque la passerelle 110 décode un protocole AH au moyen du PROT, il se produit une authentification du paquet en utilisant sa signature numérique. Cela est décrit plus en détail sur la Fig. 4 conjointement avec diverses autres structures de paquets.

Une fois authentifié, le processus de relais AH dans la passerelle 110 procède au remplacement de l'entête (comme dans le cas précédent), suivi de la régénération de la signature du paquet en utilisant le code privé d'authentification de la passerelle 110. La passerelle 110 envoie alors le paquet au dispositif 140 à l'étape 355. Le dispositif 140 peut vérifier la signature du paquet en utilisant le code public associé à l'adresse G2 et qui est certifié dans un certificat G2 ou envoyé dans la SA comme étant le code public d'authentification du dispositif 100.

Du dispositif 140 au dispositif 100, il se produit un processus similaire commençant par la transmission d'un paquet AH IPsec à l'étape 360 avec

<Desc/Clms Page number 24>

une adresse de destination G2. La passerelle 110 effectue les trois étapes d'authentification du paquet, de remplacement des zones d'adresse de l'en-tête et de remodelage de la signature du paquet. Elle envoie ensuite le paquet AH IPsec modifié au dispositif 100 à l'étape 365.

Dans l'un des procédés décrits ci-dessus, le cryptage peut être effectué dans le dispositif 100 ou le dispositif 140 et le décryptage dans le dispositif 140 ou le dispositif 100, respectivement. Les deux dispositifs utilisent le même code secret symétrique qui peut être basé sur divers algorithmes de cryptage bien connus aménagés en utilisant une valeur de code public Diffie-Hellman et l'ensemble de codes de cryptage privés/publics associés aux dispositifs 100 et 140. La passerelle 110 ne partage pas ce code secret de cryptage, car les codes privés de cryptage des dispositifs 100 et 140 ne sont jamais divulgués à la passerelle 110.

Les Fig. 4A-4D décrivent les structures de paquets IPsec pris à titre d'exemple, qui peuvent être transportés selon les diverses formes de réalisation.

Sur la Fig. 4A, le paquet 410 représente un paquet IPsec utilisant un mode tunnel IPsec avec un entête ESP 416. La charge interne 412 et l'en-tête IP 414 sont cryptés, tandis que le paquet entier, à l'exception de l'en-tête tunnel 418, est authentifié (c'est-à-dire intégré à la signature du paquet). En conséquence, un changement de l'en-tête tunnel 418 peut être effectué sans impact sur l'authentification du paquet.

Sur la Fig. 4B, le paquet 420 représente un paquet IPsec en utilisant le mode transport IPsec avec

<Desc/Clms Page number 25>

un en-tête ESP 428 et un tunnelage d'encapsulation de routage général (GRE). La charge interne 422 et l'entête IP 424 ainsi que la partie GRE 426 sont cryptés, tandis que le paquet entier, à l'exception de l'en-tête tunnel 429, est intégré à la signature du paquet (c'est-à-dire authentifiée). En conséquence, un changement de l'en-tête tunnel peut être effectué sans impact sur l'authentification du paquet. Ce cas utilise le même procédé à en-tête par remplacement d'un paquet 410 illustré sur la Fig. 4A.

Sur la Fig. 4C, le paquet 430 représente un paquet IPsec en utilisant un mode tunnel IPsec avec un en-tête AH 436. Aucune zone n'est cryptée, tandis que le paquet entier, y compris l'en-tête tunnel 438, est intégré à la signature du paquet. En conséquence, un changement de l'en-tête tunnel 438 ne peut être effectué sans qu'il y a ait un impact sur l'authentification du paquet. Le procédé dans la passerelle 110 comprend donc les trois étapes décrites ci-dessus pour authentifier le paquet, remplacer les zones d'adresse d'en-tête et réaménager la signature du paquet (c'est-à-dire la réauthentifier).

Sur la Fig. 4D, le paquet 440 représente un paquet IPsec utilisant un mode tunnel IPsec avec des en-tètes AH et ESP 448 et 446, respectivement. La charge interne 442 et l'en-tête IP 44 sont cryptés, tandis que le paquet entier, y compris l'en-tête tunnel 449, est intégré à la signature du paquet. En conséquence, comme sur la Fig. 4C, un changement de l'en-tête tunnel 449 ne peut être effectué sans un impact sur l'authentification du paquet et le procédé a trois étapes d'authentification du paquet, de remplacement des zones d'adresse d'en-tête et de

<Desc/Clms Page number 26>

réaménagement de la signature du paquet doivent à nouveau être réalisées dans la passerelle 110.

La Fig. 5 montre diverses vues simplifiées de structures de paquets d'en-tête IP pour des parties d'en-tête tunnel, telles que les parties 418,429, 438 et 449 illustrées sur les Fig. 4A-AD.

Comme montré sur la Fig. 5A, l'en-tête tunnel est un en-tête IP qui contient des zones différentes comme montré dans l'en-tête IP générale 510. Les zones comprennent des zones de terminaison/pied de page d'entête IP 512 ainsi qu'une zone d'adresse de source SA (514), une zone d'adresse de destination DA (516) et une zone de protocole PROT (518).

La Fig. 5B montre un premier procédé de remplacement d'en-tête lorsqu'un paquet est envoyé du dispositif 100 au dispositif 140 via la passerelle 110.

Spécifiquement, le paquet 520 montre une adresse de source A dans la zone d'adresse de source 542a, indiquant l'origine dans le dispositif 100, et une adresse de destination Gl dans la zone d'adresse de source 526a, indiquant une destination de la passerelle 110. Comme le paquet 520 est relayé via la passerelle 110, la zone d'adresse de source 524b est commutée pour contenir une nouvelle adresse de source de G2, tandis que la zone de l'adresse de destination 526b est commutée pour contenir une adresse de destination B.

De la même manière, la Fig. 5C montre un deuxième procédé de remplacement d'en-tête lorsqu'un paquet est envoyé du dispositif 140 au dispositif 100 via la passerelle 110. Ici, le paquet 530 montre une adresse de source B dans la zone d'adresse de source 544a, indiquant l'origine dans le dispositif 140, et une adresse de destination G2 dans la zone d'adresse de

<Desc/Clms Page number 27>

source 546a, indiquant une destination de la passerelle 110. Comme le paquet 530 est relayé via la passerelle 110, la zone d'adresse de source 544b est commutée pour contenir une nouvelle adresse de source de G1, tandis que la zone d'adresse de destination 546b est commutée pour contenir une adresse de destination B.

S'il y a projection un à un entre l'adresse de dispositif A et Gl, d'une part, et l'adresse de dispositif B et G2, d'autre part, le procédé est aisément mis en #uvre. Cependant, il est également possible de partager une seule adresse Gl entre divers dispositifs situés sur le WAN 120 et/ou de partager une seule adresse G2 entre divers dispositifs situés sur le réseau privé 130. Dans ce cas, une table répertoire locale ou éloignée sera utilisée pour identifier, sur la base de l'adresse de source, l'homologue IPsec qui correspond à ce flux. Il peut s'agir d'une table élaborée au cours de la phase SA, d'un répertoire statique ou d'un répertoire dynamique utilisant un serveur DNS ou un certificat numérique provenant d'un serveur d'autorité de certification. Cependant, tous les procédés précités auront typiquement cette restriction que seule une destination peut être liée à une adresse de source particulière.

La Fig. 6 décrit des exemples de structures de certificats pour chaque type de dispositif lorsque des certificats sont utilisés dans le procédé SA. Les certificats 600a et 600b des dispositifs 100 et 140 des Fig. 6A et 6B peuvent être des certificats standard ou des certificats "vrais", car tous les paramètres inclus dans les zones de certificat appartiennent réellement à ces dispositifs. Un certificat 600a pour l'adresse de dispositif A comme montré sur la Fig. 6A n'est présenté

<Desc/Clms Page number 28>

qu'à un dispositif situé sur le WAN 120 et un certificat 600b pour l'adresse de dispositif B comme montré sur la Fig. 6B n'est présenté qu'à un dispositif situé sur le réseau privé 130.

Comme montré sur la Fig. 6A, une partie 610a du certificat 600a peut contenir l'identité et la signature de l'autorité de certification (CA), tandis qu'une partie 620a contient diverses informations pour le dispositif 100 ayant l'adresse A, notamment son identité sur la WAN 120, l'adresse IP, le code public de dispositif, le code public d'authentification IPsec et le code public de cryptage IPsec.

De la même manière, comme montré sur la Fig. 6B, une partie 610b du certificat 600b peut contenir l'identité et la signature CA, tandis qu'une partie 620b contient diverses informations pour le dispositif 140 ayant l'adresse B, notamment son identité sur le réseau privé 130, l'adresse IP, le code public de dispositif, le code public d'authentification IPsec et le code public de cryptage IPsec.

La Fig. 6C montre un type de certificat 600c qu'un dispositif 140 ayant l'adresse de dispositif B (un dispositif en situation similaire) peut recevoir lorsqu'il demande un certificat pour un dispositif tel que le dispositif ayant l'adresse de dispositif A (ou un dispositif en situation similaire). Un certificat tel que 600c est un "faux" certificat, car il est validé par la CA comme étant valide même s'il contient certaines zones avec des informations erronées pour opérer convenablement. En effet, si le certificat 600c est considéré comme appartenant à la passerelle 110, la passerelle 110 usurpe l'identité du dispositif 100 ayant l'adresse A comme s'il possédait l'identité du

<Desc/Clms Page number 29>

dispositif (en ce qui concerne le réseau privé 130) et le code de cryptage public.

En variante, si le certificat 600c est considéré comme appartenant au dispositif 100, il peut être considéré comme un vrai-faux certificat "hybride", car l'identité et le code de cryptage public sont corrects, mais les zones restantes (c'est-à-dire, l'adresse IP, le code public du dispositif et le code public d'authentification IPsec) sont incorrectes. Néanmoins, il est à noter que ces certificats sont des certificats valables qui peuvent être aisément élaborés par l'administrateur de sécurité du réseau.

Des commentaires similaires s'appliquent à l'inverse au certificat 600b de la Fig. 6D ; effet, il représente un type de certificat 600d qu'un dispositif 100 ayant l'adresse de dispositif A peut recevoir lorsqu'il demande un certificat pour un dispositif, tel que le dispositif 140, ayant l'adresse de dispositif B.

Il est à noter que, bien que la passerelle 110 puisse avoir différentes adresses de dispositifs G1 et G2, comme discuté, ce qui convieent dans la mesure où ces adresses appartiennent à des réseaux séparés, un code public de dispositif G2 et des codes publics d'authentification IPsec peuvent être les mêmes que les codes correspondants pour l'adresse G1.

La Fig. 7 montre des exemples d'étapes de procédé effectuées par la passerelle 110 au cours de l'établissement d'une SA. Il est à noter que, à chaque étape, le procédé peut s'arrêter s'il se produisait une erreur ou une demande erronée, qui mènerait à un rejet de la SA. Cependant, cela n'est pas illustré à chaque étape pour simplifier le procédé ; seules les étapes où

<Desc/Clms Page number 30>

il y a une forte probabilité de rejet sont illustrées en tant que telles.

A l'étape 710, la passerelle 110 attend de détecter un message SA de phase 1 provenant de l'interface du WAN 120 ou de l'interface du réseau privé 130. Il est à noter que toute nouvelle SA est considérée comme un procédé séparé si bien qu'un seul de ces procédés sera détaillé ici. Lorsqu'un message SA ayant une nouvelle adresse IP de source est décodé, une adresse de source et une adresse de destination sont déterminées à l'étape 712. Comme mentionné déjà, une adresse de source d'un initiateur de SA peut être incluse dans le message ou peut être recherchée par la passerelle 110 en utilisant une consultation DNS ou une demande de certificat par la CA appropriée.

Si l'identité est reconnue et permet d'établir une session IPsec avec un dispositif situé sur le réseau opposé, le procédé passe à l'étape 714. A l'étape 714, la destination IP du message SA est contrôlée, notamment la vérification qu'il s'agit d'une destination valable pour IPsec et que cette destination peut être atteinte et est active.

La passerelle 110 peut également valider la destination selon la source en utilisant une comparaison et une validation complètes des certificats des entités. Par exemple, si les deux entités n'appartiennent à la même société ou VPN, la SA peut être rejetée selon des règles prédéfinies. Dans le cas d'un rejet, le procédé s'arrête à l'étape 720, qui peut comprendre un message de rejet adressé à l'initiateur du message ou non, après quoi la passerelle 110 retourne à son état d'attente 710.

<Desc/Clms Page number 31>

Si l'adresse IP et l'identité de destination sont autorisées comme destination par rapport à l'adresse de source IP et à l'identité associée, le procédé à l'étape 716 démarre, comme initiateur de SA, une association de sécurité de phase 1 secondaire. Le procédé, également à l'étape 718, démarre un chronomètre et attend une réponse à ce message à l'étape 730.

A l'étape 732, si aucune réponse n'est reçue en raison d'une expiration du temps du chronomètre, d'une mauvaise réponse ou d'une réponse de rejet, la première SA est rejetée à l'étape 720. Si une réponse acceptable est reçue, la réponse est analysée et traitée à l'étape 734 selon le standard IKE (ISAKMP). Dans ce cas, une réponse affirmative est également fournie au premier dispositif initiateur de SA de l'étape 734.

La Fig. 8 décrit d'autres messages SA tels que traités par la passerelle 110. Ils comprennent d'autres messages de phase 1 ainsi que des messages SA de phase phase 2 selon ISAKMP/IKE. Comme les première et deuxième associations de sécurité répondent complètement aux recommandations standard de l'ISAKMP et de l'IKE, elles ne sont pas autrement détaillées. La Fig. 8 se réfère uniquement à des paramètres échangés qui sont différents du ou des procédés standard.

A l'étape 810, la passerelle 110 attend des messages SA supplémentaires. Lorsqu'un message SA provenant d'une session existante arrive à l'étape 812 (notamment depuis le dispositif 100 ayant l'adresse de dispositif A), la passerelle 110 analyse le contenu du message et prépare une demande similaire à l'autre dispositif de liaison SA sur l'autre réseau (tel que le

<Desc/Clms Page number 32>

dispositif 140 ayant l'adresse de dispositif B) à l'étape 814.

Ensuite, un chronomètre est lancé à l'étape 816 et la passerelle 110 commence à attendre une réponse du dispositif 140 à l'étape 820. Si aucune réponse n'est reçue avant le chronomètre n'arrive à expiration à l'étape 822, la session peut être avortée à l'étape 824. Lorsqu'une réponse est reçue à l'étape 822, le procédé passe à l'étape 826, où une réponse équivalente est élaborée et envoyée au premier initiateur de message (A dans l'exemple décrit).

Ainsi, comme on peut le voir dans la description précitée, la présente invention vise une méthodologie pour établir une connexion privée sécurisée entre des dispositifs, même lorsque l'un des dispositifs est situé sur un réseau privé de sorte que son adresse de dispositif ne soit pas disponible dans le public. Dans une forme de réalisation, la présente invention opère en formant une première connexion sécurisée entre un premier dispositif et une passerelle avec le réseau privé et ensuite en formant une deuxième connexion sécurisée entre la passerelle et le deuxième dispositif. Une fois que divers paramètres de sécurité, d'authentification et/ou de cryptage sont échangés via les deux connexions, les communications entre les deux dispositifs peuvent avoir lieu. De cette manière, ni l'un, ni l'autre dispositif de point terminal n'a besoin de connaître une adresse réelle de l'autre dispositif. En outre, une fois qu'une première connexion sécurisée est établie entre le premier dispositif et la passerelle, une pluralité de connexions sécurisées peuvent être mises en #uvre entre la passerelle et chacun d'une pluralité de dispositifs

<Desc/Clms Page number 33>

connectés au réseau privé. De cette manière, on améliore la gestion du réseau.

Bien que la présente invention ait été décrite dans divers exemples de réalisation, d'autres formes de réalisation et d'autres variantes pourraient être effectuées par un homme de l'art sans sortir du cadre de l'invention.

Claims (24)

REVENDICATIONS

1. Procédé pour mettre en #uvre des communications de réseau sécurisées entre un premier dispositif et un deuxième dispositif, l'un au moins des dispositifs communiquant avec un réseau public via un ordinateur séparé, caractérisé en ce qu'il comprend : la réception d'une demande d'une première connexion sécurisée en provenance du premier dispositif ; le masquage d'une adresse du premier dispositif par rapport au deuxième dispositif ; etle lancement d'une deuxième connexion sécurisée entre l'ordinateur séparé et le deuxième dispositif; la première et la deuxième connexion sécurisée permettant les communications de réseau sécurisées entre le permier et le deuxième dispositifs.

2. Procédé selon la revendication 1, caractérisé en ce que la première connexion sécurisée est une association de sécurité négociée en utilisant une adresse du premier dispositif et une adresse du premier dispositif de l'ordinateur séparé.

3. Procédé selon la revendication 2, caractérisé en ce que la deuxième connexion sécurisée est une association de sécurité négociée en utilisant une adresse de deuxième dispositif de l'ordinateur séparé et une adresse du deuxième dispositif.

4. Procédé selon la revendication 3, caractérisé en ce qu'il comprend en outre : le relais des communications sécurisées entre le premier et le deuxième dispositif,

<Desc/Clms Page number 35>

des communications provenant du premier et du deuxième dispositif étant reçues à l'adresse du premier et du deuxième dispositif, respectivement, de l'ordinateur séparé.

5. Procédé selon la revendication 3, caractérisé en ce qu'il comprend en outre : le maintien d'une table concernant les adresses des deux dispositifs et les adresses de dispositif de l'ordinateur séparé; et l'acheminement des communication sécurisées entre le premier et le deuxième dispositif sur la base de la table.

6. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre : la communication des adresses du premier et du deuxième dispositif entre les deux dispositifs, via la première et la deuxième connexion sécurisées; et l'acheminement des communications sécurisées en utilisant les adresses respectives des premier et deuxième dispositifs.

7. Procédé selon la revendication 1, caractérisé en ce que lesdites première et deuxième connexions sécurisées sont des associations de sécurité séparées, et en ce qu'il comprend en outre : l'acheminement de paramètres de cryptage des deux dispositifs entre les deux dispositifs pour établir les associations de sécurité.

8. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre : le remplacement d'une adresse de source et d'une adresse de destination contenues dans un paquet reçu du premier dispositif de sorte que le paquet soit acheminé au deuxième dispositif.

<Desc/Clms Page number 36>

9. Dispositif de liaison virtuel pour mettre en #uvre une connexion de réseau sécurisée entre un premier et un deuxième dispositif, l'un au moins des dispositifs étant un dispositif de réseau privé communiquant avec un réseau public via le dispositif de liaison virtuel, caractérisé en ce qu'il comprend : des moyens pour recevoir une demande pour une première connexion du premier dispositif; des moyens pour demander une deuxième connexion avec le deuxième dispositif; des moyens pour acheminer des paramètres de cryptage entre les deux dispositifs afin d'établir ainsi les première et deuxième connexions ; des moyens pour établir la connexion sécurisée sur la base des première et deuxième connexions.

10. Dispositif selon la revendication 9, caractérisé en ce qu'il comprend également : des moyens pour relayer des données entre les deux dispositifs via la connexion de réseau sécurisée.

11. Dispositif selon la revendication 10, caractérisé en ce qu'il comprend en outre : une adresse de dispositif à laquelle le premier et le deuxième dispositif envoient des communications lors de la demande et de l'établissement des première et deuxième connexions.

12. Dispositif selon la revendication 11, caractérisé en ce qu'il comprend en outre : un code public pour authentifier les paquets acheminés par le dispositif de liaison virtuel

13. Dispositif selon la revendication 9, caractérisé en ce que les première et deuxième connexions sont des associations de sécurité négociées en tant que partie d'un session IPsec.

<Desc/Clms Page number 37>

14. Article de fabrication comprenant un support lisible par un ordinateur, dans lequel est stocké un programme d'ordinateur réalisant un procédé pour mettre en #uvre une connexion sécurisée entre deux dispositifs, caractérisé en ce que le programme d'ordinateur comprend : un premier segment de code pour établir une adresse de dispositif associée à l'article de fabrication ; un deuxième segment de code pour établir une première liaison entre un premier dispositif et l'adresse de dispositif; un troisième segment de code pour établir une deuxième liaison entre un deuxième dispositif et l'adresse de dispositif; un quatrième segment de code pour échanger des paramètres de cryptage associés à chacun des premier et deuxième dispositifs via la première et la deuxième liaison ; et un cinquième segment de code pour établir la connexion sécurisée sur la base des paramètres de cryptage.

15. Article de fabrication selon la revendication 14, caractérisé en ce que l'un au moins des dispositifs est situé sur un réseau privé, et en ce que l'article de fabrication est un dispositif passerelle sur le bord du réseau privé.

16. Article de fabrication selon la revendication 14, caractérisé en ce qu'il comprend en outre: un sixième segment de code pour relayer des communications entre les deux dispositifs via la

<Desc/Clms Page number 38>

connexion sécurisée avec une liaison virtuelle ayant les deux dispositifs comme points terminaux.

17. Article de fabrication selon la revendication 14, caractérisé en ce qu'il comprend en outre : un sixième segment de code pour associer l'adresse de dispositif associée à l'article de fabrication en tant qu'adresse du deuxième dispositif.

18. Article de fabrication selon la revendication 14, caractérisé en ce que les première et deuxième liaisons ont les mêmes paramètres de cryptage.

19. Procédé de transmission de données caractérisé en ce qu'il comprend : la négociation d'une première association de sécurité entre un premier dispositif et un deuxième dispositif; la négociation d'une deuxième association de sécurité entre un deuxième dispositif et un troisième dispositif, qui est indépendante de la première association de sécurité; et la transmission de données inaccessibles audit deuxième dispositif entre le premier et le troisième dispositif, via le deuxième dispositif.

20. Procédé selon la revendication 19, caractérisé en ce qu'il comprend en outre : la construction d'un code secret de cryptage partagé uniquement par le premier et le troisième dispositif, qui permet au premier et au troisième dispositif de crypter et de décrypter les données transmises entre eux.

21. Procédé selon la revendication 20, caractérisé en ce que les données comprennent des

<Desc/Clms Page number 39>

paquets de données, et en ce qu'une première partie des paquets de données est cryptée en utilisant le code secret de cryptage, tandis qu'une deuxième partie des paquets de données est authentifiée en utilisant une signature numérique.

22. Procédé selon la revendication 21, caractérisé en ce que le deuxième dispositif redirige les paquets de données en remplaçant, dans une partie d'en-tête de chaque paquet de données, une adresse de l'un des premier et troisième dispositifs qui doit recevoir les données par sa propre adresse de dispositif.

23. Procédé selon la revendication 19, caractérisé en ce que ladite transmission comprend en outre : la réception de données du premier dispositif dans le deuxième dispositif; l'authentification des données comme ayant été transmises par le deuxième dispositif; et la transmission des données au troisième dispositif.

24. Procédé selon la revendication 23, caractérisé en ce que ladite réception de données du premier dispositif dans le deuxième dispositif comprend en outre : l'authentification des données comme ayant été transmises par le premier dispositif; et le remplacement, dans une partie d'en-tête d'un paquet contenant les données, d'une adresse du deuxième dispositif par une adresse du troisième dispositif.