Étude de chiffrement dans un réseau IoT : le cas LoRaWan

LoRaWAN est un protocole permettant la communication à bas débit dans des réseaux étendus au moyen de la technologie de modulation LoRa développée par la société SemTech. Celle-ci permet de communiquer sur de longues distances de l’ordre de la dizaine de kilomètres en utilisant peu d’énergie ; elle fait partie des choix réalisés dans le développement des réseaux IoT. Son développement commercial est suivi par différents opérateurs de télécommunications du marché.

La société Orange a ainsi annoncé : « LoRa sera déployé dès 2016, pour répondre à un besoin de connectivité des objets déjà très présent. […] Orange a démarré son projet IoT en 2011 […] Un réseau test à Grenoble nous a pleinement convaincus d’adopter la technologie LoRa […] D’ores et déjà, nous allons déployer rapidement le réseau LoRa sur 1 200 communes de 17 agglomérations françaises dès le 1er trimestre 2016. » [ORA].

La société Bouygues a quant à elle annoncé : « À l’issue d’une expérimentation menée à Grenoble, Bouygues Télécom a fait le lancement en juin 2015 du premier réseau français dédié aux objets connectés basé sur la technologie LoRa. Il l’a annoncé lors du CES (Consumer Electronics Show) de 2015. Membre fondateur de l’Alliance LoRa, Bouygues Télécom est le premier opérateur français à déployer commercialement cette technologie reconnue mondialement comme la plus aboutie dans le domaine de l’Internet of Things. » [BOUY].

Il existe déjà des publications sur la sécurité LoRaWAN. Cependant, les articles publiés sont restés théoriques tel [MRW]. D’autres présentations sont restées privées [REN] et ont fait l’objet d’une vulgarisation dans la presse généraliste [01net]. Le but de cet article est de présenter quelques résultats au travers du déploiement d’une infrastructure de test afin d’étudier la capture et le chiffrement du trafic LoRaWAN.

1. Architecture et chiffrement

Un réseau LORAWAN comprend trois catégories d’éléments représentés dans la figure 1 :

• Les nœuds : il s’agit des objets connectés disposant d’un émetteur récepteur LoRaWAN. Ils disposent de capteurs afin d’effectuer de la remontée d’informations et peuvent recevoir des messages pour déclencher des opérations. Ils sont déployés dans l’environnement après avoir été configurés et doivent être autonomes. Ils disposent d’un identifiant unique DevEUI de 64 bits. Les informations remontées sont associées à un numéro d’application unique AppEUI de 64 bits. Selon la méthode d’activation choisie, une clé AppKey ou deux clés NwkSKey et AppSKey devront être choisies. Elles ont une taille de 128 bits.
• Les passerelles : elles sont déployées par les opérateurs ou par des associations souhaitant déployer un réseau IoT LoRaWAN. Placées de préférence en hauteur afin de maximiser la réception, elles sont chargées de recevoir les paquets LoRa et de transmettre ceux qui sont des paquets LoRaWAN valides vers les différents serveurs applicatifs. Pour y parvenir, elles sont connectées à ceux-ci au moyen de liens réseaux classiques : réseaux câblés ou mobiles. Elles sont identifiées par un identifiant de 8 octets.
• Les serveurs applicatifs : ces équipements prennent en charge le traitement du protocole LoRaWAN : activation des nœuds, déchiffrement des données et transmission vers les applications métiers.

1.1 Choix des clés, méthode d’activation et sécurité

Lors de la configuration des nœuds, il est nécessaire de choisir entre deux modes d’activation :

• ABP (Activation By Personalization) : deux clés NwkSKey et AppSKey doivent être choisies ainsi qu’une adresse réseau DevAddr de 4 octets. Ce sont ces clés qui seront utilisées pour dériver un keystream utilisé lors des opérations de chiffrement. Elles sont configurées directement dans l’équipement avant son déploiement et dans l’interface d’administration des objets connectés du serveur d’applications.
• OTAA (Over The Air Activation) : dans ce mode, une simple clé AppKey est nécessaire à la configuration du nœud. Elle doit être aussi configurée dans le serveur d’application. Lors du démarrage du nœud, cette clé sera utilisée au cours d’un premier échange de messages Join-Request et Join-Accept pour générer des clés de session NwkSKey et AppSKey qui seront ensuite utilisées pour chiffrer les données échangées ; ces clés de session sont conservées jusqu’à leur réinitialisation. Lors de cette étape, le nœud envoie un aléa de 16 bits qui sera utilisé pour dériver les clés de sessions. Un paquet Join-Accept sera renvoyé à destination du nœud, chiffré avec l’AppKey et contenant notamment l’adresse DevAddr attribuée automatiquement ainsi qu’un aléa de 24 bits utilisé pour dériver les clefs de sessions.

