RAPPORT D PROJET DE FIN DTUDE

SCURIT E
D LINTERNET DES OBJETS
E
Marwa wachem
Afef ouhaichia
Safa wachem

Encadr par

Mme : raja
 Rapport de projet

Table des matires

Introduction.......................................................................................................................................... 4

tat de lart........................................................................................................................................... 5
Les rseaux IoT................................................................................................................................5
Couche physique LoRa.................................................................................................................7
Modulation..................................................................................................................................7
Encodage.....................................................................................................................................8
Rtro-ingnierie........................................................................................................................ 10
Couche transport LoRaWAN...................................................................................................... 12
Gnralits................................................................................................................................ 12
Structure des paquets................................................................................................................ 13
Processus dauthentification et dactivation..............................................................................14
La scurit de LoRaWAN................................................................................................................... 16
Risques internes............................................................................................................................. 16
Chiffrement des paquets............................................................................................................16
End-device de classe B et C......................................................................................................17
Performances.............................................................................................................................18
Risques externes............................................................................................................................ 19
Implmentation......................................................................................................................... 19
Rle de loprateur....................................................................................................................20
Analyse de consommation........................................................................................................ 21
Rcapitulatif des risques........................................................................................................... 23
Conclusion..........................................................................................................................................24
 Index des illustrations

Illustration 1 : Schma d'un rseau IoT................................................................................................5

Illustration 2 : Rseau en toile............................................................................................................6
Illustration 3 : Influence du spreading factor sur l'allure du chirp.......................................................8
Illustration 4 : tapes de modulation et dmodulation.......................................................................12
Illustration 5 : Couche MAC et couche de modulation......................................................................13
Illustration 6 : Spectre frquentiel d'une communication LoRa.........................................................14
Illustration 7 : Saut de frquence LoRa..............................................................................................15
Illustration 8 : Classe d'metteur LoRa..............................................................................................16
Illustration 9 : Sous-couches MAC....................................................................................................16
Illustration 10 : Structure de paquets LoRaWAN...............................................................................17
Illustration 11 : Paquet join_request...................................................................................................19
Illustration 12 : Paquet join_accept....................................................................................................19
Illustration 13 : Utilisation des cls....................................................................................................20
Illustration 14 : Balise mise par une gateway Beacon......................................................................24
Illustration 15 : Collision de paquet pour 1000 end-devices..............................................................25
Illustration 16 : Utilisation d'un tiers de confiance.............................................................................27
Illustration 17 : Transmission de 2 paquets, avec chec du premier..................................................28
Illustration 18 : Puissance consomme pour une fentre d'mission.................................................29
Illustration 19 : Puissance consomme pour une fentre de rception n1........................................29
Illustration 20 : Puissance consomme pour une fentre de rception n2........................................29
Illustration 21 : Rcapitulatif des risques...........................................................................................30
Introduction
L'internet des objets (Internet of Things IoT) dsigne l'appropriation de l'internet par de
nombreux objets connects varis. Les prvisions du nombre de capteurs montrent une trs forte
croissance dans les annes venir pour des domaines comme la domotique, l'industrie ou encore la
golocalisation. La scurit de ces rseaux est tout aussi majeure que l'expansion de ce parc d'objets
connects. Parmi les protocoles crs sur mesure pour s'adapter aux nouveaux besoins de cet IoT,
nous retrouvons le couple LoRa et LoRaWAN.

LoRa (Long Range rseau tendu longue porte) est le nom donn une technologie de
modulation talement de spectre invente en 2010 et brevete en 2012 par la start-up franaise
Cycleo. Cette entreprise grenobloise a t rachete par le fabricant amricain de semi-conducteur
Semtech pour 5 millions de dollars. C'est la partie propritaire de la technologie.

LoRaWAN dcrit le protocole de transport qui utilise la modulation LoRa. Cette couche est
open-source et relativement bien documente. Cette rcente technologie est au centre de l'actualit
et de toutes les attentions puisque Semtech a trouv des investissements hauteur de 50 millions de
dollars et la technologie a t bien accueillie au CES 2017. La technologie concurrente Sigfox a
lev quant elle 150 millions de fonds.

