IMA4 2018/2019 P70

Impact du matériel et du logiciel sur le champ électromagnétique

Présentation générale

Projet : Impact du matériel et du logiciel sur le rayonnement électromagnétique

Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.

Etudiants : Souheib KHINACHE et Antoine MOREAU

Encadrants : Alexandre BOE, Xavier REDON et Thomas VANTROYS

Description

L'internet des objets est un marché en plein essor. La communication entre les différents objets connectés crée un nuage de signaux autour d'eux. Ces derniers sont vus par les utilisateurs comme des boîtes noires : le fonctionnement se fait sans en connaître les composants matériels et logiciels. Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant.

Bien qu'ils peuvent porter à débat sur l'impact sur la santé, ces signaux peuvent représenter de réelles sources d'informations sur l'aspect matériel et applicatif de l'objet.

Il serait donc intéressant d'avoir idée générale sur le fonctionnement du système en interprétant les ondes électromagnétiques émises par ce système.

Objectifs

Les principaux objectifs de ce projet seront donc de mesurer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et sur la consommation électrique. Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. Cependant, nous pourrions concevoir notre propre système de capture et d'interprétation à partir d'une antenne, de filtres de fréquences et d'un microcontrôleur (on commencera par un ATMega328P). Il sera nécessaire de prendre en compte les perturbations issues de notre appareil de mesure et d'en tenir compte.

On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :

• l'aspect "Hardware" en étudiant différents modèles pour un même type de shield
• l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)
• l'aspect "Software", en étudiant l'impact du logiciel et du firmware d'un même composant (différents firmwares pour un même shield Wi-Fi)
• l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).

L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. Afin de mieux appréhender le problème, il nous est nécessaire de comprendre les phénomènes physiques issus de la notion d'électromagnétisme.

Ces études mèneront à une étape plus complexe : l'interprétation des signaux. En effet, l'un des objectifs de ce projet est de comprendre du mieux possible le fonctionnement d'un système sans y avoir accès directement, et donc dans ce contexte "traduire" un ensemble de signaux électromagnétiques.

On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.

Analyse du projet

Positionnement par rapport à l'existant

Bien qu'aux yeux de nombreuses personnes le bruit électromagnétique créé par les équipements électroniques du quotidien peut porter à controverse (débats concernant l'impact sur la santé par exemple), il peut être une source d'informations. De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.

On peut prendre l'exemple de Milos Prvulovic, professeur à l'Institut Technologique de Géorgie, ayant simulé un contexte de cybercafé, dans lequel il place une antenne magnétique, un ordinateur portable cible et un ordinateur "espion". Il réussit, grâce aux signaux EM émis par l'impulsion de l'appui des touches clavier à capter un message écrit par un ordinateur cible.

Néanmoins, dans le quotidien, l'utilisation des sondes électromagnétiques se fait pour l'étude énergétique d'un système électronique (fuites électromagnétiques anormales, preuves d'une anomalie...) afin de respecter certaines normes législatives. Le code du travail par exemple réglemente et définit des valeurs seuils par le biais des articles R. 4453-3 et R. 4453-4.

Analyse du premier concurrent

NBM-520 de NARDA STS

NBM-TS, application des appareils NBM

NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques. La NBM-520 est un appareil de la franchise, mesurant le champ électrique et magnétique. Elle donne des valeurs précises du champ électromagnétique ambiant sur une large bande. Elle propose différentes sondes modulables permettant une souplesse au niveau de l'étude en fonction des besoins, avec des sondes pouvant étudier des signaux de fréquence de 100kHz à 6GHz ou même de 300kHz à 50GHz (en fonction de la sonde choisie).

En outre, le dispositif peut se connecter en USB sur PC afin d'envoyer les données capturées et d'en faire une étude. Le dispositif propose un logiciel d'étude, NBM-TS, permettant d'observer du champ en fonction du temps, de la fréquence, de la position...

L'équipement est utilisé par l'ANF (l'Agence Nationale des Fréquences, agence gérant l'ensemble des normes autour des radiofréquences), et est donc un gage de qualité.

Avantages :

• Large bande de fréquence
• Matériel solide
• Application fonctionnelle permettant l'étude et gestion des données
• Possibilité d'étudier séparément champ électrique et magnétique

Inconvénients:

• Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)
• Prix élevé : à partir de 3100€
• La cible de ce produit est surtout les professionels

Analyse du second concurrent

Une pita.

Comment mon pain à pita vole ta clé RSA ?

Une pita.

Des chercheurs israéliens ont découvert un moyen de capturer des clés de cryptage RSA, réputées comme inviolables, par le biais d'une pita... du moins avec un dispositif suffisamment petit pour être caché dans un pain à pita. Le dispositif, renommé PITA pour Portable Instrument for Trace Acquisition a la particularité de capturer les ondes radio électromagnétiques émanantes d'un PC, qu'il soit connecté à un réseau ou pas. Les différentes opérations du processeur sont identifiées en distinguant les différents modèles de l'activité radio sur le spectre EM.