1.2 Chiffrement des données LoRaWAN

Comme mentionné dans [MWR], les clés NwkSKey et AppSKey ne sont pas utilisées pour chiffrer au moyen d’AES, mais pour en dériver une séquence de clés qui seront utilisées pour du chiffrement par bloc au moyen d’une opération Xor. Les paramètres qui permettent de déterminer l’étape de cette séquence sont l’adresse DevAddr du nœud et le champ sequenceCounter du message. Ces deux champs sont connus lors de l’interception de paquets. On pourra se référer au chapitre 4 de la spécification LoRaWAN [LORA] pour le format des différents messages.

Par ailleurs, le choix de la clé à utiliser est déterminé par un champ Fport présent dans les requêtes d’envoi de données. Le port 0 est réservé aux messages à destination du Network Server qui seront déchiffrés en utilisant NwkSKey ; les autres ports sont laissés aux applications qui utiliseront la clé AppSKey.

2. Installation d’une infrastructure LoRaWAN

Le schéma suivant présente les composants a installer :

Le choix du matériel s’est porté sur les éléments suivants :

• Un concentrateur iC880A-USB [Gate] pour la passerelle : basé sur la référence SX1257 de Semtech, il permet la réception de paquets LoRa sur les différents canaux disponibles et leur démodulation en paquets LoRaWAN.
• Un StarterKit IM880B [Node] : basé sur la référence SX1272, ces deux nœuds de développement permettent l’utilisation d’un firmware LoRa ou LoRaWAN ; il est par ailleurs possible de reconfigurer leur DevEUI, les sources de l’implémentation sont disponibles, ce qui permet leur inspection ainsi que leur réutilisation dans le développement d’outils.

2.1 Installation d’une passerelle

2.1.1 Compilation et installation du packet_forwarder

La fonction de passerelle entre les nœuds et les serveurs applicatifs est assurée par le packet_forwarder. Celui-ci qui communique d’une part avec le concentrateur en USB pour l’échange des paquets LoRaWAN, d’autre part en UDP avec le serveur applicatif.

L’implémentation Semtech [STH] ne supportant pas l’USB, on utilise l’implémentation proposée par TheThingsNetwork [TTN]. Il s’agit d’une initiative déployant une infrastructure LoRaWAN libre dans différents pays d’Europe : Pays-Bas, Suisse…

Afin de construire le packet forwarder, il sera nécessaire préalablement de compiler et installer la bibliothèque [mpss]. Elle permet d’interagir en I2C avec un périphérique FTDI/USB. Elle sera nécessaire à la compilation du packet_forwarder et de la libloragw [LIBLG].

Lors de la compilation de lora_gateway, il est nécessaire de modifier la configuration afin de spécifier la plateforme à utiliser. La configuration par défaut de celle-ci lui permet de fonctionner avec une plateforme matérielle Kerlink en SPI. Dans le cas de l’ic880A, il faudra modifier les champs CFG_SPI de native à ftdi et PLATFORM de kerlink à lorank dans le fichier library.cfg avant de procéder à la compilation pour pouvoir utiliser la communication FTDI.

Les fichiers de configuration chargés sont d’abord global_conf.json puis local_conf.json dont les options écraseront les précédentes. Il est important de vérifier la valeur du champ gateway_ID qui sera utilisé pour surveiller des files [MQTT]. Il s’agit d’un protocole de messagerie utilisé entre les différents composants du serveur applicatif et pris en charge par le serveur mosquitto.

2.1.2 Test du concentrateur LoRaWAN

En branchant le concentrateur, un nouveau périphérique FTDI devrait être détecté. Il sera alors possible de vérifier son fonctionnement avec l’utilitaire util_tx_test avant de pouvoir utiliser le packet_forwarder.

Le packet_forwarder a pour rôle de recevoir les paquets à partir du concentrateur LoRa. Ils sont ensuite transmis par UDP vers l’infrastructure LoRaWAN : Network et Application server qui prendront en charge la configuration des nœuds ainsi que le déchiffrement des paquets. Si le serveur applicatif est installé sur une machine différente, il sera nécessaire de reconfigurer le packet_forwarder en modifiant les champs server_address, serv_port_up et serv_port_down dans le fichier de configuration global_conf.json.