Ce rapport prsente dans un premier temps un tat de l'art de ces protocoles. Ensuite
l'aspect de la scurit de LoRaWAN sera approfondi.
 tat de l'art

Les rseaux IoT

Voici un schma qui rsume les quatre grandes tapes de la communication d'un rseau IoT.

Illustration 1: Schma dun rseau IoT

Dans lIoT, on considre souvent des objets (capteurs) qui ont des contraintes matrielles et
logicielles qui ne leur permettent pas de se connecter directement au rseau Internet. Ils sy
connectent travers une passerelle (gateway). En effet, dun ct internet nest pas dimensionn
pour grer ladressage d'autant dobjets connects. Dun autre ct l'ipv6 est un protocole souvent
trop lourd pour tre exploit directement par les capteurs. Aujourdhui l'ipv6 est utilis via le
protocole 6LowPAN (IPv6 Low power Wireless Personal Area Networks) qui est exploit au-dessus
des protocoles rseaux rgis par l'IEEE 802.15.4.

Les gateways traduisent aussi les protocoles propritaires vers un protocole comprhensible
sur internet et certaines peuvent jouer le rle dagrgateurs de rseaux. Les rseaux qui les
connectent doivent aussi rpondre ces besoins de lgret, de simplicit et de faible cot. Ainsi,
les oprateurs tlcoms doivent sadapter car utiliser les rseaux cellulaires pour transmettre
quelques kilo doctets par capteur cote trs cher. De plus, le rseau 2G est en cours de
dmantlement. Ceci offre une opportunit pour dvelopper des rseaux sans fils
MachineMachine (M2M) longue porte, basse nergie et trs bas dbit qui cotent beaucoup
moins cher que les rseaux cellulaires.

Le rseau LoRa prsent ensuite a principalement t conu pour l'utilisation d'un schma en
toile. Ceci a l'avantage d'avoir une grande simplicit de dploiement et une faible consommation
nergtique de la part des quipements metteurs. Les particularits des technologies sans fil longue
distance permettent ce type d'architecture.

Illustration 2: Rseau en toile

Voici quelques technologies et protocoles actuels autour du monde de l'IoT :

LoRaWAN
Sigfox
ZigBee
6LoWPAN
OCARI
DASH-7
Bluetooth Low-Energy (BLE)
NFC
Couche physique LoRa
Modulation
Il existe principalement deux documents officiels publis par Semtech qui nous aident
tudier LoRa: la spcification du brevet dpos et l'Application Note 1200.22. Cependant il faut
prendre ces informations avec prudence, car il n'y a aucune garantie que le protocole rel
corresponde exactement ce qui est dcrit. En effet la documentation fournie par Semtech cherche
aussi offusquer le fonctionnement rel pour protger la technologie.

LoRa utilise le Chirp Spread Spectrum. L'volution de la frquence d'un tel signal est
toujours strictement croissante (upchirp) ou dcroissante (downchirp) et linaire au cours du temps.
L'information est transmise par des dplacements de frquence, on peut donc faire le rapprochement
entre LoRa et une modulation par dplacement de frquence multiple (multiple frequency-shift
keying MFSK). Comme il y a talement de spectre, cela rend la transmission trs rsistante aux
interfrences tout en restant peu gourmande en nergie. Cette modulation de frquence est
typiquement utilise par les Radars. La frquence est gnralement tendue sur une bande passante
de 125 kHz 500 kHz. La robustesse du signal est vitale pour les technologies mettant dans les
bandes industrielles, scientifiques et mdicales (ISM) qui sont utilises par plusieurs services et
donc trs bruyantes . En Europe, la bande de fonctionnement de LoRa est 868MHz. On peut
galement communiquer sur les bandes 915MHz et 433MHz.
Encodage
Le coding rate (CR) dfinit le ratio de bits utile servant effectivement au transport
d'information par rapport au nombre de bits de dtection et de correction d'erreur. Cette valeur varie
entre 1 et 4 et indique le nombre de frquences sur lesquelles la modulation peut se dplacer .
L'ensemble du CR et de la bande passante (bandwidth BW) est appel datarate. Grce un tel
signal on peut transmettre entre 7 et 12 bits par symbole, ce nombre est appel spreading factor
(SF).