Bien que la capture des clés RSA a été faite dans des conditions particulières (modification du processeur de l'ordinateur cible), il est néanmoins possible, selon les chercheurs, d'identifier quelle type d'activité est exercée par l'ordinateur ainsi que son état.

Un dessous de pita.

L'un des points importants concernant le dispositif est son coût : moins de 300 euros. L'appareil dispose :

• d'un PC portatif (PC-on-a-stick) Rikomagic MK802 IV,
• d'un recepteur radio SDR FUNcube Dongle Pro+
• d'une antenne radio
• d'une batterie
• d'une antenne WiFi
• d'une carte MicroSD
• d'un adapteur d'antenne
• et d'une pita.

Le dispositif aurait une portée de 50cm. Les chercheurs israéliens ont collaboré avec GNU Private Guard (logiciel de cryptage asymétrique) afin de protéger contre ces attaques les clés de cryptage.

Scénario d'usage du produit ou du concept envisagé

Scénario 1

Gérard a toujours le flair pour les bonnes affaires. Il a acheté une centaine de clés WiFi à un prix dérisoire sur AloXpresso afin de faire du profit à la revente. Le vendeur lui garantit que toutes les clés fonctionnent correctement. Gérard veut vérifier. Après vérification, 99 des clés sur 100 fonctionnent comme prévu. Gérard aimerait être sûr du disfonctionnement, mais Gérard n'est pas une pointure en informatique.

Coup de génie ! Il se rappelle qu'il dispose d'un dispositif qui capte les ondes EM et les interprète directement. C'est le moment de tester ça. Il remarque une anomalie sur le spectre. Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.

Scénario 2

La police fait une perquisition chez un individu soupçonné de graves délits. Cela fait plusieurs mois que la brigade criminelle prépare l'intervention, et une fois sur les lieux ils arrêtent le soupçonné malfaiteur. Cependant avant de repartir, elle veut faire l'acquisition d'un maximum de preuves. Elle veut alors prendre l'essentiel des objets, dont certains objets éléctroniques connectés de l'individu dont elle pourra extraire les informations qui serviront à le faire tomber.

Par chance, elle dispose d'un petit outil qui scannera les signatures alentours des objets connectés, comme des téléphones cachés, clés USB wifi dissimulées dans le décor etc.. Et si le suspect avait modifié malignement un objet connecté banal pour l'utiliser autrement à ses fins, la police le découvrirait car elle possède une base de données de toutes les signatures spectrales des objets connectés sur le marché et celle de l'objet modifié ne collerait pas avec celle de la base de données.

Réponse à la question difficile

Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?

Les signaux électromagnétiques des microcontrôleurs ou d'autres composants peuvent être faibles. Il y a une possibilité pour palier à ce problème, c'est de capter les signaux depuis une antenne émettrice que l'on rajoute à l'objet d'étude. Nous utiliserons un SDR (Software Defined-Radio) afin de capter les ondes radio et les étudier directement sur PC. Le filtrage s'effectuera ainsi de manière numérique. Plusieurs tests seront effectués pour le même objet à étudier (quand on parle d'objet, on évoque un ensemble de plusieurs composants, comme par exemple une alimentation, un micro-contrôleur et une antenne). Ainsi, de manière statistique, nous pourrons en déduire un pattern récurrent pour chaque expérience en les effectuant dans différents environnements (pourquoi pas une chambre anachoïque).

Préparation du projet

Cahier des charges

Nous souhaitons

• Capter le signal émis par un objet connecté le plus précisément possible

• Concevoir nos propres objets connectés tous différents mais basés sur un même modèle

• Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions

• Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché

Choix techniques : matériel et logiciel

Choix logiciel :

- La distribution Linux Pentoo ou Kali pour traiter les signaux avec GNU RADIO (Suite logicielle dédiée à l’implémentation de radios logicielles et de systèmes de traitement du signal).

- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560

Choix Matériel :

- Plusieurs modules radios émetteurs

- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560

- Des alimentations identiques pour chaque PCB

- Un HackRF pour la réception des signaux

- Une antenne 50 Ohm pour le HackRF [1]

Liste des tâches à effectuer

Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :

- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.

- Une multitude de PCB qui seront utilisés comme objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)

Ensuite afin de récupérer une "signature" d'un de nos objets , il faudra faire plus de 50 analyses spectrales pour conclure statistiquement sur une bonne signature qui caractérisera l'objet.

Nous devons donc dans un second temps:

- Récupérer la signature de deux objets connectés identiques mais qui ont un firmware différent.

- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le microcontrôleur.

- Récupérer la signature de deux objets connectés identiques dont seul le PCB diffère.

Grâce à tous ces tests , nous pourrons conclure et voir l'impact qu'à le matériel ou le logiciel sur la signature d'un objet.

Enfin si les délais nous le permettent, nous pourrons réaliser un software qui cartographiera nos objets connectés dans la pièce grâce à la puissance de la signature reçue (Ce qui devrait être réalisable puisqu'à ce stade nous aurons une base de donnée des signatures).

Réalisation du Projet

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
Analyse du projet	3	8	0	0	0	0	0	0	0	0	0
Recherches	1	3	3	3	6	3	3	3	4	3	4
Prise en main de GnuRadio	0	4	4	4	3	2	3	2	1	1	1
Configuration Xbee	0	2	2	1	1	2	2	0	0	0	0
Expériences	0	0	0	0	0	0	0	1	3	3	5
Total	4	15	9	8	7	8	8	x

Semaine 1

Le HackRF One

Durant cette semaine, nous avons continué nos recherches notamment sur le moyen de transmission de nos objets connectés. Nous avons confirmé notre choix de notre SDR : Monsieur Boé nous a confirmé que des HackRF seraient disponibles dans les laboratoires et qu'il pourrait nous en prêter un. On disposera donc d'une antenne puissante pour traiter les signaux émis par nos objets communiquants.

Il faudra coupler notre HackRF avec un logiciel appelé GNU RADIO qui est un logiciel très complet ( Pour information : la NASA a utilisé GNU RADIO afin de rétablir le contact avec une sonde spatiale abandonnée ). Afin de faire tourner ce logiciel libre, nous aurons besoin de la distribution Kali Linux, ex Backtrack.

Choix des émetteurs/récepteurs

Nous avons décidé que nos objets connectés communiqueront dans deux bandes de fréquences ISM, l'une à 900 MHz grâce à des modules Digi Xbee et l'autre à 2,4 GHz par le moyen de modules émetteurs Bluetooth. On rappellera que les Digi Xbee et les émetteurs/récepteurs Bluetooth seront pilotés par des ATMEGA 2560.

Les Xbee ne communiqueront pas entre eux et émettront en continu les mêmes données car ils le peuvent, alors que les émetteurs/récepteurs Bluetooth devront s'échanger des données si on veut pouvoir observer un quelconque signal autour de la fréquence de leurs porteuses.

On voudra observer premièrement, si avec deux objets dans les mêmes conditions (donc même µc et même émetteur), on peut ou non distinguer une différence. Ceci est fondamental pour la suite des expériences, puisque si les deux émettent à la même fréquence, on pourra faire varier plusieurs paramètres afin de trouver des clés (des signes) qui pourraient aider à l'identification du matériel.

Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).

On planifie alors pour la semaine suivante de réussir à faire émettre, en utilisant simplement des breadboards pour commencer, nos Xbee et modules BT et observer quelque chose grâce à notre SDR.

Semaine 2

Configuration des modules XBee

Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux :

Les modules XBee ont été montés sur des platines d'interface USB/série de manière à ce qu'on puisse les paramétrer via le programme de contrôle minicom.

Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante :

minicom -b 9600 -D /dev/ttyUSB0

On active l'echo local dans minicom, afin de pouvoir observer ce qui a été envoyé par liaison série au XBee (CTRL+A puis E).

Pour commencer le paramètrage il faut taper +++ rapidement. Le XBee nous répond OK, cela veut dire que nous sommes dans le mode configuration et que nous pouvons utiliser les commandes AT. (Redirection vers la liste des commandes AT XBee [2]).

Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande ATRE.

Si on souhaite que des XBee puissent s'envoyer des données il faut qu'ils soient sur le même canal (commande ATCH) et aient le même PAN ID (commande ATID). Notre PAN ID sera BEE6 et le canal sera celui par défaut C.

Ensuite il faut leur donner une adresse de destination (ATDH & ATDL) qui sera l'adresse broadcast, pour ce faire on entre

ATDH=0000
ATDL=FFFF

Enfin ATMY représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.

N'oublions pas de sauvegarder les paramètres avec ATWR.

On vérifie que tout a bien été pris en compte :

+++OK
ATID
BEE6
ATCH
C
ATDH
0
ATDL
FFFF
ATMY
5000
ATCN
OK

Puis on fait de même avec le deuxième XBee (ID 5001).

Voilà, lorsque on envoie des caractères par liaison série sur 5000, la LED Tx de 5000 s'allume et la Led Rx de 5001 s'allume elle aussi. Cela signifie que l'envoi de donnée par onde radio s'effectue correctement.

Maintenant que les XBee émettent et reçoivent, on peut commencer les mesures avec notre SDR. Mais avant cela il va falloir bien se familiariser avec le logiciel GNU RADIO qui est assez difficile à prendre en main.

Première prise en main du logiciel GNURADIO

Installation de GNU radio avec les fonctions + drivers pour HackRF :

sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf 

Le bloc Osmocom Source sert de "passerelle" entre le logiciel et la SDR, il permet de transmettre les informations récupérées par le HackRF afin qu'on puisse les traiter avec d'autres bloc de fonctions.

Si on veut pouvoir récuperer les données il faut passer l'argument hackrf=0 dans la box périphérique du bloc Osmocom.

Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.

Semaine 3

Cette semaine nous a permis d'effectuer notre première expérience. L'utilisation des deux Xbees nous a permis d'observer l'impact des Xbee sur le champ électromagéntique environnant.

Si on analyse le spectre environnant grâce au module FFT de GNU Radio, lorsque les Xbee communiquent entre eux, on peut apercevoir un pic caractéristique propre. En effet, lors de l'emission d'un message sur le port série, on a un pic qui se dégage du spectre d'amplitude -20dBm. Ce pic est caractéristique au canal de communication choisi et configuré sur le Xbee. Néanmoins, le signal est perturbé par le bruit environnant. L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude. Il faut noter que la norme IEEE 802.11 impose au Wi-Fi l'utilisation d'une bande passante s'étalant de 2.4 GHz à 2.5 GHz.

La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.

Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.

• 

  Spectre de l'environnement autour du XBee
• 

  Lors de l'envoi de données au XBee voisin

On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz. Il nous est maintenant nécessaire d'analyser de plus près les signaux et leurs fréquence centrale dans la bande perçue au dessus de -20dB.

On réeffectuera une expérience en zone isolée des signaux parasites.

Semaine 4

Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.

En somme, nous étions confrontés à de nombreuses interrogations. Le fonctionnement du Xbee étant assez simple et la sécurité du protocole Zigbee étant moindre, y a t-il possibilité de démoduler le signal émis afin de développer nos études ?

Semaine 5

Script Python

Après réflexion et consultation de nos encadrants, nous nous sommes rendu compte que la démodulation prévue lors de la semaine 4 n'aiderait pas à répondre à la problématique de notre sujet !

Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoi sur le port série des données vers le Xbee. C'est à dire concevoir un programme Python qui automatisera l'envoi de données et le changement de channel à intervalle de temps régulier (Changement toutes les 10 secondes).

L'utilisation de Minicom n'était pas du tout la meilleure solution pour faire émettre les Xbee.

Après quelques essais, on remarque que lorsque le Xbee émet sur le channel 13, il émet à environ 2,445GHz au lieu d'émettre à 2,415GHz soit une différence de 30MHz : Ceci n'est pas important, car ce que l'on souhaite remarquer c'est un éventuel décalage de la fréquence centrale entre deux Xbee différents. Si les deux Xbee n'ont pas la même frequence centrale on pourra conclure que la fréquence centrale de la porteuse du Xbee n'est pas une des clés permettant d'identifier cet émetteur/récepteur.

Semaines 6 et 7

Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.

Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.

Planche prototype

Tout d'abord, nous avons paramétré la fréquence centrale de capture du HackRF. En effet, bien que le HackRF dispose d'une large bande passante, afin de se focaliser sur la porteuse, il est indispensable de configurer le HackRF en conséquence. En second lieu, pour éviter une variation du RSSI (Received Signal Strength Indication) et de la puissance du signal, nous devions mettre en place une prototype de "planche expérimentale" sur laquelle devaient être fixés nos différents modules (l'antenne de reception et les Xbees).

La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.

Chaque Xbee est identifié par un chiffre (1 ou 2). En effet, l'attribution de ces chiffres sera définitive pour ne pas perturber la cohérence des expériences. Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.

Expérience : Le XBee 1 émetteur directement connecté en série au PC

Schéma simple d'étude fréquentielle et temporelle

Cette expérience est la première mettant en place un contexte (un seul Xbee émetteur connecté en série au PC, le deuxième Xbee étant inactif) et nous permettra d'étudier le plus de cas possibles.

Nous avons tout d'abord commencé par un graphe GNURadio simple permettant l'observation du spectre et du signal et la variation de la fréquence d'étude.

Le script python a été réécrit afin que le XBee puisse émettre une chaîne de caractère "HELLO" * 1024. En effet, même si la fréquence de balayage du module HackRF peut être grandement augmentée, il faut éviter d'aller au dessous de 0.01s, finissant par consommer de manière considérable les ressources octroyées par le CPU le cas échéant. Le fait d'augmenter la taille de la chaine de caractère permet de mieux synchroniser l'étude en temps réel avec la capture des données.

Nous avons donc émis les données sur le canal 20 (14 en hexadécimal), soit la fréquence centrale est à 2.450GHz selon la norme Zigbee.

Etude fréquentielle

L'étude fréquentielle est similaire à celle réalisée auparavant.

• 

  Spectre fréquentiel au canal 14
• 

  Spectrogramme

Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.

D'autre part, l'ensemble des fréquences qui dessinent le spectre s'étalent sur une large bande de fréquence. En effet, cette technique d'étalement appelée DSSS (Direct-Sequence Spread Spectrum) utilisé par les modules XBee permet au signal d'être moins sensible aux interférences et aux brouillages. En outre, même si la puissance du spectre dans sa globalité reste la même, la densité spectrale elle diminue considérablement, rendant le signal plus "discret". La différence de puissance entre le lobe principal et les premiers lobes secondaires sont de 30 dB, ce qui est aussi commun au DSSS.

Le spectrogramme témoigne aussi de l'étalement du signal sur un peu plus de 6 MHz (3MHz de par et d'autre de la fréquence centrale).

Etude temporelle

Signal observable centré à 2.450GHz lors de l'émission

Le signal ici est séparé en deux composantes car il s'agit d'un signal complexe. Nous avons supposé en premier temps qu'il s'agissait du signal principal décalé de 180°, ce qui n'était pas le cas. Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante. Le signal observable témoigne d'une modulation bien spécifique au XBee. En effet, on peut observer des sauts de phase à différents points, qui correspondent à une modulation par changement de phase (modulation QPSK ou Quadratic Phase-Shift Keying). Ce sont ces sauts de phases qui permettent la transmission des bits. Les changements de phase s'il y a se font toutes les µs. En outre, on peut observer un décalage (offset) entre la composante Q et la composante I de µs/2 (propre à la modulation OQPSK).

Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudié avec Audacity, logiciel open-source de son, et donc de signaux ! L'inconvénient avec l'interface graphique QT de GNURadio est son manque de précision lors d'un dézoom sur le signal en temps réel. Audacity permet de palier à celà ! En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.

Le paquet XBee est constitué d'un premier header (header physique) de 6 octets : - la séquence de préambule (4 octets) constitué de 32 bits à 0

- l'indice de début du paquet fixé à 0x7A (1 octet)

- la longueur du paquet (1 octet);

d'un header MAC (7 à 27 octets en fonction des informations de l'adresse), d'un bloc FCS de fin de paquet (2 octets) et l'ensemble des données (de 1 à 104 octets).

