paquet.ajouterChargeU tile(données) ;
faireSuivrePaquetVersSSM(paquet) ;
L’algorithme 7 décrit formellement le mécanisme de redirection de port proposé.
6.3 Contraintes d’Internet
Dans cette section, nous étudions succintement les contraintes d’Internet dont peuvent être soumises les entités communicantes SEMOS. Les contraintes considérées portent essentiellement sur la traversée de NAT et le filtrage par les pare-feux.
L’échange de données entre des entités SEMOS distantes s’effectue par le biais de l’infrastruture P2P sous-jacente qui s’occupe du routage et des autres fonctionnalités y afférentes. Les données qui transitent entre deux nœuds du réseau recouvrant sont en effet transmises sur des sockets TCP/UDP qui, faut-il le rappeler, agissent dans ce contexte comme des canaux de multiplexage supportant plusieurs sessions SEMOS parallèles. Les paquets générés au niveau de la couche SEMOS sont ensuite encapsulés dans des paquets IP avant leur acheminement effectif. Ces propriétés permettent donc à SEMOS, lorsque des pare-feux l’exigent, d’utiliser exclusivement des connexions TCP/UDP dont les numéros de port sont explicitement autorisés et de s’en servir ensuite pour, éventuellement, multiplexer plusieurs sessions virtuelles. Ainsi, les pare-feux peuvent filtrer la communication au
68
6.4. ANALYSE DE SÉCURITÉniveau de la couche transport, sans cependant impacter sur l’échange effectué à travers des sessions virtuelles SEMOS.
En raison de leur architecture, les applications P2P se heurtent parfois aux dispositifs qui font office de NAT dans les réseaux, comme décrit dans l’article [112]. Ce défaut est en effet dû aux restrictions inhérentes au NAT : ce dernier n’autorise que les connexions sur les ports explicitement ouverts et n’accepte que des connexions entrantes/sortantes vers les hôtes clairement désignés dans sa configuration. Dépourvus d’adresses IP et de numéros de port, les paquets SEMOS se dérogent par conséquent aux règles établies relatives à la traversée de NAT. L’établissement, l’organisation, la gestion et la reprise des sessions sécurisées SEMOS ne sont ainsi nullement affectés par la présence ou l’absence de NAT sur le circuit de communication reliant les nœuds correspondants.
6.4 Analyse de sécurité
Un système VPN mobile permet, d’une part, d’offrir une communication sécurisée et de tenir les sessions sécurisées actives pendant le changement d’emplacement opéré par un pair ou lors d’une inaccessibilité passagère, répétée ou prolongée d’un correspondant. D’autre part, les systèmes VPN mobiles sont exemptés de renégociation de clés post-intérruption. En dépit de l’importance notable de ces propriétés dans un environnement autonome, distribué et dynamique, les VPN mobiles sont soumis à des défis sécuritaires liés à leur architecture. Dans cette section, nous analysons quelques-uns de problèmes de sécurité qui pourraient, éventuellement, être posés par les attaques par déni de service ou DoS (de l’anglais, Denial of Service) et les attaques par rejeu.
6.4.1 Protection contre les attaques par rejeu et les attaques DoS
Afin de déjouer des attaques par rejeu des paquets de données (cf. la figure 6.33), SEMOS intègre un mécanisme basé à la fois sur l’utilisation de numéro de séquence, destiné à différencier chaque paquet des autres, et l’authentification des champs permanents dont, justement, le numéro de séquence. Ainsi, lorsqu’un paquet de données déjà reçu est rejoué, il pourrait être aisément détecté, puis détruit sur le coup. Cependant, dépourvus de numéro de séquence, les paquets Hello et Re-hello ne bénéficient point de cette contre-mesure précédemment énoncée. Par conséquent, un attaquant pourrait intercepter ces paquets et les rejouer plus tard sans que la cible ne pourrait le détecter. Plus préoccupant encore, l’attaquant pourrait malicieusement et frauduleusement créer une flopée de copies de ces paquets et les envoyer en cascade ou en parallèle à la victime dans le but de la saturer de requêtes et la mettre ainsi hors-service (attaque DoS). En d’autres termes, l’attaque consiste à envoyer une première succession (en série ou en parallèle) de paquets et avant que la cible n’ait fini de les traiter, une autre suite de paquets lui est encore expédiée, et ainsi de suite.En l’absence de numéro de séquence, une solution serait de disposer d’un moyen pouvant déterminer lequel des paquets reçus a la date d’émission la plus récente. Ainsi, si le paquet nouvellement reçu a une date supérieure ou égale, au moment de sa réception, à celle du paquet déjà reçu, alors on estime qu’il est rejoué et est illico détruit. La mise en œuvre de cette technique pourrait conduire à l’utilisation du mécanisme de l’horodatage ou de nonce. Bien qu’ils peuvent contrecarrer les attaques par rejeu, les horodateurs exigent cependant l’utilisation des horloges synchronisées. La RFC 3161 [113] propose en effet la description d’un protocole d’horodatage destiné à s’exécuter sur une autorité d’horodatage centralisée. Toutefois, cette technique est inadaptée aux environnements entièrement distribués.
Lamport propose un protocole gérant le mécanisme de l’horodatage (timestamp, en englais) dans un environnement distribué et asynchrone [114]. Aussi, il faut préciser que l’algorithme de Lamport possède également des implications dans les problèmes basés sur les relations de causalité entre processus. Ceci étant, la gestion distribuée de l’horloge logique de Lamport est formellement décrite par l’algorithme 8. Il est donc évident de constater que l’ajout d’un champ HL dans les requêtes Hello et Re-Hello, doublé d’une authentification par HMAC, et l’application de cet algorithme
résoudraient les problèmes lié aux attaques par rejeu qui pourraient se solder par la mise hors-service de la cible. Enfin, comme SEMOS gère simultanément plusieurs sessions, chaque pair devrait alors maintenir une table de correspondance qui associe chaque session à une horloge logique afin de se synchroniser avec les horloges logiques de ses correspondants.
Algorithme 8 : Horloge logique de Lamport
1. chaque processus i tient à jour une horloge logique HLi;
2. lorsqu’un évèvement ek se produit, i met alors à jour HLi ← HLi+ tk;
3. lorsqu’un message est envoyé du processus i au processus j, HLi est joint à ce message ; 4. sur réception du message envoyé par i, le processus j calucle HLi← max(HLi, HLj) + 1.
Comme le montre l’article qui traite l’analyse de sécurité du protocole [115], le système HIP est vulnérable aux attaques DoS. Les auteurs suggèrent cependant une suite des mesures qui pourraient parer à l’éventualité de ces attaques.
6.4.2 Autres propriétés
Bien que l’intergiciel SEMOS offre un mécanisme robuste de sécurité sur la communication entre des pairs distants, la communication locale entre SEMOS et les processus applicatifs n’est pas sécurisée. En effet, un utilisateur malicieux pourrait écouter le trafic entre les applications locales et l’intergiciel SEMOS ou se connecter frauduleusement, via SEMOS, à un pair distant. Ce type d’intrusion pourrait créer des problèmes de sécurité. Afin de résoudre ces failles sécuritaires, d’une part, seules les applications ayant des adresses IP locales puissent se connecter à SEMOS. D’autre part, pour capturer les paquets circulant entre SEMOS et les processus applicaifs à l’aide des utilitaires comme tcpdump et/ou wireshark, seul l’utilisateur root pourrait le faire. Ainsi, l’échange de données entre SEMOS et les applications utilisateur est, dans certaines mesures, protégé.
6.5 Conclusion
À la lumière des études descriptives menées sur l’architecture SEMOS dans les précédentes sections, il en ressort que les sessions sécurisées virtuelles et mobiles proposées présentent des propriétés relativement intéressantes. Bénéficiant d’un découplage, basé sur une infrastruture DHT, entre l’espace d’adressage et l’espace de nommage qui fournit des identités virtuelles immuables, l’intergiciel SEMOS introduit un nouveau modèle VPN mobile distribué. Renforcé par les carac-téristiques héritées d’un système DHT entièrement distribué telles que la résistance aux pannes et la disponibilité, SEMOS est doté des facultés lui permettant d’évoluer sans encombre dans un environnement totalement mobile tout en offrant des communications sécurisées.
Les contraintes d’Internet, comme la traversée de NAT et le filtrage malencontreux de paquets par les pare-feux, dont souffrent beaucoup de systèmes P2P, sont à la fois résolues par le caractère virtuel des sessions logiques utilisées et les propriétés de l’infrastructure sous-jacente. En outre, l’analyse de sécurité montre que la protection contre les attaques par rejeu et les attaques DoS serait assurée.
Une politique de sécurité sur un réseau ne saurait être complète et fiable sans la définition et la mise en place d’un protocole robuste de gestion de clés cryptographiques. Afin de satisfaire cet impératif de sécurité, nous nous proposons, dans le prochain chapitre, de définir un mécanisme multi-chemin et distribué d’échange de clés basé sur l’extension du protocole Diffie-Hellman et sur une forme étendue du schéma à seuil (k, n) de Shamir.