En modulant ces paramtres qui sont interdpendants, on peut optimiser la modulation pour
une utilisation particulire de LoRa. Si la communication ncessite un fort dbit, on privilgiera un
SF faible. On aura donc un chirp moins tal, plus rapide et moins rsistant aux perturbations (faible
distance) mais avec un dbit plus grand. Ci-dessous on voit l'influence du SF sur l'allure du chirp. Il
est commun de varier dynamiquement ces paramtres pour s'adapter en temps rel aux conditions
d'mission.

Illustration 3: Influence du spreading factor sur lallure du chirp

Exemple avec un cas commun, pour une bande passante de 125 kHz, SF = 8 et CR = 4 :
BitRate = 3904 bits/sec BitPerSymbol = 4 bit/symbole
= 488 octets/sec 2 16 frquences de shift
 Avant de transmettre les symboles, LoRa dcrit 2 tapes principales :
Le signal est conjugu avec une squence de bruit blanc dfinie pour ajouter de l'entropie
(whitening)
Entrelacement entre les bits utiles et les bits de correction/ dtection derreur (interleaving
& error coding)

Illustration 4: tapes de modulation et dmodulation

La modulation LoRa permet de capter des signaux mis mme quand le rapport signal
bruit est infrieur 1. On peut par exemple tablir une communication mme avec un rapport signal
bruit de -20dB avec un SF de 12.

Illustration 5: Couche MAC et couche de modulation

Rtro-ingnierie
Lingnieur Matt Knight a ralis une analyse du protocole physique LoRa par rtro-
ingnierie. En partant du signal brut transmis, il explique chaque tape de la modulation en la
confrontant la documentation fournie par Semtech. La premire tape consiste capter un
message transmis et analyser grossirement l'allure du signal (modulation, chirp, prambule du
message). La figure ci-dessous montre l'volution de la frquence (abscisse) et de l'amplitude (cote)
en fonction du temps (ordonne) d'un signal LoRa. On y voit les discontinuits provoques par les
changements de frquence.

Illustration 6: Spectre frquentiel dune communication LoRa

 Ensuite nous pouvons ramener l'tude du signal ltude d'une MFSK en combinant le
message transmis avec des chirps opposs.

Illustration 7: Saut de frquence LoRa

On peut voir sur le graphe ci-dessus le signal original gauche, le signal conjugu avec des
upchirps ensuite, et droite le signal conjugu avec des downchirps. Les pentes des chirps se
compensent et laissent apparatre des constantes. Ces constantes indiquent les sauts de frquences et
contiennent linformation (symboles). Le prambule est une srie de downchirps suivit de 2
upchirps qui servent la synchronisation. Nous sommes ici en prsence d'un SF valant 8 et d'un CR
valant 4 d'o les symboles cods sur 16 frquences.

Ensuite se pose la question de ce que reprsentent ces symboles. En effet ici le message
transmis subit les tapes de whitening et d'entrelacement. Lors de l'tape de whitening, le message
subit un XOR avec une matrice alatoire connue de toutes les radios LoRa. En passant un message
rempli de 0 on retrouve donc exactement cette matrice alatoire.
Couche transport LoRaWAN
Gnralits
LoRaWAN (Long Range Wide Area Network) est la couche de contrle d'accs au support
(media access control MAC) pour le protocole LoRa. La spcification de la premire version a t
publie en janvier 2015 et une nouvelle version est en cours d'laboration.

