0 100 200 300 400 500 600 700 800 1 2 3 4 5 6 7 8 9 d u rée d e d éma rra g e (ms ) nombre de nœuds Démarrage à froid
CASAN-S moyenne avec le module Ethernet (a)
100 100 100 100 100 98 100 100 100
CASAN-S médiane avec le module Ethernet (b)
100 100 100 100 100 98 100 100 100
CASAN-S moyenne à 57600 bauds (c)
100 100 97 97 96 90 89 88 83
CASAN-S théorie 57600 bauds avec retransmissions (d) CASAN-S théorie avec le module Ethernet (e) A-DTLS théorie (f) A-DTLS moyenne (g)
100 95 70 53 45
42 37 35 30
Figure 9.7 – Mesure du temps de démarrage d’un réseau dans les architectures A-DTLS et CASAN-S (avec module Ethernet et liaison série).
Dans cette section, nous allons voir que le démarrage d’une architecture A-DTLS est plus rapide que CASAN-S car la durée des opérations cryptographiques dans CASAN-S retarde la stabilisation du réseau, tout en restant en dessous de 500 ms pour l’insertion d’un nœud dans l’architecture. Nous
7. Calculer le temps d’attente théorique lors de plusieurs échanges simultanés est un exercice difficile : la perte d’un message implique l’arrêt de l’échange, et les durées d’attente sont négligeables face au temps pris par les opérations cryptographiques.
9.5. Résultats : durée de démarrage du réseau 103 présentons les résultats obtenus pour le premier scénario, puis nous présentons et expliquons ces résultats. Un autre enseignement de ces mesures est que l’insertion avec A-DTLS s’effondre dès que nous dépassons 2 nœuds simultanés, ce qui a motivé notre choix de ne pas augmenter davantage le nombre de nœuds dans notre dispositif expérimental.
La figure9.7présente les courbes combinées des temps moyens de démarrage dans les architectures A-DTLS et CASAN-S. Les courbes pleines représentent les moyennes des mesures des durées de démarrage (avec module Ethernet ou liaison série pour CASAN-S). Les traits discontinus représentent les médianes et les courbes théoriques, calculées à partir des tailles des messages et de la durée théorique des échanges sur IEEE 802.15.4 (et sur liaison série). Ces courbes incluent également les pertes et temps de retransmission (voir annexe C). Le taux de démarrages réussis est indiqué sur chaque point des courbes de mesures. Nous pouvons voir une chute importante du taux de complétion de démarrages dans l’architecture A-DTLS (courbe (g), qui passe de 95 % pour 2 nœuds à 53 % pour 4 nœuds).
9.5.1 La mesure pour A-DTLS
Cette courbe n’augmente pas comme la courbe théorique : en effet, lors d’une perte de paquet non liée au réseau (problème à cause d’une mémoire tampon insuffisante, voir annexe C), le nœud attend plusieurs secondes avant d’envoyer à nouveau le message. La connexion n’est alors pas terminée à temps et n’est pas prise en compte dans la moyenne. Les messages de connexion suivants ne sont pas envoyés, le réseau est moins congestionné, et finalement les nœuds n’ayant pas perdu de paquet terminent plus rapidement leur connexion au réseau. Par conséquent, un essai avec un faible taux de réussite peut avoir un temps moyen plus faible qu’en théorie si seuls les premiers nœuds à terminer leur connexion sont pris en compte. Si les pertes surviennent au début de la connexion, l’envoi des autres messages est retardé au-delà de la durée d’un essai : c’est ce qui arrive à la courbe A-DTLS avec plus de 5 nœuds. De plus, le serveur de ressources attend 8 secondes avant de retransmettre un message en cas de non réponse, donc toute perte entraîne un échec de la connexion dans notre expérimentation. 9.5.2 Les mesures pour CASAN-S
Les temps d’insertion pour CASAN-S sont plus importants que A-DTLS, mais CASAN-S n’est pas sujet à l’effondrement constaté par A-DTLS du taux de complétion.
Nous avons mesuré les durées moyennes de démarrage de l’architecture CASAN-S avec un module Ethernet (figure 9.7, courbe a) et avec un module avec liaison série (courbe c) reliant le maître au réseau contraint. La médiane pour Ethernet est également indiquée (courbe b), ainsi que les valeurs théoriques pour la liaison série et prenant en compte les retransmissions (courbe d) et les valeurs théoriques pour Ethernet (courbe e).
Nous observons une courbe de moyenne Ethernet qui montre des temps moins bons que la courbe de moyenne avec liaison série malgré une bande passante beaucoup plus importante. Cette différence s’explique par un taux de pertes plus important avec la liaison série. Les durées de retransmission lors d’une perte sur CASAN-S sont de 150 à 450 ms, ce qui permet à CASAN-S de garder un bon taux de complétion. Cette durée avant retransmission permet de terminer le démarrage dans l’intervalle de temps imparti pour la mesure, c’est-à-dire en moins de 5 secondes (voir les paramètres d’expérimen- tation section9.4.3page101). La courbe médiane b des durées de démarrage avec le module Ethernet montre que la moitié des démarrages se terminent en un temps proche de la valeur théorique lors des essais à un et deux nœuds. Au-delà, la courbe n’augmente plus de manière linéaire, indiquant la présence de pertes suivies de retransmissions, ce qui est d’autant plus marqué lors de la comparaison avec la moyenne (courbe a) : la médiane se rapproche de la moyenne, de moins en moins de nœuds ter- minent leur démarrage sans perte. Les pertes peuvent être reportées au delà de l’intervalle de mesure ; le taux de complétion des démarrages est alors inférieur mais la moyenne est meilleure.
Nous observons également un taux de complétion bien meilleur avec le Zigduino Ethernet qu’avec le Stick Digi via la liaison série (où ce taux descend jusqu’à 83 %), ce qui s’explique par un plus faible taux de pertes (voir annexeC).
Opération Durée (ms) Écart type (ms) p-valeur
Génération de clé (maître) 0,540 0,742 4,1 ×10−11
Génération de signature (maître) 0,316 0,413 6,3 ×10−12
Génération de clé (esclave) 218 0,216 2,2 ×10−16
Authentification du maître 120 0 -
Génération de signature (esclave) 127 0,216 2,2 ×10−16
(a) Mesures des durées des fonctions cryptographiques au démarrage d’un nœud.
Génération clé (maître) 0.1% Signature (maître) 0.1% Génération clé (esclave) 46.8% Authentification (esclave) 25.8% Signature (esclave) 27.3%
(b) Proportion des durées cryptographiques au démarrage d’un nœud CASAN-S.
Figure 9.8 – Opérations cryptographiques lors d’une requête dans le réseau CASAN-S. La durée de génération de la signature sur l’esclave comprend également la génération et la mise en file d’attente
du message Slave Assoc.
9.5.3 Comparaison des architectures sur les durées d’insertion
Contrairement à l’architecture A-DTLS, la durée des échanges avec l’architecture CASAN-S ne correspond pas simplement au temps d’attente et de transfert sur le lien 802.15.4 : la différence majeure entre ces deux architectures réside dans les opérations cryptographiques effectuées. En effet, dans l’architecture maître-esclave, l’esclave a une communication sécurisée avec le maître et, lors de son démarrage, ils construisent des clés cryptographiques puis ils s’authentifient. La figure9.8amontre les durées cryptographiques, mesurées sur 100 essais et la figure9.8billustre la proportion de ces durées. Ce qui est appelé signature ici est un condensat chiffré représentant les données de la poignée de mains, nous ne parlons pas ici d’une signature réalisée avec un algorithme asymétrique. La vitesse mesurée des opérations varie davantage sur le maître que sur l’esclave (voir p-valeur plus importante sur la figure 9.8a), du fait de l’exécution des opérations sur un système généraliste avec de multiples programmes en concurrence pour l’accès au CPU. Cependant, les durées de ces opérations sont négligeables en comparaison des durées des opérations cryptographiques sur l’esclave, qui sont de plusieurs ordres de grandeur supérieures.
9.5.4 Impact de la cryptographie lors de l’insertion d’un nœud dans CASAN-S Les opérations cryptographiques sont identifiables dans les délais des messages, en analysant les temps d’attente entre les différents messages. La figure 9.9a montre les opérations mesurées sur l’es- clave, et la figure 9.9b illustre les résultats. La quasi-totalité du temps de démarrage se situe avant l’envoi du message « Slave Assoc », lorsque l’esclave doit effectuer toutes ses opérations cryptogra- phiques.
Le premier message est envoyé après un temps de démarrage logiciel de quelques millisecondes (après le démarrage matériel). Le message « Discover Verify » est reçu le temps d’un aller-retour sur le réseau IEEE 802.15.4, aucun calcul n’est effectué. De même, le message suivant est envoyé rapidement par l’esclave (moins de 2 ms) puisque la seule opération à effectuer est une copie de mémoire