P17 Sécurité de l'internet des objets : Différence entre versions
(→Semaine 30 Jan 2017) |
(→Avancée du projet) |
||
| Ligne 82 : | Ligne 82 : | ||
Matt Knight full reverse-engineering | Matt Knight full reverse-engineering | ||
https://github.com/matt-knight/research/tree/master/2016_12_29_ccc-33c3 | https://github.com/matt-knight/research/tree/master/2016_12_29_ccc-33c3 | ||
| + | |||
| + | Ceci m'a permis d'avoir une première prise en main du protocole et de son inscription dans le marché concurrentiel qu'est l'IoT. | ||
== Semaine 23 Jan 2017 == | == Semaine 23 Jan 2017 == | ||
| Ligne 98 : | Ligne 100 : | ||
== Semaine 30 Jan 2017 == | == Semaine 30 Jan 2017 == | ||
| − | + | '''USB2.0 != USB3.0''' | |
| − | [13966.109866] usb 3-9: new full-speed USB device number 22 using xhci_hcd | + | |
| + | Voici le détail et et la résolution du problème USB2.0 / USB3.0. Le module noyau en charge d'allouer les terminaux tty détachait régulièrement (toutes les 3 à 5 sec) le périphérique NUCLEO. Voici les messages de log du noyau : | ||
| + | [13966.109866] usb 3-9: new full-speed USB device number 22 using '''xhci_hcd''' | ||
[13966.239940] usb 3-9: New USB device found, idVendor=0483, idProduct=374b | [13966.239940] usb 3-9: New USB device found, idVendor=0483, idProduct=374b | ||
[13966.239946] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3 | [13966.239946] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3 | ||
| Ligne 124 : | Ligne 128 : | ||
[14017.951574] usb 3-9: reset full-speed USB device number 22 using '''xhci_hcd''' | [14017.951574] usb 3-9: reset full-speed USB device number 22 using '''xhci_hcd''' | ||
| − | Lorsqu'on branche la carte programmable, le noyau la reconnaît bien et lui attribue un téléscripteur (ttyACMX). Cependant la dernière ligne | + | Lorsqu'on branche la carte programmable, le noyau la reconnaît bien et lui attribue un téléscripteur (ttyACMX). Cependant la dernière ligne indique que le module du noyau responsable de l'USB3.0 xhci_hcd a reset la connexion. La carte se reconnecte sous peu mais le problème est toujours le même. Lorsque la limite du nombre d'ACMX à allouer est atteinte (31) le module n'en n'alloue plus. |
[10095.392845] cdc_acm 3-1:1.2: '''no more free acm devices''' | [10095.392845] cdc_acm 3-1:1.2: '''no more free acm devices''' | ||
[10096.391780] scsi 12:0:0:0: Direct-Access MBED microcontroller 1.0 PQ: 0 ANSI: 2 | [10096.391780] scsi 12:0:0:0: Direct-Access MBED microcontroller 1.0 PQ: 0 ANSI: 2 | ||
[10096.392246] sd 12:0:0:0: Attached scsi generic sg2 type 0 | [10096.392246] sd 12:0:0:0: Attached scsi generic sg2 type 0 | ||
| − | + | Aucun soucis une fois passé sur un port USB2.0. C'est le module ehci_pci qui est alors utilisé. Il me semble possible de forcer l'utilisation de ce module sur un port USB donné. | |
| − | + | ||
| − | + | '''Test de l'émission LoRa ''' | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | Aucun soucis une fois passé sur un port USB2.0. | ||
J'ai pu ensuite rassembler les sources autour du protocole LoRaWAN et trier les sources officielles du code indépendant. Mbed possède un IDE en ligne qui permet d'écrire et de compiler rapidement du code pour les boards utilisées. Cependant, l'IDE n'est pas toujours explicite sur les erreurs de compilation. Parfois même on obtient une erreur interne sans aucun détail ou des timeout après plusieurs minutes de compilations. J'ai donc cloné mes projets localement et j'alterne entre différents environnements. L'IDE permet également de parcourir beaucoup plus facilement les librairies officielles de Semtech. | J'ai pu ensuite rassembler les sources autour du protocole LoRaWAN et trier les sources officielles du code indépendant. Mbed possède un IDE en ligne qui permet d'écrire et de compiler rapidement du code pour les boards utilisées. Cependant, l'IDE n'est pas toujours explicite sur les erreurs de compilation. Parfois même on obtient une erreur interne sans aucun détail ou des timeout après plusieurs minutes de compilations. J'ai donc cloné mes projets localement et j'alterne entre différents environnements. L'IDE permet également de parcourir beaucoup plus facilement les librairies officielles de Semtech. | ||
| − | [[Fichier:Lora_chirp.png|thumb|Spectre LoRa montrant les chirp|right| | + | [[Fichier:Lora_chirp.png|thumb|Spectre LoRa montrant les chirp|right|250px]] |
| − | [[Fichier:Lora_first_try.png|thumb| | + | [[Fichier:Lora_first_try.png|thumb|300px|Paquet join_request|left]] |
Le code d'un end-device s'intègre parfaitement sur la radio SX1276, prévue à cet effet. J'ai pu donc effectuer mes premiers essais d'émission. A gauche, on a le spectre observé à l'aide d'une radio logicielle pour les paramètres suivants : | Le code d'un end-device s'intègre parfaitement sur la radio SX1276, prévue à cet effet. J'ai pu donc effectuer mes premiers essais d'émission. A gauche, on a le spectre observé à l'aide d'une radio logicielle pour les paramètres suivants : | ||
Fréquence : 868.1MHz | Fréquence : 868.1MHz | ||
| Ligne 148 : | Ligne 147 : | ||
activation : On-The-Air Activation | activation : On-The-Air Activation | ||
| − | Ce paquet correspond à un join_request. Je n'ai pas réussis à contourner la procédure d'activation avec la procédure ABP (activation by personnalization) pour directement émettre des messages chiffrés. D'autres paramètres n'améliorent pas significativement la qualité visuelle du spectre. A droite est représenté [https://revspace.nl/DecodingLora un exemple] de spectre que l'on pourrait obtenir avec un radio de meilleure qualité | + | Ce paquet correspond à un join_request. Je n'ai pas réussis à contourner la procédure d'activation avec la procédure ABP (activation by personnalization) pour directement émettre des messages chiffrés. D'autres paramètres n'améliorent pas significativement la qualité visuelle du spectre. A droite est représenté [https://revspace.nl/DecodingLora un exemple] de spectre que l'on pourrait obtenir avec un radio de meilleure qualité. |
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
== Semaine 6 Feb 2017 == | == Semaine 6 Feb 2017 == | ||
| Ligne 154 : | Ligne 162 : | ||
Les modules LoRa SX125x et SX127x sont prévus pour être des end-devices au sein d'un réseau LoRa. Le dépot [https://github.com/Lora-net/ github officiel] de LoRaWAN distribue donc tout le code nécessaire pour des end-device avec ces radios. Cependant le code officiel fournis par Semtech pour une gateway n'est compatible (out of the box) qu'avec un chip SX1301. Je me suis donc renseigner sur les alternatives possibles et j'ai recherché du code existant qui se rapprochait le plus de ce que je voulais. Voici une liste non exhaustive des projets indépendants que j'ai trouvés : | Les modules LoRa SX125x et SX127x sont prévus pour être des end-devices au sein d'un réseau LoRa. Le dépot [https://github.com/Lora-net/ github officiel] de LoRaWAN distribue donc tout le code nécessaire pour des end-device avec ces radios. Cependant le code officiel fournis par Semtech pour une gateway n'est compatible (out of the box) qu'avec un chip SX1301. Je me suis donc renseigner sur les alternatives possibles et j'ai recherché du code existant qui se rapprochait le plus de ce que je voulais. Voici une liste non exhaustive des projets indépendants que j'ai trouvés : | ||
| − | |||
* [https://github.com/mirakonta/lora_gateway Adaptation] du code de la gateway pour une carte Multitech MTAC-LORA (MultiConnect mCard) | * [https://github.com/mirakonta/lora_gateway Adaptation] du code de la gateway pour une carte Multitech MTAC-LORA (MultiConnect mCard) | ||
* [https://github.com/maartenweyn/lpwansimulation/ Tests de charge LoRaWAN] par un chercheur belge, ainsi que la discussion autour de son travail [https://www.thethingsnetwork.org/forum/t/universal-lora-wan-gateway-limitations-because-physics/1749/2 sur the Things Network] | * [https://github.com/maartenweyn/lpwansimulation/ Tests de charge LoRaWAN] par un chercheur belge, ainsi que la discussion autour de son travail [https://www.thethingsnetwork.org/forum/t/universal-lora-wan-gateway-limitations-because-physics/1749/2 sur the Things Network] | ||
| Ligne 161 : | Ligne 168 : | ||
* [https://github.com/PiInTheSky/lora-gateway Autre gateway contrôlée par SPI] | * [https://github.com/PiInTheSky/lora-gateway Autre gateway contrôlée par SPI] | ||
* [https://github.com/brocaar/loraserver Implémentation non-officielle d'un network server] | * [https://github.com/brocaar/loraserver Implémentation non-officielle d'un network server] | ||
| − | |||
J'ai choisis de m'inspirer de ces exemples ainsi que des exemples et librairies officielles (Mbed & LoRaWAN) pour réaliser un premier programme simple pour tester la connectivité entre les deux radios. | J'ai choisis de m'inspirer de ces exemples ainsi que des exemples et librairies officielles (Mbed & LoRaWAN) pour réaliser un premier programme simple pour tester la connectivité entre les deux radios. | ||
| + | |||
| + | ''' Ping / Pong ''' | ||
| + | [[Fichier:lora_transmit_example.png|500px|thumb|Schéma des protocoles utilisés pour le ping/pong|right]] | ||
| + | Une carte programmable NUCLEO contrôle la puce LoRa SX1276 à travers une interface SPI. Une librairie existe déjà pour définir les constantes pour écrire / lire dans ces registres. J'ai donc ré-utilisé un exemple de communication entre deux radios LoRa pour rediriger les informations à travers une connexion série. Le schéma ci-dessous représente la maquette réalisée. | ||
| + | Ce programme écoute le trafic LoRa en boucle sur une fréquence spécifique, avec des paramètres très spécifiques (spreading factor, bande passante, taille de buffer ...). Dès que l'on reçoit une trame, on regarde le contenu (ping ou pong) et cela va dicter la réponse à envoyer, toujours selon les mêmes paramètres radios. | ||
| + | |||
| + | |||
| + | |||
| + | [[Fichier:Lora_ping_pong1.png|650px|left]] | ||
| + | Ce mode de dialogue volontairement simpliste donne les résultats suivants : | ||
| + | - On envoie un ping toutes les 3 secondes | ||
| + | - La seconde radio accuse la réception, et renvoie un pong | ||
| + | - Accusé de réception de la première radio, et renvoi toute de suite (10ms) d'un ping | ||
| + | - ... | ||
| + | Les messages onRxDone et onTxDone sont affichés à des fins de debug. | ||
| Ligne 171 : | Ligne 192 : | ||
| − | |||
| − | + | A l'aide d'une radio logicielle j'ai confirmation de l'échange entre les deux radios : | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | A l'aide d'une radio logicielle | ||
[[Fichier:Lora_ping_pong2.jpg.png|center|700px|thumb]] | [[Fichier:Lora_ping_pong2.jpg.png|center|700px|thumb]] | ||
La faible qualité de ma radio ne me permet pas de distinguer les chirps caractéristiques du protocole LoRa (échantillonnage limité). On y voit bien cependant les échanges de message. La fréquence est fixée à 867.1MHz et la bande passante est de 125kHz (spreading factor = 12). | La faible qualité de ma radio ne me permet pas de distinguer les chirps caractéristiques du protocole LoRa (échantillonnage limité). On y voit bien cependant les échanges de message. La fréquence est fixée à 867.1MHz et la bande passante est de 125kHz (spreading factor = 12). | ||
Version du 13 février 2017 à 16:13
Sommaire
Informations générales
Étudiants Jérémie Denéchaud
Tuteurs Alexandre Boé / Xavier Redon / Thomas Vantroys
Les fichiers sources du projet sont disponibles sur le Git de l'IRCICA
Présentation du projet
Objectifs
L'Internet des objets est un secteur en plein accroissement. De nouveaux objets connectés sont disponibles tous les jours. Cependant, cette rapidité de mise en oeuvre se fait souvent au détriment de la sécurité. Les objectifs de ce projet sont de :
- Effectuer un état de l'art sur les protocoles LoRa (Long Range) et LoRaWAN (Long Range Wide-area network ou Réseau étendu à longue portée)
- Concevoir et réaliser une plate-forme d'analyse et de tests du comportement d'objets connectés selon l'ANSSI.
Étapes du projet
- Étape 1 - Etat de l'art V1
- Prise en main des protocoles
- Description du fonctionnement global
Fichier:Etat Art LoRa V0.1.pdf
- Étape 2 - Etude des risques V1
- Détail du fonctionnement
- Revue des menaces
Fichier:Lora Scénarios Menace.pdf
- Étape 3 - LoRa ping-pong
- Implémenter sur les board NUCELO le protocole LoRa
- Faire communiquer les deux boards
- Pas de surcouche LoRaWAN
Étape 4 - Sniffeur LoRaWAN
- LoRaWAN officiel sur émetteur
- Récepteur générique pour sniffer tous les paquets
- Étape 5 - Implémentation processus OTA
- Implémenter OTA LoRaWAN officiel
- Gestion des clés, déchiffrer paquets
- Étape 6 -
Matériel
| Produit | Quantité |
|---|---|
| Capteur LoRa | 5 |
| Raspberry Pi | 1(2?) |
Avancée du projet
Semaine 16 Jan 2017
Prise de contact avec les tuteurs de projet. Définition des attentes et discussion sur le projet. Dans un premier temps, il est nécessaire de fournir un état de l'art sur la technologie LoRa et LoRaWAN. J'ai donc débuté la rédaction d'un document, en m'aidant des sources suivantes :
Référence 802.15.4: http://www.ieee802.org/15/pub/TG4.html
Guide du développeur et retour d'expérience d'Orange https://partner.orange.com/wp-content/uploads/2016/04/LoRa-Device-Developer-Guide-Orange.pdf
LoRa Application Note (quasiment le seul document technique sur la couche physique LoRa) http://www.semtech.com/images/datasheet/an1200.22.pdf
LoRaWAN Specifications (couche liaison) https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf
LoRa Design Guide https://www.semtech.com/images/datasheet/LoraDesignGuide_STD.pdf
Etudes déjà réalisées sur LoRa par reverse-engineering https://revspace.nl/DecodingLora
Matt Knight full reverse-engineering https://github.com/matt-knight/research/tree/master/2016_12_29_ccc-33c3
Ceci m'a permis d'avoir une première prise en main du protocole et de son inscription dans le marché concurrentiel qu'est l'IoT.
Semaine 23 Jan 2017
Réception du matériel :
- Deux émetteurs/récepteurs LoRa (mbed - SX1273MB1)
- Deux cartes programmables Nucleo (NUCLEO - F401RE)
Première version de l'état de l'art :
Fichier:Etat Art LoRa V0.1.pdf
J'ai commencé la rédaction d'une spécification technique autour de la sécurité des protocoles : limites, risques, menaces etc. Comme il est difficile de trouver des documentations assez précises et fiables, je me base sur le code source officiel : https://github.com/Lora-net
J'ai également commencé à prendre en main les boards programmables. Pour un hello-world basique à travers un port série par USB, j'ai rencontré quelques soucis de compatibilité (USB2.0 != USB3.0). Je programme et je compile dans l'IDE mbed prévu à cet effet.
Semaine 30 Jan 2017
USB2.0 != USB3.0
Voici le détail et et la résolution du problème USB2.0 / USB3.0. Le module noyau en charge d'allouer les terminaux tty détachait régulièrement (toutes les 3 à 5 sec) le périphérique NUCLEO. Voici les messages de log du noyau :
[13966.109866] usb 3-9: new full-speed USB device number 22 using xhci_hcd [13966.239940] usb 3-9: New USB device found, idVendor=0483, idProduct=374b [13966.239946] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [13966.239950] usb 3-9: Product: STM32 STLink [13966.239952] usb 3-9: Manufacturer: STMicroelectronics [13966.239955] usb 3-9: SerialNumber: 0670FF575056805087031133 [13966.240229] usb 3-9: ep 0x84 - rounding interval to 1024 microframes, ep desc says 2040 microframes [13966.295683] usb-storage 3-9:1.1: USB Mass Storage device detected [13966.295954] scsi16 : usb-storage 3-9:1.1 [13966.296267] cdc_acm 3-9:1.2: This device cannot do calls on its own. It is not a modem. [13966.296287] cdc_acm 3-9:1.2: ttyACM2: USB ACM device [13967.295646] scsi 16:0:0:0: Direct-Access MBED microcontroller 1.0 PQ: 0 ANSI: 2 [13967.296255] sd 16:0:0:0: Attached scsi generic sg2 type 0 [13967.296562] sd 16:0:0:0: [sdb] 1072 512-byte logical blocks: (548 kB/536 KiB) [13967.296841] sd 16:0:0:0: [sdb] Write Protect is off [13967.296847] sd 16:0:0:0: [sdb] Mode Sense: 03 00 00 00 [13967.297101] sd 16:0:0:0: [sdb] No Caching mode page found [13967.297107] sd 16:0:0:0: [sdb] Assuming drive cache: write through [13967.304706] sdb: [13967.307414] sd 16:0:0:0: [sdb] Attached SCSI removable disk [13984.989018] cdc_acm 3-9:1.2: failed to set dtr/rts [13999.024323] cdc_acm 3-9:1.2: failed to set dtr/rts [14016.061852] cdc_acm 3-9:1.2: failed to set dtr/rts [14017.951574] usb 3-9: reset full-speed USB device number 22 using xhci_hcd
Lorsqu'on branche la carte programmable, le noyau la reconnaît bien et lui attribue un téléscripteur (ttyACMX). Cependant la dernière ligne indique que le module du noyau responsable de l'USB3.0 xhci_hcd a reset la connexion. La carte se reconnecte sous peu mais le problème est toujours le même. Lorsque la limite du nombre d'ACMX à allouer est atteinte (31) le module n'en n'alloue plus.
[10095.392845] cdc_acm 3-1:1.2: no more free acm devices [10096.391780] scsi 12:0:0:0: Direct-Access MBED microcontroller 1.0 PQ: 0 ANSI: 2 [10096.392246] sd 12:0:0:0: Attached scsi generic sg2 type 0
Aucun soucis une fois passé sur un port USB2.0. C'est le module ehci_pci qui est alors utilisé. Il me semble possible de forcer l'utilisation de ce module sur un port USB donné.
Test de l'émission LoRa
J'ai pu ensuite rassembler les sources autour du protocole LoRaWAN et trier les sources officielles du code indépendant. Mbed possède un IDE en ligne qui permet d'écrire et de compiler rapidement du code pour les boards utilisées. Cependant, l'IDE n'est pas toujours explicite sur les erreurs de compilation. Parfois même on obtient une erreur interne sans aucun détail ou des timeout après plusieurs minutes de compilations. J'ai donc cloné mes projets localement et j'alterne entre différents environnements. L'IDE permet également de parcourir beaucoup plus facilement les librairies officielles de Semtech.
Le code d'un end-device s'intègre parfaitement sur la radio SX1276, prévue à cet effet. J'ai pu donc effectuer mes premiers essais d'émission. A gauche, on a le spectre observé à l'aide d'une radio logicielle pour les paramètres suivants :
Fréquence : 868.1MHz Spreading factor : 12 Coding rate : 4/5 Bande passante : 125kHz activation : On-The-Air Activation
Ce paquet correspond à un join_request. Je n'ai pas réussis à contourner la procédure d'activation avec la procédure ABP (activation by personnalization) pour directement émettre des messages chiffrés. D'autres paramètres n'améliorent pas significativement la qualité visuelle du spectre. A droite est représenté un exemple de spectre que l'on pourrait obtenir avec un radio de meilleure qualité.
Semaine 6 Feb 2017
Recherche
Les modules LoRa SX125x et SX127x sont prévus pour être des end-devices au sein d'un réseau LoRa. Le dépot github officiel de LoRaWAN distribue donc tout le code nécessaire pour des end-device avec ces radios. Cependant le code officiel fournis par Semtech pour une gateway n'est compatible (out of the box) qu'avec un chip SX1301. Je me suis donc renseigner sur les alternatives possibles et j'ai recherché du code existant qui se rapprochait le plus de ce que je voulais. Voici une liste non exhaustive des projets indépendants que j'ai trouvés :
- Adaptation du code de la gateway pour une carte Multitech MTAC-LORA (MultiConnect mCard)
- Tests de charge LoRaWAN par un chercheur belge, ainsi que la discussion autour de son travail sur the Things Network
- Implémentation d'une gateway LoRa, simple conversion en paquet IP et surcouches pour le traitement des données. Fonctionne sur un seul canal avec SX1272 et SX1276 mais contrôlé directement par spi par une raspberry Pi.
- Autre gateway contrôlée par SPI
- Autre gateway contrôlée par SPI
- Implémentation non-officielle d'un network server
J'ai choisis de m'inspirer de ces exemples ainsi que des exemples et librairies officielles (Mbed & LoRaWAN) pour réaliser un premier programme simple pour tester la connectivité entre les deux radios.
Ping / Pong
Une carte programmable NUCLEO contrôle la puce LoRa SX1276 à travers une interface SPI. Une librairie existe déjà pour définir les constantes pour écrire / lire dans ces registres. J'ai donc ré-utilisé un exemple de communication entre deux radios LoRa pour rediriger les informations à travers une connexion série. Le schéma ci-dessous représente la maquette réalisée. Ce programme écoute le trafic LoRa en boucle sur une fréquence spécifique, avec des paramètres très spécifiques (spreading factor, bande passante, taille de buffer ...). Dès que l'on reçoit une trame, on regarde le contenu (ping ou pong) et cela va dicter la réponse à envoyer, toujours selon les mêmes paramètres radios.
Ce mode de dialogue volontairement simpliste donne les résultats suivants : - On envoie un ping toutes les 3 secondes - La seconde radio accuse la réception, et renvoie un pong - Accusé de réception de la première radio, et renvoi toute de suite (10ms) d'un ping - ... Les messages onRxDone et onTxDone sont affichés à des fins de debug.
A l'aide d'une radio logicielle j'ai confirmation de l'échange entre les deux radios :
La faible qualité de ma radio ne me permet pas de distinguer les chirps caractéristiques du protocole LoRa (échantillonnage limité). On y voit bien cependant les échanges de message. La fréquence est fixée à 867.1MHz et la bande passante est de 125kHz (spreading factor = 12).
Analyse des risques
Première version de l'analyse des risques du protocole LoRa : Fichier:Lora Scénarios Menace.pdf
En résumé, voici un schéma réunissant les principaux risques :
