https://projets-ima.plil.fr/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=AmoreauWiki de Projets IMA - Contributions de l’utilisateur [fr]2026-05-14T09:44:52ZContributions de l’utilisateurMediaWiki 1.29.2https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=76043IMA4 2018/2019 P702019-05-10T10:48:44Z<p>Amoreau : /* Feuille d'heures */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13+ !! Total<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Préparation expérimentale (écriture de codes et scripts...) <br />
|0<br />
|0<br />
|2<br />
|3<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Etude et interprétation des résultats<br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|<br />
|<br />
|}<br />
<br />
<br />
A partir de la semaine 10/11, nous n'avions plus trop de notions du temps passé sur notre projet. Nous préférons être honnête et ne rien mettre plutôt que de mettre de fausses heures !<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
===Premières observations===<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 emet une chaîne de caractères HELLO*256 </I><br />
<br />
L'objectif de cette expérience est d'étudier le temps de variation de l'amplitude du signal entre l'état où le signal n'est pas reçu et l'état où le signal est réceptionné et donc l'amplitude constante.<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
A 20MHz de fréquence d'echantillonage, le temps de variation moyen est de 3 échantillons, soit 0.15µs, pour toutes les captures faîtes.<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
L'expérience n'a pas été concluante. 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. <br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
Néanmoins, l’étude de ces “temps morts” se voit entravée par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I><br />
<br />
<I> Le XBee1 dispose du firmware 10EF </I><br />
<br />
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I><br />
<br />
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.<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li><br />
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li><br />
</ul></div><br />
<br />
Pour les nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur ATMega328p sur 706 échantillons</U><br />
<br />
<U>Moyenne</U> : 265818.58<br />
<br />
<U>Ecart-type</U> : 4748.5965<br />
<br />
<U>Variance</U> : 22549168<br />
<br />
<br />
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U><br />
<br />
<U>Moyenne</U> : 262877.83<br />
<br />
<U>Ecart-type</U> : 3675.037<br />
<br />
<U>Variance</U> : 13505897<br />
<br />
<br />
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent. <br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I><br />
<br />
<I> On change le firmware du XBee1 pour le 10ED </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<br />
[[Fichier:FW10ED.png|thumb|left|400px|Observation du temps de division d'un paquet lors du changement du firmware]]<br />
<br />
<br />
<U>Xbee1 sur 821 échantillons</U><br />
<br />
<U>Moyenne</U> : 259735.52<br />
<br />
<U>Ecart-type</U> : 8501.3996<br />
<br />
<U>Variance</U> : 72273796<br />
<br />
<br />
Après avoir changé le firmware, on a pu voir que les résultats ne changeaient pas par rapport à l'expérience témoin. On est même très proche des temps du XBee bien que l'expérience ne s'est pas faîte dans les mêmes conditions (pas au même endroit, donc possibilité de perturbations).<br />
On peut donc en conclure que le firmware n'a pas un impact sur le temps de calcul du FCS.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.<br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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 quant aux expériences orientées SNR des Xbee.<br />
<br />
<br />
[[Fichier:SDRProgC.gif|center|Le programme sniffe l'environnement et renvoie les caractéristiques lors de la reception d'un signal]]<br />
<br />
L'avantage de l'utilisation de l'application nous permet directement de nous focaliser sur les paquets correctement reçus et non les données parasites qui peuvent perturber l'antenne. En effet, le programme reste à l'écoute de l'environnement électromagnétique sur une bande de fréquence autour de la fréquence d'écoute du HackRF. Lors de la reception d'un signal, le programme démodule le signal et vérifie si le CRC (ou le FCS pour le Frame Check Sequence) et les données concordent. Si c'est le cas, le CRC nous renvoie 1. Il s'agit là alors d'un signal. L'utilisation ainsi de ce programme nous permet de ne pas obtenir de valeurs parasites pour le SNR et filtrer directement les informations qui nous sont intéressantes.<br />
<br />
L'algorithme que nous avions écrit en Python est correct, néanmoins l'étude sur un signal enregistré requiert le chargement de l'intégralité du signal. Là où nos recherches se basent sur de la capture et du traitement post-capture, le travail d'Etienne se base sur un traitement du signal en temps-réel, ce qui nous permet ainsi de gagner un temps considérable.<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 sont des modèles série s1</I> disposent du firmware : 10EF<br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> : <br />
<br />
'''Hardware''' : Les paquets émis via liaison série ont plus de puissance que ceux émis grâce aux arduino UNO et MEGA notamment à 10 cm, 40 cm et 50 cm. On remarque aussi une baisse du SNR moyen à 30 cm surtout en liaison série et ce, avec nos quatres XBEE. Coté ATMEGA , le SNR reste plutôt stable et décroit très doucement. Ainsi lors d’un calcul de SNR/Distance on pourra estimer si le XBEE est connecté au PC en liaison série ou à une ATMEGA quelconque selon si son SNR suit l’allure ou non de la courbe de la transmission classique. <br />
<br />
''En cherchant des raisons à cela, on se demande si ce phénomène n’a pas un rapport avec la longueur d’onde du signal modulé : la longueur d’onde est de 12 cm à 2.455 GHz, et la distance 30 cm coïnciderait avec sa demi-longueur d’onde.''<br />
<br />
Par le biais de ces mesures, on a pu démontrer que le matériel a un impact sur le SNR en fonction de la distance. A ce stade nous ne pouvons toujours pas déceler si le XBEE est géré par un microcontrôleur ATMEGA328P ou un ATMEGA2560.. Peut-être que l'étude du SNR selon le canal d'émission nous apportera des réponses? <br />
<br />
'''Software''' : Il n'y a pas de différence notable à en sortir de l'expérience quant à la partie logicielle. Nous ne pouvons pas nous avancer sur l'influence du firmware sur la puissance du signal uniquement par cette expérience.<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
<br />
<br />
L'expérience s'effectue de la même manière que précédemment. L'algorithme utilisé est le même. Néanmoins, nous verrons comme le SNR varie ici non pas en fonction de la distance mais en fonction du canal choisi. Pour celà, on choisira 3 canaux : le canal 0x11 (17), le canal 0x13 (19) et le canal 0x15 (21).<br />
En effet, ces canaux n'ont pas été choisis aléatoirement. Lors de nos études, on a observé le XBee Pro ne transmettait pas sur certains canaux particuliers.<br />
<br />
Etait-ce dû à une erreur de manipulation ?<br />
<br />
Afin d'être sûr, on a pris des canaux qui était communs aux deux modèles (série S1 et Pro).<br />
<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 1</U></B>:<br />
<br />
<I>Les XBee1, XBee2, XBee3 et XBee4 sont connectés au PC et sont à 10 cm de l'antenne SDR. </I><br />
<br />
<I>Ils disposent du même firmware : 10ef </I><br />
<br />
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
Il n'y a pas réellement de conclusion à tirer dans ce contexte. On ne fait que confirmer la différence de SNR entre le XBee de série S1 et le XBee Pro, différence qu'on observait déjà lors de l'expérience précédente.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 2</U></B>:<br />
<br />
<I>Les XBee1 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560. Il se trouve à 10 cm de l'antenne SDR. </I><br />
<br />
<I>Ils disposent du même firmware : 10ef </I><br />
<br />
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
On observe que le rapport Signal Bruit lors de la transmission sur PC est supérieur au SNR transmis par l'ATMega328p et l'ATMega2560.<br />
On observe en plus une légère différence entre celui de l'ATMega328p et l'ATMega2560. La puissance des microprocesseurs se reflèterait-elle sur le signal ?<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
[[Fichier:XBEE4 SNR freq.png|thumb|400px|left]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B>:<br />
<br />
<I>Les XBee3 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560.</I><br />
<br />
<I>On réeffectue la même expérience avec le XBee4 </I><br />
<br />
<I>Ils disposent du même firmware : 10ef </I><br />
<br />
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I><br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
On observe la même chose que pour le contexte précédent, il y a une différence entre le SNR du XBee3 témoin et de celui relié aux micro-contrôleurs. L'erreur n'est pas à négliger, car la distance peut grandement influencer sur l'amplitude du signal. On considère une marge d'erreur de +-0,2cm lors de cette expérience, celà même si les résultats ne s'opposent à ceux du contexte précédent.<br />
Pour le XBee3 et XBee4, les phénomènes sont semblables.<br />
Celà nous conforte dans l'identité d'une identité électromagnétique pour un matériel.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience </U></B>:<br />
<br />
Après avoir comparé tous les graphes, on peut dire que systématiquement la puissance émise selon les canaux est la même pour chaque hardware : <br />
SNR_série > SNR_ATMEGA2560 > SNR_ATMEGA328<br />
Cependant, les courbes ne suivent pas un pattern caractéristique qui permettrait à l’aide à l’identification du matériel. Si par exemple deux XBEE émettent avec un hardware différent, on pourra seulement conclure « Les XBEE n’utilisent pas le même matériel pour émettre ». Dans un contexte particulier, on pourrait distinguer le nombre de modules sans néanmoins les identifier.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Conclusion du projet=<br />
<br />
Durant ce projet, nous avons cherché à determiner l'impact potentiel du matériel et informatique sur le champ électromagnétique. Dans l'idée commune, le signal émis par une antenne de même type est censé être le même, afin de le démoduler correctement au niveau de la reception. Néanmoins, il est très rare d'un point de physique d'avoir des signaux parfaitement identiques et celà dans les mêmes conditions expérimentales.<br />
<br />
On a pu voir que de nombreux facteurs témoignaient de potentielles - et il est important de souligner le terme potentielles - caractéristiques uniques provoquées non pas par l'antenne émettrice, mais par le matériel et/ou le logiciel. En effet, les conjectures émises en conclusion des expériences ne peuvent être validées de manière absolue, mais sont néanmoins la preuve d'une réelle influence du matériel et sont selon nous des pistes à développer (le modèle de boîte noire se rapporte à notre projet). <br />
<br />
Dans le cadre de notre projet, c'est l'antenne XBee qui a été étudiée.<br />
<br />
A l'issue de ces expériences, nous avons pu mettre en évidence de nombreux points :<br />
<br />
- les signaux émis par les XBee respectent les caractéristiques temporelles et fréquentielles données par leur datasheet (première expérience)<br />
<br />
- le firmware ne semble pas avoir pas de réel impact sur les signaux, ni sur la variation d'amplitude<br />
<br />
- le SNR témoigne de la puissance d'émission de l'antenne et permet de distinguer un module XBee Pro d'un module Xbee Série S1, permet aussi de différencier les signaux (sans nécessairement les identifier) et présente un potentiel gap entre un signal émis directement par série et un signal émis par un Arduino.<br />
<br />
- le temps de fragmentation d'un paquet transmis ainsi que le calcul du FCS montre un schéma pouvant potentiellement être unique à tout un chacun des composants.<br />
<br />
Nous aurions pu faire d'autres expériences pour nous conforter sur nos positions, néanmoins, nous n'avions pas trouvé d'autres d'idées qui pouvaient être réalisées avec nos outils (la variation de l'amplitude du signal nous a montré que le HackRF n'est pas exempt de défaut).<br />
<br />
<br />
Ce projet a été pour nous une expérience nouvelle. Là où la plupart des projets étaient plus orientés à la conception et la réalisation, avec un objectif bien défini, le notre lui était tout autre. En effet, l'approche était plus expérimentale et orientée vers la recherche.<br />
<br />
Les premières pistes de ce projet, bien qu'elles ne soient pas à négliger, se basaient sur les fuites électromagnétiques dispersées par les différents composants électroniques et informatiques d'un système. Néanmoins, avec le matériel et les compétences actuelles, il nous aurait été difficile de mener à bien ce projet de recherche et de poursuivre nos idées.<br />
Ainsi, le fait d'étudier les signaux directement par canal direct et non annexe (pas de CEM), nous permettant de chercher des potentielles caractéristiques uniques (le terme utilisé étant les clés) était donc la piste privilégiée.<br />
<br />
La difficulté n'en était pas amoindrie. De nombreux obstacles devaient être franchis.<br />
<br />
Tout d'abord, il nous a été nécessaire de nous initier à la radio logicielle, qui était l'outil principal pour mettre en oeuvre nos idées. Néanmoins, hormis dans le cadre de la démodulation de signaux et dans celui du Hacking (attaque radio, par replay etc...), il y a très peu de documentation au niveau de la radio logicielle et reste un domaine peu accessible au grand public (matériel et conditions d'acquisition obligent). Le procédé de recherches et les expériences nous ont donc été propre. <br />
<br />
Ce qui nous mène à la seconde difficulté : la mise en place du protocole de recherche. La caractérisation d'un signal ou d'une empreinte propre necessite de faire des tests qui peuvent mener ou alors à des pistes intéressantes voire concluantes, ou alors à des echecs.<br />
<br />
Dans notre cas, tout ne nous permettait pas de développer le sujet. <br />
La rencontre de Etienne Helluy Lafont a été pour nous d'une grande aide et nous a permis de savoir si les pistes qui avaient été développées étaient pertinentes ou non.<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts et codes utilisés : <br />
<br />
[[Fichier:Scripts.zip]]<br />
<br />
<br />
Le rapport<br />
<br />
[[Fichier:Rapport_projet_P70_2019.pdf]]<br />
<br />
=Bibliographie et liens=<br />
<br />
Datasheet XBee : https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf<br />
<br />
Wiki GNURadio : https://wiki.gnuradio.org/index.php/Main_Page<br />
<br />
Documentation Doxygen GNURadio (prototypes des fonctions python) : https://www.gnuradio.org/doc/doxygen/<br />
<br />
HackRF One: https://greatscottgadgets.com/hackrf/</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=75969IMA4 2018/2019 P702019-05-09T22:46:13Z<p>Amoreau : /* Documents Rendus */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13+ !! Total<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Préparation expérimentale (écriture de codes et scripts...) <br />
|0<br />
|0<br />
|2<br />
|3<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Etude et interprétation des résultats<br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
===Premières observations===<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 emet une chaîne de caractères HELLO*256 </I><br />
<br />
L'objectif de cette expérience est d'étudier le temps de variation de l'amplitude du signal entre l'état où le signal n'est pas reçu et l'état où le signal est réceptionné et donc l'amplitude constante.<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
A 20MHz de fréquence d'echantillonage, le temps de variation moyen est de 3 échantillons, soit 0.15µs, pour toutes les captures faîtes.<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
L'expérience n'a pas été concluante. 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. <br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
Néanmoins, l’étude de ces “temps morts” se voit entravée par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I><br />
<br />
<I> Le XBee1 dispose du firmware 10EF </I><br />
<br />
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I><br />
<br />
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.<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li><br />
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li><br />
</ul></div><br />
<br />
Pour les nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur ATMega328p sur 706 échantillons</U><br />
<br />
<U>Moyenne</U> : 265818.58<br />
<br />
<U>Ecart-type</U> : 4748.5965<br />
<br />
<U>Variance</U> : 22549168<br />
<br />
<br />
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U><br />
<br />
<U>Moyenne</U> : 262877.83<br />
<br />
<U>Ecart-type</U> : 3675.037<br />
<br />
<U>Variance</U> : 13505897<br />
<br />
<br />
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent. <br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I><br />
<br />
<I> On change le firmware du XBee1 pour le 10ED </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<br />
[[Fichier:FW10ED.png|thumb|left|400px|Observation du temps de division d'un paquet lors du changement du firmware]]<br />
<br />
<br />
<U>Xbee1 sur 821 échantillons</U><br />
<br />
<U>Moyenne</U> : 259735.52<br />
<br />
<U>Ecart-type</U> : 8501.3996<br />
<br />
<U>Variance</U> : 72273796<br />
<br />
<br />
Après avoir changé le firmware, on a pu voir que les résultats ne changeaient pas par rapport à l'expérience témoin. On est même très proche des temps du XBee bien que l'expérience ne s'est pas faîte dans les mêmes conditions (pas au même endroit, donc possibilité de perturbations).<br />
On peut donc en conclure que le firmware n'a pas un impact sur le temps de calcul du FCS.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.<br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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 quant aux expériences orientées SNR des Xbee.<br />
<br />
<br />
[[Fichier:SDRProgC.gif|center|Le programme sniffe l'environnement et renvoie les caractéristiques lors de la reception d'un signal]]<br />
<br />
L'avantage de l'utilisation de l'application nous permet directement de nous focaliser sur les paquets correctement reçus et non les données parasites qui peuvent perturber l'antenne. En effet, le programme reste à l'écoute de l'environnement électromagnétique sur une bande de fréquence autour de la fréquence d'écoute du HackRF. Lors de la reception d'un signal, le programme démodule le signal et vérifie si le CRC (ou le FCS pour le Frame Check Sequence) et les données concordent. Si c'est le cas, le CRC nous renvoie 1. Il s'agit là alors d'un signal. L'utilisation ainsi de ce programme nous permet de ne pas obtenir de valeurs parasites pour le SNR et filtrer directement les informations qui nous sont intéressantes.<br />
<br />
L'algorithme que nous avions écrit en Python est correct, néanmoins l'étude sur un signal enregistré requiert le chargement de l'intégralité du signal. Là où nos recherches se basent sur de la capture et du traitement post-capture, le travail d'Etienne se base sur un traitement du signal en temps-réel, ce qui nous permet ainsi de gagner un temps considérable.<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 sont des modèles série s1</I> disposent du firmware : 10EF<br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> : <br />
<br />
'''Hardware''' : Les paquets émis via liaison série ont plus de puissance que ceux émis grâce aux arduino UNO et MEGA notamment à 10 cm, 40 cm et 50 cm. On remarque aussi une baisse du SNR moyen à 30 cm surtout en liaison série et ce, avec nos quatres XBEE. Coté ATMEGA , le SNR reste plutôt stable et décroit très doucement. Ainsi lors d’un calcul de SNR/Distance on pourra estimer si le XBEE est connecté au PC en liaison série ou à une ATMEGA quelconque selon si son SNR suit l’allure ou non de la courbe de la transmission classique. <br />
<br />
''En cherchant des raisons à cela, on se demande si ce phénomène n’a pas un rapport avec la longueur d’onde du signal modulé : la longueur d’onde est de 12 cm à 2.455 GHz, et la distance 30 cm coïnciderait avec sa demi-longueur d’onde.''<br />
<br />
Par le biais de ces mesures, on a pu démontrer que le matériel a un impact sur le SNR en fonction de la distance. A ce stade nous ne pouvons toujours pas déceler si le XBEE est géré par un microcontrôleur ATMEGA328P ou un ATMEGA2560.. Peut-être que l'étude du SNR selon le canal d'émission nous apportera des réponses? <br />
<br />
'''Software''' : Il n'y a pas de différence notable à en sortir de l'expérience quant à la partie logicielle. Nous ne pouvons pas nous avancer sur l'influence du firmware sur la puissance du signal uniquement par cette expérience.<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
<br />
<br />
L'expérience s'effectue de la même manière que précédemment. L'algorithme utilisé est le même. Néanmoins, nous verrons comme le SNR varie ici non pas en fonction de la distance mais en fonction du canal choisi. Pour celà, on choisira 3 canaux : le canal 0x11 (17), le canal 0x13 (19) et le canal 0x15 (21).<br />
En effet, ces canaux n'ont pas été choisis aléatoirement. Lors de nos études, on a observé le XBee Pro ne transmettait pas sur certains canaux particuliers.<br />
<br />
Etait-ce dû à une erreur de manipulation ?<br />
<br />
Afin d'être sûr, on a pris des canaux qui était communs aux deux modèles (série S1 et Pro).<br />
<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 1</U></B>:<br />
<br />
<I>Les XBee1, XBee2, XBee3 et XBee4 sont connectés au PC et sont à 10 cm de l'antenne SDR. </I><br />
<br />
<I>Ils disposent du même firmware : 10ef </I><br />
<br />
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
Il n'y a pas réellement de conclusion à tirer dans ce contexte. On ne fait que confirmer la différence de SNR entre le XBee de série S1 et le XBee Pro, différence qu'on observait déjà lors de l'expérience précédente.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 2</U></B>:<br />
<br />
<I>Les XBee1 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560. Il se trouve à 10 cm de l'antenne SDR. </I><br />
<br />
<I>Ils disposent du même firmware : 10ef </I><br />
<br />
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
On observe que le rapport Signal Bruit lors de la transmission sur PC est supérieur au SNR transmis par l'ATMega328p et l'ATMega2560.<br />
On observe en plus une légère différence entre celui de l'ATMega328p et l'ATMega2560. La puissance des microprocesseurs se reflèterait-elle sur le signal ?<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
[[Fichier:XBEE4 SNR freq.png|thumb|400px|left]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B>:<br />
<br />
<I>Les XBee3 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560.</I><br />
<br />
<I>On réeffectue la même expérience avec le XBee4 </I><br />
<br />
<I>Ils disposent du même firmware : 10ef </I><br />
<br />
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I><br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
On observe la même chose que pour le contexte précédent, il y a une différence entre le SNR du XBee3 témoin et de celui relié aux micro-contrôleurs. L'erreur n'est pas à négliger, car la distance peut grandement influencer sur l'amplitude du signal. On considère une marge d'erreur de +-0,2cm lors de cette expérience, celà même si les résultats ne s'opposent à ceux du contexte précédent.<br />
Pour le XBee3 et XBee4, les phénomènes sont semblables.<br />
Celà nous conforte dans l'identité d'une identité électromagnétique pour un matériel.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience </U></B>:<br />
<br />
Après avoir comparé tous les graphes, on peut dire que systématiquement la puissance émise selon les canaux est la même pour chaque hardware : <br />
SNR_série > SNR_ATMEGA2560 > SNR_ATMEGA328<br />
Cependant, les courbes ne suivent pas un pattern caractéristique qui permettrait à l’aide à l’identification du matériel. Si par exemple deux XBEE émettent avec un hardware différent, on pourra seulement conclure « Les XBEE n’utilisent pas le même matériel pour émettre ». Dans un contexte particulier, on pourrait distinguer le nombre de modules sans néanmoins les identifier.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Conclusion du projet=<br />
<br />
Durant ce projet, nous avons cherché à determiner l'impact potentiel du matériel et informatique sur le champ électromagnétique. Dans l'idée commune, le signal émis par une antenne de même type est censé être le même, afin de le démoduler correctement au niveau de la reception. Néanmoins, il est très rare d'un point de physique d'avoir des signaux parfaitement identiques et celà dans les mêmes conditions expérimentales.<br />
<br />
On a pu voir que de nombreux facteurs témoignaient de potentielles - et il est important de souligner le terme potentielles - caractéristiques uniques provoquées non pas par l'antenne émettrice, mais par le matériel et/ou le logiciel. En effet, les conjectures émises en conclusion des expériences ne peuvent être validées de manière absolue, mais sont néanmoins la preuve d'une réelle influence du matériel et sont selon nous des pistes à développer (le modèle de boîte noire se rapporte à notre projet). <br />
<br />
Dans le cadre de notre projet, c'est l'antenne XBee qui a été étudiée.<br />
<br />
A l'issue de ces expériences, nous avons pu mettre en évidence de nombreux points :<br />
<br />
- les signaux émis par les XBee respectent les caractéristiques temporelles et fréquentielles données par leur datasheet (première expérience)<br />
<br />
- le firmware ne semble pas avoir pas de réel impact sur les signaux, ni sur la variation d'amplitude<br />
<br />
- le SNR témoigne de la puissance d'émission de l'antenne et permet de distinguer un module XBee Pro d'un module Xbee Série S1, permet aussi de différencier les signaux (sans nécessairement les identifier) et présente un potentiel gap entre un signal émis directement par série et un signal émis par un Arduino.<br />
<br />
- le temps de fragmentation d'un paquet transmis ainsi que le calcul du FCS montre un schéma pouvant potentiellement être unique à tout un chacun des composants.<br />
<br />
Nous aurions pu faire d'autres expériences pour nous conforter sur nos positions, néanmoins, nous n'avions pas trouvé d'autres d'idées qui pouvaient être réalisées avec nos outils (la variation de l'amplitude du signal nous a montré que le HackRF n'est pas exempt de défaut).<br />
<br />
<br />
Ce projet a été pour nous une expérience nouvelle. Là où la plupart des projets étaient plus orientés à la conception et la réalisation, avec un objectif bien défini, le notre lui était tout autre. En effet, l'approche était plus expérimentale et orientée vers la recherche.<br />
<br />
Les premières pistes de ce projet, bien qu'elles ne soient pas à négliger, se basaient sur les fuites électromagnétiques dispersées par les différents composants électroniques et informatiques d'un système. Néanmoins, avec le matériel et les compétences actuelles, il nous aurait été difficile de mener à bien ce projet de recherche et de poursuivre nos idées.<br />
Ainsi, le fait d'étudier les signaux directement par canal direct et non annexe (pas de CEM), nous permettant de chercher des potentielles caractéristiques uniques (le terme utilisé étant les clés) était donc la piste privilégiée.<br />
<br />
La difficulté n'en était pas amoindrie. De nombreux obstacles devaient être franchis.<br />
<br />
Tout d'abord, il nous a été nécessaire de nous initier à la radio logicielle, qui était l'outil principal pour mettre en oeuvre nos idées. Néanmoins, hormis dans le cadre de la démodulation de signaux et dans celui du Hacking (attaque radio, par replay etc...), il y a très peu de documentation au niveau de la radio logicielle et reste un domaine peu accessible au grand public (matériel et conditions d'acquisition obligent). Le procédé de recherches et les expériences nous ont donc été propre. <br />
<br />
Ce qui nous mène à la seconde difficulté : la mise en place du protocole de recherche. La caractérisation d'un signal ou d'une empreinte propre necessite de faire des tests qui peuvent mener ou alors à des pistes intéressantes voire concluantes, ou alors à des echecs.<br />
<br />
Dans notre cas, tout ne nous permettait pas de développer le sujet. <br />
La rencontre de Etienne Helluy Lafont a été pour nous d'une grande aide et nous a permis de savoir si les pistes qui avaient été développées étaient pertinentes ou non.<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts et codes utilisés : <br />
<br />
[[Fichier:Scripts.zip]]<br />
<br />
<br />
Le rapport<br />
<br />
[[Fichier:Rapport_projet_P70_2019.pdf]]<br />
<br />
=Bibliographie et liens=<br />
<br />
Datasheet XBee : https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Rapport_projet_P70_2019.pdf&diff=75968Fichier:Rapport projet P70 2019.pdf2019-05-09T22:45:31Z<p>Amoreau : Impact du matériel et du logiciel sur le champ électromagnétique</p>
<hr />
<div>Impact du matériel et du logiciel sur le champ électromagnétique</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=75720IMA4 2018/2019 P702019-05-09T12:51:20Z<p>Amoreau : /* Expérience : Variation de l'amplitude */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 emet une chaîne de caractères HELLO*256 </I><br />
<br />
L'objectif de cette expérience est d'étudier le temps de variation de l'amplitude du signal entre l'état où le signal n'est pas reçu et l'état où le signal est réceptionné et donc l'amplitude constante.<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
A 20MHz de fréquence d'echantillonage, le temps de variation moyen est de 3 échantillons, soit 0.15µs, pour toutes les captures faîtes.<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
L'expérience n'a pas été concluante. 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. <br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
Néanmoins, l’étude de ces “temps morts” se voit entravée par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I><br />
<br />
<I> Le XBee1 dispose du firmware 10EF </I><br />
<br />
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I><br />
<br />
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.<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li><br />
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li><br />
</ul></div><br />
<br />
Pour les nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur ATMega328p sur 706 échantillons</U><br />
<br />
<U>Moyenne</U> : 265818.58<br />
<br />
<U>Ecart-type</U> : 4748.5965<br />
<br />
<U>Variance</U> : 22549168<br />
<br />
<br />
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U><br />
<br />
<U>Moyenne</U> : 262877.83<br />
<br />
<U>Ecart-type</U> : 3675.037<br />
<br />
<U>Variance</U> : 13505897<br />
<br />
<br />
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent. <br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I><br />
<br />
<I> On change le firmware du XBee1 pour le 10ED </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<br />
[[Fichier:FW10ED.png|thumb|left|400px|Observation du temps de division d'un paquet lors du changement du firmware]]<br />
<br />
<br />
<U>Xbee1 sur 821 échantillons</U><br />
<br />
<U>Moyenne</U> : 259735.52<br />
<br />
<U>Ecart-type</U> : 8501.3996<br />
<br />
<U>Variance</U> : 72273796<br />
<br />
<br />
Après avoir changé le firmware, on a pu voir que les résultats ne changeaient pas par rapport à l'expérience témoin. On est même très proche des temps du XBee bien que l'expérience ne s'est pas faîte dans les mêmes conditions (pas au même endroit, donc possibilité de perturbations).<br />
On peut donc en conclure que le firmware n'a pas un impact sur le temps de calcul du FCS.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.<br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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.<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 sont des modèles série s1</I> disposent du firmware : 10EF<br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> : <br />
<br />
'''Hardware''' : Les paquets émis via liaison série ont plus de puissance que ceux émis grâce aux arduino UNO et MEGA notamment à 10 cm, 40 cm et 50 cm. On remarque aussi une baisse du SNR moyen à 30 cm surtout en liaison série et ce, avec nos quatres XBEE. Coté ATMEGA , le SNR reste plutôt stable et décroit très doucement. Ainsi lors d’un calcul de SNR/Distance on pourra estimer si le XBEE est connecté au PC en liaison série ou à une ATMEGA quelconque selon si son SNR suit l’allure ou non de la courbe de la transmission classique. <br />
<br />
''En cherchant des raisons à cela, on se demande si ce phénomène n’a pas un rapport avec la longueur d’onde du signal modulé : la longueur d’onde est de 12 cm à 2.455 GHz, et la distance 30 cm coïnciderait avec sa demi-longueur d’onde.''<br />
<br />
Par le biais de ces mesures, on a pu démontrer que le matériel a un impact sur le SNR en fonction de la distance. A ce stade nous ne pouvons toujours pas déceler si le XBEE est géré par un microcontrôleur ATMEGA328P ou un ATMEGA2560.. Peut-être que l'étude du SNR selon le canal d'émission nous apportera des réponses? <br />
<br />
'''Software''' : Le firmware affecte un peu la puissance d'émission<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
<br />
<br />
<br />
L'expérience s'effectue de la même manière que précédemment. L'algorithme utilisé est le même. Néanmoins, nous verrons comme le SNR varie ici non pas en fonction de la distance mais en fonction du canal choisi. Pour celà, on choisira 3 canaux : le canal 0x11 (17), le canal 0x13 (19) et le canal 0x15 (21).<br />
En effet, ces canaux n'ont pas été choisis aléatoirement. Lors de nos études, on a observé le XBee Pro ne transmettait pas sur certains canaux particuliers.<br />
<br />
Etait-ce dû à une erreur de manipulation ?<br />
<br />
Afin d'être sûr, on a pris des canaux qui était communs aux deux modèles (série S1 et Pro).<br />
<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 1</U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 2</U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 3</U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=75714IMA4 2018/2019 P702019-05-09T12:16:40Z<p>Amoreau : /* Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 emet une chaîne de caractères HELLO*256 </I><br />
<br />
L'objectif de cette expérience est d'étudier le temps de variation de l'amplitude du signal entre l'état où le signal n'est pas reçu et l'état où le signal est réceptionné et donc l'amplitude constante.<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
A 20MHz de fréquence d'echantillonage, le temps de variation moyen est de 3 échantillons, soit 0.15µs, pour toutes les captures faîtes.<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
L'expérience n'a pas été concluante. 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. <br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
Néanmoins, l’étude de ces “temps morts” se voit entravée par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I><br />
<br />
<I> Le XBee1 dispose du firmware 10EF </I><br />
<br />
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I><br />
<br />
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.<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li><br />
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li><br />
</ul></div><br />
<br />
Pour les nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur ATMega328p sur 706 échantillons</U><br />
<br />
<U>Moyenne</U> : 265818.58<br />
<br />
<U>Ecart-type</U> : 4748.5965<br />
<br />
<U>Variance</U> : 22549168<br />
<br />
<br />
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U><br />
<br />
<U>Moyenne</U> : 262877.83<br />
<br />
<U>Ecart-type</U> : 3675.037<br />
<br />
<U>Variance</U> : 13505897<br />
<br />
<br />
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent. <br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I><br />
<br />
<I> On change le firmware du XBee1 pour le 10ED </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<br />
[[Fichier:FW10ED.png|thumb|left|400px|Observation du temps de division d'un paquet lors du changement du firmware]]<br />
<br />
<br />
<U>Xbee1 sur 821 échantillons</U><br />
<br />
<U>Moyenne</U> : 259735.52<br />
<br />
<U>Ecart-type</U> : 8501.3996<br />
<br />
<U>Variance</U> : 72273796<br />
<br />
<br />
Après avoir changé le firmware, on a pu voir que les résultats ne changeaient pas par rapport à l'expérience témoin. On est même très proche des temps du XBee bien que l'expérience ne s'est pas faîte dans les mêmes conditions (pas au même endroit, donc possibilité de perturbations).<br />
On peut donc en conclure que le firmware n'a pas un impact sur le temps de calcul du FCS.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.<br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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.<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 sont des modèles série s1</I> disposent du firmware : 10EF<br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> : <br />
<br />
'''Hardware''' : Les paquets émis via liaison série ont plus de puissance que ceux émis grâce aux arduino UNO et MEGA notamment à 10 cm, 40 cm et 50 cm. On remarque aussi une baisse du SNR moyen à 30 cm surtout en liaison série et ce, avec nos quatres XBEE. Coté ATMEGA , le SNR reste plutôt stable et décroit très doucement. Ainsi lors d’un calcul de SNR/Distance on pourra estimer si le XBEE est connecté au PC en liaison série ou à une ATMEGA quelconque selon si son SNR suit l’allure ou non de la courbe de la transmission classique. <br />
<br />
''En cherchant des raisons à cela, on se demande si ce phénomène n’a pas un rapport avec la longueur d’onde du signal modulé : la longueur d’onde est de 12 cm à 2.455 GHz, et la distance 30 cm coïnciderait avec sa demi-longueur d’onde.''<br />
<br />
Par le biais de ces mesures, on a pu démontrer que le matériel a un impact sur le SNR en fonction de la distance. A ce stade nous ne pouvons toujours pas déceler si le XBEE est géré par un microcontrôleur ATMEGA328P ou un ATMEGA2560.. Peut-être que l'étude du SNR selon le canal d'émission nous apportera des réponses? <br />
<br />
'''Software''' : Le firmware affecte un peu la puissance d'émission<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
<br />
<br />
<br />
L'expérience s'effectue de la même manière que précédemment. L'algorithme utilisé est le même. Néanmoins, nous verrons comme le SNR varie ici non pas en fonction de la distance mais en fonction du canal choisi. Pour celà, on choisira 3 canaux : le canal 0x11 (17), le canal 0x13 (19) et le canal 0x15 (21).<br />
En effet, ces canaux n'ont pas été choisis aléatoirement. Lors de nos études, on a observé le XBee Pro ne transmettait pas sur certains canaux particuliers.<br />
<br />
Etait-ce dû à une erreur de manipulation ?<br />
<br />
Afin d'être sûr, on a pris des canaux qui était communs aux deux modèles (série S1 et Pro).<br />
<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 1</U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 2</U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<B><U>Contexte 3</U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Résultats </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience </U></B>:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=75685IMA4 2018/2019 P702019-05-09T11:47:41Z<p>Amoreau : /* Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
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. <br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
Néanmoins, l’étude de ces “temps morts” se voit entravée par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I><br />
<br />
<I> Le XBee1 dispose du firmware 10EF </I><br />
<br />
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I><br />
<br />
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.<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li><br />
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li><br />
</ul></div><br />
<br />
Pour les nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur ATMega328p sur 706 échantillons</U><br />
<br />
<U>Moyenne</U> : 265818.58<br />
<br />
<U>Ecart-type</U> : 4748.5965<br />
<br />
<U>Variance</U> : 22549168<br />
<br />
<br />
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U><br />
<br />
<U>Moyenne</U> : 262877.83<br />
<br />
<U>Ecart-type</U> : 3675.037<br />
<br />
<U>Variance</U> : 13505897<br />
<br />
<br />
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent. <br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I><br />
<br />
<I> On change le firmware du XBee1 pour le 10ED </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<br />
[[Fichier:FW10ED.png|thumb|left|400px|Observation du temps de division d'un paquet lors du changement du firmware]]<br />
<br />
<br />
<U>Xbee1 sur 821 échantillons</U><br />
<br />
<U>Moyenne</U> : 259735.52<br />
<br />
<U>Ecart-type</U> : 8501.3996<br />
<br />
<U>Variance</U> : 72273796<br />
<br />
<br />
Après avoir changé le firmware, on a pu voir que les résultats ne changeaient pas par rapport à l'expérience témoin. On est même très proche des temps du XBee bien que l'expérience ne s'est pas faîte dans les mêmes conditions (pas au même endroit, donc possibilité de perturbations).<br />
On peut donc en conclure que le firmware n'a pas un impact sur le temps de calcul du FCS.<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.<br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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.<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 sont des modèles série s1</I> disposent du firmware : 10EF<br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=75673IMA4 2018/2019 P702019-05-09T11:22:15Z<p>Amoreau : /* Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
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. <br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I><br />
<br />
<I> Le XBee1 dispose du firmware 10EF </I><br />
<br />
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I><br />
<br />
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.<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li><br />
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li><br />
</ul></div><br />
<br />
Pour les nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur ATMega328p sur 706 échantillons</U><br />
<br />
<U>Moyenne</U> : 265818.58<br />
<br />
<U>Ecart-type</U> : 4748.5965<br />
<br />
<U>Variance</U> : 22549168<br />
<br />
<br />
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U><br />
<br />
<U>Moyenne</U> : 262877.83<br />
<br />
<U>Ecart-type</U> : 3675.037<br />
<br />
<U>Variance</U> : 13505897<br />
<br />
<br />
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent. <br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I><br />
<br />
<I> On change le firmware du XBee1 pour le 10ED </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.<br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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.<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 sont des modèles série s1</I> disposent du firmware : 10EF<br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=75672IMA4 2018/2019 P702019-05-09T11:20:12Z<p>Amoreau : /* Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
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. <br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I><br />
<br />
<I> Le XBee1 dispose du firmware 10EF </I><br />
<br />
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I><br />
<br />
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.<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li><br />
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li><br />
</ul></div><br />
<br />
Pour les nouveaux échantillons, on a les caractéristiques suivantes :<br />
<br />
<U>Xbee1 sur ATMega328p sur 706 échantillons</U><br />
<br />
<U>Moyenne</U> : 265818.58<br />
<br />
<U>Ecart-type</U> : 4748.5965<br />
<br />
<U>Variance</U> : 22549168<br />
<br />
<br />
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U><br />
<br />
<U>Moyenne</U> : 262877.83<br />
<br />
<U>Ecart-type</U> : 3675.037<br />
<br />
<U>Variance</U> : 13505897<br />
<br />
<br />
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent. <br />
<br />
<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I><br />
<br />
<I> On change le firmware du XBee1 pour le 10ED </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.<br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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.<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=75573IMA4 2018/2019 P702019-05-09T09:20:13Z<p>Amoreau : /* Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
<br />
===Expérience : Variation de l'amplitude===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<B><U>Résultats </U></B> :<br />
<br />
<B><U>Conclusion sur l'expérience </U></B> :<br />
<br />
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. <br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B> :<br />
<br />
<br />
<nowiki><br />
def etudeAmplitude(name, liste_temps):<br />
<br />
threshold_0=0.05 # Threshold<br />
threshold_1=0.4<br />
max_transition_time=50 #O<br />
<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
p=1<br />
size=amppha.__len__()<br />
<br />
debut=1<br />
tps_variation=0 <br />
<br />
<br />
transition=False # Vérifie si le signal est en transition ou stable<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal<br />
if(transition==False):<br />
transition=True<br />
tps_variation=tps_variation+1<br />
<br />
elif(transition==True and amppha[val].real>threshold_1):<br />
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<br />
if(tps_variation < max_transition_time):<br />
liste_temps.append(tps_variation)<br />
<br />
transition=False<br />
tps_variation=0<br />
else:<br />
tps_variation=tps_variation+1<br />
else:<br />
transition=False<br />
tps_variation=0<br />
</nowiki><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Rencontre avec Etienne Helluy Lafont ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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.<br />
<br />
<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li><br />
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li><br />
</ul></div><br />
<br />
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. <br />
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. <br />
<br />
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).<br />
<br />
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. <br />
<br />
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]<br />
<br />
<br />
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. <br />
Pour chaque échantillon du signal, on calculait le SNR tel que :<br />
<br />
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center><br />
<br />
Dans notre cas, on a :<br />
<br />
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center><br />
<br />
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.<br />
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.<br />
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.<br />
Ainsi, on obtient les valeurs SNR cherchées.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 1</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I><br />
<br />
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I><br />
<br />
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I><br />
<br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]<br />
<br />
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.<br />
<br />
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.<br />
<br />
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]<br />
<br />
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é. <br />
<br />
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).<br />
<br />
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).<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<B><U>Contexte 2</U></B> :<br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee1 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<B><U>Contexte 3</U></B> :<br />
<br />
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I><br />
<br />
<I> 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 </I><br />
<br />
<I> Le XBee3 dispose du firmware : 10EF </I><br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]<br />
<br />
<br />
<B><U>Contexte 4</U></B> :<br />
<br />
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I><br />
<br />
<I> 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 </I><br />
<br />
<br />
<br />
<B><U>Résultats</U></B> :<br />
<br />
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é. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
<br />
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===<br />
<br />
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]<br />
<br />
<br />
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|right]]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<B><U>Code python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
def SNRStudy(name):<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
<br />
f = open(name+"_SNR_Values","a")<br />
<br />
p=1<br />
size = tmp.__len__()<br />
magnitude = (numpy.real(tmp)).tolist()<br />
<br />
threshold=10<br />
<br />
P=0<br />
SNR_graph=[]<br />
SNR=[]<br />
<br />
win_sz=64<br />
<br />
if(size>=win_sz):<br />
for val in range(0,size-win_sz):<br />
<br />
if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
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) )<br />
<br />
<br />
<br />
size=len(SNR_graph)<br />
<br />
for i in range(1, size-1):<br />
if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):<br />
SNR.append(SNR_graph[i])<br />
<br />
<br />
tmp=numpy.asarray(SNR)<br />
tmp.tofile(f)<br />
<br />
<br />
def main():<br />
try:<br />
SNRStudy(sys.argv[1])<br />
#except IndexError:<br />
#print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
</nowiki><br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74329IMA4 2018/2019 P702019-05-05T15:24:05Z<p>Amoreau : /* Rencontre avec un doctorant */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
===Expérience : SNR ===<br />
<br />
Maintenant nous voulons vérifier si la mesure du SNR est une expérience pertinente pour l'identification des xbee. Nous allons prendre plusieurs xbee , et nous les déplacerons dans la salle à des endroits précis. A chaque déplacement nous mesurerons le SNR grâce à notre algorithme. <br />
<br />
Ce script écrit en python permet de :<br />
<br />
=== Rencontre avec un doctorant ===<br />
<br />
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.<br />
<br />
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 [https://github.com/pothosware/SoapySDR/] 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.<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74260IMA4 2018/2019 P702019-05-04T11:05:45Z<p>Amoreau : /* Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
<br />
<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
===Expérience : SNR ===<br />
<br />
Maintenant nous voulons vérifier si la mesure du SNR est une expérience pertinente pour l'identification des xbee. Nous allons prendre plusieurs xbee , et nous les déplacerons dans la salle à des endroits précis. A chaque déplacement nous mesurerons le SNR grâce à notre algorithme. <br />
<br />
Ce script écrit en python permet de :<br />
<br />
=== Rencontre avec un doctorant ===<br />
<br />
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é la SDR d'un de nos signaux, nous nous sommes confrontés à des résultats assez incohérents. De nombreuses erreurs peuvent se glisser<br />
Ces semaines<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74259IMA4 2018/2019 P702019-05-04T11:03:14Z<p>Amoreau : /* Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
[Pseudo code ici]<br />
def etudeSubdivPaquet(name, inter_time_values):<br />
<br />
threshold = 0.30<br />
ground = false<br />
p=1<br />
<br />
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##<br />
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) <br />
<br />
<br />
## On récupère la taille du tableau de complexes (taille du signal) ##<br />
size=amppha.__len__()<br />
<br />
debut=0<br />
inter_time=0<br />
min_limit=150000<br />
max_limit=350000<br />
accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation<br />
signalFnd=False<br />
<br />
for val in range(debut,size):<br />
if(val>=((size-debut)/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
<br />
if(amppha[val].real>threshold):<br />
if(ground==True):<br />
if(signalFnd==True):<br />
if(len(inter_time_values)>0):<br />
moy=moyenne(inter_time_values)<br />
if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):<br />
print("Yes "+str(inter_time))<br />
inter_time_values.append(inter_time)<br />
inter_time=0<br />
elif(inter_time>=min_limit and inter_time<=max_limit):<br />
inter_time_values.append(inter_time)<br />
else:<br />
signalFnd=True<br />
ground=False<br />
else:<br />
ground=True<br />
if(signalFnd==True):<br />
inter_time=inter_time+1<br />
<br />
if(len(inter_time_values)>0):<br />
print("Moyenne "+ str(moyenne(inter_time_values)))<br />
</nowiki><br />
<br />
===Expérience : SNR ===<br />
<br />
Maintenant nous voulons vérifier si la mesure du SNR est une expérience pertinente pour l'identification des xbee. Nous allons prendre plusieurs xbee , et nous les déplacerons dans la salle à des endroits précis. A chaque déplacement nous mesurerons le SNR grâce à notre algorithme. <br />
<br />
Ce script écrit en python permet de :<br />
<br />
=== Rencontre avec un doctorant ===<br />
<br />
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é la SDR d'un de nos signaux, nous nous sommes confrontés à des résultats assez incohérents. De nombreuses erreurs peuvent se glisser<br />
Ces semaines<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74258IMA4 2018/2019 P702019-05-04T09:48:49Z<p>Amoreau : /* Expérience : SNR */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
[Pseudo code ici]<br />
</nowiki><br />
<br />
<br />
===Expérience : SNR ===<br />
<br />
Maintenant nous voulons vérifier si la mesure du SNR est une expérience pertinente pour l'identification des xbee. Nous allons prendre plusieurs xbee , et nous les déplacerons dans la salle à des endroits précis. A chaque déplacement nous mesurerons le SNR grâce à notre algorithme. <br />
<br />
Ce script écrit en python permet de :<br />
<br />
=== Rencontre avec un doctorant ===<br />
<br />
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é la SDR d'un de nos signaux, nous nous sommes confrontés à des résultats assez incohérents. De nombreuses erreurs peuvent se glisser<br />
Ces semaines<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74256IMA4 2018/2019 P702019-05-04T09:12:18Z<p>Amoreau : /* Semaines supplémentaires */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
[Pseudo code ici]<br />
</nowiki><br />
<br />
<br />
===Expérience : SNR ===<br />
<br />
Maintenant nous voulons vérifier si la mesure du SNR est une expérience pertinente pour l'identification des xbee. Nous allons prendre plusieurs xbee , et nous les déplacerons dans la salle aux mêmes endroits. A chaque déplacement nous veillerons à mesurer le SNR grâce à notre algorithme. <br />
Ce script écrit en python permet de : <br />
- Capturer les paquets émis<br />
<br />
<br />
<br />
=== Rencontre avec un doctorant ===<br />
<br />
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é la SDR d'un de nos signaux, nous nous sommes confrontés à des résultats assez incohérents. De nombreuses erreurs peuvent se glisser<br />
Ces semaines<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74254IMA4 2018/2019 P702019-05-04T09:04:30Z<p>Amoreau : /* Semaines supplémentaires */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
[Pseudo code ici]<br />
</nowiki><br />
<br />
<br />
===Expérience : SNR ===<br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74253IMA4 2018/2019 P702019-05-04T09:03:29Z<p>Amoreau : /* Documents Rendus */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
[Pseudo code ici]<br />
</nowiki><br />
<br />
=Documents Rendus=<br />
<br />
<br />
L'archive des scripts python : <br />
<br />
[archive.zip]<br />
<br />
<br />
Le rapport<br />
<br />
[Rapport.pdf]</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=74252IMA4 2018/2019 P702019-05-04T08:45:19Z<p>Amoreau : /* Semaines supplémentaires */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- 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)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
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).<br />
<br />
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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 9 et 10==<br />
<br />
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li><br />
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li><br />
</ul></div><br />
<br />
<br />
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. <br />
<br />
<nowiki><br />
#include <iostream><br />
import scipy<br />
import numpy<br />
import sys<br />
<br />
def binToComplex64(name):<br />
threshold=0.10<br />
tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)<br />
tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)<br />
<br />
f2 = open(name+"_filtre", "w+") <br />
f = open(name+"_PhaseMeg_filtre","w+")<br />
<br />
p=1<br />
size=tmp.__len__()<br />
size2=tmp2.__len__()<br />
<br />
if size > size2:<br />
size=size2<br />
<br />
<br />
ground=False<br />
newListSignal=[]<br />
newListMagnPh=[]<br />
for val in range(0,size): <br />
if(val>=(size/100)*p):<br />
print(str(p)+" %")<br />
p=p+1<br />
if(tmp[val].real>threshold):<br />
if(ground==True):<br />
for i in range(0,1000):<br />
newListSignal.append(numpy.complex64(0))<br />
newListMagnPh.append(numpy.complex64(0))<br />
ground=False<br />
newListSignal.append(tmp2[val])<br />
newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))<br />
else:<br />
ground=True<br />
<br />
tmp=numpy.asarray(newListMagnPh)<br />
tmp.tofile(f)<br />
tmp2=numpy.asarray(newListSignal) <br />
tmp2.tofile(f2)<br />
<br />
<br />
def main():<br />
try:<br />
binToComplex64(sys.argv[1])<br />
except IndexError:<br />
print("Donnez le nom du fichier\n")<br />
except IOError:<br />
print("Le fichier n'existe pas\n")<br />
<br />
<br />
<br />
if __name__=='__main__':<br />
main()<br />
<br />
</nowiki><br />
<br />
<br />
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.<br />
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.<br />
<br />
==Semaine 11==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
==Semaines supplémentaires==<br />
<br />
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===<br />
<br />
<B><U>Contexte</U></B> :<br />
<br />
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I><br />
<br />
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I><br />
<br />
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I><br />
<br />
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs<br />
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.<br />
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.<br />
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.<br />
<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]] </li><br />
</ul></div><br />
<br />
<br />
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.<br />
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.<br />
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.<br />
Pour régler ce problème, on a écrit un script shell de capture.<br />
Ce script consiste à:<br />
<br>- effectuer une capture d’une durée de 1 sec<br />
<br>- d’enregistrer la capture<br />
<br>- 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<br />
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier<br />
<br>- on réeffectue la capture …<br />
<br />
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)<br />
<br />
La capture et l'étude de chacun des modules dure une à deux heures.<br />
<br />
<B><U>Résultats :</U></B><br />
<br />
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :<br />
<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li><br />
</ul></div><br />
<br />
<br />
XBee1 : <br />
<br />
<U>Moyenne</U> : 259675,81<br />
<br />
<U>Ecart-type</U> : 8369.7417<br />
<br />
<U>Variance</U> : 70052576.<br />
<br />
<br />
XBee2:<br />
<br />
<U>Moyenne</U> : 258762.58<br />
<br />
<U>Ecart-type</U> : 9165.4097<br />
<br />
<U>Variance</U> : 84004736.<br />
<br />
<br />
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.<br />
<br />
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, <br />
<br />
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.<br />
<br />
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.<br />
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.<br />
<br />
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.<br />
<br />
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.<br />
<br />
<br />
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.<br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]] </li><br />
</ul></div><br />
<br />
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :<br />
<U>Xbee1 sur 1688 échantillons</U><br />
<br />
<U>Moyenne</U> : 260230.3<br />
<br />
<U>Ecart-type</U> : 8427.3923<br />
<br />
<U>Variance</U> : 71020941<br />
<br />
<br />
<U>Xbee2 sur 1722 échantillons</U><br />
<br />
<U>Moyenne</U> : 259899.41<br />
<br />
<U>Ecart-type</U> : 9831.5106<br />
<br />
<U>Variance</U> : 96658601<br />
<br />
<br />
<br />
<B><U>Conclusion de l'expérience</U></B> :<br />
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. <br />
<br />
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.<br />
<br />
<br />
<br />
<B><U>Algorithme python utilisé pour l'étude du signal</U></B>:<br />
<nowiki><br />
[Pseudo code ici]<br />
</nowiki><br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73742IMA4 2018/2019 P702019-04-25T20:26:32Z<p>Amoreau : /* Semaine 10 et + */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
[[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]]<br />
[[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]]<br />
A partir de la semaine 10 nous n'avons fait qu’enchaîner les expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<br />
<br />
L'utilisation du script LightSignal permet de retirer toutes les phases en dehors du signal. Ainsi on peut bien observer le diagramme de constellation.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73741IMA4 2018/2019 P702019-04-25T20:26:19Z<p>Amoreau : /* Semaine 10 et + */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
[[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]<br />
[[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]<br />
A partir de la semaine 10 nous n'avons fait qu’enchaîner les expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<br />
<br />
L'utilisation du script LightSignal permet de retirer toutes les phases en dehors du signal. Ainsi on peut bien observer le diagramme de constellation.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73740IMA4 2018/2019 P702019-04-25T20:25:51Z<p>Amoreau : /* Semaine 10 et + */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
[[Fichier:Traitement xbee2.png|thumb|right|redresse=2]|Signal Xbee2 post-traitement ]<br />
[[Fichier:Constellation xbee2.png|thumb|right|redresse=2] | Diagramme de constellation xbee2 après utilisation de LightSignal]<br />
A partir de la semaine 10 nous n'avons fait qu’enchaîner les expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
<br />
<br />
<br />
L'utilisation du script LightSignal permet de retirer toutes les phases en dehors du signal. Ainsi on peut bien observer le diagramme de constellation.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73739IMA4 2018/2019 P702019-04-25T20:22:57Z<p>Amoreau : /* Semaine 10 et + */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
<br />
A partir de la semaine 10 nous n'avons fait qu’enchaîner les expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
[[Fichier:Traitement xbee2.png|thumb|left|redresse=2]]<br />
<br />
<br />
L'utilisation du script LightSignal permet de retirer toutes les phases en dehors du signal. Ainsi on peut bien observer le diagramme de constellation.<br />
<br />
[[Fichier:Constellation xbee2.png|thumb|left|redresse=2]]<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Constellation_xbee2.png&diff=73738Fichier:Constellation xbee2.png2019-04-25T20:22:47Z<p>Amoreau : </p>
<hr />
<div></div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73737IMA4 2018/2019 P702019-04-25T20:20:24Z<p>Amoreau : /* Semaine 10 et + */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
<br />
A partir de la semaine 10 nous n'avons fait qu’enchaîner les expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
[[Fichier:Traitement xbee2.png|thumb|left|redresse=2]]<br />
<br />
<br />
<br />
<br />
<br />
.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73736IMA4 2018/2019 P702019-04-25T20:20:14Z<p>Amoreau : /* Semaine 10 et + */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
<br />
A partir de la semaine 10 nous n'avons fait qu’enchaîner les expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
[[Fichier:Traitement xbee2.png|thumb|left|redresse=2]]<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73735IMA4 2018/2019 P702019-04-25T20:15:55Z<p>Amoreau : /* Semaine 10 et + */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
<br />
A partir de la semaine 10 nous n'avons fait qu’enchaîner les expériences pour avoir suffisamment de données et en tirer des conclusions.<br />
<br />
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.<br />
<br />
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :<br />
[[Fichier:Traitement xbee2.png]]<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Traitement_xbee2.png&diff=73734Fichier:Traitement xbee2.png2019-04-25T20:14:15Z<p>Amoreau : Amoreau a téléversé une nouvelle version de Fichier:Traitement xbee2.png</p>
<hr />
<div></div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Traitement_xbee2.png&diff=73733Fichier:Traitement xbee2.png2019-04-25T20:06:58Z<p>Amoreau : </p>
<hr />
<div></div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=73732IMA4 2018/2019 P702019-04-25T19:53:08Z<p>Amoreau : /* Réalisation du Projet */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|3<br />
|4<br />
|3<br />
|4<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|2<br />
|1<br />
|1<br />
|1<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|-<br />
|Expériences<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|1<br />
|3<br />
|3<br />
|5<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
<br />
==Semaine 9==<br />
<br />
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).<br />
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.<br />
En effet, le Xbee transmet toutes les 100ms.<br />
Donc qu'une partie du signal nous est utile.<br />
<br />
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.<br />
<br />
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> 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.<br />
<br />
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:<br />
<br />
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code><br />
<br />
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.<br />
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.<br />
<br />
== Semaine 10 et + ==<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Discussion:Projets_IMA4_SC_%26_SA_2018/2019&diff=71903Discussion:Projets IMA4 SC & SA 2018/20192019-03-27T17:33:45Z<p>Amoreau : /* Présence */</p>
<hr />
<div>== Répartition des binômes ==<br />
<br />
{| class="wikitable"<br />
| Projet || Analyse || Matériel || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo<br />
|-<br />
| P9 [[IMA4 2018/2019 P9|Spider and I]]<br />
| La description des "concurrents" aurait pu être plus précise. Un effort sur le scénario d'usage qui aurait, lui aussi, pu être développé. Des coquilles. Un vague plan de travail.<br />
| Rien ou presque, fournisseur non utilisable.<br />
|<br />
| N'utilisez pas le mode "code" (espace en première colonne) pour distinguer une ligne. Une progression régulière mais il faudrait résoudre les problèmes soulevés à la semaine 7. Le travail à réaliser est assez simple, un résultat parfait est attendu.<br />
|<br />
|<br />
|<br />
|-<br />
| P10 [[IMA4 2018/2019 P10|Capteur de niveau d'eau et de pollution]]<br />
| Des coquilles. Bonne description des concurrents. Un effort pour le scénario, bonne mise en contexte, forcer sur la description de l'usage. Un plan de travail correct.<br />
| Une liste préliminaire de matériels. Fournisseurs correctement choisis. Rien sur la page principale.<br />
|<br />
| <font color="red">Coquilles inacceptables dans le Wiki</font>. <font color="orange">Wiki assez vide. Il est à espérer que le projet est plus avancé !</font>.<br />
|<br />
|<br />
|<br />
|-<br />
| P12 [[IMA4 2018/2019 P12|Recyclage plastique imprimante 3D]]<br />
| Vous êtes sur pour les servo-moteurs ? Ne serait-ce point des moteurs pas à pas ? Très bonne description du produit à réaliser avec illustrations. Bel effort de rédaction, encore pas mal de coquilles surtout en fin de page. Bonne étude des concurrents. Un scénario d'usage un peu rapide qui ne donne pas assez envie d'acquérir le produit. Questions difficiles mal exploitées (une réponse à la première question pourrait aussi être "par l'expérience", pas de réponse à la seconde question). Une étude solide du projet même si la liste des tâches à effectuer manque.<br />
| Bonne question sur le budget, mais posez la si vous voulez une réponse :D Liste de matériel encore très embryonnaire : rien sur l'électronique, une discussion avec votre encadrant s'impose pour fixer la partie mécanique.<br />
|<br />
| <font color="green">Wiki très bien tenu mais corrigez les quelques coquilles. Avancé du travail bien présenté.</font> Vous devez toujours me présenter la note pour les matériels achetés chez Leroy-Merlin.<br />
|<br />
|<br />
|<br />
|-<br />
| P13 [[IMA4 2018/2019 P13|Emetteur / Récepteur analogique en bande 5725-5875 MHz]]<br />
| Un seul concurrent. Scénario d'usage ne donnant probablement pas la pleine mesure du produit. <font color="red">Rien sur la planification</font>.<br />
| <font color="red">Rien.</font><br />
|<br />
| <font color="red">Rien. Votre travail n'est pas évaluable. Votre projet est en péril.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P14 [[IMA4 2018/2019 P14|Voiture autonome en modèle réduit]]<br />
| Il me semble que le chassis doit être celui d'un modèle radio-commandé existant. Il me semble que le pilotage manuel n'est pas autorisé. Description un peu rapide des concurrents. Une synthèse du matériel et logiciels employés aurait été intéressant. Pour le scénario d'usage, une description avec la voiture comme sujet aurait être plus intéressant. La réponse à la première question ne va pas dans le sens de l'autonomie. Dire que python est le langage par défaut de la RPi n'a pas de sens. Vous avez tout intérêt à prendre le langage le plus efficace est ce n'est probablement pas python. Pas de servo-moteurs continus sur une voiture radio-commandé. Pas vraiement de plan de travail. <font color="orange">Prenez contact avec votre encadrant direct, j'aimerais que vos choix soient validés, certains me paraissent discutables.</font><br />
| Aucune référence précise pour les matériels. Rien sur la page principale.<br />
|<br />
| Wiki moyen, peu dense, très peu illustré. Vous partez comme les IMA5 sur une solution de votre cru alors que vous n'avez aucune expérience en réseaux de neurones. Il est à craindre que le résultat final soit décevant.<br />
|<br />
|<br />
|<br />
|-<br />
| P22 [[IMA4 2018/2019 P22|Secure And Verified Public Announcements through Blockchain]]<br />
| <font color="green">Excellente rédaction.</font> Une bonne tentative de description du projet mais toujours un flou sur le travail à réaliser. Cela aurait pu être levé avec une liste précise des tâches à effectuer (une tentative de liste dans les objectifs).<br />
| Pas de matériel nécessaire (une RPi peut être).<br />
|<br />
| <font color="green">Un wiki très propre. Travail effectué décrit.</font>. Il manque juste l'information sur la validation du prototype 0 par l'encadrant direct.<br />
|<br />
|<br />
|<br />
|-<br />
| P26 [[IMA4 2018/2019 P26|Discussion pair à pair]]<br />
| <font color="red">Nombre de coquilles inacceptable</font>. Rajouter dans les objectifs de devoir tenter une ouverture de bouclier pour TCP (TCP Hole Punching). Analyse du premier concurrent : le prétexte pour n'utiliser que des serveurs microsoft pour les supernoeuds skype est le faible nombre de machines d'utilisateurs non handicapées par des parefeux. Bonne réponse aux questions difficile. L'expérience de skype dit qu'il faut totalement éviter qu'un noeud utilisateur ait à relayer les communications d'un autre utilisateur (ce qui est d'ailleurs contraire aux objectifs). Il faut donc une solution de pair à pair pour '''tous''' les clients. En particulier, IPv6 '''doit''' être intégré dans les solutions possibles. Il ne me semble pas que l'enregistrement des utilisateurs soit nécessaire, elle nuit même à la vie privée. Il faut simplement mémoriser les utilisateurs connectés. <br />
| Pas de matériel listé pourtant il faut mettre en place un banc d'essai.<br />
|<br />
| <font color="red">Coquilles inacceptables dans le Wiki</font>. <font color="orange">En fin de projet vous avez seulement mis en place le banc de test sans aucun développement d'un système de perçage de box que ce soit en UDP ou en TCP</font>.<br />
|<br />
|<br />
|<br />
|-<br />
| P28 [[IMA4 2018/2019 P28|Affichage à billes]]<br />
| Pour les panneaux d'affichage publicitaire, je ne suis pas sur que la consommation puisse être qualifiée d'énorme (il semble que si, à la lecture de votre réponse aux questions difficiles mais cela doit comprendre l'éclairage dont votre produit pourrait avec aussi besoin). <font color='green'>Rédaction très correcte. Un gros effort sur les illustrations. Un scénario d'usage, lui aussi, bien rédigé</font>. La réponse à la question difficile sur l'énergie consommée par votre produit ne me convainc pas : partez sur la différence d'énergie potentielle pour monter une bille pas sur la force à exercer qu'il faudrait intégrer sur la hauteur de la remontée. Il faut approfondir l'analyse des tâches à effectuer.<br />
| Il me semble avoir demandé de limiter la complexité du dispositif : 8 moteurs ?? Pas de références précises pour les matériels (lien sur le matériel dans le site du fournisseur).<br />
|<br />
| <font color="green">Très bon Wiki. Avancé du travail très bien présenté.</font> On attend avec impatience le résultat des tests sur le prototype "carton".<br />
|<br />
|<br />
|<br />
|-<br />
| P30 [[IMA4 2018/2019 P30|Système minimal de gestion de conteneurs]]<br />
| <font color="green">Excellent Wiki à ce jour. Rédaction très claire. Très bonne introduction. Tâches à réalisées clairement listées (mais dans les objectifs). Présentation très correcte du "concurrent principal". Un scénario d'usage correct (j'aurais plutôt insisté sur la faible consommation du système en ressources que sur l'installation dans un système fortement personnalisé). Un calendrier prévisionnel.</font> Le second "concurrent" est en fait l'ancienne couche bas niveau de <code>Docker</code>. Il faudrait utiliser la syntaxe Wiki mais ne touchez à rien avant la séance du 10 décembre cela me fera un exemple parfait pour expliquer cette syntaxe.<br />
| Pas de matériel nécessaire (une machine virtuelle sera concédée en cours de projet).<br />
|<br />
| <font color="green">Wiki très complet et très propre. Avancé du travail bien présenté.</font> Il faut arriver à finaliser les scripts de gestion des conteneurs. <br />
|<br />
|<br />
|<br />
|-<br />
| P31 [[IMA4 2018/2019 P31|Robot hexapode de mesure de RSSI WiFi]]<br />
| <font color="red">Beaucoup trop de coquilles</font>. Bonne présentation des "concurrents" qui vous servent aussi pour expliquer que votre projet est leur synthèse. Le scénario d'usage se tient. Bonne réponse à la question. Je ne crois pas trop au positionnement par RFID (il faut être sur un tag RFID pour le lire). Etes-vous sur pour l'Arduino méga ? Un Uno avec un bouclier PWM ne serait-il pas plus efficace ?<br />
| <font color="green">Effort de liste de matériel avec des références précises</font>. Pas de liste sur la page principale.<br />
|<br />
| <font color="orange">N'utilisez pas le mode "code" de mediawiki (espace en première colonne) pour distinguer des lignes. Utilisez la syntaxe pour les items. Wiki très peu dense. L'avancement du projet semble être suspendu.</font> Un bel effort pour la partie mécanique (les pattes du robot). Par contre la partie programmation semble très peu avancée.<br />
|<br />
|<br />
|<br />
|-<br />
| P32 [[IMA4 2018/2019 P32|Robe augmentée]]<br />
| En français l'abréviation de Monsieur est M. Mr est l'abrévation de Mister donc à n'utiliser qu'en anglosaxonnerie. Attention nous avons une expérience du fil à coudre conducteur et cela ne marche pas très bien sauf sur une surface très réduite. <font color="orange">Le scénario d'usage est perturbant : cela semble être un scénario pour deux produits différents</font>. <font color="orange">Vous avez considérablement simplifié le projet (sous-ensemble de projets déjà réalisés), la réalisation devra être impeccable pour que cela puisse être validé comme projet IMA4</font>.<br />
| La liste du matériel précise ce que vous souhaitez faire. Que vient faire la platine d'essai dans cette liste ? Pour le prototype ? Vous ne parlez pas du tout de la carte contrôleur. C'est une Lilypad ?<br />
|<br />
| Wiki bien illustré mais une rédaction séche. Développez un peu. OK pour les cartes électroniques mais vous devriez présenter une esquisse de la robe telle que vous souhaitez la réaliser.<br />
|<br />
|<br />
|<br />
|-<br />
| P33 [[IMA4 2018/2019 P33|Collier à animations lumineuses]]<br />
| Un français imaginatif avec un nombre de coquilles dans la moyenne. Un scénario d'usage rocambolesque (il doit me manquer quelques références) mais acceptable. Des concurrents pertinents. Réponses aux questions acceptables. Se limiter à trois plaques ne me semble pas pertinent (même si vous pouvez faire un premier test sur trois plaques). Pour l'étude de la communication prévoyez un prototype avec quelques Arduino.<br />
| Une liste de matériel qui semble être établie à la hâte. Il manque de nombreux composants électroniques pour faire tourner micro-contrôleurs et pilotes de LED. Pas de référence précise pour les composants.<br />
|<br />
| <font color="red">Rien sur votre travail, il n'est donc pas évaluable. Votre projet est en péril.</font> Vous devriez avoir fait les tests de communication sur le bus SPI et avoir conçu votre PCB.<br />
|<br />
|<br />
|-<br />
| P35 [[IMA4 2018/2019 P35|Machine Learning pour navigation autonome de robots mobiles]]<br />
| Il n'est pas tenu compte des erreurs de français. Dans la partie objectifs, la première sous-partie devrait plutôt s'appeler "partie robotique", il n'y a rien d'électronique ici. Le travail a effectuer est assez flou. En particulier le Wiki ne contient rien sur les bibliothèques de "machine learning" à utiliser.<br />
| Le matériel est fourni par les encadrants directs (AIP ?)<br />
|<br />
| <font color="red">J'ai peur que votre Wiki rende bien compte du travail effectué jusque là : uniquement des études, rien de concret à part utiliser une manette pour acquérir des jeux de données. C'est très inquiétant en cette période de fin de projet. Votre projet pourrait ne pas être validé.</font> <br />
|<br />
|<br />
|<br />
|-<br />
| P37 [[IMA4 2018/2019 P37|Station de recharge intelligente pour robot mobile]]<br />
| Trop de coquilles. <font color="orange">Il semble que le sujet initial ne correspond plus à ce qui est demandé, merci de préciser le nouveau sujet, calibrage du robot ?</font>Comment comptez-vous calibrer un préhenseur avec simplement du code (pas de réponse au niveau de la question difficile) ? <font color="red">Un seul concurrrent et sur la partie obsolète du projet</font>. Une analyse du travail a effectuer qui ne tient pas compte de l'abandon du sujet original.<br />
| <font color="red">Aucune liste de matériel</font><br />
|<br />
| Rien à redire sur votre Wiki. Il me semble bien rendre compte de l'avancé de votre projet. <font color="red">Une liste de matériel finalisée en fin de projet : vous prenez de grands risques. Je vous rappelle qu'un prototype fonctionnel est attendu.</font><br />
|<br />
|<br />
|-<br />
| P38 [[IMA4 2018/2019 P38|Interface Graphique pour Robotino 2 Upgradé]]<br />
| Choix des "concurrents" peu pertinents ou il fallait insister sur les différences entre ces robots et le robotino 2 amélioré. Le scénario d'usage se tient. Bonne réponse à la question "difficile". Il semble que le but du projet se réduise à créer une interface web avec une bibliothèque spécifique. <font color="orange">L'interface devra être irréprochable pour constituer un projet IMA4</font>.<br />
| Projet purement informatique, pas de matériel nécessaire (autre qu'un robotino amélioré).<br />
|<br />
| <font color="orange">N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Corrigez les coquilles ! En cette fin de projet vous semblez bien peu avancés sur l'interface Web. Rien sur la démonstration de fonctionnement du robotino que vous devez implanter. Il va falloir diantrement accélérer !</font><br />
|<br />
|<br />
|<br />
|-<br />
| P40 [[IMA4 2018/2019 P40|RFID/NFC]]<br />
| L'objectif est clairement explicité et dans un français très correct. Desc concurrents peu pertinents et une analyse trop hâtive des dits concurrents. La réponse sur la question de la difficulté du projet n'est pas convaincante. <font color="orange">Votre application de contrôle du robotino par smartphone se devra d'être irréprochable pour constituer un projet IMA4</font>.<br />
| Attention, tout votre projet repose sur la validité des lecteur RFID commandés. Si ces lecteurs ne sont pas utilisables votre projet tombe à l'eau. Vous avez étudié la compatibilité des lecteurs avec les robotino ?<br />
|<br />
| Vous semblez avoir avancé dans votre projet mais vos dernières entrées dans le Wiki sont trop courtes pour permettre de juger. Etoffez votre Wiki en décrivant mieux cette application (copies d'écrans). Je ne vois aucune trace de la partie de connexion IP automatique via NFC au robotino ?<br />
|<br />
|<br />
|<br />
|-<br />
| P42 [[IMA4 2018/2019 P42|Coupe de robotique des écoles primaires]]<br />
| <font color="red">Beaucoup trop de coquilles</font>. Objectifs très clairement précisés. Analyse des concurrents et réponse lapidaires. Le fait que vous ne respectiez pas le cahier des charges imposé aux enfants est problématique. <font color="green">Une liste précise des tâches a effectuer. Un calendrier prévisionnel.</font><br />
| Bel effort de liste de matériel. Quelques composants chez des fournisseurs non agréés. <font color="green">Liste sur la page principale</font>.<br />
|<br />
| <font color="green">Wiki plus que correct qui donne bien une idée de la progression.</font> Tentez d'appeler Robotshop pour savoir ce qu'est devenue la commande. Il faut aussi que vous vous penchiez sur le PCB de commande des LED et servo-moteurs de la piste.<br />
|<br />
|<br />
|<br />
|-<br />
| P44 [[IMA4 2018/2019 P44|Clônes améliorés des modules ARDUINO]]<br />
| Restriction du sujet à la conception et réalisation d'une seule carte, ce qui est, ma foi, prudent. Bonne description de "concurrents". Des coquilles mais sans plus. Ne mettez pas d'espace ou d'accents dans les noms des fichiers téléchargés. Scénario d'usage acceptable. Clairement vous avez déjà pas mal réfléchi à votre carte. <br />
| Une liste de matériel mais sans lien vers le composant chez un fournisseur agréé.<br />
|<br />
| <font color="red">Rien. Votre travail n'est pas évaluable. Votre projet est en péril.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P45 [[IMA4 2018/2019 P45|Sac à main ou sac à dos solaire]]<br />
| <font color="green">Wiki très bien illustré, rédaction assez correcte (quelques coquilles)</font>. Bonne description de concurrents, scénario d'usage convenable. Réponses un peu rapides aux questions "difficiles"<br />
| Une liste de composants qui parait encore bien préliminaire. Aucun lien sur les composants chez les fournisseurs.<br />
|<br />
| <font color="orange">Vous avez posé quelques réflexions dans votre Wiki. Cependant aucune trace de réalisation. Une liste de matériel exploitable trop tardive.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P46 [[IMA4 2018/2019 P46|Kit Robot]]<br />
| PLutôt bien rédigé malgré quelques coquilles. Objectifs bien fixés. Concurrents décrits en détail (un peu de synthèse n'aurait pas fait de mal). <font color="green">Scénario d'usage très correct</font>. <br />
| Un liste de composants bien avancée. <font color="green">Des liens vers les fournisseurs. Matériels sur la page principale.</font><br />
|<br />
| Le Wiki est correct. Vous semblez avoir terminé la phase de conception même s'il manque les informations sur le PCB. Disons que je serais rassuré quand vous aurez découpé les pièces du chassis et fait réaliser la carte électronique. En une phrase : il est plus que temps d'avoir des résultats tangibles !<br />
|<br />
|<br />
|<br />
|-<br />
| P57 [[IMA4 2018/2019 P57|Mise à jour over the air]]<br />
| Bon cahier des charges qui répond aux questions que l'on pourrait se poser à la lecture du reste de la page. Quelle différence entre votre solution et Dualoptiboot du coup ? Dualoptiboot ne comprend pas la partie matérielle ? Allez-vous l'utiliser ? Un scénario d'usage bien rapide. La réponse semble à coté de la question, il semble que vous répondez à la question "comment vérifier une somme de contrôle avant de flasher la mémoire programme ?". Comment allez vous gérer la clef de chiffrement ? Elle est figée dans l'amorceur ? Je crois comprendre en fin de page que vous voulez fixer une clef par capteur, cela casse le principe de la mise à jour par diffusion radio, non ?<br />
| Une première liste de matériel sans lien vers les sites des fournisseurs agréés.<br />
|<br />
| <font color="orange">N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Cinq semaines pour router une carte ? Au minimum donnez les problèmes rencontrés et les résultats obtenus. Dans l'état de vacuité de votre Wiki, il est légitime de douter de la validation du projet.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P63 [[IMA4 2018/2019 P63|Etude de la consommation d'un capteur de pollution]]<br />
| <font color="green">Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire</font>.<br />
| Une liste de matériel avec des liens vers des fournisseurs. Par contre les fournisseurs choisis ne sont pas forcément utilisables.<br />
|<br />
| Il y a comme un trou entre la semaine 3 et la semaine 7 ? Un problème de légende et de figure. <font color="green">Wiki acceptable.</font> <font color="orange">Les cartes doivent être vérifiées et réalisées de toute urgence.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P70 [[IMA4 2018/2019 P70|Impact du matériel et du logiciel sur le rayonnement électromagnétique]]<br />
| <font color="green">Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire.</font><br />
| Une liste de matériels très embryonnaire et sans lien exploitable.<br />
|<br />
| Le Wiki n'est pas à jour et ne permet pas de se faire une idée du travail des deux dernières semaines. Rien à redire sur le travail antérieur.<br />
|<br />
|<br />
|<br />
|-<br />
| P72 [[IMA4 2018/2019 P72|Mesure du courant simple]]<br />
| <font color="green">Rédaction correcte. Wiki bien illustré. Une partie analyse correcte.</font><br />
| <font color="green">Une liste de matériel bien avancée avec des liens exploitables.</font> Recopiez les liens sur la page principale.<br />
|<br />
| <font color="green">Wiki très correct. Bien illustré. Il manque le schematic de la carte, vous l'avez réalisé n'est-ce pas ?</font> <font color="orange">Vous devriez déjà avoir routé et réalisé votre carte.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P73 [[IMA4 2018/2019 P73|Ecriture automatique de partition musicale]]<br />
| <font color="green">Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire. Un calendrier prévisionnel.</font><br />
| Une tentative de liste de matériel qui ne pourra effectivement être finalisé qu'après discussions avec un électronicien.<br />
|<br />
| <font color="green">Wiki très correct. Bien illustré.</font> Par contre vous semblez marquer le pas sur ces deux dernières semaines alors qu'il s'agirait, au contraire, de mettre un coup d'accélerateur. <font color="orange">Routez cette carte, il est plus que temps !</font><br />
|<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
== Présence ==<br />
<br />
{| class="wikitable"<br />
! Projet !! Elèves !! 10/12/2018 !! 16/01/2019 !! 23/01/2019 !! 30/01/2019 !! 06/02/2019 !! 13/02/2019 !! 27/02/2019 !! 06/03/2019 !! 13/03/2019 !! 20/03/2019 !! 27/03/2019<br />
|-<br />
| P9 [[IMA4 2018/2019 P9|Spider and I]]<br />
| Nestor Martinez / Lina Mejbar<br />
| OK<br />
| E305<br />
| E305<br />
| E305<br />
| E304<br />
| A208<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
|-<br />
| P10 [[IMA4 2018/2019 P10|Capteur de niveau d'eau et de pollution]]<br />
| Antoine Branquart<br />
| Absent (certificat médical)<br />
| E305<br />
| E305<br />
| E301<br />
| Absent (certificat médical)<br />
| E301<br />
| E303<br />
<font color="green">Présent</font><br />
| <font color="blue">Excusé (malade)</font><br />
| C201<br />
<font color="green">Présent</font><br />
|C201<br />
|C201<br />
|-<br />
| P12 [[IMA4 2018/2019 P12|Recyclage plastique imprimante 3D]]<br />
| Corentin Danjou / Pol Mulon<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E304/E301<br />
| E301<br />
| E303<br />
<font color="green">Présents</font><br />
| E303<br />
| E303<br />
<font color="green">Présents</font><br />
| E304 / C201<br />
| Fabricarium / C201<br />
|-<br />
| P13 [[IMA4 2018/2019 P13|Emetteur / Récepteur analogique en bande 5725-5875 MHz]]<br />
| Arthur Reviron<br />
| Absent<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
|<br />
| C201<br />
<font color="green">Présent</font><br />
|-<br />
| P14 [[IMA4 2018/2019 P14|Voiture autonome en modèle réduit]]<br />
| Hugo Dejaegher / Brandon Elemva<br />
| OK<br />
| E306<br />
| E306<br />
| E306<br />
| E306<br />
| E306<br />
| E306 + Fabricarium<br />
<font color="green">Présents</font><br />
| E306<br />
| E306<br />
<font color="green">Présents</font><br />
| E306<br />
|-<br />
| P22 [[IMA4 2018/2019 P22|Secure And Verified Public Announcements through Blockchain]]<br />
| Arezki Ait Mouheb<br />
| OK<br />
| E306<br />
| E305<br />
| E306<br />
| E306<br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| E306<br />
| E306<br />
|-<br />
| P26 [[IMA4 2018/2019 P26|Discussion pair à pair]]<br />
| Fabien Di Natale / Ibrahim Ben Dhiab<br />
| OK<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
|-<br />
| P28 [[IMA4 2018/2019 P28|Affichage à billes]]<br />
| Flora Dziedzic / Martin Michel <br />
| OK<br />
| Fabricarium<br />
| E305<br />
| Fabricarium<br />
| Fabricarium<br />
| A311<br />
| Fabricarium<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
|-<br />
| P30 [[IMA4 2018/2019 P30|Système minimal de gestion de conteneurs]]<br />
| Hind Malti<br />
| OK<br />
|E304<br />
|E304<br />
|E304<br />
|E304<br />
|E303<br />
|E306<br />
<font color="green">Présente</font><br />
|E306<br />
|E306<br />
<font color="green">Présents</font><br />
|E306<br />
|E306<br />
|-<br />
| P31 [[IMA4 2018/2019 P31|Robot hexapode de mesure de RSSI WiFi]]<br />
| Rémi Foucault / Hugo Velly<br />
| OK<br />
|E304<br />
|E304<br />
|E304 / Fabricarium<br />
|E304 / Fabricarium<br />
|E304<br />
|E303<br />
<font color="green">Présents</font><br />
|E303<br />
|E303<br />
<font color="green">Présents</font><br />
|E303/C202-bis<br />
|E304<br />
|-<br />
| P32 [[IMA4 2018/2019 P32|Robe augmentée]]<br />
| Brinda Muzakare / Yan Xuelu<br />
| OK<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présentes</font><br />
| E304<br />
| E304<br />
<font color="green">Présentes</font><br />
| E304<br />
| E304<br />
|-<br />
| P33 [[IMA4 2018/2019 P33|Collier à animations lumineuses]]<br />
| Loris Ahouassou<br />
| OK<br />
| E306<br />
| E305<br />
| E304<br />
| E304<br />
| C201<br />
| E304<br />
<font color="green">Présent</font><br />
| E304<br />
| <br />
<font color="red">Absent</font><br />
| E304<br />
|-<br />
| P35 [[IMA4 2018/2019 P35|Machine Learning pour navigation autonome de robots mobiles]]<br />
| Wenjing Chen / Puyuan Lin<br />
| OK<br />
| E304<br />
| E305<br />
| C304<br />
| C102<br />
| C304<br />
| C304<br />
<font color="red">Absents</font><br />
| C002<br />
<font color="green">Présents</font><br />
| C002<br />
<font color="green">Présents</font><br />
|-<br />
| P37 [[IMA4 2018/2019 P37|Station de recharge intelligente pour robot mobile]]<br />
| Guillaume Declerck / Pierre Guigo<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E303<br />
| E301<br />
| E303<br />
<font color="green">Pierre Guigo présent</font><br />
<font color="red">Guillaume Declerck absent</font><br />
| E303 & C201<br />
| C201 & E303<br />
<font color="green">Présents</font><br />
|<br />
|C203<br />
|-<br />
| P38 [[IMA4 2018/2019 P38|Interface Graphique pour Robotino 2 Upgradé]]<br />
| François Brassart / Jérôme Haon<br />
| OK<br />
| E304<br />
| E304<br />
| E303<br />
| E304<br />
| E305<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
|C304<br />
|C304<br />
|-<br />
| P40 [[IMA4 2018/2019 P40|RFID/NFC]]<br />
| Jean De Dieu Nduwamungu / Xinwei Hu<br />
| OK<br />
| E305<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
|-<br />
| P42 [[IMA4 2018/2019 P42|Coupe de robotique des écoles primaires]]<br />
| Pierre Frison / Thibault Lepoivre<br />
| OK<br />
| E305<br />
| E305<br />
| E304<br />
| Fabricarium<br />
| E301(fab fermé)<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| Fab et C201<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| E303 (Lepoivre) / frison absent(malade)<br />
|-<br />
| P44 [[IMA4 2018/2019 P44|Clônes améliorés des modules ARDUINO]]<br />
| Théau Moinat<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
|<br />
| C201<br />
<font color="green">Présent</font><br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
|-<br />
| P45 [[IMA4 2018/2019 P45|Sac à main ou sac à dos solaire]]<br />
| Mathis Dupré<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E304<br />
| E306<br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| C201<br />
|-<br />
| P46 [[IMA4 2018/2019 P46|Kit Robot]]<br />
| Valentin Pitre / Gaëlle Bernard<br />
| OK<br />
| E304<br />
| E305<br />
| E303<br />
| E304<br />
| A208<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| C202<br />
|-<br />
| P57 [[IMA4 2018/2019 P57|Mise à jour over the air]]<br />
| Florent Leroy<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
|-<br />
| P63 [[IMA4 2018/2019 P63|Etude de la consommation d'un capteur de pollution]]<br />
| Victor Lorthios / Juliette Obled<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201+E303<br />
<font color="green">Présents</font><br />
| E303<br />
| C201<br />
<font color="green">Présents</font><br />
| C201<br />
| C201<br />
|-<br />
| P70 [[IMA4 2018/2019 P70|Impact du matériel et du logiciel sur le rayonnement électromagnétique]]<br />
| Antoine Moreau / Souheib Khinache<br />
| OK<br />
| E305<br />
| E305<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| Fabricarium<br />
|-<br />
| P72 [[IMA4 2018/2019 P72|Mesure du courant simple]]<br />
| Raphaël Martin<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E303<br />
| E303<br />
| E303<br />
| E303<br />
<font color="green">Présent</font><br />
| E303<br />
| E303<br />
<font color="green">Présent</font><br />
| E303<br />
|-<br />
| P73 [[IMA4 2018/2019 P73|Ecriture automatique de partition musicale]]<br />
| Hugo Leurent / Fabien Ronckier<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
<font color="green">Présents</font><br />
| C201<br />
| C201<br />
<font color="green">Présents</font><br />
| C201<br />
| C201<br />
|-<br />
|}</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Discussion:Projets_IMA4_SC_%26_SA_2018/2019&diff=71902Discussion:Projets IMA4 SC & SA 2018/20192019-03-27T17:33:19Z<p>Amoreau : /* Présence */</p>
<hr />
<div>== Répartition des binômes ==<br />
<br />
{| class="wikitable"<br />
| Projet || Analyse || Matériel || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo<br />
|-<br />
| P9 [[IMA4 2018/2019 P9|Spider and I]]<br />
| La description des "concurrents" aurait pu être plus précise. Un effort sur le scénario d'usage qui aurait, lui aussi, pu être développé. Des coquilles. Un vague plan de travail.<br />
| Rien ou presque, fournisseur non utilisable.<br />
|<br />
| N'utilisez pas le mode "code" (espace en première colonne) pour distinguer une ligne. Une progression régulière mais il faudrait résoudre les problèmes soulevés à la semaine 7. Le travail à réaliser est assez simple, un résultat parfait est attendu.<br />
|<br />
|<br />
|<br />
|-<br />
| P10 [[IMA4 2018/2019 P10|Capteur de niveau d'eau et de pollution]]<br />
| Des coquilles. Bonne description des concurrents. Un effort pour le scénario, bonne mise en contexte, forcer sur la description de l'usage. Un plan de travail correct.<br />
| Une liste préliminaire de matériels. Fournisseurs correctement choisis. Rien sur la page principale.<br />
|<br />
| <font color="red">Coquilles inacceptables dans le Wiki</font>. <font color="orange">Wiki assez vide. Il est à espérer que le projet est plus avancé !</font>.<br />
|<br />
|<br />
|<br />
|-<br />
| P12 [[IMA4 2018/2019 P12|Recyclage plastique imprimante 3D]]<br />
| Vous êtes sur pour les servo-moteurs ? Ne serait-ce point des moteurs pas à pas ? Très bonne description du produit à réaliser avec illustrations. Bel effort de rédaction, encore pas mal de coquilles surtout en fin de page. Bonne étude des concurrents. Un scénario d'usage un peu rapide qui ne donne pas assez envie d'acquérir le produit. Questions difficiles mal exploitées (une réponse à la première question pourrait aussi être "par l'expérience", pas de réponse à la seconde question). Une étude solide du projet même si la liste des tâches à effectuer manque.<br />
| Bonne question sur le budget, mais posez la si vous voulez une réponse :D Liste de matériel encore très embryonnaire : rien sur l'électronique, une discussion avec votre encadrant s'impose pour fixer la partie mécanique.<br />
|<br />
| <font color="green">Wiki très bien tenu mais corrigez les quelques coquilles. Avancé du travail bien présenté.</font> Vous devez toujours me présenter la note pour les matériels achetés chez Leroy-Merlin.<br />
|<br />
|<br />
|<br />
|-<br />
| P13 [[IMA4 2018/2019 P13|Emetteur / Récepteur analogique en bande 5725-5875 MHz]]<br />
| Un seul concurrent. Scénario d'usage ne donnant probablement pas la pleine mesure du produit. <font color="red">Rien sur la planification</font>.<br />
| <font color="red">Rien.</font><br />
|<br />
| <font color="red">Rien. Votre travail n'est pas évaluable. Votre projet est en péril.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P14 [[IMA4 2018/2019 P14|Voiture autonome en modèle réduit]]<br />
| Il me semble que le chassis doit être celui d'un modèle radio-commandé existant. Il me semble que le pilotage manuel n'est pas autorisé. Description un peu rapide des concurrents. Une synthèse du matériel et logiciels employés aurait été intéressant. Pour le scénario d'usage, une description avec la voiture comme sujet aurait être plus intéressant. La réponse à la première question ne va pas dans le sens de l'autonomie. Dire que python est le langage par défaut de la RPi n'a pas de sens. Vous avez tout intérêt à prendre le langage le plus efficace est ce n'est probablement pas python. Pas de servo-moteurs continus sur une voiture radio-commandé. Pas vraiement de plan de travail. <font color="orange">Prenez contact avec votre encadrant direct, j'aimerais que vos choix soient validés, certains me paraissent discutables.</font><br />
| Aucune référence précise pour les matériels. Rien sur la page principale.<br />
|<br />
| Wiki moyen, peu dense, très peu illustré. Vous partez comme les IMA5 sur une solution de votre cru alors que vous n'avez aucune expérience en réseaux de neurones. Il est à craindre que le résultat final soit décevant.<br />
|<br />
|<br />
|<br />
|-<br />
| P22 [[IMA4 2018/2019 P22|Secure And Verified Public Announcements through Blockchain]]<br />
| <font color="green">Excellente rédaction.</font> Une bonne tentative de description du projet mais toujours un flou sur le travail à réaliser. Cela aurait pu être levé avec une liste précise des tâches à effectuer (une tentative de liste dans les objectifs).<br />
| Pas de matériel nécessaire (une RPi peut être).<br />
|<br />
| <font color="green">Un wiki très propre. Travail effectué décrit.</font>. Il manque juste l'information sur la validation du prototype 0 par l'encadrant direct.<br />
|<br />
|<br />
|<br />
|-<br />
| P26 [[IMA4 2018/2019 P26|Discussion pair à pair]]<br />
| <font color="red">Nombre de coquilles inacceptable</font>. Rajouter dans les objectifs de devoir tenter une ouverture de bouclier pour TCP (TCP Hole Punching). Analyse du premier concurrent : le prétexte pour n'utiliser que des serveurs microsoft pour les supernoeuds skype est le faible nombre de machines d'utilisateurs non handicapées par des parefeux. Bonne réponse aux questions difficile. L'expérience de skype dit qu'il faut totalement éviter qu'un noeud utilisateur ait à relayer les communications d'un autre utilisateur (ce qui est d'ailleurs contraire aux objectifs). Il faut donc une solution de pair à pair pour '''tous''' les clients. En particulier, IPv6 '''doit''' être intégré dans les solutions possibles. Il ne me semble pas que l'enregistrement des utilisateurs soit nécessaire, elle nuit même à la vie privée. Il faut simplement mémoriser les utilisateurs connectés. <br />
| Pas de matériel listé pourtant il faut mettre en place un banc d'essai.<br />
|<br />
| <font color="red">Coquilles inacceptables dans le Wiki</font>. <font color="orange">En fin de projet vous avez seulement mis en place le banc de test sans aucun développement d'un système de perçage de box que ce soit en UDP ou en TCP</font>.<br />
|<br />
|<br />
|<br />
|-<br />
| P28 [[IMA4 2018/2019 P28|Affichage à billes]]<br />
| Pour les panneaux d'affichage publicitaire, je ne suis pas sur que la consommation puisse être qualifiée d'énorme (il semble que si, à la lecture de votre réponse aux questions difficiles mais cela doit comprendre l'éclairage dont votre produit pourrait avec aussi besoin). <font color='green'>Rédaction très correcte. Un gros effort sur les illustrations. Un scénario d'usage, lui aussi, bien rédigé</font>. La réponse à la question difficile sur l'énergie consommée par votre produit ne me convainc pas : partez sur la différence d'énergie potentielle pour monter une bille pas sur la force à exercer qu'il faudrait intégrer sur la hauteur de la remontée. Il faut approfondir l'analyse des tâches à effectuer.<br />
| Il me semble avoir demandé de limiter la complexité du dispositif : 8 moteurs ?? Pas de références précises pour les matériels (lien sur le matériel dans le site du fournisseur).<br />
|<br />
| <font color="green">Très bon Wiki. Avancé du travail très bien présenté.</font> On attend avec impatience le résultat des tests sur le prototype "carton".<br />
|<br />
|<br />
|<br />
|-<br />
| P30 [[IMA4 2018/2019 P30|Système minimal de gestion de conteneurs]]<br />
| <font color="green">Excellent Wiki à ce jour. Rédaction très claire. Très bonne introduction. Tâches à réalisées clairement listées (mais dans les objectifs). Présentation très correcte du "concurrent principal". Un scénario d'usage correct (j'aurais plutôt insisté sur la faible consommation du système en ressources que sur l'installation dans un système fortement personnalisé). Un calendrier prévisionnel.</font> Le second "concurrent" est en fait l'ancienne couche bas niveau de <code>Docker</code>. Il faudrait utiliser la syntaxe Wiki mais ne touchez à rien avant la séance du 10 décembre cela me fera un exemple parfait pour expliquer cette syntaxe.<br />
| Pas de matériel nécessaire (une machine virtuelle sera concédée en cours de projet).<br />
|<br />
| <font color="green">Wiki très complet et très propre. Avancé du travail bien présenté.</font> Il faut arriver à finaliser les scripts de gestion des conteneurs. <br />
|<br />
|<br />
|<br />
|-<br />
| P31 [[IMA4 2018/2019 P31|Robot hexapode de mesure de RSSI WiFi]]<br />
| <font color="red">Beaucoup trop de coquilles</font>. Bonne présentation des "concurrents" qui vous servent aussi pour expliquer que votre projet est leur synthèse. Le scénario d'usage se tient. Bonne réponse à la question. Je ne crois pas trop au positionnement par RFID (il faut être sur un tag RFID pour le lire). Etes-vous sur pour l'Arduino méga ? Un Uno avec un bouclier PWM ne serait-il pas plus efficace ?<br />
| <font color="green">Effort de liste de matériel avec des références précises</font>. Pas de liste sur la page principale.<br />
|<br />
| <font color="orange">N'utilisez pas le mode "code" de mediawiki (espace en première colonne) pour distinguer des lignes. Utilisez la syntaxe pour les items. Wiki très peu dense. L'avancement du projet semble être suspendu.</font> Un bel effort pour la partie mécanique (les pattes du robot). Par contre la partie programmation semble très peu avancée.<br />
|<br />
|<br />
|<br />
|-<br />
| P32 [[IMA4 2018/2019 P32|Robe augmentée]]<br />
| En français l'abréviation de Monsieur est M. Mr est l'abrévation de Mister donc à n'utiliser qu'en anglosaxonnerie. Attention nous avons une expérience du fil à coudre conducteur et cela ne marche pas très bien sauf sur une surface très réduite. <font color="orange">Le scénario d'usage est perturbant : cela semble être un scénario pour deux produits différents</font>. <font color="orange">Vous avez considérablement simplifié le projet (sous-ensemble de projets déjà réalisés), la réalisation devra être impeccable pour que cela puisse être validé comme projet IMA4</font>.<br />
| La liste du matériel précise ce que vous souhaitez faire. Que vient faire la platine d'essai dans cette liste ? Pour le prototype ? Vous ne parlez pas du tout de la carte contrôleur. C'est une Lilypad ?<br />
|<br />
| Wiki bien illustré mais une rédaction séche. Développez un peu. OK pour les cartes électroniques mais vous devriez présenter une esquisse de la robe telle que vous souhaitez la réaliser.<br />
|<br />
|<br />
|<br />
|-<br />
| P33 [[IMA4 2018/2019 P33|Collier à animations lumineuses]]<br />
| Un français imaginatif avec un nombre de coquilles dans la moyenne. Un scénario d'usage rocambolesque (il doit me manquer quelques références) mais acceptable. Des concurrents pertinents. Réponses aux questions acceptables. Se limiter à trois plaques ne me semble pas pertinent (même si vous pouvez faire un premier test sur trois plaques). Pour l'étude de la communication prévoyez un prototype avec quelques Arduino.<br />
| Une liste de matériel qui semble être établie à la hâte. Il manque de nombreux composants électroniques pour faire tourner micro-contrôleurs et pilotes de LED. Pas de référence précise pour les composants.<br />
|<br />
| <font color="red">Rien sur votre travail, il n'est donc pas évaluable. Votre projet est en péril.</font> Vous devriez avoir fait les tests de communication sur le bus SPI et avoir conçu votre PCB.<br />
|<br />
|<br />
|-<br />
| P35 [[IMA4 2018/2019 P35|Machine Learning pour navigation autonome de robots mobiles]]<br />
| Il n'est pas tenu compte des erreurs de français. Dans la partie objectifs, la première sous-partie devrait plutôt s'appeler "partie robotique", il n'y a rien d'électronique ici. Le travail a effectuer est assez flou. En particulier le Wiki ne contient rien sur les bibliothèques de "machine learning" à utiliser.<br />
| Le matériel est fourni par les encadrants directs (AIP ?)<br />
|<br />
| <font color="red">J'ai peur que votre Wiki rende bien compte du travail effectué jusque là : uniquement des études, rien de concret à part utiliser une manette pour acquérir des jeux de données. C'est très inquiétant en cette période de fin de projet. Votre projet pourrait ne pas être validé.</font> <br />
|<br />
|<br />
|<br />
|-<br />
| P37 [[IMA4 2018/2019 P37|Station de recharge intelligente pour robot mobile]]<br />
| Trop de coquilles. <font color="orange">Il semble que le sujet initial ne correspond plus à ce qui est demandé, merci de préciser le nouveau sujet, calibrage du robot ?</font>Comment comptez-vous calibrer un préhenseur avec simplement du code (pas de réponse au niveau de la question difficile) ? <font color="red">Un seul concurrrent et sur la partie obsolète du projet</font>. Une analyse du travail a effectuer qui ne tient pas compte de l'abandon du sujet original.<br />
| <font color="red">Aucune liste de matériel</font><br />
|<br />
| Rien à redire sur votre Wiki. Il me semble bien rendre compte de l'avancé de votre projet. <font color="red">Une liste de matériel finalisée en fin de projet : vous prenez de grands risques. Je vous rappelle qu'un prototype fonctionnel est attendu.</font><br />
|<br />
|<br />
|-<br />
| P38 [[IMA4 2018/2019 P38|Interface Graphique pour Robotino 2 Upgradé]]<br />
| Choix des "concurrents" peu pertinents ou il fallait insister sur les différences entre ces robots et le robotino 2 amélioré. Le scénario d'usage se tient. Bonne réponse à la question "difficile". Il semble que le but du projet se réduise à créer une interface web avec une bibliothèque spécifique. <font color="orange">L'interface devra être irréprochable pour constituer un projet IMA4</font>.<br />
| Projet purement informatique, pas de matériel nécessaire (autre qu'un robotino amélioré).<br />
|<br />
| <font color="orange">N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Corrigez les coquilles ! En cette fin de projet vous semblez bien peu avancés sur l'interface Web. Rien sur la démonstration de fonctionnement du robotino que vous devez implanter. Il va falloir diantrement accélérer !</font><br />
|<br />
|<br />
|<br />
|-<br />
| P40 [[IMA4 2018/2019 P40|RFID/NFC]]<br />
| L'objectif est clairement explicité et dans un français très correct. Desc concurrents peu pertinents et une analyse trop hâtive des dits concurrents. La réponse sur la question de la difficulté du projet n'est pas convaincante. <font color="orange">Votre application de contrôle du robotino par smartphone se devra d'être irréprochable pour constituer un projet IMA4</font>.<br />
| Attention, tout votre projet repose sur la validité des lecteur RFID commandés. Si ces lecteurs ne sont pas utilisables votre projet tombe à l'eau. Vous avez étudié la compatibilité des lecteurs avec les robotino ?<br />
|<br />
| Vous semblez avoir avancé dans votre projet mais vos dernières entrées dans le Wiki sont trop courtes pour permettre de juger. Etoffez votre Wiki en décrivant mieux cette application (copies d'écrans). Je ne vois aucune trace de la partie de connexion IP automatique via NFC au robotino ?<br />
|<br />
|<br />
|<br />
|-<br />
| P42 [[IMA4 2018/2019 P42|Coupe de robotique des écoles primaires]]<br />
| <font color="red">Beaucoup trop de coquilles</font>. Objectifs très clairement précisés. Analyse des concurrents et réponse lapidaires. Le fait que vous ne respectiez pas le cahier des charges imposé aux enfants est problématique. <font color="green">Une liste précise des tâches a effectuer. Un calendrier prévisionnel.</font><br />
| Bel effort de liste de matériel. Quelques composants chez des fournisseurs non agréés. <font color="green">Liste sur la page principale</font>.<br />
|<br />
| <font color="green">Wiki plus que correct qui donne bien une idée de la progression.</font> Tentez d'appeler Robotshop pour savoir ce qu'est devenue la commande. Il faut aussi que vous vous penchiez sur le PCB de commande des LED et servo-moteurs de la piste.<br />
|<br />
|<br />
|<br />
|-<br />
| P44 [[IMA4 2018/2019 P44|Clônes améliorés des modules ARDUINO]]<br />
| Restriction du sujet à la conception et réalisation d'une seule carte, ce qui est, ma foi, prudent. Bonne description de "concurrents". Des coquilles mais sans plus. Ne mettez pas d'espace ou d'accents dans les noms des fichiers téléchargés. Scénario d'usage acceptable. Clairement vous avez déjà pas mal réfléchi à votre carte. <br />
| Une liste de matériel mais sans lien vers le composant chez un fournisseur agréé.<br />
|<br />
| <font color="red">Rien. Votre travail n'est pas évaluable. Votre projet est en péril.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P45 [[IMA4 2018/2019 P45|Sac à main ou sac à dos solaire]]<br />
| <font color="green">Wiki très bien illustré, rédaction assez correcte (quelques coquilles)</font>. Bonne description de concurrents, scénario d'usage convenable. Réponses un peu rapides aux questions "difficiles"<br />
| Une liste de composants qui parait encore bien préliminaire. Aucun lien sur les composants chez les fournisseurs.<br />
|<br />
| <font color="orange">Vous avez posé quelques réflexions dans votre Wiki. Cependant aucune trace de réalisation. Une liste de matériel exploitable trop tardive.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P46 [[IMA4 2018/2019 P46|Kit Robot]]<br />
| PLutôt bien rédigé malgré quelques coquilles. Objectifs bien fixés. Concurrents décrits en détail (un peu de synthèse n'aurait pas fait de mal). <font color="green">Scénario d'usage très correct</font>. <br />
| Un liste de composants bien avancée. <font color="green">Des liens vers les fournisseurs. Matériels sur la page principale.</font><br />
|<br />
| Le Wiki est correct. Vous semblez avoir terminé la phase de conception même s'il manque les informations sur le PCB. Disons que je serais rassuré quand vous aurez découpé les pièces du chassis et fait réaliser la carte électronique. En une phrase : il est plus que temps d'avoir des résultats tangibles !<br />
|<br />
|<br />
|<br />
|-<br />
| P57 [[IMA4 2018/2019 P57|Mise à jour over the air]]<br />
| Bon cahier des charges qui répond aux questions que l'on pourrait se poser à la lecture du reste de la page. Quelle différence entre votre solution et Dualoptiboot du coup ? Dualoptiboot ne comprend pas la partie matérielle ? Allez-vous l'utiliser ? Un scénario d'usage bien rapide. La réponse semble à coté de la question, il semble que vous répondez à la question "comment vérifier une somme de contrôle avant de flasher la mémoire programme ?". Comment allez vous gérer la clef de chiffrement ? Elle est figée dans l'amorceur ? Je crois comprendre en fin de page que vous voulez fixer une clef par capteur, cela casse le principe de la mise à jour par diffusion radio, non ?<br />
| Une première liste de matériel sans lien vers les sites des fournisseurs agréés.<br />
|<br />
| <font color="orange">N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Cinq semaines pour router une carte ? Au minimum donnez les problèmes rencontrés et les résultats obtenus. Dans l'état de vacuité de votre Wiki, il est légitime de douter de la validation du projet.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P63 [[IMA4 2018/2019 P63|Etude de la consommation d'un capteur de pollution]]<br />
| <font color="green">Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire</font>.<br />
| Une liste de matériel avec des liens vers des fournisseurs. Par contre les fournisseurs choisis ne sont pas forcément utilisables.<br />
|<br />
| Il y a comme un trou entre la semaine 3 et la semaine 7 ? Un problème de légende et de figure. <font color="green">Wiki acceptable.</font> <font color="orange">Les cartes doivent être vérifiées et réalisées de toute urgence.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P70 [[IMA4 2018/2019 P70|Impact du matériel et du logiciel sur le rayonnement électromagnétique]]<br />
| <font color="green">Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire.</font><br />
| Une liste de matériels très embryonnaire et sans lien exploitable.<br />
|<br />
| Le Wiki n'est pas à jour et ne permet pas de se faire une idée du travail des deux dernières semaines. Rien à redire sur le travail antérieur.<br />
|<br />
|<br />
|<br />
|-<br />
| P72 [[IMA4 2018/2019 P72|Mesure du courant simple]]<br />
| <font color="green">Rédaction correcte. Wiki bien illustré. Une partie analyse correcte.</font><br />
| <font color="green">Une liste de matériel bien avancée avec des liens exploitables.</font> Recopiez les liens sur la page principale.<br />
|<br />
| <font color="green">Wiki très correct. Bien illustré. Il manque le schematic de la carte, vous l'avez réalisé n'est-ce pas ?</font> <font color="orange">Vous devriez déjà avoir routé et réalisé votre carte.</font><br />
|<br />
|<br />
|<br />
|-<br />
| P73 [[IMA4 2018/2019 P73|Ecriture automatique de partition musicale]]<br />
| <font color="green">Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire. Un calendrier prévisionnel.</font><br />
| Une tentative de liste de matériel qui ne pourra effectivement être finalisé qu'après discussions avec un électronicien.<br />
|<br />
| <font color="green">Wiki très correct. Bien illustré.</font> Par contre vous semblez marquer le pas sur ces deux dernières semaines alors qu'il s'agirait, au contraire, de mettre un coup d'accélerateur. <font color="orange">Routez cette carte, il est plus que temps !</font><br />
|<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
== Présence ==<br />
<br />
{| class="wikitable"<br />
! Projet !! Elèves !! 10/12/2018 !! 16/01/2019 !! 23/01/2019 !! 30/01/2019 !! 06/02/2019 !! 13/02/2019 !! 27/02/2019 !! 06/03/2019 !! 13/03/2019 !! 20/03/2019 !! 27/03/2019<br />
|-<br />
| P9 [[IMA4 2018/2019 P9|Spider and I]]<br />
| Nestor Martinez / Lina Mejbar<br />
| OK<br />
| E305<br />
| E305<br />
| E305<br />
| E304<br />
| A208<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
|-<br />
| P10 [[IMA4 2018/2019 P10|Capteur de niveau d'eau et de pollution]]<br />
| Antoine Branquart<br />
| Absent (certificat médical)<br />
| E305<br />
| E305<br />
| E301<br />
| Absent (certificat médical)<br />
| E301<br />
| E303<br />
<font color="green">Présent</font><br />
| <font color="blue">Excusé (malade)</font><br />
| C201<br />
<font color="green">Présent</font><br />
|C201<br />
|C201<br />
|-<br />
| P12 [[IMA4 2018/2019 P12|Recyclage plastique imprimante 3D]]<br />
| Corentin Danjou / Pol Mulon<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E304/E301<br />
| E301<br />
| E303<br />
<font color="green">Présents</font><br />
| E303<br />
| E303<br />
<font color="green">Présents</font><br />
| E304 / C201<br />
| Fabricarium / C201<br />
|-<br />
| P13 [[IMA4 2018/2019 P13|Emetteur / Récepteur analogique en bande 5725-5875 MHz]]<br />
| Arthur Reviron<br />
| Absent<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
|<br />
| C201<br />
<font color="green">Présent</font><br />
|-<br />
| P14 [[IMA4 2018/2019 P14|Voiture autonome en modèle réduit]]<br />
| Hugo Dejaegher / Brandon Elemva<br />
| OK<br />
| E306<br />
| E306<br />
| E306<br />
| E306<br />
| E306<br />
| E306 + Fabricarium<br />
<font color="green">Présents</font><br />
| E306<br />
| E306<br />
<font color="green">Présents</font><br />
| E306<br />
|-<br />
| P22 [[IMA4 2018/2019 P22|Secure And Verified Public Announcements through Blockchain]]<br />
| Arezki Ait Mouheb<br />
| OK<br />
| E306<br />
| E305<br />
| E306<br />
| E306<br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| E306<br />
| E306<br />
|-<br />
| P26 [[IMA4 2018/2019 P26|Discussion pair à pair]]<br />
| Fabien Di Natale / Ibrahim Ben Dhiab<br />
| OK<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
|-<br />
| P28 [[IMA4 2018/2019 P28|Affichage à billes]]<br />
| Flora Dziedzic / Martin Michel <br />
| OK<br />
| Fabricarium<br />
| E305<br />
| Fabricarium<br />
| Fabricarium<br />
| A311<br />
| Fabricarium<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
|-<br />
| P30 [[IMA4 2018/2019 P30|Système minimal de gestion de conteneurs]]<br />
| Hind Malti<br />
| OK<br />
|E304<br />
|E304<br />
|E304<br />
|E304<br />
|E303<br />
|E306<br />
<font color="green">Présente</font><br />
|E306<br />
|E306<br />
<font color="green">Présents</font><br />
|E306<br />
|E306<br />
|-<br />
| P31 [[IMA4 2018/2019 P31|Robot hexapode de mesure de RSSI WiFi]]<br />
| Rémi Foucault / Hugo Velly<br />
| OK<br />
|E304<br />
|E304<br />
|E304 / Fabricarium<br />
|E304 / Fabricarium<br />
|E304<br />
|E303<br />
<font color="green">Présents</font><br />
|E303<br />
|E303<br />
<font color="green">Présents</font><br />
|E303/C202-bis<br />
|E304<br />
|-<br />
| P32 [[IMA4 2018/2019 P32|Robe augmentée]]<br />
| Brinda Muzakare / Yan Xuelu<br />
| OK<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présentes</font><br />
| E304<br />
| E304<br />
<font color="green">Présentes</font><br />
| E304<br />
| E304<br />
|-<br />
| P33 [[IMA4 2018/2019 P33|Collier à animations lumineuses]]<br />
| Loris Ahouassou<br />
| OK<br />
| E306<br />
| E305<br />
| E304<br />
| E304<br />
| C201<br />
| E304<br />
<font color="green">Présent</font><br />
| E304<br />
| <br />
<font color="red">Absent</font><br />
| E304<br />
|-<br />
| P35 [[IMA4 2018/2019 P35|Machine Learning pour navigation autonome de robots mobiles]]<br />
| Wenjing Chen / Puyuan Lin<br />
| OK<br />
| E304<br />
| E305<br />
| C304<br />
| C102<br />
| C304<br />
| C304<br />
<font color="red">Absents</font><br />
| C002<br />
<font color="green">Présents</font><br />
| C002<br />
<font color="green">Présents</font><br />
|-<br />
| P37 [[IMA4 2018/2019 P37|Station de recharge intelligente pour robot mobile]]<br />
| Guillaume Declerck / Pierre Guigo<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E303<br />
| E301<br />
| E303<br />
<font color="green">Pierre Guigo présent</font><br />
<font color="red">Guillaume Declerck absent</font><br />
| E303 & C201<br />
| C201 & E303<br />
<font color="green">Présents</font><br />
|<br />
|C203<br />
|-<br />
| P38 [[IMA4 2018/2019 P38|Interface Graphique pour Robotino 2 Upgradé]]<br />
| François Brassart / Jérôme Haon<br />
| OK<br />
| E304<br />
| E304<br />
| E303<br />
| E304<br />
| E305<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
|C304<br />
|C304<br />
|-<br />
| P40 [[IMA4 2018/2019 P40|RFID/NFC]]<br />
| Jean De Dieu Nduwamungu / Xinwei Hu<br />
| OK<br />
| E305<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| E304<br />
|-<br />
| P42 [[IMA4 2018/2019 P42|Coupe de robotique des écoles primaires]]<br />
| Pierre Frison / Thibault Lepoivre<br />
| OK<br />
| E305<br />
| E305<br />
| E304<br />
| Fabricarium<br />
| E301(fab fermé)<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| Fab et C201<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| E303 (Lepoivre) / frison absent(malade)<br />
|-<br />
| P44 [[IMA4 2018/2019 P44|Clônes améliorés des modules ARDUINO]]<br />
| Théau Moinat<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
|<br />
| C201<br />
<font color="green">Présent</font><br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
|-<br />
| P45 [[IMA4 2018/2019 P45|Sac à main ou sac à dos solaire]]<br />
| Mathis Dupré<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E304<br />
| E306<br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| E306<br />
| E306<br />
<font color="green">Présent</font><br />
| C201<br />
|-<br />
| P46 [[IMA4 2018/2019 P46|Kit Robot]]<br />
| Valentin Pitre / Gaëlle Bernard<br />
| OK<br />
| E304<br />
| E305<br />
| E303<br />
| E304<br />
| A208<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| C202<br />
|-<br />
| P57 [[IMA4 2018/2019 P57|Mise à jour over the air]]<br />
| Florent Leroy<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
| C201<br />
| C201<br />
<font color="green">Présent</font><br />
|-<br />
| P63 [[IMA4 2018/2019 P63|Etude de la consommation d'un capteur de pollution]]<br />
| Victor Lorthios / Juliette Obled<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201+E303<br />
<font color="green">Présents</font><br />
| E303<br />
| C201<br />
<font color="green">Présents</font><br />
| C201<br />
| C201<br />
|-<br />
| P70 [[IMA4 2018/2019 P70|Impact du matériel et du logiciel sur le rayonnement électromagnétique]]<br />
| Antoine Moreau / Souheib Khinache<br />
| OK<br />
| E305<br />
| E305<br />
| E304<br />
| E304<br />
| E304<br />
| E304<br />
<font color="green">Présents</font><br />
| E304<br />
| Fabricarium<br />
<font color="green">Présents</font><br />
| Fabricarium<br />
| E304<br />
|-<br />
| P72 [[IMA4 2018/2019 P72|Mesure du courant simple]]<br />
| Raphaël Martin<br />
| OK<br />
| E305<br />
| E305<br />
| E301<br />
| E303<br />
| E303<br />
| E303<br />
| E303<br />
<font color="green">Présent</font><br />
| E303<br />
| E303<br />
<font color="green">Présent</font><br />
| E303<br />
|-<br />
| P73 [[IMA4 2018/2019 P73|Ecriture automatique de partition musicale]]<br />
| Hugo Leurent / Fabien Ronckier<br />
| OK<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
| C201<br />
<font color="green">Présents</font><br />
| C201<br />
| C201<br />
<font color="green">Présents</font><br />
| C201<br />
| C201<br />
|-<br />
|}</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=71814IMA4 2018/2019 P702019-03-27T14:20:19Z<p>Amoreau : /* Première prise en main du logiciel GNURADIO */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<div><ul> <br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li><br />
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li><br />
</ul></div><br />
<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<div><br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]<br />
<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div><br />
<br />
==Semaines 6 et 7==<br />
<br />
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.<br />
<br />
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.<br />
<br />
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]<br />
<br />
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.<br />
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).<br />
<br />
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.<br />
<br />
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. <br />
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.<br />
<br />
<br />
===Le XBee 1 émetteur directement connecté en série au PC===<br />
<br />
<br />
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
Nous avons donc émis les données sur le canal 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee. <br />
<br />
<br />
<B><U>Etude fréquentielle</U></B><br />
<br />
L'étude fréquentielle est similaire à celle réalisée auparavant.<br />
<br />
<br />
<div center><ul><br />
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li><br />
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li><br />
</ul></div><br />
<br />
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.<br />
<br />
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".<br />
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.<br />
<br />
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).<br />
<br />
<br />
<B><U> Etude temporelle </U></B><br />
<br />
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]<br />
<br />
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.<br />
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.<br />
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.<br />
Les changements de phase s'il y a se font toutes les µs.<br />
<br />
<br />
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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à !<br />
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.<br />
<br />
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :<br />
- la séquence de préambule (4 octets) constitué de 32 bits à 0<br />
<br />
- l'indice de début du paquet fixé à 0x7A (1 octet)<br />
<br />
- la longueur du paquet (1 octet);<br />
<br />
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).<br />
<br />
<br />
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]<br />
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]<br />
<br />
<br />
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.<br />
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.<br />
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).<br />
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).<br />
<br />
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).<br />
Sachant qu'un octet correspond à 64µs, on a :<br />
<br />
<br />
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center><br />
<br />
<br />
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.<br />
<br />
<br />
<br />
<div><ul><br />
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li> <br />
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li><br />
</ul></div><br />
<br />
// À continuer : calculs pour connaître la taille du paquet à partir du signal //<br />
<br />
==Semaine 8==<br />
<br />
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.<br />
<br />
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 :<br />
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center><br />
<br />
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.<br />
<br />
Néanmoins, 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.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70732IMA4 2018/2019 P702019-03-10T21:00:34Z<p>Amoreau : /* Semaine 5 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Programme Python fait rapidement]]<br />
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 ! <br />
<br />
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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
==Semaine 6==<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70731IMA4 2018/2019 P702019-03-10T21:00:11Z<p>Amoreau : /* Configuration des modules XBee */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Programme Python fait rapidement]]<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
==Semaine 6==<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70492IMA4 2018/2019 P702019-03-06T16:49:07Z<p>Amoreau : /* Semaine 5 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Programme Python fait rapidement]]<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
==Semaine 6==<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70491IMA4 2018/2019 P702019-03-06T16:48:59Z<p>Amoreau : /* Semaine 5 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
[[Fichier:Switchchannel pyscript2.PNG|upright=0.8|thumb|right|Programme Python fait rapidement]]<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
==Semaine 6==<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Switchchannel_pyscript.PNG&diff=70490Fichier:Switchchannel pyscript.PNG2019-03-06T16:44:48Z<p>Amoreau : Amoreau a téléversé une nouvelle version de Fichier:Switchchannel pyscript.PNG</p>
<hr />
<div></div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70471IMA4 2018/2019 P702019-03-06T15:57:00Z<p>Amoreau : /* Réalisation du Projet */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Programme Python fait rapidement]]<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
==Semaine 6==<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70470IMA4 2018/2019 P702019-03-06T15:55:28Z<p>Amoreau : /* Semaine 5 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Programme Python fait rapidement]]<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
<br />
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.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Switchchannel_pyscript.PNG&diff=70467Fichier:Switchchannel pyscript.PNG2019-03-06T15:51:02Z<p>Amoreau : </p>
<hr />
<div></div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70464IMA4 2018/2019 P702019-03-06T15:41:25Z<p>Amoreau : /* Semaine 5 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
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.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70453IMA4 2018/2019 P702019-03-06T15:22:09Z<p>Amoreau : /* Semaine 5 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
Après quelques essais, on remarque que lorsque le Xbee émet sur le channel 13, il émet à environ 2,445GHz.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70434IMA4 2018/2019 P702019-03-06T14:32:19Z<p>Amoreau : /* Réalisation du Projet */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|6<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70432IMA4 2018/2019 P702019-03-06T14:31:57Z<p>Amoreau : /* Semaine 5 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<br />
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 ! <br />
<br />
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoie 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). <br />
<br />
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70425IMA4 2018/2019 P702019-03-06T14:22:53Z<p>Amoreau : /* Semaine 4 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<br />
On décide d'automatiser le processus d'envoie sur le port série des données vers le Xbee.<br />
En effet, le fait que des données soient envoyées sur un temps t ne nous permet de voir correctement le signal. Il nous est nécessaire d'approcher le moment de balayage avec l'envoi des données.<br />
<br />
Un script python est réalisé afin d'envoyer en continue les données.<br />
En outre, le script permet de changer toutes les dix secondes de canal d'envoi.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70424IMA4 2018/2019 P702019-03-06T14:22:39Z<p>Amoreau : /* Semaine 4 */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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 ?<br />
<br />
==Semaine 5==<br />
<br />
On décide d'automatiser le processus d'envoie sur le port série des données vers le Xbee.<br />
En effet, le fait que des données soient envoyées sur un temps t ne nous permet de voir correctement le signal. Il nous est nécessaire d'approcher le moment de balayage avec l'envoi des données.<br />
<br />
Un script python est réalisé afin d'envoyer en continue les données.<br />
En outre, le script permet de changer toutes les dix secondes de canal d'envoi.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70422IMA4 2018/2019 P702019-03-06T14:20:28Z<p>Amoreau : /* Feuille d'heures */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous nous sommes principalement à la tâche de recherche afin de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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éveloppper nos études ?<br />
<br />
==Semaine 5==<br />
<br />
On décide d'automatiser le processus d'envoie sur le port série des données vers le Xbee.<br />
En effet, le fait que des données soient envoyées sur un temps t ne nous permet de voir correctement le signal. Il nous est nécessaire d'approcher le moment de balayage avec l'envoi des données.<br />
<br />
Un script python est réalisé afin d'envoyer en continue les données.<br />
En outre, le script permet de changer toutes les dix secondes de canal d'envoi.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70420IMA4 2018/2019 P702019-03-06T14:20:18Z<p>Amoreau : /* Feuille d'heures */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|2<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|4<br />
|15<br />
|9<br />
|8<br />
|7<br />
|8<br />
|8<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous nous sommes principalement à la tâche de recherche afin de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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éveloppper nos études ?<br />
<br />
==Semaine 5==<br />
<br />
On décide d'automatiser le processus d'envoie sur le port série des données vers le Xbee.<br />
En effet, le fait que des données soient envoyées sur un temps t ne nous permet de voir correctement le signal. Il nous est nécessaire d'approcher le moment de balayage avec l'envoi des données.<br />
<br />
Un script python est réalisé afin d'envoyer en continue les données.<br />
En outre, le script permet de changer toutes les dix secondes de canal d'envoi.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70415IMA4 2018/2019 P702019-03-06T14:17:33Z<p>Amoreau : /* Réalisation du Projet */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|0<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|1<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|2<br />
|0<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous nous sommes principalement à la tâche de recherche afin de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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éveloppper nos études ?<br />
<br />
==Semaine 5==<br />
<br />
On décide d'automatiser le processus d'envoie sur le port série des données vers le Xbee.<br />
En effet, le fait que des données soient envoyées sur un temps t ne nous permet de voir correctement le signal. Il nous est nécessaire d'approcher le moment de balayage avec l'envoi des données.<br />
<br />
Un script python est réalisé afin d'envoyer en continue les données.<br />
En outre, le script permet de changer toutes les dix secondes de canal d'envoi.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70413IMA4 2018/2019 P702019-03-06T14:17:17Z<p>Amoreau : /* Feuille d'heures */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
|3<br />
|8<br />
|0<br />
|0<br />
|0<br />
|0<br />
|<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Recherches<br />
|1<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|1<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|2<br />
|0<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous nous sommes principalement à la tâche de recherche afin de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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éveloppper nos études ?<br />
<br />
==Semaine 5==<br />
<br />
On décide d'automatiser le processus d'envoie sur le port série des données vers le Xbee.<br />
En effet, le fait que des données soient envoyées sur un temps t ne nous permet de voir correctement le signal. Il nous est nécessaire d'approcher le moment de balayage avec l'envoi des données.<br />
<br />
Un script python est réalisé afin d'envoyer en continue les données.<br />
En outre, le script permet de changer toutes les dix secondes de canal d'envoi.<br />
<br />
=Documents Rendus=</div>Amoreauhttps://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&diff=70410IMA4 2018/2019 P702019-03-06T14:15:46Z<p>Amoreau : /* Feuille d'heures */</p>
<hr />
<div><div class="center" style="font-size: 30px; width: auto; margin-left: auto; margin-right: auto;">Impact du matériel et du logiciel sur le champ électromagnétique</div><br />
<br />
<br />
<br />
__TOC__<br />
<br style="clear: both;"/><br />
<br />
<br />
=Présentation générale=<br />
<br />
<ins>'''Projet'''</ins> : Impact du matériel et du logiciel sur le rayonnement électromagnétique<br />
<br />
''Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.''<br />
<br />
<ins>'''Etudiants'''</ins> : Souheib KHINACHE et Antoine MOREAU<br />
<br />
<ins>'''Encadrants'''</ins> : Alexandre BOE, Xavier REDON et Thomas VANTROYS<br />
<br />
==Description==<br />
<br />
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. <br />
Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Objectifs==<br />
<br />
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.<br />
Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. <br />
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.<br />
<br />
On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :<br />
*l'aspect "Hardware" en étudiant différents modèles pour un même type de shield <br />
*l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)<br />
*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)<br />
*l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).<br />
<br />
L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. <br />
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.<br />
<br />
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.<br />
<br />
On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.<br />
<br />
=Analyse du projet=<br />
<br />
==Positionnement par rapport à l'existant==<br />
<br />
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. <br />
De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.<br />
<br />
On peut prendre l'exemple de [https://www.eurekalert.org/pub_releases/2015-01/giot-rwt010715.php 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. <br />
<br />
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.<br />
<br />
==Analyse du premier concurrent==<br />
<br />
'''NBM-520 de NARDA STS'''<br />
[[Fichier: NBM_TS.png|thumb|300px|NBM-TS, application des appareils NBM]]<br />
NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques.<br />
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).<br />
<br />
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...<br />
<br />
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é.<br />
<br />
<br />
<ins>''Avantages :''</ins><br />
* Large bande de fréquence<br />
* Matériel solide<br />
* Application fonctionnelle permettant l'étude et gestion des données<br />
* Possibilité d'étudier séparément champ électrique et magnétique<br />
<br />
<ins>''Inconvénients:''</ins><br />
* Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)<br />
* Prix élevé : à partir de 3100€<br />
* La cible de ce produit est surtout les professionels<br />
<br />
==Analyse du second concurrent==<br />
<br />
'''Une pita.'''<br />
<br />
''Comment mon pain à pita vole ta clé RSA ?''<br />
<br />
[[Fichier:Pita.jpg|200px|thumb|left|Une pita.]]<br />
<br />
<br />
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. <br />
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.<br />
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.<br />
<br />
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.<br />
<br />
<br />
[[Fichier:PITA.jpg|300px|thumb|right|Un dessous de pita.]]<br />
<br />
<br />
<br />
L'un des points importants concernant le dispositif est son coût : moins de 300 euros.<br />
L'appareil dispose :<br />
* d'un PC portatif (PC-on-a-stick) ''Rikomagic MK802 IV'',<br />
* d'un recepteur radio SDR ''FUNcube Dongle Pro+''<br />
* d'une antenne radio<br />
* d'une batterie<br />
* d'une antenne WiFi<br />
* d'une carte MicroSD<br />
* d'un adapteur d'antenne<br />
* et d'une '''pita'''.<br />
<br />
<br />
Le dispositif aurait une portée de 50cm. <br />
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.<br />
<br />
==Scénario d'usage du produit ou du concept envisagé==<br />
<br />
''Scénario 1''<br />
<br />
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. <br />
<br />
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.<br />
Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. <br />
Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.<br />
<br />
<br />
''Scénario 2''<br />
<br />
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.<br />
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.<br />
<br />
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..<br />
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.<br />
<br />
==Réponse à la question difficile==<br />
<br />
'''Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?'''<br />
<br />
<br />
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. <br />
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). <br />
<br />
<br />
=Préparation du projet=<br />
<br />
==Cahier des charges==<br />
<br />
Nous souhaitons <br />
* Capter le signal émis par un objet connecté le plus précisément possible<br />
<br />
* Concevoir nos propres objets connectés tous différents mais basés sur un même modèle<br />
<br />
* Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions<br />
<br />
* Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché<br />
<br />
==Choix techniques : matériel et logiciel==<br />
<br />
<br />
Choix logiciel :<br />
<br />
- 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).<br />
<br />
- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560<br />
<br />
<br />
Choix Matériel : <br />
<br />
- Plusieurs modules radios émetteurs <br />
<br />
- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560<br />
<br />
- Des alimentations identiques pour chaque PCB<br />
<br />
- Un HackRF pour la réception des signaux<br />
<br />
- Une antenne 50 Ohm pour le HackRF [https://www.passion-radio.fr/accessoires-sdr/antenne-ant500-74.html]<br />
<br />
==Liste des tâches à effectuer==<br />
<br />
Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :<br />
<br />
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.<br />
<br />
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)<br />
<br />
<br />
<br />
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.<br />
<br />
Nous devons donc dans un second temps: <br />
<br />
- Récupérer la signature de deux objets connectés identiques mais qui ont un '''firmware''' différent.<br />
<br />
- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le '''microcontrôleur'''.<br />
<br />
- Récupérer la signature de deux objets connectés identiques dont seul le '''PCB''' diffère.<br />
<br />
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.<br />
<br />
<br />
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).<br />
<br />
==Calendrier prévisionnel==<br />
<br />
=Réalisation du Projet=<br />
==Feuille d'heures==<br />
<br />
{| class="wikitable"<br />
!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<br />
|-<br />
| Analyse du projet <br />
| 2<br />
| 8<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Prise en main de GnuRadio<br />
|0<br />
|4<br />
|4<br />
|4<br />
|3<br />
|2<br />
|3<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Configuration Xbee<br />
|0<br />
|2<br />
|2<br />
|1<br />
|1<br />
|1<br />
|2<br />
|x<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Total<br />
|2<br />
|0<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|}<br />
<br />
==Prologue==<br />
==Semaine 1==<br />
[[Fichier:HackrfOne.jpeg|200px|thumb|right|Le HackRF One]]<br />
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. <br />
<br />
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.<br />
<br />
<br />
=== Choix des émetteurs/récepteurs === <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).<br />
<br />
''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.''<br />
<br />
==Semaine 2==<br />
<br />
<br />
=== Configuration des modules XBee ===<br />
<br />
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux : <br />
<br />
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''. <br />
<br />
Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante : <br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div><br />
<br/><br />
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''').<br />
<br />
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 [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).<br />
<br />
Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande '''ATRE'''.<br />
<br />
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'''.<br />
<br />
Ensuite il faut leur donner une adresse de destination ('''ATDH''' & '''ATDL''') qui sera l'adresse broadcast, pour ce faire on entre <br />
ATDH=0000<br />
ATDL=FFFF<br />
<br />
Enfin '''ATMY''' représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.<br />
<br />
N'oublions pas de sauvegarder les paramètres avec '''ATWR'''.<br />
<br />
On vérifie que tout a bien été pris en compte :<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
+++OK<br />
<br/><br />
ATID<br />
<br/><br />
BEE6<br />
<br/><br />
ATCH<br />
<br/><br />
C<br />
<br/><br />
ATDH<br />
<br/><br />
0<br />
<br/><br />
ATDL<br />
<br/><br />
FFFF<br />
<br/><br />
ATMY<br />
<br/><br />
5000<br />
<br/><br />
ATCN<br />
<br/><br />
OK<br />
</div><br />
<br/><br />
Puis on fait de même avec le deuxième XBee (ID 5001).<br />
<br />
Voilà, lorsque on envoi 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.<br />
<br />
<br />
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.<br />
<br />
=== Première prise en main du logiciel GNURADIO ===<br />
<br />
Installation de GNU radio avec les fonctions + drivers pour HackRF : <br />
<br />
sudo apt-get install gqrx gnuradio gr-osmosdr hackrf <br />
<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.<br />
<br />
<br />
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]<br />
<br />
==Semaine 3==<br />
<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
Néanmoins, le signal est perturbé par le bruit environnant. <br />
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.<br />
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.<br />
<br />
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.<br />
<br />
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.<br />
<br />
<br />
<br />
<!-- [[Fichier:Channel135001.png|thumb|400 px]] --><br />
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] --><br />
<br />
[[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|400 px]][[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]]<br />
<br />
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.<br />
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.<br />
<br />
On réeffectuera une expérience en zone isolée des signaux parasites.<br />
<br />
<br />
==Semaine 4==<br />
<br />
Cette semaine, nous nous sommes principalement à la tâche de recherche afin de mieux comprendre les signaux émis par le Xbee.<br />
<br />
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éveloppper nos études ?<br />
<br />
==Semaine 5==<br />
<br />
On décide d'automatiser le processus d'envoie sur le port série des données vers le Xbee.<br />
En effet, le fait que des données soient envoyées sur un temps t ne nous permet de voir correctement le signal. Il nous est nécessaire d'approcher le moment de balayage avec l'envoi des données.<br />
<br />
Un script python est réalisé afin d'envoyer en continue les données.<br />
En outre, le script permet de changer toutes les dix secondes de canal d'envoi.<br />
<br />
=Documents Rendus=</div>Amoreau