IMA4 2016/2017 P33 : Différence entre versions

De Wiki de Projets IMA
(→‎Objectif)
(→‎Feuille d'heures)
 
(60 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 9 : Ligne 9 :
 
===Description du projet===
 
===Description du projet===
  
−
Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau . Une fois la maquette prête , nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames .  
+
Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames.  
−
Pour tester les attaques de type man in the middle,ie introduire des trames dans le réseau , nous allons créer des trames et les faire accepter par le réseau.
+
Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.
  
 
===Choix techniques : matériel et logiciel===
 
===Choix techniques : matériel et logiciel===
 +
'''Fonction principale:'''
 +
 +
Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.
 +
 +
'''Sous-fonction 1:'''
 +
 +
 +
'''Sous-fonction 1:'''
 +
Effectuer la communication entre les modules LoRa:
 +
 +
Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.
 +
 +
[[Fichier:pt1.png]]
 +
 +
Sous-fonction 2:
 +
on récupère le signal  avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.
 +
 +
 +
[[Fichier:pt2.png]]
 +
 +
'''
 +
Sous-fonction 3:'''
 +
 +
A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa .
 +
Pour l’interception , en fonction de la trame que  recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.
  
 
===Calendrier prévisionnel===
 
===Calendrier prévisionnel===
  
 
====Liste des tâches à effectuer====
 
====Liste des tâches à effectuer====
 +
 +
'''Tâche 1''': Etablir la communication entre deux modules LoRa.<br>
 +
'''Tâche 2''' :Visualiser sur l'analyseur de spectre le signal émis  .<br>
 +
'''Tâche 3''': .Prise en main du format du protocole LoRa<br>
 +
'''Tâche 4''' : Ecrire un paquet LoRa  et le faire accepter par un module LoRa .<br>
  
 
====Calendrier====
 
====Calendrier====
Ligne 24 : Ligne 54 :
 
{| class="wikitable"
 
{| class="wikitable"
 
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
 
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
 +
|-             
 +
| Définition cahier des charges
 +
|4h
 +
|6h
 +
|6h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|16h
 
|-
 
|-
−
| Définition cahier des charges
+
|Découverte Feather + documentation LoRa
−
| 0
+
|
−
|  
+
|
 +
|
 +
|4h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|4h
 +
|-
 +
|Tache1 : 1ere communication 2 feather
 +
|
 +
|
 +
|
 +
|
 +
|6h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|6h
 +
|-
 +
|Test RSSI + mesures sur le spectre visualisé
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|8h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|8h
 +
|-
 +
|Modification code émission+ réception
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|8h
 +
|
 +
|
 +
|
 +
|
 +
|8h
 +
|-
 +
|Plan de mesures
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|8h
 +
|8h
 +
|
 +
|
 +
|16h
 +
|-
 +
|Mesures
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|8h
 +
|8h
 +
|16h
 +
|-
 +
|
 +
|
 
|
 
|
 
|
 
|
Ligne 38 : Ligne 165 :
 
|
 
|
 
|
 
|
 +
|74h
 
|}
 
|}
 +
<br>
  
 
==Avancement du Projet==
 
==Avancement du Projet==
  
 
===Semaine 1===
 
===Semaine 1===
 +
Définition du cahier des charges et prise en main du protocole LoRa
 +
 +
===Semaine 2===
 +
 +
Suite du cahier des charges
 +
 +
===Semaine 3===
 +
 +
-Découverte du Feather <br>
 +
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa.<br>
 +
 +
===Semaine 4===
 +
 +
Tache 1 réalisée:<br>
 +
#Installation des librairies Adafruit (Sur deux machines pour emission/Reception)<br>
 +
#Test  des codes Emission/Réception proposés par la datasheet.<br>
 +
#Communication réalisée entre deux modules LoRa .<br>
 +
 +
 +
====Emission====
 +
[[Fichier:femission.png]]
 +
 +
 +
 +
====Réception====
 +
 +
[[Fichier:freception.png]]
 +
 +
===Semaine 5===
 +
 +
Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.
 +
 +
[[Fichier:mont3.jpg|500px|down|Montage 3 module LoRa : 1 émetteur & 2 récepteurs]]
 +
 +
 +
 +
On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .
 +
 +
 +
[[Fichier:rssi1.png]]
 +
 +
 +
[[Fichier:rssi2.png]]
 +
 +
 +
 +
1ere séance de mesures :
 +
 +
On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre . <br>
 +
 +
[[Fichier:fr434.jpg|500px|down]]
 +
 +
On mesure pour la fréquence '''434MHz''':
 +
 +
'''le rapport signal sur bruit SNR '''
 +
 +
le rapport SNR donne une valeur de : 13 dBm
 +
[[Fichier:cn.jpg|500px|down|]]
 +
 +
La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .
 +
 +
===Semaine 6 ===
 +
 +
Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)
 +
 +
(voir codes : fichier rendus).
 +
 +
===Semaine 7 et 8 ===
 +
 +
Plan de mesures (voir fichiers rendus en bas de la page).
 +
 +
===Semaine 9 et 10 ===
 +
 +
Mesures :
 +
 +
Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .
 +
 +
Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :
 +
 +
 +
'''Emission :'''  [[Fichier:Emission_patch.jpg|500px|down|]]
 +
 +
 +
 +
'''Reception: ''' [[Fichier:Reception_patch.jpg|500px|down|]]
 +
 +
Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal.
 +
On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) . <br>
 +
 +
