SLA de sécurité pour la couche sensing : SECgSLA

Afin de prendre en considération les besoins de sécurité relatifs à la couche sensing de l’architecture IoT décrits dans la section 6.2 de ce chapitre, nous spécifions le contrat de type

SECgSLA avec différents paramètres que nous décrivons dans la section suivante. Paramètres du SECgSLA

Le contrat SECgSLA est un contrat interne à l’IoT-SP permettant de spécifier les mesures de

sécurité à mettre en place au niveau de la couche sensing afin de contribuer à l’offre de sécurité

globale exigée par l’IoT-C. Ce contrat comprend 5 parties à savoir : « Identification », « Validity »,

6.3. Extension des SLA du Framework

136

de type SECgSLA comporte des informations qui permettent de l’identifier à travers un SECgSLA ID

et de l’associer, à travers le gSLA ID, au contrat de QoS de type gSLA qu’il permet d’étendre à la

sécurité. D’autre part, le contrat SECgSLA dispose des mêmes informations que le gSLA (cf. section

4.3.3.2) en ce qui concerne la validité du contrat, les partenaires du contrat (IoT-SP étant le client et

HL-Gw étant le fournisseur) et l’identification du service (voir Figure 6.11). Le contrat SECgSLA ne

comprend pas de paramètres commerciaux comme il s’agit d’un contrat interne à l’IoT-SP.

Figure 6.11 : Représentation globale du schéma XML du SECgSLA

Les paramètres de sécurité de l’attribut « Security » du SECgSLA (voir Figure 6.12) peuvent

être spécifiés d’une façon qualitative (i.e., Gold, Silver, Bronze) ou quantitative sachant qu’un niveau de sécurité décrit d’une façon qualitative est mappé à un ensemble de paramètres de sécurité

quantitatifs spécifiés par l’IoT-SP.

Chapitre 6 – Extension du Framework de garantie de niveau de service à la sécurité

137

Les paramètres de sécurité quantitatifs du SECgSLA concernent la confidentialité, l’intégrité,

l’identification, le contrôle d’accès et la vie privée au niveau de la couche sensing à travers les attributs « Sensing Data Confidentiality », « Sensing Integrity », « Sensing Identification », « Sensing Access Control » et « Sensing Privacy on HL-Gw ». Ainsi, la confidentialité et l’intégrité des données au niveau de la couche sensing sont spécifiées à travers un ensemble d’algorithmes de chiffrement et de hachage adaptés aux objets ayant des contraintes en termes de capacités de traitement et de mémoire (voir Figure 6.13).

Figure 6.13 : Paramètres de sécurité quantitatifs du SECgSLA : Confidentialité

L’intégrité des objets IoT de la couche sensing est préservée en définissant des groupes d’objets avec les mêmes caractéristiques (logiciels installés par exemple) dont le digest est calculé

grâce au Trusted Platform Module (TPM) ou encore à l’Integrity Measurement Architecture (IMA).

De même, nous préservons l’intégrité des passerelles de bas niveau et de haut niveau (LL-Gw et

HL-Gw) en utilisant le module TPM ou l’architecture IMA pour vérifier leurs digests (voir Figure 6.14).

Ce digest nous permet de déterminer l’empreinte digitale utilisée dans d’autres services de sécurité telle que la vérification d’identité.

De plus, les objets et les passerelles doivent être identifiés au niveau de la couche sensing. Par conséquent, nous définissons dans l’attribut « Sensing Identification » (voir Figure 6.15) du

SECgSLA les paramètres utilisés pour leurs identifications. Ainsi, l’identification des objets IoT est basée sur l’appartenance à un groupe d’objets ayant chacun un identifiant et un type de service IoT

(i.e., RTMC, RTNMC, Streaming, NRT).Le groupe d’objets comporte aussi les identifiants des

passerelles LL-Gw impliquées dans l’offre d’un service IoT ainsi que son empreinte digitale. De

même, les passerelles LL-Gw et HL-Gw sont identifiées via leurs identifiants (LL-Gw ID et HL-Gw

6.3. Extension des SLA du Framework

138

Figure 6.14 : Paramètres de sécurité quantitatifs du SECgSLA : Intégrité

Chapitre 6 – Extension du Framework de garantie de niveau de service à la sécurité

139

D’autre part, le contrôle d’accès des objets IoT à la passerelle LL-Gw est défini dans l’attribut

« Sensing Access Control » (voir Figure 6.16) du SECgSLA via un modèle basé sur les attributs. Ce

modèle prend en considération les attributs suivants : identifiant du groupe et niveau de confiance de base pour les objets du groupe. Le niveau de confiance est utilisé afin de donner accès aux objets IoT

ayant un niveau de confiance supérieur ou égal au niveau de confiance spécifié dans le SECgSLA. La

méthode que nous avons spécifiée pour la détermination du niveau de confiance des objets IoT est détaillée dans le chapitre 7.

Le modèle basé sur les attributs prend en considération aussi le temps de service comme paramètre environnemental afin de prendre une décision relative à différentes actions possibles (lecture, écriture et modification) dans le cadre du contrôle d’accès de l’objet IoT à la ressource de

type LL-Gw. De même, un contrôle d’accès pour les LL-Gw auprès des HL-Gw est spécifié dans ce

même attribut « Sensing Access Control » du SECgSLA en utilisant un modèle basé sur les attributs

identique à celui du modèle du contrôle d’accès des objets.

Figure 6.16 : Paramètres de sécurité quantitatifs du SECgSLA : Contrôle d’accès Enfin, la protection de la vie privée des utilisateurs au niveau de la couche sensing est prise

6.3. Extension des SLA du Framework

140

spécifiant la localisation du stockage des données et des sauvegardes de secours, la possibilité de

vente des données à des tierces parties et l’anonymisation des données.

Figure 6.17 : Schéma XML du SECgSLA : Protection de la vie privée Procédure d’établissement du SECgSLA

Différents échanges doivent avoir lieu entre l’IoT-SP et la HL-Gw pour établir le SECgSLA.

Ces échanges permettent aux différentes parties de se mettre d’accord sur les paramètres de sécurité

demandés par l’IoT-SP. Nous spécifions dans la Figure 6.18 l'ensemble des états de l'automate fini

FSM concernant l’établissement du SECgSLA au niveau de l’IoT-SP.

Figure 6.18 : FSM de l’IoT-SP pour l’établissement du SECgSLA

Dans l’état S0, l’IoT-SP attend la demande de souscription d’un nouveau service IoT avec

sécurité émanant d’un IoT-C. Suite à la réception de cette demande, l’IoT-SP passe à l’état S1. Dans

cet état, il envoie une requête d’initialisation d’un SECgSLA vers une HL-Gw avant de passer vers

l’état S2. L’IoT-SP reste dans l’état S2 en recevant l’offre de sécurité de la HL-Gw correspondante.

Si l’offre de sécurité reçue n’est pas convenable, l’IoT-SP revient à l’état S1 et change de HL-Gw.

Dans ce cas (i.e. dans l’état S1), si l’IoT-SP a déjà refusé toutes les offres de sécurité émanant de

toutes les HL-Gw disponibles, l’IoT-SP reste dans l’état S1 et implémente une nouvelle HL-Gw.

Chapitre 6 – Extension du Framework de garantie de niveau de service à la sécurité

141

spécification des mécanismes de sécurité à appliquer par la HL-Gw et passe à l’état S3. Dans cet état,

l’IoT-SP reçoit l’offre SECgSLA de la HL-Gw qu’il accepte avant de passer vers l’état S0 en attendant la fin du service IoT avec garantie de sécurité correspondant pour résilier ce contrat.