2.2 Installation du serveur applicatif

Afin de fournir les services basiques LoRaWAN d’activation et de déchiffrement, il est nécessaire d’installer un serveur applicatif. Une solution libre existe qui fournit les services de base des réseaux de classe B:LoRaServer [APPS].

Il se compose de trois éléments distincts dont l’installation ne présente pas de difficulté particulière : lora-gateway-bridge, loraserver et lora-app-server. Chaque logiciel nécessite un fichier de configuration dans /lib/systemd/system pour pouvoir démarrer automatiquement en tant que service ainsi qu’une configuration minimale dans /etc/default. Différents fichiers de configuration sont fournis en annexe sur le [GITHUB].

• Lora-gateway-bridge : cet élément reçoit les paquets UDP transmis par le packet_forwarder. Ces paquets sont alors stockés dans une file MQTT.
• Loraserver : à partir des files MQTT, le loraserver prend en charge les paquets LoRaWAN afin de répondre aux demandes d’activation et de déchiffrer les données reçues pour les nœuds dont les clés de session ont été configurées. Il est nécessaire d’installer une base de données postgresql qui permet la persistance des données notamment pour les clés de session utilisées.
• Lora-app-server : cette interface permet la création et configuration de nœuds pris en charge par le loraserver.

Si jamais le packet_forwarder fonctionne sur une machine différente, il est nécessaire de s’assurer que le champ UDP_BIND est correctement configuré dans le fichier de configuration du serveur lora-gateway-bridge.

Une fois ces éléments installés et démarrés, il est possible de se connecter à l’interface de gestion du serveur applicatif en pointant un navigateur vers l’adresse https://loraserver:8080/.

2.3 Installation d’un nœud

Nous allons déployer un nœud en mode OTAA ; nous observerons ainsi les différentes étapes d’activation d’un nœud et pourrons traiter les paquets reçus. Afin de faciliter les tests, les éléments suivants sont sélectionnés selon une méthode triviale permettant de s’en souvenir pour les paramétrer à différents endroits. Toute ressemblance avec des faits existants ou ayant existé dans un environnement en production …

2.3.1 Configuration du nœud sur le serveur applicatif

Il est nécessaire de configurer notre nœud dans le serveur applicatif. Pour cela, sur l’interface, il suffit de cliquer sur le bouton Create Node, de remplir les champs et de valider par un clic sur Submit.

2.3.2 Configuration du nœud sous Windows

Les logiciels de contrôle du nœud fonctionnent sous Windows. Ils nécessitent la création d’un compte afin d’être téléchargés. Ils peuvent être installés dans une machine virtuelle supportant la connexion de périphériques USB. Ils nécessitent l’installation d’un driver [FTDI]. Le logiciel WiMOD LoRaWAN EndNode Studio téléchargeable ici [STULW] permet le paramétrage du firmware LoRaWAN.

Chaque nœud LoRaWan possède un identifiant unique DevEUI. La plateforme de test SK-iM880B permet la reconfiguration de ce champ. Pour cela, il est nécessaire dans le menu Extras de reconfigurer l’Operation mode du nœud en Customer mode et d’appliquer le changement avec le bouton Set Operation mode.

Une fois ce mode activé, il est possible de modifier le DevEUI du nœud avec le bouton Set Device EUI. Une fois un DevEUI choisi et configuré, il est nécessaire de repasser le nœud en mode Application en validant avec Set Operation Mode comme indiqué dans l’image 3.

Il est possible dans l’onglet Network Service de configurer les différents éléments selon le mode d’activation choisi. Dans notre situation, le menu Device Activation Over The Air nous permet de définir l’ApplicationEUI et l’Application Key à utiliser ; une fois ces paramètres validés avec Set Join Parameter, le bouton Join Network déclenche l’activation. Si celle-ci s’est bien déroulée, Network Status indiquera Active (OTAA) comme sur la capture d’écran.

Pour vérifier que l’association s’est bien déroulée, il est possible aussi de consulter les logs renvoyés par les différents services Lora.

Dans l’interface web du LoraServer, on doit alors pouvoir consulter que l’activation s’est bien déroulée en cliquant sur notre nœud puis sur le bouton Node session / ABP et en vérifiant que des clés de sessions ont bien été générées en même temps qu’une adresse DevAddr.

Le bouton Send U-Data nous permet dès lors d’envoyer des données qui seront chiffrées au moyen des clés de session. En adaptant le script Monitor.py, il est possible de s’abonner à la file de notre nœud pour s’assurer que les données ont bien été reçues et déchiffrées.