Le cas était aussi pour le signal de reception , mais qui est modulé en AM .
 +
 +
Cette "déformation" des signaux  est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz).<br>
 +
 +
''''''Solution'''''' <br>
 +
 +
En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu :<br>
 +
 +
[[Fichier:Lora_frame.jpg|500px|down|]] <br>
 +
On peut remarquer la présence de deux trames , une correspond à la première émission et l’autre au retour amis par le module récepteur . <br>
 +
 +
Le signal d’en bas qui est un zoom de la trame , nous montre les chirps qu’on devrait avoir . En se basant sur la méthode suivant , on pourra décoder ce signal . <br>
 +
 +
 +
Le but est d’avoir la taille minimale possible pour rendre plus facile le parcours de la trame .
 +
Il faut d’abord penser à changer la bande passante et passer de 125 KHz à  8 KHz. <br>
 +
 +
 +
'''Preamble : '''
 +
Comme la taille du préambule n’affecte pas la transmission , on peut donc la réduire au minimum configurable qui est  6 avec la fonction setPreambleLength . Ce qui nous fera 10 symboles pour le preambule . Il faudra donc trouver 10 sauts de phases. <br>
 +
 +
'''Header : '''
 +
En choisissant le mode SF=6 on force l’utilisation du mode implicit tout en réduisant également le nombre de chips par symbole:65 chips/symbol au lieu de 128 . <br>
 +
 +
'''Payload :'''
 +
 +
En utilisant maintenant SF= 6 , on envoie donc 6 char ( 111111 par exemple) et on s’attend à avoir 8 sauts de phase et 8*65 chirps ce qui donne 520 chirps pour le payload  qui reste quand même beaucoup à compter pour s’en assurer  . On se basera donc uniquement sur le comptage de sauts pour compter 8 symboles. Il faut noter que la taille max du payload est de 251 bits , même si on envoie que 6 bits de 1 le reste est mis à 0 . Cette taille peut être réduite en utilisant une bande passante plus petite <br>
 +
 +
'''CRC : '''
 +
Comme on utilise le mode implicite , on n’est donc pas sur d’avoir un CRC , on vérifiera la présence de ce dernier sachant qu’il a une taille de 16 bits ce qui vaut 3 symboles à peu près . <br>
 +
 +
== Fichiers Rendus ==
 +
 +
[[Fichier:Plandemesures.pdf]]
  
−
== Fichiers Rendus ==
+
[[Fichier:Rapportprojet33.pdf]]