On observe graphiquement qu'un paquet est transmis en 3846µs

Paquet XBee

Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS. Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en chips. Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips). Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).

Les signaux reçus par l'antenne HackRF étaient deux sinusoïdes modulées en phase et qui s'étalaient sur une période d'environ 3840µs (3846µs graphiquement mais il y a possibilité d'erreur à l'echelle du µs). Sachant qu'un octet correspond à 64µs, on a :

$N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets$

L'analogie peut être effectuée entre paquet Ethernet et paquet ZigBee. En effet, la taille limite des données d'un paquet est de 104 octets. La chaîne de caractère n'étant qu'envoyée par paquet, le paquet observé n'est que de 120 octets, ce qui est cohérent avec les caractéristiques du XBee.

• 

  Temps de transmission de la chaîne de caractères "HELLO" 1024 fois
• 

  51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois

Semaine 8

L'étude des signaux posait réellement problème de par le fait qu'une grande partie de la capture faite n'était que purement le bruit sans signal (utile plus tard pour l'étude du SNR). Prenons l'exemple d'un paquet de 21 octets (un paquet contenant une seule chaîne de caractères HELLO). Le signal s'étalerait en théorie sur 21*64 chips soit 672 chips. Sachant que la modulation est une modulation QPSK, on s'étale sur un temps de 672µs. En effet, le Xbee transmet toutes les 100ms. Donc qu'une partie du signal nous est utile.