On distingue dans cette partie les end-device (capteur) de la gateway (agrgateur). Les end-
devices sont classs en fonction de leur comportement. Nous allons principalement tudier le
protocole avec des metteurs de classe A.

Illustration 8: Classe dmetteur LoRa

Pour grer les diffrentes parties d'une communication au niveau de la couche MAC,
LINSEE 802.15.4 spcifie trois parties :

MCPS MAC Common Part Sublayer

Fonctions dactivation, accus de rceptions
MLME MAC layer Management Entity
Fonctions dintgrit
MIB MAC Information Base
Cl de chiffrement, taux dencodage, adresses

Illustration 9: Sous-couches MAC

 LoRaWAN est compatible avec plusieurs options mais peu sont obligatoires. Le chiffrement
de bout en bout par exemple est support et recommand mais aucunement obligatoire. On peut
galement citer d'autres fonctionnalits comme l'adaptation automatique du taux d'change de
donnes, adaptation dynamique du SF. De manire native, les end-device changent
automatiquement de canal dans la bande ISM donnes pour tre plus robuste aux interfrences.
Dans la bande des 868MHz par exemple, LoRaWAN dcrit 3 canaux minimum. Toujours dans
cette bande, il faut faire attention aux contraintes sur le temps d'mission qui est rglement et qui
ne doit pas dpasser 1 % pour les end-devices.

Structure des paquets

Voici la structure gnrale dun paquet LoRaWAN dcrite dans la spcification officielle :

Illustration 10: Structure de paquets LoRaWAN

Processus dauthentification et dactivation
Avant de communiquer, tous les end-devices doivent tre authentifis et activs au sein d'un
rseau. Il existe deux mthodes pour cela. La premire consiste authentifier et activer
manuellement tous les end-devices ainsi que configurer le serveur qui va traiter la demande
(network server). La deuxime et la plus pratique est celle dite -la-vole (On-The-Air
Activation) qui va authentifier et activer automatiquement l'end-device. Sur un rseau de taille
rduite, le serveur peut tre associ la gateway (Raspberry Pi avec un module LoRa par exemple).
Cette procdure a pour but de gnrer sur l'end-device et sur le serveur une paire de cl pour chiffrer
tout futur message. videmment, les cls ou les lments servant les gnrer ne doivent pas tre
compromis pendant la procdure.

Au pralable il est ncessaire de prparer le device en lui renseignant :

Un identifiant global unique (DevEUI)
Un identifiant global dapplication (AppEUI)
Une cl AES-128 unique pour chaque device (AppKey)

Le serveur auquel le device fait sa demande possde au pralable les informations suivantes :
LAppKey du device
Un identifiant global unique de rseau (NwkID)
Une adresse rseau libre fournir au device (NwkAddr)

Seulement alors peut commencer le processus d'authentification et d'activation la vole.

Un premier paquet, la demande, est mis en clair sur des canaux par dfaut par le device. Le
message est envoy en clair mais un code d'intgrit du message (Message Integrity Code MIC)
est calcul pour signer le paquet. Il permettra d'authentifier cette demande et de garantir la
lgitimit de celle-ci auprs du serveur. Un nonce est un code utilisable qu'une seule fois.
Uniquement si toutes les informations sont correctes, le serveur lui rpond par un message
join_accept.

la fin de la procdure, grce aux champs NetID et DevAddr, l'end-device possde les
informations ncessaires pour communiquer au sein du rseau. En effet les informations reues
permettent de driver une paire de cls partir de l'AppKey. L'AppSKey chiffre le message alors
que la NwkSKey sert calculer le MIC.

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)

AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
 Voici en dtail les changes lors dune telle procdure.

End-device
Envoi un join_request contenant un nonce alatoire, sign par lAppKey

Illustration 11: Paquet join_request

Network Server
Vrifie que le nonce n'a jamais t utilis
Gnre et compare le MIC
Vrifie les identifiants du device et de lapplication
Gnre un nouveau nonce alatoire
Envoi un join_accept sign et chiffr par lAppKey contenant ce nonce
Gnre la paire de cls (NwkSKey, AppSKey)

