Lithe [85] adopte une autre approche pour réduire la surcharge de DTLS : il repose sur 6LoWPAN pour compresser les informations de DTLS et ainsi gagner 8 octets de charge utile lors des échanges de données (une fois l’établissement de la connexion terminée). Le gain est rendu possible en tronquant respectivement les champs Epoch et Sequence Number à 8 et 16 bits (au lieu de 16 et 48 bits). Cette réduction de taille de champs limite le nombre d’échanges lors d’une connexion (jusqu’à 216). Par
ailleurs, Lithe ne supprime pas les informations redondantes entre les couches Record et Application des en-têtes DTLS, et est lié à 6LoWPAN et est, par définition, dépendant de la couche réseau.
Robust Header Compression (ROHC) est une méthode décrite dans [86]–[90] pour compresser les en-têtes, telles que IP et UDP (entre autres). Le principe est de ne pas envoyer d’en-tête s’il n’a pas changé entre deux échanges, ou juste envoyer la différence. Cela peut être utilisé pour augmenter la charge utile d’un message, ainsi qu’avec notre version optimisée de DTLS si le déploiement inclut une couche réseau.
Les performances des courbes elliptiques sur des capteurs ont été testées [30] avec une bibliothèque nommée TinyECC. Cette bibliothèque permet aux développeurs d’activer à loisir des optimisations dans des algorithmes de courbes elliptiques, et peut être utilisée pour améliorer les performances. Ces travaux montrent que les algorithmes asymétriques avec courbes elliptiques restent un ordre de grandeur plus lents que les algorithmes symétriques sur les appareils contraints, même en étant optimisés. De plus, la taille des clés utilisées dans ces travaux est obsolète selon le NIST, les temps de calcul présentés doivent être revus à la hausse. Par conséquent, les algorithmes asymétriques ne peuvent pas êtres utilisés sur des matériels contraints sans optimisation matérielle.
Une autre approche est d’exécuter les calculs d’authentification sur un autre matériel, comme pro- posé par [91]. Ces travaux s’approchent d’une architecture de type maître-esclave, dans le sens où nous pouvons considérer l’entité d’authentification comme étant séparée de l’entité serveur de ressources. L’authentification peut se faire via des algorithmes asymétriques sans pénalité sur le temps d’authen- tification. Cependant, cette approche conserve les inconvénients caractéristiques d’une communication de bout-en-bout : empreinte mémoire liée au nombre de clients, absence de cache de données et donc nombre de messages dans le réseau contraint important.
Finalement, le nombre de messages échangés durant la poignée de mains implique des performances dégradées dans les réseaux avec rapport cyclique. Dans ces réseaux la durée de poignée de mains dépasse les 30 secondes, et notre optimisation peut grandement aider à augmenter les performances.
7.8 Conclusion
Notre travail d’optimisation de DTLS permet une amélioration de la durée des poignées de mains de 19,2 %, une réduction de la mémoire utilisée (7,3 % RAM, 5 % Flash) en supprimant des messages, et enfin un gain de 8,2 % de charge utile pour les données applicatives, grâce à la suppression du vecteur d’initialisation pour les algorithmes AEAD. Ces optimisations sur le protocole de sécurité représentent une amélioration de la communication entre un client et un serveur de ressources dans une architecture de référence. L’usage d’algorithmes asymétriques n’est cependant toujours pas envisageable, seule la séparation de l’entité d’authentification sur un matériel dédié le permettrait.
Dans le chapitre suivant, nous présenterons une architecture maître-esclave. Cette architecture sera ensuite utilisée pour mettre en avant les avantages et les inconvénients d’une architecture maître- esclave par rapport à une architecture de référence.
81
Chapitre
8
Exemple d’architecture maître-esclave : CASAN
Dans les chapitres précédents, nous avons étudié des architectures de sécurité avec un serveur mandataire gérant l’entité d’authentification. Cette entité d’authentification est séparée du serveur de ressources pour réduire l’empreinte mémoire et diminuer les calculs sur les nœuds contraints. Dans ce chapitre, nous présentons l’architecture maître-esclave CASAN : son fonctionnement, l’authentifi- cation des clients, ses principes de fonctionnement, la gestion de la confiance ainsi que la protection des communications. Nous introduisons également les différents inconvénients de la protection des communications avec DTLS dans CASAN. Enfin, nous présentons notre contribution : CASAN-S, un nouveau protocole de communication intégré à l’architecture CASAN, plus efficace et léger, qui simplifie la communication entre le maître et ses esclaves. Cette optimisation est permise grâce à l’architecture maître-esclave qui ne nécessite pas une communication de bout-en-bout, et permet par conséquent d’alléger les échanges dans le réseau contraint.Ce chapitre présente l’architecture maître-esclave CASAN, son fonctionnement, l’authentification des clients, ses avantages et la protection de ses communications. De plus, nous décrivons cette architecture selon notre méthode de description des architectures de sécurité présentée au chapitre 4(page 29).
Ce chapitre présente les contributions suivantes :
1. L’intégration de la sécurité dans les échanges CASAN, menant à la création du protocole CASAN-S ;
2. La description de cette nouvelle architecture selon la méthode décrite au chapitre4 (page29).
8.1 Architectures de référence
La vision de l’Internet des Objets promue par l’IETF met en avant les protocoles 6LoWPAN et CoAP.
Les schémas 8.1illustrent cette vision, avec des cas d’usage du protocole CoAP selon une logique d’architecture de référence : dans chaque cas, la connexion est de bout-en-bout, du client au serveur de ressources. La prise en compte des contraintes dans les réseaux de capteurs est croissante. La taille minimale des messages associée aux cas d’usage est indiquée sur le schéma1. Dans chaque scénario, le capteur (sur la droite) embarque une pile IP complète (IPv6 ou IPv4 et IPv6). La taille des paquets sur le réseau est réduite avec l’aide de 6LoWPAN. Il faut une pile IP car l’adressage est commun (les deux utilisent une adresse IP pour se contacter). Ces illustrations ne présentent pas les protocoles associés (DNS, détection d’adresses dupliquées, découverte des voisins, etc.), ni les mécanismes nécessaires en
1. La taille de l’en-tête de niveau 2 n’est pas indiquée puisqu’elle dépend de la technologie utilisée. Dans chaque cas, nous comptons la taille la plus favorable, par exemple nous comptons 32 octets = 20 (IPv4, pas IPv6), 8 (UDP) et 4 (en-tête CoAP sans option ni token).
CoAP UDP IPv4/v6 Réseau L2 CoAP UDP IPv4/v6 Réseau L2
CoAP − UDP − IPv4/v6 − L2
Internet
taille entêtes
taille entêtes
52 octets
52 octets
(a) CoAP en point-à-point sur une connectivité internet IPv4/v6 Internet 6LoWPAN Proxy 6LoWPAN IPv6 Réseau L2 UDP Réseau L2
CoAP − UDP − IPv6 − L2
CoAP UDP IPv6 Réseau L2 Ethernet − 802.15.4, etc Réseau L2 CoAP − 6LoWPAN − L2 taille entêtes 6LoWPAN Réseau L2 CoAP taille entêtes 28 octets 52 octets
(b) CoAP avec un proxy 6LoWPAN
Internet Réseau L2 HTTP Proxy HTTP/CoAP TCP IPv4/v6 IPv4/v6 CoAP UDP Réseau L2 Réseau L2 IPv4/v6 UDP CoAP Ethernet − 802.15.4, etc Réseau L2 CoAP − UDP − IPv4/v6 − L2 HTTP − TCP − IPv4/v6 − L2 HTTP TCP IPv4/v6 Réseau L2 taille entêtes taille entêtes 52 octets 52 octets
(c) capteur IPv4/v6 avec un proxy HTTP
6LoWPAN Réseau L2 CoAP Ethernet − 802.15.4, etc Réseau L2 CoAP − 6LoWPAN − L2 HTTP − TCP − IPv4/v6 − L2 taille entêtes taille entêtes 6LoWPAN Proxy HTTP/CoAP HTTP TCP IPv4/v6 Réseau L2 Réseau L2 CoAP HTTP TCP Réseau L2 IPv4/v6 Internet 11 octets 52 octets
(d) capteur 6LoWPAN avec proxy HTTP
Figure 8.1 – Cas d’usage de CoAP. Le client est à gauche, le capteur est à droite. Les protocoles ainsi que la taille des messages sont indiqués.
pratique dans les déploiements (comme le contrôle d’accès). Ces usages n’ont pas engendré le succès escompté puisqu’il n’y a à ce jour ni offre commerciale ni déploiement significatif.
Nous avons montré des architectures de référence, ainsi qu’une architecture maître-esclave (MQTT- SN) mais qui ne permettait pas un déploiement d’actionneurs. Nous souhaitons désormais illustrer une architecture maître-esclave qui comble ce besoin : CASAN.