Nous avons donc décider d'écrire un script qui nous permettrait d'étudier le signal dans de meilleures conditions, et donc de le filtrer.

Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction File Sink du compagnon GNURadio. Néanmoins, les fichiers obtenus sont des fichiers binaires assez lourds (environ 500Mo pour une capture de 3s), ce qui est un réel problème et qui implique le filtrage du signal.

La bibliothèque numpy pour python nous permet en outre directement d'importer les échantillons des signaux, les traduisant du binaire à un format cible (complexe flottant 64 bits) dans un Array par le biais de la fonction:

f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64)

La première solution pour réduire ce signal était d'imposer un threshold directement sur le signal, supérieur au bruit, mais qui conduirait à une perte d'une partie du signal à étudier. La deuxième solution qui a été retenue était tout simplement de calculer l'amplitude et la phase du signal et appliquer ce même threshold à l'amplitude.

Semaine 9 et 10

A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.

Lorsqu'on fait une acquisition d'un signal xbee , on peut maintenant via un script traiter cette acquisition et récupérer seulement les parties qui nous intéressent : A savoir la partie réelle et la partie imaginaire, l'amplitude du signal et enfin la phase du signal.

Exemple ci dessous après acquisition + traitement de notre xbee n°2 :

• 

  Signal Xbee2 post-traitement