Illustration 12: Paquet join_accept

End-device
Vrifie le MIC
Dchiffre le join_accept avec lAppKey
Gnre la paire de cls (NwkSKey, AppSKey) avec les informations du join_accept
La scurit de LoRaWAN

Risques internes
Chiffrement des paquets
La scurit de LoRa se repose en grande partie sur le triplet de cls voqu prcdemment.
Si on dsigne par oprateur un fournisseur qui possde la gateway et le network server, voici la
porte thorique de ces cls :
AppKey est connue du client uniquement
AppSKey est connue uniquement du client
NwkSKey est connue du client et de loprateur

Illustration 13: Utilisation des cls

Les deux cls de sessions sont utilises ensuite comme dcrit dans la figure ci-dessus. Le
chiffrement avec l'AppSKey contient un dsavantage majeur : il ne change pas l la taille du
message envoy. En effet, voici le message utile (payload) est dabord dcoup en bloc de 16bits.
Ensuite une matrice de chiffrement est labor pour chacun des blocs puis une opration XOR
entre le message et l'ensemble de ces matrices est effectu.

Lunicit de la matrice de chiffrement est entre autre garantie par l'utilisation lors de la
gnration de la matrice du compteur de message (nonce) et de l'indice du bloc. Ceci vite le rejeu.
Il est alors possible de distinguer les messages en fonction de leur longueur, ce qui peut se rvler
utile si les messages sont assez rptitifs.
End-device de classe B et C
Dans certains cas, l'end-device peut tre configur pour couter la gateway. Dans ce cas-
l dautres enjeux apparaissent. En effet la tentation d'effectuer un message multi-cast est grande,
pour divulguer rapidement une commande MAC de la gateway vers tous les objets connects. Mais
diffuser de tels messages de faon scurise n'est tout simplement pas prvu par le protocole. La
spcification prtend supporter cette fonction mais le problme est vident : comment authentifier le
message si tous les end-device ont une cl NwkSKey diffrente ? En effet les messages MAC sont
forcment chiffrs par le network server avec NwkSKey, la seule cl qu'il est cens possder. La
communication ne peut donc pas tre nativement multi-cast et scurise.

Illustration 14: Balise mise par une gateway Beacon

De mme pour les gateway qui diffusent en clair un timestamp et leurs coordonnes GPS,
cela introduit de nouvelles problmatiques. Les coordonnes sont videmment des informations
prcieuses pour mener vers les gateways elle-mmes. Des comportements de bords peuvent aussi
tre tudis en diffusant malicieusement des timestamp extrmes (1 janvier 1970, ou 19 janvier
2038, etc.).
Performances
Pour un end-device de classe A, la rgle d'mission est similaire au protocole ALOHA dans
sa premire version (pure ALOHA). Il nexiste aucune coute avant mission, aucune gestion de
collision de message et on rmet priodiquement le message jusqu' bonne rception. La
transmission n'est donc pas optimise. La consquence directe est qu'un parc d'objets connects
consquent cre un environnement dense dans lequel il est difficile de communiquer. Le chercheur
Maarten Weyn analys les pertes de paquets dans des conditions optimales selon les lgislations
europennes (contrainte de puissance, de temps d'mission continue, etc.). Le graphe ci-dessous
reprsente le nombre de collision de paquet et le taux d'erreur d'un paquet. Pour une centaine d'end-
device qui mettent la mme minute, on atteint dj les 10 % d'erreur dans le paquet transmis.

Illustration 15: Collision de paquet pour 1000 end-devices

L'effet pernicieux est que plus le facteur d'talement (SF) est lev, plus le signal sera
transmis loin (rsistance aux interfrences) mais plus le risque de collision et dchec de
transmission est lev. Le compromis est difficile trouver. Le protocole LoRaWAN prend aussi en
compte la limite de cycle d'mission pour respecter la lgislation europenne. Ceci implique que
pour respecter la spcification du protocole le maximum de transmission continue pour un end-
device est de 36 secondes toutes les heures.
Risques externes
Implmentation
Le protocole prvoit des scurits mais libre celui qui l'implmente d'adapter l'architecture
son utilisation et son matriel. Au vu du faible des cots des capteurs, une forte population non
sensibilis la scurit peut dployer son propre matriel. Les risques qui en dcoulent sont trs
nombreux sur les rseaux ouverts comme The Things Network. La meilleure solution actuelle pour
ce rseau est de ne pas chiffrer le trafic et d'avertir qu'aucune garantie n'est fournie. La cl
NwkSKey de ce rseau par exemple tait pendant longtemps publie sur leur site. Ceci reprsentait
un risque norme puisque les messages de contrles d'accs au mdia sont uniquement chiffrs en
utilisant cette cl. On pouvait donc trs facilement se faire passer pour une gateway du rseau et
causer d'normes dgts (changement des frquences utilises, changement des fentres d'coute,
etc.). Plus globalement, aucune implmentation open source d'un network server respectant la
spcification LoRaWAN n'est disponible.