3. Capture et analyse de trafic

Cette infrastructure permet la capture et l’analyse de trafic LORAWAN. Les messages reçus par la passerelle sont stockés dans des files MQTT auxquelles il est possible de s’abonner avec le script Monitor.py.

Il est possible de se constituer une boîte à outils LoRaWAN avec les éléments suivants :

• Lora-wan-parser [LWP] : ce programme permet de générer et valider des requêtes LoRaWAN et s’avère ainsi être un outil de débogage lors du développement d’autres outils.
• Monitor.py : ce script surveille les files MQTT du serveur LoRa afin d’afficher les paquets interceptés par notre passerelle. Il permet l’extraction des différents paramètres nécessaires pour utiliser les autres outils.
• LoRaskeys : ce programme réimplémente la génération des clés de sessions AppSKey et NwkSKey à partir d’un aléa « DNonce » connu et de la réponse Join-Request reçue qui contient un aléa « ANonce ».
• Loracrypt : ce programme permet de réaliser des expérimentations sur la dérivation des blocs utilisés pour chiffrer les données envoyées.

Les trois derniers outils sont récupérables sur le [Github].

3.1 Génération des clés NwkSKey et AppSKey

Le script Monitor.py surveille les paquets échangés par la passerelle LoRa et le serveur applicatif afin d’en afficher les principaux champs. Dans le cas d’une activation over the air, une requête Join-Request capturée permettra de connaître les informations suivantes : AppEUI, DevEUI ainsi que l’aléa « DNonce ». Ce dernier est utilisé pour générer les clés de sessions.

La capture d’une réponse Join-Accept permettra d’en déchiffrer le contenu à partir d’une AppKey connue et d’en extraire en cas de succès un autre aléa « ANonce » utilisé pour générer les clés de session. Ce message contient par ailleurs la valeur de l’adresse « DevAddr » attribuée au nœud.

En capturant un échange d’activation Join-Request et Join-Accept, il devient possible de générer les clés NwkSKeys et AppSKeys à partir de l’aléa « DNonce » et du message Join-Accept dont est extrait l’aléa « ANonce ».

Il est possible par la suite en capturant les messages dont l’adresse « DevAddr » correspond à celle de la réponse Join-Accept précédente de les valider au moyen du programme lora-wan-parser. Il est nécessaire pour cela de spécifier les clés NwkSKey et AppSKey. En cas de succès, les données seront déchiffrées.

Il est ainsi possible pour un attaquant écoutant du trafic LoRaWAN de tenter de bruteforcer des clés de session. C’est réalisable en premier lieu si elles ont été choisies de façon non aléatoire par exemple lors d’une activation ABP. Par ailleurs, si un échange par activation OTAA est capturé, il devient possible de bruteforcer l’AppKey. En cas de succès, il est possible de dériver les clés de sessions utilisées.

La passerelle que nous avons testée dans Paris pour une durée de huit jours nous a permis de capturer du trafic LoRaWAN au sein duquel une douzaine de flux différents ont été identifiés. Cependant, sur l’ensemble du trafic capturé, aucune requête Join-Request n’a été interceptée. Par ailleurs, aucun des paquets reçus n’a pu être validé au cours des tests avec des clés de session triviales.

3.2 Cryptanalyse de la séquence des blocs de chiffrement

Parmi les vulnérabilités évoquées dans les publications en début d’article, l’usage non optimal d’AES a été souligné. En effet, le chiffrement utilise une opération Xor associée à une séquence de blocs de chiffrement qui peut être générée à partir de la clé de session ainsi que des valeurs connues de DevAddr et de sequenceNumber. Ce dernier est un entier sur 16 bits. Lorsqu’il boucle, la séquence de blocs de chiffrement est réutilisée.

Le programme Loracrypt permet de chiffrer un message à partir d’une AppSKey, du DevAddr et du sequenceCounter (Fcnt) qui sont connus. Il permet de visualiser la génération de la séquence des blocs de chiffrement.

Dès lors que des paquets chiffrés avec la même clé seront capturés, si les clés de session ne sont pas réinitialisées, selon la nature des données et leur variabilité, il sera possible de procéder à une opération xor bloc par bloc afin d’extraire des éléments de la clé « courante » de la séquence de chiffrement. Ces informations agrégées dans le temps peuvent faciliter une cryptanalyse.