• 

  Diagramme de constellation xbee2 après utilisation de LightSignal

L'utilisation du script LightSignal permet de retirer toutes les phases en dehors du signal. Ainsi, on peut caractériser le diagramme de constellation comme un diagramme propre à la modulation QPSK.

#include <iostream>
import scipy
import numpy
import sys

def binToComplex64(name):
    threshold=0.10
    tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)
    tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)
    
    f2 = open(name+"_filtre", "w+") 
    f = open(name+"_PhaseMeg_filtre","w+")
    
    p=1
    size=tmp.__len__()
    size2=tmp2.__len__()
    
    if size > size2:
        size=size2

    
    ground=False
    newListSignal=[]
    newListMagnPh=[]
    for val in range(0,size): 
        if(val>=(size/100)*p):
            print(str(p)+" %")
            p=p+1
        if(tmp[val].real>threshold):
            if(ground==True):
                for i in range(0,1000):
                    newListSignal.append(numpy.complex64(0))
                    newListMagnPh.append(numpy.complex64(0))
                ground=False
            newListSignal.append(tmp2[val])
            newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))
        else:
            ground=True
    
    tmp=numpy.asarray(newListMagnPh)
    tmp.tofile(f)
    tmp2=numpy.asarray(newListSignal) 
    tmp2.tofile(f2)
 