La recommandation principale de scurit est d'utiliser une cl dapplication unique pour

chaque end-device. Ainsi la compromission d'une seule cl ne remet pas en cause la scurit de tout
le parc d'objets connects. De nouveaux risques apparaissent de la gnration de ces nombreuses
cls et de leur transfert vers l'end-device. Cela dpasse le cadre de notre tude mais la solution
encore une fois adopte par de nombreux oprateurs est de gnrer eux-mmes l'AppKey.

On peut galement citer les attaques par side-channel. Le faible cot des end-device l aussi
ne pousse pas investir dans la prvention des risques lis ces attaques. Trs souvent les solutions
hardware sont des systmes simples sans protection de mmoire et des ports srie encore actifs. Il
faut videmment relativiser la compromission d'un seul capteur sur un parc de potentiellement
plusieurs milliers. Les gateways ont cependant un impact bien plus grand. Le cot dune telle
attaque semble assez dissuasifs pour ne pas proccuper les oprateurs.

Une autre faille rside dans la couche applicative. Si un oprateur fournit une interface pour
remonter les valeurs des end-devices, toute l'infrastructure est sensible aux attaques dj bien
connues (XSS, injection, Man in the Middle, etc.). La base de donnes, le serveur web, l'interface
utilisateur ou tout autres lments en faade dinternets sont autant d'lments qui doivent tre
robustes. Une chane est aussi solide que son maillon le plus faible. Le protocole souvent utilis
pour remonter l'information l'heure actuelle est MQTT (Message Queue Telemetry Transport). La
mise en place de ce protocole souffre souvent d'une scurit nglige.
 Lalgorithme de chiffrement AES-128 est trs robuste. Par exemple, les documents classifis
et secrets amricains peuvent tre chiffrs par cette mthode. La meilleure attaque purement
algorithmique (force brute) actuelle utilise 9 ptaoctets de stockage et quelques milliards d'annes.
L'change de cl cependant est par contre beaucoup moins scuris. L'utilisation de l'AES-128-ECB
semble non justifie par rapport un chiffrement par cipher-block chain (CBC).
Rle de loprateur
Le primtre des trois cls LoRaWAN doit tre bien dfini. La plupart des oprateurs, si ce
n'est tous, possde les network servers qui stockent les trois cls. La confiance dans la scurit du
protocole LoRa est donc limite par la confiance dans son oprateur. Orange confirme par exemple
dans son guide du dveloppeur LoRaWAN que leur serveur gnre et stock la paire de cl NwkSKey
et AppSKey. L'oprateur a donc toutes les informations ncessaires pour chiffrer et dchiffrer la
communication dun client.

