La sécurité des systèmes (Lora, Sigfox, Nb-IoT)

Ilyas Lougmiri
INSA TC
Published in
6 min readNov 2, 2020

--

Introduction

L’industrie connectée, la voiture autonome, la domotique, ou l’agriculture intelligente sont des domaines d’application de l’IoT (l’internet des objets). Le développement des LPWAN (Low Power Wide Area Network) permet d’avoir environ 31 milliards d’objets connectés mais cette évolution n’échappe pas de plusieurs failles au niveau sécurité. A travers cet article, nous traitons la sécurité des technologies les plus utilisés actuellement dans l’IoT et qui sont : LoRaWAN, SigFox et Nb-iot. Cette étude se basera sur les questions suivantes : Quelles sont les aspects de sécurité des systèmes Lora , nb-iot et sig fox ? Comment les technologies LPWANs visent la confidentialité, l’intégrité et la disponibilité des messages échangés pour les réseaux à longue portée ? Y a-t-il des limites de sécurité dans ses systèmes ?

LoRaWAN : Analyse du système de sécurité, vulnérabilités et les limites.

La sécurité dans Lora/Lorawan est basée sur un algorithme de chiffrement symétrique nommé « AES-128 bits » [2].Actuellement, cet algorithme permet d’empêcher les tentatives de fraude pour deviner la clé, mais cela pourrait ne plus être le cas dans 10 ans. On utilise AppKey (clé d’AES) afin de générer deux clés de sessions nommées « NetworkSessionkey » et « ApplicationSessionKey » . La première clé est partagée entre l’end-device et le serveur afin de générer un code MIC (Message Integrity Code ) pour chaque message. Ensuite la deuxième clé consiste à chiffrer et déchiffrer les données échangées entre l’équipement et le serveur d’application. [1]

Le système de sécurité dans Lora/lorawan a prouvé qu’il est robuste et bien sécurisé mais cela n’empêche pas qu’il y a des vulnérabilités et des limites .

En effet , d’après des études on a trouvé que la modulation lora pendant la transmission a besoin d’une durée entre [0.9–1.2s] . Cette large fenêtre de transmission donne beaucoup d’opportunités aux plusieurs attaques . [1]

L’une des attaques qui exploitent cette durée c’est l’inhibition des communications radio lora (jamming attack) qui se base sur le fait de brouiller les transmissions en générant d’interférences sur la même bande de fréquence à l’aide d’un produit informatique standard (COTS ) . [1] Lors de la procédure d’activation ABP l’adresse du dispositif (DevAddr), NwkSKey et AppSKey sont directement définies et stockées dans le dispositif final. Par conséquent, il ne génère aucune clé et peut directement chiffrer les messages via ces clés. Si ces dernières sont compromises, toutes les communications entre l’appareil, la passerelle et le « network server « peuvent être décryptées par des entités tierces pendant la durée de vie de l’appareil . [1]

En ce qui concerne le end-device, il se compose d’un microcontrôleur (MCU) et une partie radio Lora .Les deux parties communiquent entre elles à l’aide d’une interface UART qui représente aussi une vulnérabilité. En effet , Les commandes et les échanges de données entre l’hôte(microcontrôleur ) et la partie radio LoRa peut être intercepté à l’aide de matériel externe. Par exemple, si l’interface UART est utilisée entre deux circuits intégrés, il nous suffit juste une interface FTDI pour extraire tous les échanges clés. [1]

On peut avoir aussi une entité malveillante qui pourrait également intercepter tous les échanges de données entre l’UCM hôte et la partie Lora et utiliser ces informations interceptées pour créer un dispositif factice avec les mêmes références afin de manipuler la charge de données. [1]

La dernière vulnérabilité dépend de l’existence du champs Frame counters , ce dernier est un compteur de trame (incrément à chaque envoi). [1]Un attaquant peut exploiter l’absence de ce champ en effectuant une attaque par rejeu « replay attack » qui consiste à tromper le serveur en renvoyant les données surtout dans la partie « handshake » afin de prendre l’identité de l’end-device . Ceci peut être facilement détecter lors de la présence du champ « frame counters » car si un message est reçu avec un compteur de trames plus faible que le dernier message, il est ignoré. [1]

SigFox : Fort concurrent du LoRa mais possédant aussi des faiblesses.

Au niveau sécurité, la technologie Sigfox se base sur les éléments suivants :

Porting Authorization Code (PAC) : il joue le rôle de la preuve de propriété d’un dispositif (titre de propriété) et sert à l’enregistrement de ce dernier. Seul le propriétaire actuel du dispositif le connaît. Dans le cas de transfert de cet objet une nouvelle PAC est régénérée. [7]

  • Unique device identifier (ID) : C’est l’identifiant unique de chaque dispositif qui sert à achever l’authentification avec le serveur à l’aide du Network Authentication Key (NAK) qui est aussi unique et généré par le Cipher-based Message Authentication Code function (CMAC). [7]
  • Message Integrity Code (MIC) : c’est la section de contrôle du message transmis par le dispositif. Il est de taille variant de 2 jusqu’à 5 octets. Via cette section du message et le numéro de séquence attribué au payload par un conteur, on vérifie l’intégrité du message envoyé vers la getway. [7]