def main():
    try:
        binToComplex64(sys.argv[1])
    except IndexError:
        print("Donnez le nom du fichier\n")
    except IOError:
        print("Le fichier n'existe pas\n")



if __name__=='__main__':
    main()

Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee. En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.

Semaine 11

Nous avons décidé cette semaine d'étudier, ce qui est selon pour nous, l'une des pistes fondamentales de notre projet, et plus particulièrement de l'étude de nos signaux : le rapport signal bruit.

L'objectif de cette semaine et de celle à venir était, à partir du signal acquis par le hackrf, d'effectuer le calcul du SNR (signal-to-noise ratio) tel que :

$SNR =\frac{P_{signal}}{P_{bruit}}$

Le script python qui nous a permis de communiquer entre les deux shields Xbee se verra amélioré afin de faire plusieurs acquisition des signaux lors de la communication entre les Xbee, effectuer une moyenne statistique, et de même lorsqu'il n'y a pas de communication.

Nous avons essayé d'approcher le SNR directement depuis l'interface de GnuRadio par le biais de l'utilitaire graphique et le langage en bloc, néanmoins nous procéderons à l'étude de ce rapport avec Scilab ou Matlab.

Semaines supplémentaires

Expérience : Variation de l'amplitude

Contexte :

Résultats  :

Conclusion sur l'expérience  :

L'expérience n'a pas été fructueuse. Même si elle nous a permis de voir quelques différences (probablement provoquées pas des erreurs de capture et d'analyse), le HackRF nous limite beaucoup sur ce point de vue là. En effet, la fréquence d'échantillonage étant limitée à 20MHz, le HackRF n'est pas suffisamment précis pour capturer un nombre d'échantillons nous permettant de confirmer une quelconque hypothèse.

Code python utilisé pour l'étude du signal :

def etudeAmplitude(name, liste_temps):

    threshold_0=0.05 # Threshold
    threshold_1=0.4
    max_transition_time=50 #O

    amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) 

    p=1
    size=amppha.__len__()
    
    debut=1
    tps_variation=0 


    transition=False # Vérifie si le signal est en transition ou stable

    for val in range(debut,size):
        if(val>=((size-debut)/100)*p):
            print(str(p)+" %")
            p=p+1

        if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal
            if(transition==False):
                transition=True
            tps_variation=tps_variation+1

        elif(transition==True and amppha[val].real>threshold_1):
            if(amppha[val].real>=amppha[val-1].real-amppha[val-1].real*0.05 and amppha[val].real<=amppha[val-1].real+amppha[val-1].real*0.05): # L'amplitude du signal est stable
                if(tps_variation < max_transition_time):
                    liste_temps.append(tps_variation)

                transition=False
                tps_variation=0
            else:
                tps_variation=tps_variation+1
        else:
            transition=False
            tps_variation=0

Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2

Contexte 1 :

Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)

Le XBee1 et XBee2 disposent du firmware : 10EF

Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur

On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet. L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet. L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.

• 

  Les différents temps à mesurer

Néanmoins, l’étude de ces “temps morts” se voit entravé par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes. En outre, pour 5 secondes d’étude et pour une fréquence d’échantillonage de 20MHz (soit un temps Te=5.10e8), on compte 100.000.000 d’échantillons. Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise. Pour régler ce problème, on a écrit un script shell de capture. Ce script consiste à:
- effectuer une capture d’une durée de 1 sec
- d’enregistrer la capture
- d’effectuer un traitement de ces paquets par un algorithme python en étudiant le temps entre chacun des fragments. Ce temps sera obtenu en nombre d’échantillons, défini avec un seuil d’acceptation absolu entre 150.000 et 300.000 échantillons (pour bien capturer ces temps intermédiaires et pas les temps provoqués par des signaux parasites ou du bruit), et pour affiner l’étude, on impose un seuil d’erreur de +-10% autour de la moyenne. La moyenne est calculée en continue
- l’ensemble des valeurs obtenues sont enregistrées dans un fichier
- on réeffectue la capture …

On répète le processus un certains nombre de fois afin d’obtenir un nombre de valeurs nous permettant de nous conforter sur l'issue de l'expérience (environ 1000 valeurs)

La capture et l'étude de chacun des modules dure une à deux heures.

Résultats :

Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :

• 

  On peut observer des pics caractéristiques à l'envoi
• 

  Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module

XBee1 :

Moyenne : 259675,81

Ecart-type : 8369.7417

Variance : 70052576.

XBee2:

Moyenne : 258762.58

Ecart-type : 9165.4097

Variance : 84004736.

Les graphes présentent le nombre de répétitions des temps de calcul de fragements.

On peut voir des pics spécifiques à certains points dans les deux expériences. Ces pics sont caractéristiques et au module XBee, et à la chaîne de caractère HELLO. Les deux expériences étant effectuées dans le même contexte,

De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.

