IPsec est conçu pour protéger différentes communications (en les discriminant sur leurs adresses IP, les ports ou le protocole) avec différents secrets et algorithmes. Ce protocole est pensé pour les communications sur Internet pour protéger diverses communications entre des nœuds distants. Dans les environnements contraints, chaque serveur de ressources a généralement une seule tâche, donc la discrimination ne se passe que sur les adresses IP, ce qui est inutile dans notre cas : une seule association de sécurité est suffisante entre le client et le serveur de ressources qui n’a qu’une seule tâche. Finalement, les fonctionnalités spécifiques d’IPsec ne sont pas utiles dans les environnements contraints tels que nous les avons décrits dans ce document, son usage reste pertinent entre des routeurs, mais cela est hors du cadre de notre étude.
6.1.4 Conclusion
Kerberos a un problème de taille de messages, SSH nécessite des algorithmes asymétriques, et les fonctionnalités d’IPsec ne sont pas pertinentes dans les environnements contraints. Aucune de ces trois architectures n’est donc à recommander pour des environnements contraints.
6.2 Contraintes de déploiement
Dans cette section, nous détaillons des contraintes de déploiement (nombre de clients, fréquence des demandes, etc.) et classons les architectures selon ces contraintes.
Chaque déploiement a un objectif particulier, mais tous les déploiements partagent des paramètres communs (et potentiellement des contraintes). Parmi ces paramètres, nous retrouvons le nombre de clients, la fréquence de leurs requêtes, la granularité de l’autorisation offerte par l’architecture, etc. Dans cette section, nous ordonnons les architectures selon leur pertinence par rapport à ces paramètres. 6.2.1 Grand nombre de clients
Pour les déploiements avec un grand nombre de clients, les architectures avec un serveur mandataire (MQTT-SN et OSCAR) ont un avantage puisque le nombre de clients et le nombre de messages transmis aux serveurs de ressources ne sont pas corrélés (avec un cache par exemple). De plus, le serveur mandataire peut également effectuer l’authentification et l’autorisation, et donc les serveurs de ressources n’ont pas à stocker d’informations à propos de chaque client, réduisant leur consommation de mémoire.
6.2.2 Haute fréquence de demandes
Pour les déploiements avec une haute fréquence de requêtes (avec des données rapidement obso- lètes), disposer d’un cache n’est pas suffisant : la latence des requêtes devient une métrique importante. Les architectures les plus adaptées dans ce contexte sont celles récoltant les données dans un cache avant d’être demandées par les clients (OSCAR, MQTT-SN) : il n’y a pas d’authentification entre les clients et les serveurs de ressources (moins de messages générés, moins de contrainte sur la mé- moire des serveurs de ressources, moins de connexions à maintenir). Les architectures sans cache sont moins efficaces. Les paramètres tels que l’usage de cryptographie asymétrique et le nombre de relations entre les domaines sont à prendre en compte pour choisir une architecture. Selon ces critères, voici le classement des architectures de la plus à la moins adaptée : ACE DCAF (pas de cryptographie asymétrique), ACE OAuth (pas de cryptographie asymétrique sauf si DTLS est utilisé pour contacter SR), puis OSCORE (requiert de la cryptographie asymétrique mais seulement deux messages sont requis par requête) et finalement A-DTLS qui nécessite de la cryptographie asymétrique.
6.2.3 Déploiements sans serveur mandataire
Dans notre document, nous considérons un serveur mandataire comme non contraint, ainsi il peut être utilisé comme un cache de données.
Pour les déploiements avec des nœuds indépendants sans serveur mandataire (e.g. : une ampoule connectée), la mémoire disponible sur les serveurs de ressources est un problème. Dans ce cas, les serveurs de ressources doivent (i) mémoriser l’identité et le matériel cryptographique de chaque client, et (ii) ils doivent gérer plusieurs connexions simultanées avec des informations qui leur sont liées (par exemple le matériel cryptographique, l’état ou des temporisateurs).
OSCAR fournit une atténuation simple pour (i) et (ii) : l’architecture nécessite de stocker, sur des serveurs de ressources, une clé pour chaque type de ressources uniquement et non une pour chaque client. Chaque architecture peut supprimer l’association de sécurité après chaque requête, permettant aux serveurs de ressources de stocker peu de contextes (algorithmes et clés négociés, options, numéros de séquence et ainsi de suite), cela est la méthode la plus efficace pour atténuer (ii). Malheureusement, OSCAR nécessite une entité d’authentification pour gérer des clients et diminuer le travail à faire sur le serveur de ressources. De ce fait, la seule manière pour une architecture de se démarquer des autres est d’avoir moins de messages transmis entre les domaines (en incluant la communication avec l’entité d’authentification).
Dans les déploiements avec des serveurs de ressources indépendants (i.e. sans serveur central d’au- thentification ni d’autorisation), la communication peut être réduite simplement au protocole de com- munication sécurisé. La plupart des architectures utilisent DTLS pour sécuriser les échanges entre les domaines : OSCAR, ACE DCAF, ACE OAuth, MQTT-SN, A-OSCORE (au moins dans le pre- mier scénario) et l’architecture éponyme. A-DTLS n’utilise que les protocoles DTLS et CoAP entre deux appareils, les autres architectures échangent plus de messages car elles utilisent des appareils ou des protocoles supplémentaires. Si le critère de sélection de l’architecture est basé entièrement sur le nombre de messages échangés, alors les architectures restantes sont A-DTLS et A-IPsec. A-OSCORE peut être utilisé mais uniquement avec des clés pré-configurées.
6.2.4 Granularité d’autorisation attendue
La granularité de l’autorisation varie selon l’architecture. ACE DCAF, ACE OAuth et MQTT-SN ont une granularité d’autorisation jusqu’à la ressource. OSCAR accorde des permissions aux clients avec une granularité jusqu’au type de ressources sur tous les serveurs de ressources à la fois, mais ce système implique une clé unique partagée sur plusieurs appareils : un seul serveur de ressources avec une vulnérabilité peut affecter la sécurité de tous les serveurs de ressources. Les architectures basées sur un seul protocole (DTLS, IPsec et OSCORE) délèguent l’autorisation à l’application, la granularité peut être jusqu’à la ressource mais doit être configurée sur chaque serveur de ressources ce qui peut être contraignant pour de grands déploiements.
6.2.5 Déploiements avec actionneurs
Demander une donnée à un serveur de ressources n’est pas différent d’envoyer une commande à un actionneur pour toutes les architectures, excepté MQTT-SN qui n’utilise pas CoAP. Dans l’architec- ture MQTT-SN, les clients ne communiquent pas avec les serveurs de ressources, ils ne leur envoient aucune information directement. MQTT-SN est conçu comme un système de publication et de sous- cription, les clients demandent à recevoir des mises à jour d’un sujet (une ressource). Par conséquent, cette architecture est adaptée à la récolte de données, mais peu adaptée aux déploiements avec des actionneurs5.
5. Dans l’architecture MQTT-SN, nous pourrions faire fonctionner des actionneurs au prix d’un détournement du fonction- nement initial. Par exemple, le serveur de ressources avec des actionneurs s’inscrit à un sujet auprès du serveur mandataire, et le client s’enregistre comme diffuseur sur ce sujet. De ce fait, quand le client va publier un message, il sera retransmis au serveur de ressources, simulant une requête. Ce détournement du protocole implique plus de messages de contrôle.
6.3. Contraintes sur les nœuds 69