En addition de ces processus, chaque message est envoyé 3 fois et d’une manière identique pour assurer la disponibilité du service ciblé par le dispositif mais sans aucun message d’acquittement de la part de la getway.[7]

Malgré cette implémentation dont le but de sécuriser les communications Sigfox, cette technologie contient aussi des failles au niveau cryptage et protection. Cette technologie se caractérise par l’absence de chiffrement, ce qui engendre que lors d’une capture d’un message transmis par le dispositif on pourra extraire tout donnés du payload. De cette manière, un malveillant pourra identifier l’émetteur et récupérer tout échange Uplink. Ainsi on peut, comme étant utilisateur de ce périphérique, perdre le contrôle sur le device. [7]

NB - Iot : Héritière de la 4G.

La technologie NB-IoT se compose en trois couches : perceptron, transmission et application. Les exigences de sécurité visent ces trois couches. La couche “perceptron” est susceptible aux attaques à la fois actives et passives. Dans une attaque passive, l’attaquant se contente de surveiller le trafic du réseau. Par contre l’attaque active affecte l’intégrité du message et la falsification des données encodées. [6]

La NarrowBand-Iot possède les spécifications de sécurités de la 4G suivantes :

  • L’identification des dispositifs.[5]
  • La confidentialité de l’identité des utilisateurs.[5]
  • L’authentification des entités.[5]
  • L’intégrité des données. [5]

Ainsi pour réaliser une authentification au réseau, des vecteurs d’authentification sont téléchargés par le MME à partir du centre d’authentification lorsque le MME reçoit de l’équipement les messages Attach Request ou Service Request. [3]

On sait que UE peut envoyer des paquets IP au PGW. Ce qui donne des opportunités à des attaques classiques d’IP. Pour qu’un UE reçoit des paquets IP d’un serveur internet, ce dernier doit établir un tunnel avec le PGW pour l’échange de données. L’établissement de cette session doit obligatoirement inclure la sélection d’un APN par l’UE .[4]

Une entreprise qui utilise un grand nombre d’UE est susceptible de les faire connecter au même réseau privé (LAN) ce qui va faciliter la tâche d’un hacker pour attaquer les autres équipements (UE) dès la prise en contrôle du premier équipement. Par exemple, si l’UE de la victime choisit un port pour communiquer avec un serveur IoT, l’attaquant peut exploiter ce choix en utilisant une UE malveillante qui pourrait envoyer des données malveillantes au même port ouvert comme étant le serveur iot (usurpation d’identité). [4]

Un autre impact de cette attaque qu’on peut avoir est le « Denial of Service ». Par exemple, un attaquant pourrait forcer l’UE à recevoir et à envoyer des données (By pinging the Ue’s victim), vidant la batterie de la victime, qui conduirait à une déclaration de sûreté permanente (obligeant le propriétaire de l’appareil à remplacer la batterie de l’UE).[4]

En guise de conclusion:

Cette analyse nous a permis de répondre aux problématiques d’ouverture et de déduire que le développement et la recherche dans l’IoT doit compenser les failles déduises et de mener cette évolution en parallèle avec les nouvelles implémentations des objets connectés et ainsi que les nouvelles technologies de communication (5G…).

Sources :

[1]: Exploring The Security Vulnerabilities of LoRa; https://ieeexplore.ieee.org/document/7985777

[2] : oÿs Augustin, Jiazi Yi et Thomas Clausen, « A Study of LoRa: Long Range & Low Power Networks for the Internet of Things », Sensors Special Issue Enabling the Move from Wireless Sensor Networks to Internet of Things and Cyber-Physical Systems,‎ septembre 2016

[3] : http://www.efort.com/r_tutoriels/SECURITE_MOBILE_EFORT.pdf?fbclid=IwAR3Sw33FxMldZ7l3ImckVRjQvoKpDWUBICkbH1mEPRxNwP6WqbgobQsQfWI

[4] : Security Issues in Internet of Things: Vulnerability Analysis of LoRaWAN, Sigfox and NB-IoT Florian Laurentiu Coman, Krzysztof Mateusz Malarski, Martin Nordal Petersen and Sarah Ruepp Technical University of Denmark, 2800 Kongens Lyngby, Denmark

[5] : https://www.thalesgroup.com/en/markets/digital-identity-and-security/iot/resources/innovation-technology/nb-iot

[6] : https://iopscience.iop.org/article/10.1088/1757-899X/396/1/012027/pdf?fbclid=IwAR0ktNO38l-qAEhiPHl2Jqz_EPPKzzRkrgcn5mdkOPAdZLC60Zsq_YTzn-A

[7] : On Track of Sigfox Confidentiality with End-to-End Encryption

--

--