Version actuelle datée du 18 mai 2017 à 12:34

Présentation du projet

Contexte

Les objets connectés se font une place dans le quotidien et se déploient de plus en plus mais en ce qui concerne leur sécurité, il apparaît que les fabricants ont souvent négligé la sécurité des technologies et de les protéger contre les cyberattaques. Afin de tester la sécurité des réseaux utilisés dans les objets connectés, nous étudierons le fonctionnement de ces protocoles. Dans le cadre de ce projet nous nous intéresserons aux protocoles LoRa et SigFox.

Objectif

L'objectif est donc de réaliser l'écoute de trame d'un réseau sans-fil (LoRa et SigFox) en capturant des trames afin de comprendre le fonctionnement de ces protocoles, et déterminer le format des trames ainsi que des méthodes d'attaque du réseau. C'est ce qu'on appelle l'ingénierie inverse.

Description du projet

Pour comprendre le fonctionnement du protocole, nous mettrons en place une maquette contenant des émetteurs et récepteurs afin d'écouter les trames dans le réseau. Une fois la maquette prête, nous mettrons en place une méthode d'écoute des trames et des captures de trames par un analyseur de spectre pour ensuite décoder ces trames. Pour tester les attaques de type man in the middle, ie introduire des trames dans le réseau, nous allons créer des trames et les faire accepter par le réseau.

Choix techniques : matériel et logiciel

Fonction principale:

Ingénierie inverse : Pouvoir injecter des trames “écrites à la main” entre l'émetteur/récepteur LoRa.

Sous-fonction 1:


Sous-fonction 1: Effectuer la communication entre les modules LoRa:

Pour etablir la communication on utilisera deux Arduino qui serviront à controler l’emission et la reception des données ainsi que les messages à transmettre.

Pt1.png

Sous-fonction 2: on récupère le signal avec un analyseur de spectre pour pouvoir “décoder” le paquet LoRa.


Pt2.png

Sous-fonction 3:

A partir du paquet “décodé” , écrire un autre paquet pour l’envoyer à un récepteur LoRa . Pour l’interception , en fonction de la trame que recoit les modules LoRa , on décidera la méthode avec laquelle on intercepte la communication afin d’envoyer des trames “ecrites à la main”.

Calendrier prévisionnel

Liste des tâches à effectuer

Tâche 1: Etablir la communication entre deux modules LoRa.
Tâche 2 :Visualiser sur l'analyseur de spectre le signal émis .
Tâche 3: .Prise en main du format du protocole LoRa
Tâche 4 : Ecrire un paquet LoRa et le faire accepter par un module LoRa .

Calendrier

Feuille d'heures

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 Total
Définition cahier des charges 4h 6h 6h 16h
Découverte Feather + documentation LoRa 4h 4h
Tache1 : 1ere communication 2 feather 6h 6h
Test RSSI + mesures sur le spectre visualisé 8h 8h
Modification code émission+ réception 8h 8h
Plan de mesures 8h 8h 16h
Mesures 8h 8h 16h
74h


Avancement du Projet

Semaine 1

Définition du cahier des charges et prise en main du protocole LoRa

Semaine 2

Suite du cahier des charges

Semaine 3

-Découverte du Feather
-Etude sur le protocole LoRa et distinction entre Réseau (LoRaWAN) et le protocole LoRa.

Semaine 4

Tache 1 réalisée:

  1. Installation des librairies Adafruit (Sur deux machines pour emission/Reception)
  2. Test des codes Emission/Réception proposés par la datasheet.
  3. Communication réalisée entre deux modules LoRa .


Emission

Femission.png


Réception

Freception.png

Semaine 5

Après avoir effectué la communication entre deux modules LoRa , on ajoute un troisième module comme étant récepteur pour voir les changement dus à la présence d'un ou d'autres récepteurs.

Montage 3 module LoRa : 1 émetteur & 2 récepteurs


