La Journée pour un internet plus sûr a été lancée en 1999 dans plusieurs pays européens afin de sensibiliser les utilisateurs à la sécurité sur internet. Toutefois, le thème de la sécurité est très pertinent dans presque tous les domaines de l'internet. L'Internet des objets (IoT) ne fait pas exception à la règle.
Cet article est consacré au thème de la sécurité de LoRaWAN. Une partie peut être transférée à d'autres technologies LPWAN.
Le phénomène de l'Internet des objets se caractérise par une prédominance croissante d'objets et d'instances capables de transférer automatiquement des données et ayant chacun des identifiants uniques. La densité accrue de l'infrastructure IdO est principalement due à la communication de machine à machine (M2M), c'est-à-dire les systèmes de capteurs tels qu'on les trouve dans les maisons ou les villes intelligentes, les processus d'automatisation industrielle, les dispositifs informatiques portables, dits mobiles, la communication de véhicule à véhicule, etc.
Une analyse ne doit pas considérer isolément un seul appareil sur le terrain. Au contraire, toutes les interfaces avec les passerelles, les applications et les dispositifs de stockage de données, dans lesquels de grandes quantités de données sont traitées et stockées, doivent être considérées comme systémiques.
Les défis de sécurité existent dans toutes les couches des architectures IdO. L'effort pour concilier la protection des données et les exigences des entreprises et des sociétés est considérable.
Un organisme important dans ce domaine est l'association des principaux leaders de l'industrie, l'Internet of Things Security Foundation (IoTSF). L'IoTSF est une réponse internationale, collaborative et non commerciale aux défis complexes posés par un monde en expansion et de plus en plus interconnecté. Elle atteint son objectif en coordonnant la coopération entre les entreprises et en encourageant les fabricants à envisager la sécurité des dispositifs et des systèmes à partir de la base. Les principaux représentants de l'IoTSF sont Intel, Huawei, IBM, Thales, Secure-IC, BT, Vodafone, Imagination Technologies, l'université Royal Holloway de Londres, l'université calédonienne de Glasgow, NMI et PenTest Partners.
Le défi
Une grande partie des risques est principalement due au fait que les dispositifs IdO sont toujours en veille après la mise en service. Cela est indépendant du fait qu'ils soient réellement toujours connectés au réseau ou en mode veille. Ils ne passent par un processus d'authentification dans le système qu'au début de leur cycle de vie. Cela les rend très vulnérables du point de vue de la sécurité.
Les aspects de sécurité ne sont pas toujours pris en compte lors du développement des produits. C'est un problème majeur qui devrait être traité dans la même mesure que la connectivité elle-même. Certains produits de l'IdO ont des systèmes d'exploitation embarqués dépassés. Ce n'est pas la seule raison pour laquelle l'installation de mises à jour du système ou de la sécurité sur les dispositifs IdO constitue un défi majeur. Les nœuds de réseau sont généralement installés à l'extérieur ou sur le site du client, il n'est donc pas rare d'avoir un grand nombre de nœuds de réseau dispersés qui sont très difficiles à surveiller et à gérer.
Effectuer des réglages ou des configurations - y compris des configurations de sécurité - individuellement pour chaque nœud de réseau ne constitue pas une solution technique représentative. Le déclenchement automatique de ces nœuds de réseau par le fabricant n'est pas non plus une solution particulièrement fiable. Des procédures appropriées et éprouvées doivent empêcher que les mises à jour ne deviennent elles-mêmes des failles de sécurité.
Certaines sociétés de sécurité proposent des solutions de sécurité IdO spéciales, comme le cryptage des disques durs ou la mise en œuvre de composants inviolables. Ces solutions permettent à la fois une sécurité numérique avancée et une gestion du cycle de vie via le cryptage ainsi que des restrictions d'accès aux données sensibles.
Le marché de l'IdO est largement reconnu pour l'importance des aspects de sécurité. Les avantages des nouvelles technologies ne devraient être pleinement exploités que dans des environnements sûrs.
Quelles sont les fonctions de sécurité incluses dans la norme LoRaWAN ?
La pile de protocoles LoRaWAN est illustrée à la figure 1. Il se compose d'une couche d'application, d'une couche MAC et d'une couche PHY. Les données du niveau de l'application sont transférées aux données de l'utilisateur du MAC. Le niveau MAC crée la trame MAC à partir des données de l'utilisateur MAC. Les données utilisateur MAC contiennent un en-tête de trame (avec les adresses source et destination et un compteur de trames), un port de trame et les données utilisateur de trame (avec les données d'application). Le port de trame est utilisé pour déterminer si la trame contient uniquement des commandes MAC (si elle est définie à 0) ou des données spécifiques à l'application. Enfin, la couche PHY utilise la trame MAC comme charge utile PHY, créant ainsi la trame PHY après que le préambule, l'en-tête PHY et le CRC aient été insérés.
Figure 1 : Pile de protocoles LoRaWAN
Les paramètres RF comprennent les fréquences, les niveaux de puissance, la modulation et les protocoles RF de base. Tous ces éléments sont inclus dans la couche RF ou physique de LoRaWAN.
Comme l'intégration de la sécurité est extrêmement importante pour tout réseau sans fil, le LoRaWAN utilise deux couches de sécurité, comme le montre la figure 2 : une pour la couche réseau et une pour la couche application. La sécurité de la couche réseau garantit l'authenticité du dispositif sur le réseau. La sécurité de la couche application garantit que l'opérateur de réseau n'a pas accès aux données d'application de l'utilisateur final.
Figure 2 : Les doubles niveaux de sécurité du LoRaWAN
Un dispositif terminal (nœud de réseau) doit être activé avant de pouvoir communiquer via le réseau LoRaWAN. Deux méthodes d'activation sont disponibles dans les réseaux LoRaWAN : OTAA et ABP.
Activation aérienne (OTAA)
Cette méthode OTAA est basée sur la coopération entre les messages aériens pour les demandes de participation et les acceptations de participation. Un DevEUI 64 bits, un AppEUI 64 bits et une AppKey 128 bits sont fournis pour chaque appareil mobile (nœud de réseau). Le DevEUI est un identifiant unique et global de l'appareil qui est comparable à l'adresse MAC d'un appareil TCP/IP. L'AppKey est utilisée pour crypter la demande d'adhésion. L'AppKey est utilisée lorsque le nœud du réseau envoie un message de demande de jointure, comme le montre la figure 3. Le nœud de réseau envoie un message de demande de jointure composé de son AppEUI et de son DevEUI. Il envoie également un DevNonce - une valeur unique de 2 octets générée de façon aléatoire qui est utilisée pour empêcher les attaques de rediffusion.
Figure 3 : La méthode OTAA dans LoRaWAN
Ces trois valeurs sont identifiées via l'AppKey de l'appareil avec un MIC (Message Integrity Code) de 4 octets. Le serveur n'accepte que les demandes de jointure provenant d'appareils dont les valeurs DevEUI et AppEUI sont connues et vérifie le MIC en le faisant correspondre avec l'AppKey.
Figure 4 : Les éléments d'un message LoRaWAN
Lorsque le serveur accepte la demande de participation, il répond au dispositif par un message "Join Accept". Les serveurs d'application et de réseau calculent les deux clés de 128 bits du nœud de réseau : la clé de session d'application (AppSKey) et la clé de session de réseau (NwkSKey). Elles sont calculées sur la base des valeurs envoyées par le nœud du réseau dans le message de demande de participation.
De plus, le serveur d'application génère sa propre valeur nonce : AppNonce. Il s'agit d'une autre valeur unique, générée de manière aléatoire.
La réponse d'acceptation conjointe contient l'AppNonce, un NetID et une adresse du dispositif terminal (DevAddr) ainsi que les données de configuration pour les délais RF (RxDelay) et les canaux à utiliser (CFList). Le NetID est important pour les appareils LoRaWAN de classe B. Il s'agit d'une valeur de 3 octets qui permet aux nœuds du réseau d'identifier qu'un message a été envoyé par une passerelle de réseau interne. Il doit donc avoir un identifiant unique pour le LoRaWAN correspondant. L'adresse du dispositif terminal (DevAddr) dans la réponse d'acceptation conjointe est un identifiant de 32 bits qui est unique au sein du réseau.
Il est possible de différencier les appareils terminaux qui ont déjà rejoint le réseau grâce à l'adresse de l'appareil. Cela permet au réseau et aux serveurs d'applications d'utiliser le bon cryptage et d'interpréter correctement les données.
Lorsque les données sont reçues en retour, elles sont cryptées avec l'AppKey. Le nœud de réseau utilise ensuite l'AppKey pour décrypter les données et dérive l'AppSKey et la NwkSKey du message d'acceptation conjointe en utilisant la valeur AppNonce.
Activation par personnalisation (ABP)
Cette méthode ABP diffère de la méthode OTAA, car les nœuds du réseau sont envoyés avec le DevAddr et les deux clés de session (NwkSKey et AppSKey), qui sont uniques au nœud du réseau. Comme les nœuds du réseau disposent déjà des informations et des clés nécessaires, ils peuvent commencer à communiquer avec le serveur du réseau sans avoir à échanger des messages de jointure au préalable.
Dès qu'un nœud de réseau a rejoint un LoRaWAN - soit via OTAA ou ABP - tous les messages futurs sont cryptés avec une combinaison de différentes clés (voir aussi Sécurité dans le LoRaWAN) :
- Network Session Key (NwkSKey) - un mécanisme de sécurité de la couche réseau. Cette clé est unique pour chaque appareil final et est partagée entre l'appareil final et le serveur de réseau. La clé de session réseau assure l'intégrité des messages pendant la communication et sécurise la communication entre les appareils terminaux et le serveur réseau.
- Application Session Key (AppSKey) - Cette clé est responsable du cryptage de bout en bout (de dispositif à dispositif) des données de l'utilisateur. Il s'agit également d'une clé AES 128 bits unique pour chaque appareil et partagée entre l'appareil et le serveur d'application. La clé de session d'application crypte et décrypte les messages de données d'application et sécurise les données de l'utilisateur de l'application.
Ces deux clés de session (NwkSKey et AppSKey) sont uniques pour chaque appareil et chaque session. Si l'appareil est activé dynamiquement (OTAA), ces clés sont générées à nouveau à chaque fois qu'il est activé. Si l'appareil est activé en mode statique (ABP), ces clés restent en place jusqu'à ce qu'elles soient modifiées manuellement.
Norme de cryptage avancée (AES)
Le cryptage AES avec l'échange de clés mis en œuvre dans le LoRaWAN conformément aux mesures de sécurité pour les réseaux sans fil selon la norme IEEE 802.15.4 (voir figure 5).
Figure 5 : Transfert sécurisé des données de candidature dans LoRaWAN
Le mécanisme de cryptage mis en œuvre dans la norme LoRaWAN, qui est interopérable entre les fabricants et les fournisseurs de réseau, crée ainsi la confidentialité et l'intégrité dans la transmission de données de bout en bout.
Les points forts des fonctions de sécurité de la norme LoRaWAN
La sécurité du système dans les LoRaWAN est réalisée par une combinaison de mesures techniques et opérationnelles. À ce stade, il convient de noter que le LoRaWAN a été développé à l'origine pour des dispositifs qui sont limités au matériel. En outre, la plupart des applications du réseau LoRaWAN reçoivent des données de capteurs répartis. Pour des applications typiques, le LoRaWAN est une solution simple, économique et sûre.
Les points forts des fonctions de sécurité dans le LoRaWAN consistent en quelques bonnes pratiques :
- Provisionnement OTAA : lorsque les clés et les certificats de chaque session sont transférés dynamiquement entre un appareil et le réseau et les serveurs d'applications. Lorsque les appareils rejoignent les réseaux, leurs clés de session sont périodiquement modifiées. Il est important d'éviter les risques potentiels tels que l'usurpation d'identité, la dissimulation, etc.
- Les dispositifs activés dynamiquement (OTAA) utilisent la clé d'application (AppKey) pendant le processus d'activation pour obtenir les deux clés de session. Dans le réseau, leur valeur est fixée à l'AppKey par défaut, qui est ensuite utilisée pour activer tous les appareils. Il est recommandé de mettre en place une AppKey individuelle pour chaque appareil. Le facteur décisif est que, dans l'ensemble du processus de sécurité, les clés ne sont jamais envoyées par la voie hertzienne. Seules les parties manquantes d'un calcul sont échangées des deux côtés. La génération de clés par l'interception du trafic aérien est donc extrêmement complexe.
- La présence d'un élément matériel pour le stockage des justificatifs de sécurité dans l'appareil peut être bénéfique. L'extraction des clés par rétro-ingénierie ou par balayage des mémoires des appareils est donc considérablement plus difficile. En outre, l'utilisation d'un démarrage sécurisé devrait garantir l'intégrité du micrologiciel du périphérique.
- Un niveau de cryptage supplémentaire au niveau de l'application est toujours recommandé et devrait être mis en œuvre si nécessaire.
- Pour prévenir les attaques par rediffusion, il est important d'activer le balayage des compteurs de messages sur le réseau par liaison montante et descendante. La connexion au réseau sans fil laisse toujours la possibilité de capturer et de stocker des messages malveillants. Cependant, le cryptage des messages rend impossible leur lecture sans l'AppSKey. L'échange de messages au niveau du réseau n'est pas non plus possible sans la clé NwkSKey, car la vérification du MIC ne serait pas réussie dans ce cas. La retransmission des messages est possible. Ces attaques dites "replay" peuvent être détectées et bloquées par des compteurs de trames. Si un dispositif est activé, les deux compteurs de trame (FCntUp et FCntDown) sont mis à 0. Chaque fois que l'appareil transmet un message de liaison montante, le FCntUp est augmenté. Chaque fois que le serveur du réseau transmet un message en liaison descendante, le FCntDown est augmenté. Si l'appareil ou le réseau reçoit un message dont le nombre de trames est inférieur à celui du dernier enregistrement, le message est ignoré.
- Contrairement au TCP, l'acquittement des trames de données LoRaWAN est facultatif. Le récepteur accusait alors réception de cette trame avec une trame de données dont le bit ACK était réglé sur 1. Cet acquittement de trame optionnel est idéal pour le LoRaWAN car le temps de transmission des appareils est limité. Par conséquent, une certaine perte de paquets de données pourrait ne pas être pertinente. Un MIC est ajouté à chaque trame pour vérification. Il s'agit essentiellement d'une signature qui est calculée sur la trame à l'aide d'une clé de session réseau. Même si les mêmes données utilisateur sont transmises plusieurs fois, chaque trame reçoit une signature unique car le compteur de trame est incrémenté pour chaque transmission.
Les faiblesses des fonctions de sécurité de la norme LoRaWAN
Les développeurs de solutions LoRaWAN doivent être conscients que l 'utilisation de LoRaWAN ne garantit pas une protection à 100 % dans une zone de sécurité quelconque. Ce fait peut également être transféré à tous les autres systèmes de technologie sans fil. Les solutions LoRaWAN devraient plutôt être développées en tenant compte des risques possibles pour la sécurité.
Comme les solutions LoRaWAN sont utilisées dans un large éventail de systèmes - des solutions de sécurité domestique aux ressources pour les infrastructures de contrôle et de surveillance à distance - les attaques et les utilisations non autorisées sont tout à fait possibles.
Les principales faiblesses des fonctions de sécurité du LoRaWAN sont les suivantes
- Les messages cryptés ont la même longueur que la clé.
- La méthode ABP fixe les deux clés de session de manière permanente, ce qui entraîne des faiblesses.
- Le stockage des clés LoRaWAN (AppKey, NwkSKey et AppSKey) est un problème fondamental. La sécurité des réseaux doit être prise en compte à chaque étape du développement et de l'exploitation. Il existe plusieurs vulnérabilités en termes de gestion du cycle de vie des clés, de génération de clés de session, de stockage et de transport, qui nécessitent un développement et une mise en œuvre minutieux. Donner aux clients l'accès aux clés des appareils n'est pas bénéfique pour les ventes. En cas d'attaques connues sur les canaux secondaires, les clés peuvent être récupérées dans la mémoire de l'appareil. Toutes les clés des dispositifs doivent être sécurisées de manière appropriée, par exemple par un cryptage avec des clés maîtresses, afin de réduire le risque de leur divulgation. Le stockage des clés du serveur de réseau LoRaWAN est un processus pour lequel une solution système complète doit être fournie.
- Les processus d'identification et de connexion constituent une autre faiblesse. Chaque passerelle envoie régulièrement des balises (son identifiant individuel) au serveur. Cette identification peut être facilement retrouvée par les agresseurs. Si l'identité est connue, la passerelle peut être compromise, par exemple avec une passerelle malveillante qui envoie son identité plus fréquemment que la vraie.
Certains fabricants adoptent une approche différente : la mise à niveau des éléments de sécurité existants. Ce processus n'est pas optimal si un système comporte de nombreux composants distribués. La mise en œuvre est délicate, complexe, exigeante et ne peut souvent pas être effectuée de manière sûre, rapide et rentable.
Conclusion et perspectives
La norme actuelle LoRaWAN 1.0.x comprend déjà un niveau de sécurité relativement élevé. Les risques et les scénarios d'attaque énumérés ci-dessus sont tout à fait justifiés et doivent être évalués individuellement pour chaque cas d'utilisation. Les approches de solution ont déjà été discutées ci-dessus.
Afin de répondre aux exigences de sécurité accrues dans les réseaux IdO, la LoRa Alliance travaille constamment à l'amélioration de la norme. La LoRa Alliance est une association à but non lucratif d'organisations qui travaillent ensemble à la normalisation des réseaux de RPLP.
La nouvelle spécification LoRaWAN 1.1 a été publiée le 17 octobre 2017. Comme la nouvelle spécification apporte des changements importants aux protocoles de réseau existants et à la communication LoRaWAN, les premiers appareils terminaux conformes à la nouvelle spécification sont attendus en 2018 au plus tôt. Les appareils conformes à la norme LoRaWAN 1.1 sont rétrocompatibles avec les appareils LoRaWAN 1.0.x et peuvent également fonctionner avec les serveurs de réseau 1.0.2.
Les modifications de la spécification LoRaWAN 1.1 affectent les dispositifs finaux ainsi que les passerelles et les serveurs. Les changements les plus importants concernent la communication entre le dispositif final et les passerelles ainsi que la communication entre les serveurs.
En particulier, les attaques par répétition et les attaques ACK en liaison descendante, qui sont encore possibles dans la spécification actuelle 1.0.2.
À cette fin, par exemple, le compteur de trames de liaison montante (FCntUp) a été inclus sous forme cryptée dans les messages de confirmation (ACK Downlinks). Grâce à cette nouvelle fonctionnalité, le terminal peut reconnaître lequel de ses messages a été confirmé par le serveur du réseau.
D'autres améliorations de la sécurité comprennent la séparation claire entre le serveur de réseau, le serveur de jointure et le serveur d'application et l'introduction de clés supplémentaires telles que NwkKey, NwkSEncKey, SNwkSIntKey, FNwkSIntKey et AppSKey. Ces nouvelles clés sont particulièrement importantes pour le nouveau Handover Roaming, qui permet de transférer activement les messages des appareils terminaux vers le réseau domestique de l'appareil terminal via les réseaux LoRaWAN étrangers.
Une attention particulière a également été accordée aux "serveurs de jointure tiers" possibles selon la spécification 1.1. Ces serveurs de jointure ne sont plus gérés par les opérateurs des serveurs de réseau, mais sont désormais fournis par un tiers de confiance. Toutes les clés de sécurité des appareils mobiles sont gérées sur les serveurs de jointure et le serveur de réseau responsable du transport des messages ou le serveur d'application responsable du traitement des messages est fourni. Une séparation claire de ces responsabilités empêche l'opérateur de réseau de lire le contenu (charge utile) des messages LoRaWAN.
Si vous souhaitez être tenu au courant de la sécurité du LPWAN, il vous suffit de vous inscrire sur notre liste de diffusion.
