Version du 21 janvier 2019 à 09:18

Détection de menaces IOT sur FPGA

Présentation générale

De nos jours, l'informatique s'oriente vers une philosophie microservices. C'est-à-dire que l'on conçoit une multitude de tâches simples, qui permettent de réaliser un système plus complexe une fois rassemblées. L'IOT (internet des objets) est conçu sur ce principe. Par exemple, dans le cadre de la domotique, une maison est "connectée" grâce à une base sur laquelle viennent s'appairer plusieurs objets (capteurs, actionneurs, indicateurs, ...), constituant alors un réseau complet. Le problème est que par soucis de praticité, la grande majorité des objets IOT fonctionnent sur batterie, ce sont donc de très petit système incapables de se défendre en cas d'attaques.

Description

Ce projet a pour but de proposer un système permettant de détecter de possibles menaces sur un réseau IOT en temps réel.

Objectifs

• Lister les attaques possibles sur un réseau IOT
• Mettre en place un réseau IOT permettant d'étudier certaines attaques
• Récupérer les différentes informations des objets connectés sur un FPGA
• Agréger ces données pour en sortir des modèles
• A partir de ces modèles, être capable de détecter de possibles attaques
• Proposer un système de dashboard / alerting permettant de visualiser l'état du réseau

Cahier des charges

Le système sera composé d'une base (sur laquelle les objets seront connectés) constituée d'un FPGA couplé à un processeur fonctionnant avec linux. Ce système pourra détecter des menaces réseaux (déni de service, homme du milieu, ...) ou des menaces physiques (brouillage, diminution de la batterie, ...).

• Il faudra dans un premier temps recenser les différentes attaques possibles sur un réseau IOT puis déterminer celles qui pourront être détectées (par exemple le eavesdropping - consistant à juste écouter le traffic - ne sera pas détectable).
• Ensuite, un réseau IOT simple sera mis en place, ce dernier sera constitué de la base (décrite ci-dessus) et de quelques nœuds communicant avec cette base. Deux cas seront à prendre en compte, le premier est une communication direct entre un nœud et la base, le second est une communication d'un nœud vers un autre noeud qui relayera vers la base. Le protocole de communication sera choisi parmi ceux qui sont les plus utilisés en IOT (BLE, Z-Wave et ZigBee pour les courtes distances ; Lora et SigFox pour les distances plus longues).
• Une fois le réseau mis en place, il faudra récolter certaines informations concernant les nœuds et les agréger sur la base dans le but de définir les comportements normaux des nœuds.
• Après avoir définit ces comportements normaux, les attaques retenues dans le point 2 seront testées sur le réseau afin de voir leur(s) impacte(s) sur les données récoltées et d'en déduire des seuils permettant de basculer entre l'état normal et l'état anormal.
• Enfin, un système de dashboard sera proposé pour visualiser l'état du réseau IOT et émettre des alertes.

Réalisation du Projet

Liste non exhaustive des attaques possibles sur un réseau IOT

Couche Applicative

La couche applicative permet d'améliorer l'expérience utilisateur, elle induit aussi de possibles attaques :

• Injection de code par l'exploitation de bug : le plus souvent réaliser avec un "buffer overflow" qui va corrompre la mémoire vive et permettre d'injecter du code exécutable.

• Autorisation : beaucoup d'objets IOT ont la configuration par défaut (par exemple admin:admin comme logins) ce qui permet d'avoir un accès direct au shell de l'objet en question.

Couche Réseau

La couche réseau constitue les différents protocoles et trames utilisés par les objets pour communiquer, c'est la couche ou l'on retrouve le plus d'attaques possibles :

• Déni de service (DOS) : envoyer un nombre important de requêtes pour submerger le trafic.

• Homme du milieu (MITM) : intercepter le trafic venant d'un objet puis le transmettre à la base (ou inversement), permettant d'écouter ou de modifier le trafic de manière incognito.