On remarque que le RSSI (Received Signal Strength Indication) ne change quasiment pas (entre |21| et |19|) . On peut conclure que la présence de plusieurs récepteurs n'affecte pas la puissance du signal transmis .


Rssi1.png


Rssi2.png


1ere séance de mesures :

On réalise la communication LoRa entre les modules et on visualise le signal transmis avec une antenne PATCH connectée à un analyseur de spectre .

down

On mesure pour la fréquence 434MHz:

le rapport signal sur bruit SNR

le rapport SNR donne une valeur de : 13 dBm Cn.jpg

La puissance du signal est égale à 13 dBm . Ce résulat est identique à la puissance définit par défaut .

Semaine 6

Modification des codes d'émission et de réception : Envoyer des 1 ou des 0 au lieu du message "Hello word" ; Répondre par ce qu'on reçoit (Ping-pong)

(voir codes : fichier rendus).

Semaine 7 et 8

Plan de mesures (voir fichiers rendus en bas de la page).

Semaine 9 et 10

Mesures :

Pour visualiser le signal dans l'air , j'ai utilisé une antenne patch , en mettant tantot le module d'emission tantot le module de reception sur cette dernière .

Sur un oscilloscope 1GHz , j'ai pu visualisé les signaux suivants :


Emission : Emission patch.jpg


Reception: Reception patch.jpg

Commentaires : Le signal d'émission visualisé en haut (c1) est la trame qu'on reçoit ; celui d'en-bas (F1) n'est qu'un zoom qui nous permet de voir la forme de ce signal. On remarque qu'on a signal modulé en QPSK d'où le saut de phase . Cette forme ne correspond pas à la modulation LoRa qui est en chirp Spread Spectrum (CSS) (Cf. datasheet AN1200.22 LoRa™ Modulation) .

Le cas était aussi pour le signal de reception , mais qui est modulé en AM .

Cette "déformation" des signaux est due à l'utilisation de l'antenne patch (800MHz) qui n'est pas adapté à notre antenne (434MHz).

'Solution'

En évitant de passer par l’antenne patch , et en connectant directement l’antenne du module d'émission ( fil + GND) à l’oscilloscope via un câble coaxial , j’ai pu visualiser le signal prévu :

Lora frame.jpg
On peut remarquer la présence de deux trames , une correspond à la première émission et l’autre au retour amis par le module récepteur .

Le signal d’en bas qui est un zoom de la trame , nous montre les chirps qu’on devrait avoir . En se basant sur la méthode suivant , on pourra décoder ce signal .


Le but est d’avoir la taille minimale possible pour rendre plus facile le parcours de la trame . Il faut d’abord penser à changer la bande passante et passer de 125 KHz à 8 KHz.


Preamble : Comme la taille du préambule n’affecte pas la transmission , on peut donc la réduire au minimum configurable qui est 6 avec la fonction setPreambleLength . Ce qui nous fera 10 symboles pour le preambule . Il faudra donc trouver 10 sauts de phases.

Header : En choisissant le mode SF=6 on force l’utilisation du mode implicit tout en réduisant également le nombre de chips par symbole:65 chips/symbol au lieu de 128 .

Payload :

En utilisant maintenant SF= 6 , on envoie donc 6 char ( 111111 par exemple) et on s’attend à avoir 8 sauts de phase et 8*65 chirps ce qui donne 520 chirps pour le payload qui reste quand même beaucoup à compter pour s’en assurer . On se basera donc uniquement sur le comptage de sauts pour compter 8 symboles. Il faut noter que la taille max du payload est de 251 bits , même si on envoie que 6 bits de 1 le reste est mis à 0 . Cette taille peut être réduite en utilisant une bande passante plus petite

CRC : Comme on utilise le mode implicite , on n’est donc pas sur d’avoir un CRC , on vérifiera la présence de ce dernier sachant qu’il a une taille de 16 bits ce qui vaut 3 symboles à peu près .

Fichiers Rendus

Fichier:Plandemesures.pdf

Fichier:Rapportprojet33.pdf

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2016/2017_P33&oldid=42459 »