En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee. Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.

Pour confirmer ces observations, il est peut être nécessaire de répéter la même expérimentation sur un nombre d'échantillons plus grand.

Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.

En superposant les deux graphes (Xbee1 en rouge et Xbee2 en bleu), on peut voir qu'il y a moins de dispersion dans le cas du XBee1, plus centré sur des valeurs précises, contrairement au Xbee2.

• 

Pour les deux nouveaux échantillons, on a les caractéristiques suivantes : Xbee1 sur 1688 échantillons

Moyenne : 260230.3

Ecart-type : 8427.3923

Variance : 71020941

Xbee2 sur 1722 échantillons

Moyenne : 259899.41

Ecart-type : 9831.5106

Variance : 96658601

Signal observé dans le cas de l'ATMega328p

Contexte 2 :

Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium

Le XBee1 dispose du firmware 10EF

On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s

Hormis l'amplitude du signal qui paraît plus faible lors de la transmission par ATMega328p, le message transmis ne change PAS. Même si nous avons fait en sorte que la periode de transmission soit la même que pour l'expérience précédente, elle n'affecte en rien l'issue de l'expérience car c'est le temps de division de paquet.

Résultats :

• 

  Observation du temps de division d'un paquet dans le cas de l'ATMega328p
• 

  Observation du temps de division d'un paquet dans le cas de l'ATMega2560

Pour les nouveaux échantillons, on a les caractéristiques suivantes :

Xbee1 sur ATMega328p sur 706 échantillons

Moyenne : 265818.58

Ecart-type : 4748.5965

Variance : 22549168

Xbee1 sur ATMega2560 sur 711 échantillons

Moyenne : 265818.58

Ecart-type : 3675.037

Variance : 13505897

La transmission des données entre ATMega328P

Conclusion de l'expérience : L’hypothèse qui est que la variance des temps "morts" entre chaque fragments de paquet, soit le temps de calcul du FCS pour le signal émis peut être considéré comme “clé” de distinction d’un module Xbee n'est donc pas à négliger.

On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.

Code python utilisé pour l'étude du signal:

def etudeSubdivPaquet(name, inter_time_values):

threshold = 0.30
ground = false
p=1

## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) 


## On récupère la taille du tableau de complexes (taille du signal) ##
size=amppha.__len__()

    debut=0
    inter_time=0
    min_limit=150000
    max_limit=350000
    accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation
    signalFnd=False

    for val in range(debut,size):
        if(val>=((size-debut)/100)*p):
            print(str(p)+" %")
            p=p+1

        if(amppha[val].real>threshold):
            if(ground==True):
                if(signalFnd==True):
                    if(len(inter_time_values)>0):
                        moy=moyenne(inter_time_values)
                        if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):
                            print("Yes "+str(inter_time))
                            inter_time_values.append(inter_time)
                        inter_time=0
                    elif(inter_time>=min_limit and inter_time<=max_limit):
                        inter_time_values.append(inter_time)
                else:
                    signalFnd=True
                ground=False
        else:
            ground=True
            if(signalFnd==True):
                inter_time=inter_time+1

    if(len(inter_time_values)>0):
        print("Moyenne "+ str(moyenne(inter_time_values)))

Rencontre avec Etienne Helluy Lafont

Bien que plusieurs pistes ont pu être explorées, notre manque d'expertise dans le domaine de la radio logicielle nous a fait défaut sur nos recherches. En effet, après avoir calculé le SNR d'un de nos signaux, nous nous sommes retrouvés avec des résultats assez incohérents. De nombreuses erreurs peuvent se glisser et nous avions besoin de conseils à ce sujet.

Etienne Helluy-Lafont est un doctorant qui fait sa thèse sur les sondes pour la détection d’intrusions dans les architectures réseau hétérogènes et massivement distribuées. Il développe un outil permettant d'analyser le spectre environnant, de donner des informations sur les signaux émis sur certains canaux et même de démoduler ces signaux. Son programme en C est flexible puisqu'il est adapté pour beaucoup d'antennes (Une des librairies qu'il utilise est SoapySDR [3] qui possède des "codec" dont un pour notre HackRF !). Nous nous sommes servi de son outil afin d'avoir de bien meilleurs résultats pour les expériences sur le SNR des Xbee.

Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception

• 

  Calcul du SNR par FFT
• 

  Calcul du SNR par fenêtre glissante

L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. En effet, nous avions mis en suspens l'expérience qui consistait en la capture du SNR dû aux valeurs instables que l'on avait.

La première idée était de faire une FFT du signal et de calculer le rapport en prenant la moyenne de sa puissance sur une bande de 2.4MHz (1.2Mhz de part et d'autre de la fréquence de capture du HackRF).

Néanmoins, les caractéristiques du XBee (du point de vue de l'étalement spectral) rend le calcul du SNR imprécis. A la suite de la capture de signaux et de l'étude de ces mêmes signaux, les valeurs nous paraissaient incohérentes.

Pics de SNR

Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. Pour chaque échantillon du signal, on calculait le SNR tel que :

$SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}$

Dans notre cas, on a :

$SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}$

