P31 Partition HTTP/TLS pour Pepin

Cahier des charges

Présentation générale du projet

Contexte

L’équipe 2XS (eXtra Small, eXtra Safe) de l’IRCICA en train de développer un exo-noyau qui a une architecture plus simple (donc plus sécurisé) qu’un noyau monolithique. Ce type d’architecture fonctionne plutôt dans l’espace utilisateur que l’espace noyau ce qui permet d’éliminer l’abstraction d’un système d’exploitation. Ceci permet l’interaction plus direct avec les matériels.

Description du projet

Pépin (ou PIP) est l’exo-noyau développé par l’équipe dans le but de créer un système qui isole complètement les partitions de mémoire selon un modèle hiérarchique : une partition peut contenir des sous-partitions (qui peuvent elles-mêmes contenir des sous-sous-partitions). Cette isolation de mémoire garantit un niveau de sécurité élevée car les partitions de même niveau (dans la hiérarchie) ne peuvent pas communiquer entre elles.

Objectif du projet

L’intérêt de ce projet est de développer une partition qui s’exécutent au-dessus de Pépin qui héberge un serveur web et implémente un protocole d’échange sécurisé de type TLS-PSK. Pour cela, il faut adapter un serveur web existant afin de pouvoir le porter au Pépin.

Choix techniques : matériel et logiciel

Pour le développement de la partition de serveur web, on utilise le langage C et assembleur (si besoin). Pour tester le système, on l’implémente dans une carte embarquée ayant l’architecture x86 (ie : Intel Galileo).

Etapes du projet

• Etudier l'architecture de Pépin
• Identifier une solution existante de serveur web qui peut être adapté pour le système
• Adapter le code du serveur web pour pouvoir utiliser avec Pépin
• Intégrer Pépin et le serveur web dans une carte embarqué et tester la solution

Planning prévisionnel

Tâche	Date
	2016															2017
	19/09	26/09	03/10	10/10	17/10	24/10	31/10	07/11	14/11	21/11	28/11	05/12	12/12	19/12	26/12	02/01	09/01	16/01	23/01	30/01	06/02	13/02	20/02
Définition de cahier des charges
Etudier l'architecture de Pépin
Identifier un serveur web existant qui peut être adapté pour le système
Compléter le code pour un serveur web embarqué et le tester dans Linux
Adapter le code du serveur web pour pouvoir utiliser avec Pépin
Intégrer et tester le serveur web dans Intel Galileo

Avancement du Projet

Etudes de l'architecture de Pépin

L'exo-noyau Pépin se situe au dessus de niveau matériel et se constitue d'IAL, de MAL, d'une section BOOT et une section CORE.

User space	Les différentes partitions
	Multiplexeur
Kernel space	IAL	MAL	Boot	Core
Hardware

• IAL: sert à la gestion de communication avec le processeur
• MAL: sert à la gestion de communication avec la mémoire
• BOOT: contient le code pour démarrer Pépin
• CORE: contient le code de fonctionnement de Pépin
• Multiplexeur: sert à créer et gérer les partitions de mémoire et aussi pour la gestion de conflit de mémoire

Identification d'un serveur web adapté pour Pépin

Il existe plusieurs serveur web qui ont déja été développé. La table ci-dessous résume certains serveurs web qui pourraient être porté vers Pépin

Serveur web	Avantage	Inconvénient	SSL/TLS
Apache	Plus utilisé	Lourds	Oui
		Inadapté pour l'embarqué
LigHTTPD	Léger	Besoin d'un OS classique ou OS embarqué	Oui
	Facile à mettre en oeuvre
Mongoose	Petite en taille	Implémentation non complète de SSL/TLS	Manque certain type de mécanisme d'échange de clé
	API en C pour le dévelopement
SMEWS	Très petite en taille	Pas d'implementation de SSL/TLS	Non
	Bien adapté pour plusieurs types de systèmes embarqués

Nous avons choisi la solution Mongoose parce qu'il est bien adapté (même s'il manque certaines implémentation de SSL/TLS comme l'échange de clé par PSK). Donc, on va ajouter une couche de wolfSSL qui contient plusieurs mécanisme de TLS-PSK comme:

• TLS_PSK_WITH_AES_128_GCM_SHA256
• TLS_PSK_WITH_AES_256_GCM_SHA384
• TLS_PSK_WITH_AES_256_CBC_SHA384
• TLS_PSK_WITH_NULL_SHA384
• TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
• TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
• TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
• TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
• TLS_DHE_PSK_WITH_NULL_SHA256
• TLS_DHE_PSK_WITH_NULL_SHA384
• TLS_DHE_PSK_WITH_AES_128_CCM
• TLS_DHE_PSK_WITH_AES_256_CCM

Dans Pépin, nous devrions avoir une pile TCP/IP qui gère les couches hautes comme le transport et l'application sachant que les couches base sont en cours de développement. Pour cela, on a décidé d'utiliser la solution picoTCP. Donc, la solution complète est :

Couches hautes	Application	Serveur web Mongoose
	Transport	wolfSSL
		picoTCP
Couches bases	Réseau
	Liaison de données
	Physique

Compléter le code pour un serveur web embarqué et le tester dans Linux

Avant d’implementer le serveur web complet, il fallait tester d’abord le fonctionnement de picoTCP tout seul (sans glue).

picoTCP seul

Pour utiliser picoTCP sous Linux, il faut créer un tunnel TUN/TAP afin que le système d’exploitation (Linux) ne modifie pas la trame ethernet. C’est parce que l’interface de carte réseau va enlever l’entete Ethernet et va passer le payload (normalement les paquets IPs) au système. D’où l’utilisation de TUN/TAP sera utile. Un dispositif TUN/TAP peut être vu comme une interface réseau qui communique avec un programme utilisateur (dispositif logiciel) au lieu d'une vraie carte matérielle (TUN pour miner un périphérique point à point, TAP pour mimer un périphérique Ethernet). Dans ce cas, on va utiliser une interface de type TAP.

Création de l’interface tap0 (en tant que root):

tunctl ifconfig tap0 10.0.0.1

On peut tester l’impléméntation de picoTCP avec ICMP en faisant un ping vers 10.0.0.1 :

dev = pico_tap_create("tap0"); //attribute ip and netmask to a new interface in tap0 pico_string_to_ipv4("10.0.0.2", &ipaddr.addr); pico_string_to_ipv4("255.255.255.0", &netmask.addr); pico_ipv4_link_add(dev, ipaddr, netmask); //ping the ip address NUM_PING times pico_icmp4_ping("10.0.0.1", NUM_PING, 1000, 10000, 64, ping_callback_function);

Références

Introduction à l'exo-noyau
A propos de SMEWS
Introduction de picoTCP
Article à propos de Mongoose dans Linux Journal
Documentation wolfSSL