Lors de nos tests, il a été possible de capturer des envois de données assez réguliers, de l’ordre d’un paquet toutes les trente secondes. À supposer que ce périphérique ne soit pas réinitialisé, il faudrait environ 22 jours avant que le sequenceCounter boucle. C’est le temps requis pour commencer à envisager une attaque par cryptanalyse.

Celle-ci ne serait par ailleurs pas garantie selon la nature des données encodées : texte ou binaire. Il serait nécessaire de disposer de plus d’informations sur le périphérique émettant ces paquets, éventuellement en l’identifiant par son DevEUI si on a pu le capturer.

Conclusion

Les moyens techniques mis en place dans notre solution permettent la capture de paquets LoRaWAN émis par nos nœuds, mais aussi par d’autres nœuds dans l’environnement. Au cours des tests réalisés, il a été montré qu’il était possible de réaliser des attaques par bruteforce sur les différentes clés utilisées.

La sécurité LoRaWAN repose en partie sur la méthodologie implémentée dans le choix des clés. En effet, si certaines des clés sont facilement devinables lors d’une activation ABP, elles pourront faire l’objet de tentatives de bruteforce sur les paquets capturés par un attaquant. L’activation OTAA permet de s’assurer que les clés de sessions seront aléatoires. Cependant, la capture éventuelle de Join-Request et Join-Accept permet aussi d’attaquer la clé AppKey utilisée pour générer les clés de session. Il est donc nécessaire de s’assurer que ces clés sont générées de façon aléatoire.

Cependant, au-delà de ces vulnérabilités facilement évitables, l’implémentation correcte d’un environnement LoRaWAN nécessite le respect des recommandations quant au renouvellement fréquent des clés de session et à la non-réutilisation de valeurs aléatoires utilisées dans la génération des clés. Dans le cas contraire, la nature et la quantité des données échangées ainsi que la connaissance de leur structure par un attaquant, qui aurait procédé à l’analyse d’un équipement semblable, peuvent mener à la compromission du trafic via une cryptanalyse de celui-ci étalée sur une période se comptant en semaines.

Remerciements

L’auteur remercie la société LEXFO pour les moyens mis à disposition ainsi que pour les conseils, l’aide apportée et la relecture.

Références

[MWR] LoRa Security : https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-LoRa-security-guide-1.2-2016-03-22.pdf

[REN] LoRaWAN vulnerabilities : http://hardwear.io/renaud-lifchitz-speaker/

[ORAN] Déploiement Orange : https://www.orange.com/fr/Engagements/Responsabilite/Environnement/Changement-climatique/Folder/Orange-et-la-COP/Folder/LoRa

[BOUY] Réseau Bouygues : http://www.objetconnecte.com/tout-savoir-reseau-lora-bouygues/

[01net] LoRaWan vulnérable : http://www.01net.com/actualites/objets-connectes-les-reseaux-lorawan-vulnerables-aux-attaques-de-hackers-1042538.html

[LORA] LoRaWAN Specification : https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf

[STH] Implémentation Semtech : https://github.com/Lora-net/

[MQTT] MQ Telemetry Transport : https://en.wikipedia.org/wiki/MQTT

[TTN] TheThingsNetwork : https://www.thethingsnetwork.org

[LIBLG] Lib Lora Gateway : https://github.com/TheThingsNetwork/lora_gateway

[Gate] Concentrateur LoRa : https://wireless-solutions.de/products/long-range-radio/ic880a.html

[Node] StarterKit LoRaWan : http://webshop.imst.de/sk-im880b-starter-kit-for-im880b-l.html

[LWP] LoraWanParser : https://github.com/JiapengLi/lorawan-parser

[FTDI] Drivers FTDI : http://www.ftdichip.com/Drivers/CDM/CDM21224_Setup.zip

[STULR] WiMod LoRa Studio : http://www.wireless-solutions.de/images/stories/downloads/Radio%20Modules/iM880B/WiMOD_LR/WiMOD_LR_Studio_V1_18_4.zip

[FIRM] LoRaWAN Firmware : http://www.wireless-solutions.de/images/stories/downloads/Radio%20Modules/iM880B/WiMOD_LoRaWAN/WiMOD_LoRaWAN_EndNode_Firmware_V1_17.zip

[STULW] WiMod LoRaWAN Studio : http://www.wireless-solutions.de/images/stories/downloads/Radio%20Modules/iM880B/WiMOD_LoRaWAN/WiMOD_LoRaWAN_EndNode_Studio_V0_33_0.zip

[APPS] LoRaServer : https://docs.loraserver.io/loraserver/

[GitHub] Attacking LoraWan : http://github.com/AttackingLoraWan