W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic. La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale. On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable. Ainsi, on obtient les valeurs SNR cherchées.

Nous voulons donc vérifier si la mesure du SNR est une expérience pertinente pour l'identification du matériel. Nous allons prendre plusieurs XBee et mesurer le SNR à différentes distances de l'antenne SDR.

Contexte 1 :

Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)

Le XBee1 et XBee2 disposent du firmware : 10EF

Le XBee3 et XBee4 sont des modèles XBeePro

Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation.

Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin.

Résultats :

Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1

Dans notre cas, le modèle XBee1 connecté en série à notre machine nous a servi de composant témoin afin d'étudier les signaux des autres modèles. En effet, suite à la capture et l'étude des signaux, on peut voir que le nuage de points qui constitue notre graphe témoigne d'un phénomène électromagnétique ondulatoire quant au champ. Avec la distance, plus l'on éloigne le module, plus le rapport signal sur bruit diminue (le contraire nous aurait étonné). En outre, la variation ondulatoire peut être caractérisée par le champs éléctrique.

Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.

De part les potentielles erreurs et les différentes perturbations électromagnétiques ambiantes, la valeur du SNR peut être affectée. Il n'est pas possible directement par les caractéristiques du rapport signal bruit d'effectuer le distinguo entre le XBee1 et le XBee2 (contrairement à l'expérience basée sur la subdivision de paquets). Cependant, les XBee3 et XBee4 présentent une caractéristique commune. Le SNR est beaucoup plus élevé.

En effet, le pic de courant d'un XBee est de 45mA à la transmission pour une alimentation de 3.3V en tension continu, tandis qu'un module XBee pro, le pic de courant atteint les 150mA. Cette différence électronique permet ainsi au XBee pro de communiquer sur une plus grande zone (750m contre 90m pour un XBee simple).

Ainsi, on peut conclure de cette expérience que le SNR est un élément témoin de la consommation énergétique d'un composant électrique (du moins de l'antenne).

Contexte 2 :

Le XBee1 est d'abord connecté à un Arduino UNO 328P par le biais d'un shield XBee Libelium puis est connecté à un Arduino Mega 2560 par le biais du même shield

Le XBee1 dispose du firmware : 10EF

Résultats :

On peut observer que même si l'unité de contrôle n'est pas l'ordinateur mais le micro-contrôleur (ici ATMega2560 et ATMega328P), le rapport signal bruit ne change pas réellement. Néanmoins, il était pour nous intéressant de noter qu'un léger gap se créé à 30 et 40 cm de la SDR entre la communication USB et la communication avec les micro-contrôleurs.

Contexte 3 :

L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro)

Le XBee3 est d'abord connecté à un Arduino UNO 328P par le biais d'un shield XBee Libelium puis est connecté à un Arduino Mega 2560 par le biais du même shield

Le XBee3 dispose du firmware : 10EF

Résultats :

En outre, les résultats obtenus lors de l'expérience avec le XBee3 nous indique que le phénomène ondulatoire observé durant les tests précédents est moins souligné dans la communication avec les micro-contrôleur (toujours à 30 et 40cm) et celà après plusieurs tests.

Des tests plus précis auraient été plusieurs avantageux et nous auraient permis de trancher sur la décision de l'importance du SNR concernant la différenciation de différentes unités de contrôle.

Contexte 4 :

Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent)

Après capture et expérimentation, on décide de réeffectuer la même chose avec le même XBee (XBee1) avec le firmware 10ED

Résultats :

Les acquisitions étant faites dans les mêmes conditions, il semblerait que le changement de firmware ait un petit impact sur la puissance d’émission : Cette petite différence de décibel ne semble pas aléatoire puisqu’on peut clairement voir que la courbe orange reste toujours inférieure à la courbe bleue, or le niveau de bruit est resté inchangé.

Conclusion de l'expérience :

Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence

Code python utilisé pour l'étude du signal:

def SNRStudy(name):
    tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)

    f = open(name+"_SNR_Values","a")

    p=1
    size = tmp.__len__()
    magnitude = (numpy.real(tmp)).tolist()

    threshold=10

    P=0
    SNR_graph=[]
    SNR=[]

    win_sz=64

    if(size>=win_sz):
        for val in range(0,size-win_sz):

            if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude
                print(str(p)+" %")
                p=p+1

            SNR_graph.append( 20*math.log((numpy.mean(magnitude[val + win_sz/2 : val + win_sz-1]))/(numpy.mean(magnitude[val+0 : val+win_sz/2-1])), 10) )

  

    size=len(SNR_graph)

    for i in range(1, size-1):
        if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):
            SNR.append(SNR_graph[i])


    tmp=numpy.asarray(SNR)
    tmp.tofile(f)


def main():
    try:
        SNRStudy(sys.argv[1])
    #except IndexError:
        #print("Donnez le nom du fichier\n")
    except IOError:
        print("Le fichier n'existe pas\n")

Documents Rendus

L'archive des scripts python :

[archive.zip]

Le rapport

[Rapport.pdf]