• Aucun résultat trouvé

Version all´eg´ee de la Signature Algorithm Agility pour la normalisation

Dans les sections pr´ec´edentes, nous avons propos´e d’importantes modifications du protocole SEND. Ces modifications ont ´et´e jug´ees trop profondes pour ˆetre norma- lis´ees car elles n´ecessitent une r´e-´evaluation de la s´ecurit´e des CGA (lors de l’utilisa- tion des CGA multi-cl´es). De plus, certains compromis peuvent ˆetre effectu´es sur la r´etrocompatibilit´e et l’interop´erabilit´e. Ainsi, certaines conditions sont r´e´evalu´ees :

– seuls les nœuds qui ont des CGA bas´ees sur le mˆeme type de cl´e publique doivent pouvoir communiquer ensemble ;

– si, lors d’un ´echange de messages prot´eg´es par SEND, l’un des deux nœuds ne peut v´erifier la signature de son correspondant, alors le message est trait´e comme

un message ne disposant d’aucune protection (voir Section3.5) ;

– optionnellement, si deux nœuds utilisent des CGA bas´ees sur des cl´es publiques de types diff´erents et sont capable de v´erifier la signature ´emise par leur corres- pondant, ils peuvent communiquer.

Cela implique les modifications suivantes par rapport `a la solution pr´ec´edente : – les multi-cl´es CGA ne sont plus utilis´ees. L’extension de la structure de donn´ees

CGA Parameters nomm´ee Public Key extension est supprim´ee ;

– il s’ensuit que le champ position qui indiquait la position de la cl´e dans l’option Si-

gnature Universelle (Figure5.1) est supprim´e. Le champ Signature Type Identifier

est conserv´e ;

– comme la compatibilit´e entre tous les types de nœuds n’est plus primordiale, le rˆole de notaire est supprim´e ;

– l’option Supported Signature Algorithm ne permet plus une n´egociation des algo- rithmes utilis´es mais est utilis´ee `a des fins de diagnostique en cas de non commu- nication entre les nœuds.

5.5 Synth`ese du chapitre

Ce chapitre pr´esente une solution permettant la mise en œuvre du m´ecanisme de Signature Algorithm Agility au sein du protocole SEND. Offrir une telle fonctionnalit´e est souhaitable dans le but d’am´eliorer la s´ecurit´e et les performances et d’offrir une meilleur flexibilit´e du protocole. Afin de satisfaire des crit`eres d’interop´erabilit´e, nous avons d´efini de nouvelles options et de nouveaux messages pour que diff´erents nœuds SEND utilisant diff´erents couples d’algorithmes de signature et de fonctions de hachage puissent communiquer entre eux.

Une derni`ere partie de ce chapitre pr´esente une version amoindrie de la solution. Cette solution a ´et´e pr´esent´ee au groupe de travail CGA and SEND maIntenance (CSI) assurant la maintenance du protocole SEND au sein de l’IETF. D’abord accueillie avec

enthousiasme, puisque correspondant `a l’un des objectifs principaux du groupe, notre

solution n’a pas ´et´e pouss´ee vers la normalisation, faute de moyens humains. Toutefois, les diff´erents documents que nous avons soumis `a l’IETF restent valides et pourront servir de base lorsque l’attention se focalisera de nouveau sur ce groupe de travail.

6 NDprotector : impl´ementation

espace utilisateur des CGA et du

protocole SEND

Nous pr´esentons dans ce chapitre notre travail sur NDprotector, une impl´ementation des CGA et du protocole SEND. Ce travail nous permet de v´erifier la viabilit´e des ex-

tensions propos´ees dans le Chapitre5concernant le support de la Signature Algorithm

Agility. La motivation principale de notre effort est due au manque d’extensibilit´e des solutions existantes qui ne permettent pas d’int´egrer facilement nos diff´erentes propositions (par ex. le code pour la Signature Algorithm Agility).

Un des points forts de notre impl´ementation, en plus du support de la Signature Algorithm Agility, est la simplicit´e de la configuration laiss´ee `a la charge de l’utilisateur. Ainsi, pour d´emarrer la protection SEND sur un hˆote, il suffit en g´en´eral d’une seule op´eration de configuration : ajouter la ou les ancres de confiance par d´efaut.

Ce chapitre pr´esente les diff´erents aspects de notre impl´ementation. La Section6.1

explique les choix techniques que nous avons effectu´es. Puis, la Section 6.2 pr´esente

l’architecture de notre solution ainsi que le banc d’essai sur lequel nous avons effectu´e nos tests. La Section6.3´enonce les ajouts que nous avons faits `a notre impl´ementation

pour supporter la Signature Algorithm Agility all´eg´ee. Ensuite, la Section6.4 montre

des tests d’interop´erabilit´e avec plusieurs impl´ementations existantes. Pour finir, nous

indiquons dans la Section 6.5 les points `a am´eliorer pour une meilleure diffusion de