Compared to some other systems which rely on a single key for authentication and
encryption, the LoRaWAN framework separates authentication and encryption, so that
Orange is able to authenticate packets and provide integrity protection. [...] The
AppSKey and NwkSKey are stored by Orange for regulatory and security reasons.

Comme les cls sont des donnes sensibles, on peut imaginer que stocker ces informations
sur des serveurs scuriss chez l'oprateur plutt que chez le client est effectivement une mesure de
scurit. Une autre conception cependant serait de dlguer la gnration des cls entirement au
client et de renseigner l'oprateur avec uniquement la cl le concernant : NwkSKey. Le compromis
qu'a imagin Gemalto est de relayer la gnration des cls un tiers de confiance :

Illustration 16: Utilisation dun tiers de confiance

La requte join_request est transfre au tiers de confiance. Les cls sont alors gnres sans
que l'oprateur ne connaisse ni la cl AppKey ni la cl AppSKey.
Analyse de consommation
La problmatique de dure d'autonomie de l'end-device est souvent montre comme trs
avantageuse avec le protocole LoRa. Il faut cependant garder en tte certains aspects qui peuvent
drastiquement diminuer la dure de vie de la batterie.

Dans certains cas, les communications exigent des accuss de rception. Deux fentres
d'coute peuvent tre alors ouvertes des dlais prcis pour recevoir cet accus. Or comme vu
prcdemment lorsqu'on atteint une densit consquente d'end-devices, la seule solution est
d'mettre jusqu' bonne rception ou jusqu' un nombre limite autoris. En regardant de plus prs la
consommation nergtique de la radio lors de l'mission on peut dresser le bilan d'une tentative de
communication. Le schma ci-dessous illustre l'mission d'un premier message (data0). Aprs non-
rception de l'accus, re-transmission. Enfin un deuxime message (data1) est transmis
correctement

Illustration 17: Transmission de 2 paquets, avec chec du premier

 Pour la puissance l'mission nous
avons sans surprise la plus grosse
consommation nergtique avec 364 mW de
puissance moyenne pendant 61 ms. La dure
dmission est videmment fonction des
paramtres choisis tel que le SF, le CR ou
encore la bande passante.

Illustration 18: Puissance consomme pour une

fentre dmission

Pour la premire fentre de rception, nous

avons 36 mW de puissance moyenne pendant
10 ms. Cette fentre est volontairement courte
car dans des conditions idale de rception
laccus de rception ne doit pas avoir une
empreinte nergtique trop grande.

Illustration 19: Puissance consomme pour une

fentre de rception n1

linverse, la deuxime fentre dcoute est

plus grande. Ceci est logique puisque si la
premire rception n'a pas t fructueuse, il faut
prendre en compte un facteur d'erreur. Un
exemple commun est une dsynchronisation des
horloges entre lend-device et la gateway. Il est
donc ncessaire d'avoir un temps d'coute plus
long. Nous avons une consommation de 36 mW
de puissance moyenne pendant 164 ms.

Illustration 20: Puissance consomme pour une

fentre de rception n2
 Rcapitulatif des risques

Illustration 21: Rcapitulatif des risques

Conclusion
Ce projet a t une excellente occasion de dcouvrir le monde de l'internet des objets. Ce
domaine plein d'avenir a l'avantage de concerner directement la formation IMA de Polytech Lille.
La richesse se trouve notamment dans la combinaison de l'aspect purement physique (modulation,
transmission radio) et de l'aspect protocolaire de la couche MAC. Aprs une premire apprhension
du ct thorique du sujet, cette richesse m'a finalement sduit.

Les objectifs ont t remplis puisqu'un tat de l'art sur le protocole LoRa et son protocole
associ LoRaWAN a t ralis. Cependant, comme LoRa subit rgulirement des amliorations par
sa communaut trs active, il faut garder l'esprit que les informations rassembles ici peuvent
devenir dsutes. Une rflexion sur les diffrents aspects de scurit a galement t mene a bien.
Bien que non exhaustive, la liste des menaces donne de solides bases la comprhension de la
scurit du protocole.