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

Spécialité(s)


Résumé

Les opérateurs de télécommunications ont commencé à déployer des réseaux ainsi qu’à fournir des offres d’abonnements pour une galaxie d’objets connectés utilisant la technologie LoRaWAN. Celle-ci leur permet de communiquer par ondes radio sur de grandes distances afin de réaliser de la remontée d’informations. Selon son succès, notre environnement devrait progressivement s’enrichir de ces équipements « communicants » . Les quelques publications sur la sécurité des réseaux LoRaWAN ont donné lieu à des articles aux titres alarmistes qui ont suscité l’envie de savoir si un hacker pouvait effectivement pirater du trafic LoRaWAN à l’abri des ondes radio…


Body

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

LPWAN, LoRa et LoRaWAN

Dans le cadre des réseaux LPWAN (Low Power Wide Area Network), LoRa (LongRange) correspond à la couche liaison. Il s’agit d’une modulation radio utilisant des bandes radio régionales ISM : 868 Mhz en Europe. Le protocole LoRaWAN correspond quant à lui à la couche réseau. Différentes classes A,B et C offrent des fonctionnalités variées. Le cadre de cet article sera restreint aux classes B.

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.
ArchitectureLoraWan

Figure 1 : Architecture LoraWan.

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 :

LoRaArchSetup

Figure 2 : Composants de notre architecture LoRaWAN.

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.

[/opt/lorawan ] # git clone https://github.com/TheThingsNetwork/lora_gateway.git

[/opt/lorawan ] # cd lora_gateway

[/opt/lorawan/lora_gateway ] # patch -p1 <<EOF

 

index 4f08ba6..78d3a19 100644

--- a/libloragw/library.cfg

+++ b/libloragw/library.cfg

@@ -10,7 +10,7 @@

# Note: building on the MAC (OSX) is for testing purposes only

# not for regular operations.

 

-CFG_SPI= native

+CFG_SPI= ftdi

 

 

### Specify which platform you are on.

@@ -20,7 +20,7 @@ CFG_SPI= native

# imst_rpi This is for the IMST concentrators with a Raspberry Pi host.

# linklabs_blowfish_rpi This is for the LinkLabs concentrators with a Raspberry Pi host.

 

-PLATFORM= kerlink

+PLATFORM= lorank

 

 

### Debug options ###

EOF

[/opt/lorawan/lora_gateway ] # make && cd ..

[/opt/lorawan ] # sudo git clone https://github.com/TheThingsNetwork/packet_forwarder.git

[/opt/lorawan ] # cd packet_forwarder

[/opt/lorawan/packet_forwarder ] # git diff

[/opt/lorawan/packet_forwarder ] # make

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.

# dmesg

[192958.445524] usb 1-6: new high-speed USB device number 15 using xhci_hcd

[192958.630105] usb 1-6: New USB device found, idVendor=0403, idProduct=6014

[192958.630119] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[192958.630127] usb 1-6: Product: Single RS232-HS

[192958.630134] usb 1-6: Manufacturer: FTDI

[192958.631499] ftdi_sio 1-6:1.0: FTDI USB Serial Device converter detected

[192958.631625] usb 1-6: Detected FT232H

[192958.631957] usb 1-6: FTDI USB Serial Device converter now attached to ttyUSB0

#

 

$ sudo ./util_tx_test -f 868 -r 1257

Sending -1 packets on 868000000 Hz (BW 125 kHz, SF 10, CR 1, 16 bytes payload, 8 symbols preamble) at 14 dBm, with 1000 ms between each

INFO: concentrator started, packet can be sent

Sending packet number 1 ...OK

Sending packet number 2 ...OK

Sending packet number 3 ...OK

Sending packet number 4 ...OK

Sending packet number 5 ...OK

Sending packet number 6 ...OK

^CExiting LoRa concentrator TX test program

 

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.

$ sudo ./basic_pkt_fwd

*** Basic Packet Forwarder for Lora Gateway ***

Version: 2.1.0

*** Lora concentrator HAL library version info ***

Version: 3.1.0; Options: ftdi;

***

INFO: Little endian host

INFO: found global configuration file global_conf.json, parsing it

INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters

INFO: lorawan_public 1, clksrc 1

INFO: Configuring TX LUT with 16 indexes


INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7

INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate

INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters

INFO: gateway MAC address is configured to AA555A0000000000

INFO: server hostname or IP address is configured to "192.168.56.135"

INFO: upstream port is configured to "1700"

INFO: downstream port is configured to "1700"

…Truncated

INFO: redefined parameters will overwrite global parameters

INFO: local_conf.json does not contain a JSON object named SX1301_conf

INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters

INFO: gateway MAC address is configured to AA555A0000000101

INFO: packets received with a valid CRC will be forwarded

INFO: [down] PULL_ACK received in 0 ms

INFO: [down] PULL_ACK received in 0 ms

 

##### 2017-03-21 17:36:13 GMT #####

### [UPSTREAM] ###

# RF packets received by concentrator: 0

# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%

# RF packets forwarded: 0 (0 bytes)

# PUSH_DATA datagrams sent: 0 (0 bytes)

# PUSH_DATA acknowledged: 0.00%

### [DOWNSTREAM] ###

# PULL_DATA sent: 3 (100.00% acknowledged)

# PULL_RESP(onse) datagrams received: 0 (0 bytes)

# RF packets sent to concentrator: 0 (0 bytes)

# TX errors: 0

##### END #####

INFO: [down] PULL_ACK received in 0 ms

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.

source /etc/lsb-release

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00