• Sybil attack (multiplication d'identités) : créer de fausses identités sur le réseau afin de le corrompre.

• Sinkhole / Blackhole : intercepter tout le trafic et le router ailleurs (sinkhole) ou ne pas le router (blackhole), nécessite de se faire passer pour la base ou un relayeur.

• Sniffing : écouter le trafic pour l'analyser, permet ensuite de faire du DOS ou MITM.

• Hello spamming : se faire passer pour un nouvel objet et envoyer un nombre important de requête d'appairage, permet de faire du DOS ou d'obtenir la connexion au réseau.

Couche de Perception

La couche de perception permet aux objets d’émettre et de recevoir le trafic, rendant les objets vulnérables à plusieurs attaques :

• Eavesdropping : écouter le trafic.

• Brouillage RF : submerger les bandes de fréquences pour noyer les communications.

• Spoofing : se faire passer pour un nœud valide.

• Bloquer la mise en veille : envoyer des signaux de réveil de manière répétée afin de sur-consommer la batterie des objets.

Couche Physique

Enfin la couche physique, constituée du matériel à proprement parlé, ajoute une attaque à la liste :

• Ajout d'un objet malicieux

Préparation du processeur

Le processeur utilisé pour le projet est un Zynq xc7z010 (monté sur une carte Zybo), qui est constitué de deux cœurs de type CPU et d'une partie logique de type FPGA, comme indiqué sur le schéma suivant : https://www.xilinx.com/content/dam/xilinx/imgs/block-diagrams/zynq-mp-core-dual.png

On remarque les interfaces AXI qui permettrons d'établir la communication entre le CPU et le FPGA.

Pour commencer, il faut installer une distribution linux de type petalinux sur la partie CPU du processeur. Diligent propose une distribution qui est adaptée à cette famille board.

Prérequis

Vivado WebPack version 2017.2 ou 2017.4, de préférence sur une machine linux (j'ai donc installé une machine virtuelle de type ubuntu sur mon pc).

Le SDK Xilinx (proposé lors de l'installation de Vivado).

Le fichier de configuration des cartes installé dans /opt/Xilinx/Vivado/VERSION/data/boards.

Note

Les version ne sont pas toujours compatibles entre elles. Par exemple, configurer un projet petalinux de version 2015.4 avec le CLI 2017.4 ne fonctionnera pas puisque le système de fichier utilisé est différent. Dans mon cas j'utilise la version 2017.4 sur tous les outils.

Les builds avec Vivado et Petalinux sont longs, une machine avec 4 cœurs ou plus est préférable.

Sources

Xilinx Petalinux workflow

Digilent Petalinux repository

Digilent Linux Base repository

Digilent IP library

Installation de l'outil petalinux

Petalinux est un outil en ligne commande permettant de compiler des images linux, l'exécutable pour l'installation peut être trouvé ici, il choisir la même version que l'installation de Vivado.

L'installation requiert plusieurs librairies et échouera si l'une d'entre elles n'est pas installée (à exécuter en tant que root):

apt-get install g++ chrpath xvfb xterm tofrodos iproute gawk gcc git-core make net-tools libncurses5-dev tftpd zlib1g-dev libssl-dev flex bison libselinux1 lib32z1 lib32ncurses5 lib32stdc++6 libbz2-1.0:i386 libtool-bin

L'installation peut être lancée même si il manque l'une de ces librairies, mais elle échouera au bout d'une dizaine de minutes. D'autre part, en cas d'échec de l'installation, le dossier de destination n'est pas vidé, entraînant alors aussi un échec lors d'une nouvelle tentative.

L'installation peut ensuite être lancée (/opt/Petalinux doit exister et disposer d'au moins 20Go):

PATH-TO/petalinux-v2017.4-final-installer-dec.run opt/PetaLinux

Une fois l'installation terminée (ce qui peut prendre environ 15 mins), vérifiez que vous êtes bien configurer en bash et sourcez les scripts nécessaires :

sudo dpkg-reconfigure dash
source /opt/Petalinux/settings.sh
source /opt/Xilinx/Vivado/2017.4/settings64.sh

(les sources peuvent être ajoutées directement dans /etc/bash.bashrc)

Préparation de la carte SD

L'image linux va être booté depuis une carte SD. Il faut donc placer le jumper JP5 sur la carte Zybo en position SD/QSP1.

La carde SD doit être formatée avec une partition fat32 d'1Go pour le boot et d'une partition ext4 pour le système de fichier.

Pour ce faire il faut supprimer le formatage par défaut de la carte sd. Je l'ai fait depuis le powershell de Windows :

> DISKPART
DISKPART > list disk 
DISKPART > select disk 1
DISKPART > disk clean
DISKPART > exit

Ensuite j'ai monté la carte sd sur ma machine virtuelle pour la formater. Pour une machine virtuelle tournant sur VirtualBOX :

Obtenez le DeviceID du disque (depuis un powershell):

wmic diskdrive list brief

Creez le fichier vmdk (depuis un powershell en tant qu'administrateur):

C:\Program Files\Oracle\VirtualBox\VBoxManage internalcommands createrawvmdk -filename "%USERPROFILE%/Documents/sdcard.vmdk" -rawdisk "\\.\PHYSICALDRIVE1"

Ouvrez VirtualBOX en tant qu'administrateur et ajoutez le disque à la machine virtuelle (la vm doit être éteinte):

selectionner la vm > Configuration > Stockage > Contrôleur SATA > Ajoute un disque dur > Choisir un disque existant > ~/Documents/sdcard.vmdk

Pour formater la carte sd avec linux, cherchez la partition (à exécuter en tant que root):

fdisk -l

Puis lancez l'outil fdisk (en tant que root) pour configurer la carte sd (/dev/sdb dans mon cas):

> fdisk /dev/sdb
fdisk > n            créer la première partition
fdisk > p            en fait une primary
fdisk > 1            lui affecte le numéro 1
fdisk >              premier block (laissez par defaut)
fdisk > +1G          dernier block pour former une partition d'1Go
fdisk > a            en fait la partition de boot
fdisk > n            créer la deuxième partition
fdisk > p            en fait une primary
fdisk > 2            lui affecte le numéro 2
fdisk >              premier block (laissez par defaut, après la fin de la première partition)
fdisk >              dernier block (laissez par defaut pour utiliser l'espace restant)
fdisk > w            applique les changement
fdisk > p            affiche les partitions pour vérifier
fdisk > q            quitter

Configurez les partitions en fat32 et ext4 (à exécuter en tant que root):

mkfs.vfat -F 32 -n boot /dev/sdb1
mkfs.ext4 -L root /dev/sdb2

Compilation de l'image petalinux

A partir d'un fichier bsp (board support package)

Diligent propose propose une image petalinux simple à utiliser. Elle peut être téléchargée ici.

Créez le projet à partir du fichier téléchargé (cela peut prendre un certain temps):

petalinux-create -t project -s Petalinux-Zybo-2017.4-1.bsp

Il y a une images précompilée dans le dossier Petalinux-Zybo-2017.4-1/pre-built/linux/images/, copiez BOOT.BIN et image.ub dans la première partition de la carte sd. Placez la carte sd dans la Zybo et mettez la carte sous tension.

Pour se connecter à la carte, utilisez minicom sur le port série (à exécutez en root):

minicom -D /dev/ttyUSB1

Le port série doit être configuré de la façon suivante:

• baud rate = 115200
• data bits = 8
• stop bits = 1
• flow control = none
• parity = none

Le shell du petalinux devrait apparaître. Pour revoir le boot, cliquez sur le bouton BTN7 (PS-SRST) de la carte.

Il est possible de programmer la partie FPGA depuis petalinux en écrivant le bitstream dans /dev/xdevcfg :

cat bitstream.bit > /dev/xdevcfg

Néanmoins, dans mon cas, ceci écrase la configuration de petalinux et le rend inutilisable.

Cette image petalinux est adaptée à une définition hardware (block design) prédéfinie qui est la suivante :

[zybo_base_hw.png]

Si on tente de compiler le kernel linux avec un block design différent, le device tree ne correspondra pas et la compilation échouera.

Il faut donc créer sont propre projet petalinux pour y intégrer un block design custom.

A partir d'un projet petalinux standalone

Il est possible de créer une image Petalinux à partir d'un projet Vivado, incluant alors la partie Hardware (block design), la partie FPGA (bitstream), ainsi que la partie linux (FSBL). Pour commencer, je me suis basé sur un tutoriel de Digilent pour créer un IP utilisant l'interface AXI.

Projet Vivado

Xilinx SDK

Création de l'image Petalinux

L'interface de connexion AXI

Infrastructure d'un réseau IOT

Documents Rendus