notre impl´ementation.

Cette contribution s’inscrit dans le cadre du projet ANR MobiSEND1

. Elle permet de tester la conformit´e de l’impl´ementation de r´ef´erence fournie par NTT DoCoMo aux sp´ecifications de SEND et de valider de nouveaux outils facilitant les attaques sur le protocole SEND.

6.1 Choix techniques

La raison initiale de notre projet NDprotector est de d´evelopper rapidement une

impl´ementation de SEND [AKZN05]. Celle-ci doit nous permettre de d´emontrer la

viabilit´e de notre solution de Signature Algorithm Agility.

Afin de faciliter notre travail sur l’analyse et la g´en´eration des messages SEND, nous d´ecidons d’utiliser scapy. Ce qui nous contraint `a l’utilisation du langage de pro- grammation orient´ee objet Python2, souvent utilis´e pour la r´ealisation de prototypes,

1. http://mobisend.org

6 NDprotector : impl´ementation espace utilisateur des CGA et du protocole SEND Scapy est un outil permettant la g´en´eration, modification, capture et analyse d’une grande vari´et´e de messages r´eseaux. Cet outil, ´ecrit en langage Python, est fortement param´etrable et extensible et a pour philosophie d’offrir un maximum de contrˆoles lors de l’interpr´etation et la cr´eation des messages. Il peut ´egalement ˆetre int´egr´e comme un module dans d’autres programmes. Une extension, nomm´ee scapy6, ´etend cet outil

et lui rajoute le support jusque l`a manquant du protocole IPv6. Par la suite, dans

le cadre du projet MobiSEND, Arnaud Ebalard (´egalement co-auteur de scapy6 ) a ´etendu ce dernier afin de lui ajouter le support des messages et options d´efinies dans le protocole SEND ainsi que les manipulations basiques sur les CGA (g´en´eration de la structure de donn´ees CGA Parameters, calcul de hash2, etc.). Cette nouvelle branche de projet scapy s’appelle scapy6-send.

Nous avons int´egr´e le m´ecanisme de Signature Algorithm Agility dans scapy6-send. Durant cette ´etape, la flexibilit´e de l’outil scapy nous a permis de rapidement modifier et ´etendre le format des messages et options SEND d´ej`a d´efinies.

Nous avons ´egalement construit un moteur permettant le traitement des messages NDP entrants et sortants. Pour cette pi`ece centrale de notre outil, nous avons retenu un mod`ele similaire `a celui utilis´e par l’impl´ementation de NTT DoCoMo. Les paquets en- trants correspondant `a des messages NDP sont intercept´es `a l’entr´ee de la carte r´eseau (avant d’ˆetre remont´es aux diff´erentes couches r´eseaux du syst`eme). Pour chacun de ces messages, la v´erification des options SEND est effectu´ee. Si le paquet est valide, le mes- sage est r´e-introduit dans le syst`eme pour ˆetre transf´er´e vers les couches sup´erieures. Dans le cas contraire, des politiques locales d´efinissent le traitement du paquet (d´etruit ou accept´e). Les messages du NDP ´emis sont ´egalement captur´es avant d’ˆetre ´emis par la carte r´eseau (apr`es avoir ´et´e form´es par les diff´erentes couches r´eseaux). Les options SEND y sont alors ajout´ees.

Sur la majorit´e des syst`emes d’exploitation, ces op´erations peuvent ˆetre r´ealis´ees grˆace `a des hooks (ou hame¸cons) qui permettent la recopie et le traitement des paquets en espace utilisateur. C’est ce que permet l’architecture Netgraph sous FreeBSD. C’est

´egalement le cas de la biblioth`eque libnetfilter-queue3, sous GNU/Linux, que nous

avons utilis´ee. Puisque nous avons programm´e en Python, nous avons employ´e les bindings Python de la biblioth`eque libnetfilter-queue fournis par Pierre Chifflier4. Dans

la pratique, le pare-feu netfilter se voit ajouter des r`egles qui redirigent une certaine cat´egorie de paquets (configur´ee selon le filtre) vers l’espace utilisateur. Un syst`eme de queues permet de s´eparer le traitement des messages captur´es en fonction du filtre d´eclench´e et de leur affecter des traitements diff´erents.

Nous devions ´egalement choisir comment r´ealiser les op´erations syst`emes : ajout et suppression d’adresses IPv6, ajout de filtres netfilter, etc. Puisque le langage Python est `a la base un outil pour la cr´eation de scripts syst`emes, nous avons naturellement choisi de faire appel aux outils pr´esents sur le syst`eme comme la commande ip fournie

par le paquet iproute25pour l’ajout d’adresses et la commande ip6tables pour la mise

en place des filtres d’interception.

3. http://www.netfilter.org/projects/libnetfilter_queue/index.html

4. http://software.inl.fr/trac/wiki/nfqueue-bindings

6.2 Impl´ementation de NDprotector