sudo echo "deb https://repos.loraserver.io/${DISTRIB_ID,,} ${DISTRIB_CODENAME} testing" | sudo tee /etc/apt/sources.list.d/loraserver.list

sudo apt-get update

 

apt-get install lora-app-server lora-gateway-bridge loraserver postgresql redis mosquitto

useradd -s /bin/false appserver

useradd -s /bin/false loraserver

useradd -s /bin/false gatewaybridge

su – postgres

createuser -P loraserver

createdb --owner=loraserver 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/.

AppServerOk

Figure 3 : Interface d’administration du serveur applicatif.

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 …

AppEUI: A0A1A2A3A4A5A6A7

DevEUI: 0011223344556677

AppKey: 000102030405060708090A0B0C0D0E0F

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.

NodeFinalConf

Figure 4 : Configuration d’un nœud dans le serveur applicatif.

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.

Attention

Au premier démarrage, les nœuds sont susceptibles de fonctionner avec un firmware LoRa. Auquel cas, il sera nécessaire de télécharger WiMod LoRa Studio [STULR] ainsi qu’un firmware LoRaWAN [FIRM]. Dans WiMod LR Studio, dans le menu Configuration > Device Information il est nécessaire d’utiliser le bouton Update Firmware afin de modifier le firmware présent sur le nœud. Une fois cette opération effectuée, il est possible de relancer WiMOD LoRaWAN Endnode Studio pour configurer le nœud.

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.

SettingDevEUI

Figure 5 : Reconfiguration du DevEUI.

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.

WiModFinalInterface

Figure 7 : Interface de configuration des paramètres LoRaWAN.

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.

$ python Monitor.py

## Connecting to 192.168.56.135

## Subscribing to gateway/aa555a0000000101/rx

## Subscribing to gateway/aa555a0000000101/tx

## Subscribing to application/aabbccddeeff1122/node/0011223344556677/

=======> Received message on topic gateway/aa555a0000000101/rx

---> Rx: Received Message at 2017-03-21T09:55:22.580196Z

Decoded data: 00a7a6a5a4a3a2a1a0776655443322110055c6cea2649b

*** Join-request

AppEUI: a0a1a2a3a4a5a6a7

DevEUI: 0011223344556677

DNonce: c655

MIC: cea2649b

=======> Received message on topic gateway/aa555a0000000101/tx

---> Rx: Intercepting Message on TX

Decoded data: 206add0add9b87477e6a0f5e7e37254540

*** Join Accept

Data: 6add0add9b87477e6a0f5e7e

Capture de paquets LoRaWAN.

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 ».

$ ./loraskeys 000102030405060708090a0b0c0d0e0f c655 206add0add9b87477e6a0f5e7e37254540

NetID: 00010203

DevAddr: 068e8cb1

---- ComputingSkeys

NwkSkey: 3d4340fb2a8949d6a971944834b3f92f

APPSkey: 5b767e307303f36ccc2cc1b3be2acda1

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.

=======> Received message on topic gateway/aa555a0000000101/rx

---> Rx: Received Message at 2017-03-21T09:55:27.984158Z

Decoded data: 40b18c8e068000000192334b62

*** Unconfirmed data up

DevAddr: 068e8cb1 fCtrl: 80 fCtnt: 0000 fPort: 01

Data:

 

$ ./lwp -N 3d4340fb2a8949d6a971944834b3f92f -A 5b767e307303f36ccc2cc1b3be2acda1 --parse 40b18c8e068000000192334b62

 

--------------------------------------------------------------------------------

PORT (1) PRESENT WITHOUT PAYLOAD

MSG: 40 B1 8C 8E 06 80 00 00 01 92 33 4B 62

LoRaWAN R1

UNCONFIRMED DATA UP

MIC is OK [ 92 33 4B 62 ]

APPEUI: 0000000000000000

DEVEUI: 6C77700000000000

DEVADDR: 068E8CB1

ADR: 1, ADRACKREQ: 0, ACK 0

FCNT: 0 [0x00000000]

No Port and FRMPayload in message

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.

$ ./loracrypt " 123456789:;<=>?@ABCDEFGHIJKLMNO" 5b767e307303f36ccc2cc1b3be2acda1 068e8cb1 1

Dumping data with sequenceCounter = 0001

Generated blk: 010000000001018c8e010100000075dc

Generated key: c73cb68b9dc7c73128c73336f2ed75dc

Generated blk: 010000000001018c8e01010000005953

Generated key: 4830245ca248481d2a4898ab61a95953

0x000000: f7 0d 84 b8 a9 16 a7 06 10 39 09 0d ce d0 4b e3 .........9....K.

0x000010: 08 71 66 1f e6 a7 f3 5a 62 e0 d2 e0 2d e4 17 1c .qf....Zb...-...

$ ./loracrypt "1123456789:;<=>?@ABCDEFGHIJKLMNO" 5b767e307303f36ccc2cc1b3be2acda1 068e8cb1 1

Dumping data with sequenceCounter = 0001

Generated blk: 010000000001018c8e010100000075dc

Generated key: c73cb68b9dc7c73128c73336f2ed75dc

Generated blk: 010000000001018c8e01010000005953

Generated key: 4830245ca248481d2a4898ab61a95953

0x000000: f6 0d 84 b8 a9 16 a7 06 10 39 09 0d ce d0 4b e3 .........9....K.

0x000010: 08 71 66 1f e6 a7 f3 5a 62 e0 d2 e0 2d e4 17 1c .qf....Zb...-...

Chiffrement de deux messages similaires pour une clé, un devAddr et un sequenceCounter connus.

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



Article rédigé par

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous