P64 Sécurité de l'IOT
Sommaire
Objectif du PFE
L’internet des objets (IoT) se démocratise de plus en plus dans nos appareils électroniques et la question de la sécurité se pose. Si un de ces objets connait une défaillance, l’ensemble des données lié à son réseau pourrait être compromises. L’objectif de ce PFE est d’analyser le protocole réseau LORA et de déceler les failles de sécurité afin de les corriger.
Réseau LoRa
Le réseau LoRa ( Long Range ) est une technologie permettant aux objets connectés d’échanger des données de petites tailles. Le débit du réseau varie de 0,3 kb/s à 50 kb/s. La première utilité est que la consommation des objets est très faible garantissant une autonomie allant jusqu’à 10 ans. La portée maximale est d’environ 20km. L'architecture du réseau LoRaWan est utilisée sous forme de réseau hiérarchique où chaque passerelle peut transmettre les messages entre les appareils terminaux et un serveur de réseau central en arrière-plan.
Le protocole LoRa a 3 modes de fonctionnement:
- L’envoi d’informations vers une antenne puis la réception d’informations immédiatement après. Le serveur ne pourra envoyer d’informations qu’au prochain cycle d’envoi. Ce mode à la moins grande consommation d’énergie et permet d’envoyer des données de manière régulière ( ex: capteur). La portée maximale est d’environ 20 km en zone rurale et 1 km en zone urbaine.
- La réception de données à intervalles réguliers et paramétrés à l’avance.
- La réception d’informations en continu, c’est le mode qui consomme le plus.
L’alliance LoRa a publié un programme de certification obligatoire consistant à vérifier que l’objet connecté répond aux contraintes fonctionnelles du standard LoRaWAN.
La bande utilisée est 868 MHz et 900 MHZ. Elle est assez large pour protéger le signal des interférences dù à l’environnement.
Composants du réseau LoRa
La solution LoRa est constitué de Nodes (noeuds) et de Gateways (passerelles) qui communiquent avec le serveur réseau.
- Les noeuds sont utilisés pour mesurer des valeurs ou contrôler des systèmes externes. Ils ont une faible alimentation et communiquent par réseau sans fil avec un ou plusieurs passerelles. Les noeuds sont équipés d’un transmetteur LoRa géré par un microcontrôleur. Le microcontrôleur peut envoyer des commandes au transmetteur pour configurer les paramètres du réseau LoRa ou envoyer et recevoir des données d’application que le transmetteur enverra au réseau serveur par la passerelle.
Les noeuds sont usuellement en mode “call then listen”, ce qui veut dire que le noeud enverra des données au serveur et écoutera pendant une courte durée la réponse du serveur.
- Les passerelles sont moins nombreuses et transfèrent les données depuis les noeuds jusqu’au serveur réseau en utilisant des connections IP standards.
La solution LoRa a donc une topologie “star of star”; où plusieurs noeuds communiquent à une ou plusieurs passerelles, qui communiquent à un serveur réseau unique. Les passerelles n’ont pas de mesures de sécurités mais fonctionnent comme un tunnel entre les noeuds et le serveur.
- Le serveur réseau représente le stockage des données envoyées depuis les noeuds. Il est la plupart du temps une interface web où les passerelles se connectent en utilisant le réseau cellulaire.
LoRa Frame structure
La transmission d’un noeud à une passerelle est appelée uplink (liaison montante) et de la passerelle à un noeud downlink ( liaison descendante). Il y a 3 classes de réseau LoRaWAn : classe A, B et C. Les classes ont des frames différentes de uplink et downlink.
Les noeuds de classe A sont ceux qui consomment le moins niveau énergétique. Lorsqu’un uplink est transmis, 2 fenêtres de downlink sont envoyés en réponse. La fréquence des transmissions est défini par le noeud.
Les noeuds de classe B sont similaires aux classes A mais ont plus de fenêtres de downlink, définis par les passerelles.
Les noeuds de classe C sont en écoute permanente et sont donc toujours en downlink lorsqu’ils n’émettent pas en uplink. C’est le mode le plus consommateur en énergie mais il a moins de latence comparé aux autres pour la communication entre noeud et serveur.
Pile de protocole LoRa
La pile de protocole LoRa est composée de 4 couches :
- Couche Application LoRa
- Couche MAC LoRa
- Couche Physique LoRa
- Couche RF LoRa
La couche MAC contient les données relatives à la classe du noeud et varie selon son type.
La couche physique construit le paquet pour transmettre l'information de la couche MAC à la couche radio. La couche Radio PHY contient un préambule ( 8 octets ), un entête et des contrôles de redondance cycliques pour le PHY Payload et l’entête.
La couche PHY Payload commence par un entête MAC suivi d'un MAC Payload et d’un check d’intégrité du paquet. L’entête et le Payload contiennent les données de l’utilisateur plus des informations relatives au type de message et sur la version LoRa utilisée.
Le Payload MAC est constitué d'un entête comportant les adresses de la source et de la destination ainsi qu'un frame counter pour protéger le message. Il est aussi formé d'un Frame port et d'un Frame Pyload qui contiennent les données de l'application. Le Frame Port est aussi utilisé pour déterminer si le message contient seulement des commandes MAC ou des données spécifiques à l'application.
Schéma de la communication
Matériel
| Matériel | Quantité | Prix à l'unité | Prix Total | URL | statut |
|---|---|---|---|---|---|
| RF Adafruit Feather M0 RFM96 | 3 | 31,97 € | 95.91€ | http://www.mouser.fr/ProductDetail/Adafruit/3179/?qs=sGAEpiMZZMuC4zZxLL0ZTXmUcMwoRc9uEac7jsWPYbgAg4D4CJduaQ%3d%3d | Recu |
| Raspberry PI | 3 | 31,41 € | 94.23 € | http://fr.farnell.com/raspberry-pi/raspberrypi-modb-1gb/raspberry-pi-3-model-b/dp/2525225 | Recu |
| Carte SD 4 Go | 3 | 14,58 € | 43.74 € | http://fr.farnell.com/transcend/ts4gsdhc10/carte-sdhc-4gb-classe-10/dp/2290237 | Recu |
| Alimentation Raspberry Pi | 3 | 8,05 € | 24,15 € | http://fr.farnell.com/stontronics/t6090dv/psu-raspberry-pi-5v-2-5a-uk-euro/dp/2520786 | Recu |
Montage
Communication
Les Feather LoRa reçus, j'ai commencé à souder des fils de 16.5cm (pour 433 MHz) de long pour qu'ils servent d'antenne.
J'ai commencé par prendre l'exemple fourni par le site adafruit pour voir si les modules fonctionnaient correctement.
En utilisant un module comme émetteur et un autre comme récepteur, on obtient ces résultats :
Les modules communiquent bien et se répondent.
Les messages sont envoyés en clair et peuvent être interceptés par tout le monde et dans un grand périmètre puisque la portée peut être de plusieurs kilomètres.
De ce programme, j'ai déduit plusieurs fonctionnalités pour sécuriser la liaison.
Changement de fréquence
La fréquence du module LoRa est prévu pour 433 MHz. Cependant j'ai pu noter que changer cette fréquence pour l'émetteur et le récepteur garantissait toujours un bon fonctionnement si on ne dépasse pas certaines valeurs. D'après quelques tests, la plaque de fréquence peut varier de 390 à 550 MHz (faire plus de tests pour trouver les limites).
Mais le récepteur et le transmetteur doivent être sur la même fréquence à 0.02 MHz près. On peut en déduire plusieurs centaines plages de fréquence juste pour le module 433 MHz.
Un désavantage de cacher ces messages dans des fréquences précises est que si l'émetteur transmet des paquets en continu, on peut scanner certaines fréquences jusqu'à recevoir un paquet et connaître la fréquence précise. Cependant, les module LoRa émettent rarement en continu mais plutôt à des temps définis et très peu de paquets.
J'ai réalisé un programme permettant de scanner des bandes de fréquence afin de voir si des paquets sont transmis. En attendant 3 secondes par fréquence et en changeant de 0.02 MHz, on scanne 1 MHz toutes les 2m30s.
Pour scanner une plage de 100 MHz, on met à peu près 4h5m. Si un émetteur transmet en continu on peut trouver la fréquence dans un temps raisonnable. Si l'émetteur transmet seulement toutes les heures, le temps devient beaucoup plus long.
Authentification
Un problème pouvant survenir lorsque plusieurs récepteurs sont allumés et que des transmissions arrivent est que les récepteurs ne sauront pas à qui est destiné le paquet.
Authentification en 1 étape
L'émetteur envoie un paquet avec son adresse, l'adresse de destination, puis le message. Le récepteur peut checker si le message lui est dédié et par qui il est envoyé.
Le désavantage est que si quelqu'un intercepte le message, il connaît les adresses des modules et peut envoyer des paquets en se faisant passer pour un émetteur.
Authentification en 2 étapes
J'ai créée un programme pour que l'émetteur et le récepteur aient une adresse définie à l'avance et ne puissent parler qu'entre eux.
L'émetteur envoie un paquet contenant l'adresse du récepteur. Si le récepteur reçoit le paquet et que l'adresse correspond à la sienne, il renvoie un paquet avec l'adresse de l'émetteur.
L'émetteur ayant reconnu son adresse, il envoie le paquet contenant le message et le récepteur peut stocker les informations reçus.
Ce programme n'a été réalisé qu'entre 2 modules. Le premier problème est que si plusieurs émetteurs doivent envoyer des paquets au même récepteur, il ne sait pas quel émetteur lui a envoyé un paquet.
Il faudrait donc qu'un récepteur ait seulement un émetteur affilié. De plus les adresses circulent en clair et quelqu'un peut recevoir les adresses et envoyer des paquets aux modules en essayant de deviner si l'adresse est au récepteur ou à l'émetteur.
Disponibilité
Si un module est en panne ou rencontre un bug, il peut y avoir perte d'informations. Une solution pour éviter ce genre d'incident et de vérifier si le paquet est correctement reçu si le récepteur est en panne. Une réponse du récepteur vers l'émetteur serait obligatoire pour s'assurer que l'émetteur n'envoie pas dans le vide.
Si l'émetteur n'a pas de paquet de confirmation, il envoie un paquet à un module dédié au report de panne pour lui informer que son paquet à destination de l'émetteur a rencontré un problème.
Si c'est l'émetteur qui rencontre un problème, le récepteur ne peut pas savoir qu'il est en panne à moins qu'il vérifie l'état de ses émetteurs toutes les X minutes.S'il n'y a pas de réponses il envoie un paquet au module dédié au report de panne.
Dans un cas plus simple où l'on pourrait faire fonctionner les modules assez fréquemment, on pourrait imaginer un système ou tous les modules envoient un paquet au module de report de panne. Le module de report compare avec sa base de données de modules et indique lorsqu'un module ne lui a pas fait signe depuis plus de X minutes.
Intégrité des paquets
Les paquets doivent être vérifiés pour être sur qu'ils ne soient pas corrompus. Lorsqu'un paquet est envoyé au récepteur, le récepteur renvoie le paquet à l'émetteur et celui-ci vérifie s'il est conforme à celui envoyé et renvoie le paquet s'il n'est pas conforme.
