Memoire Online - Sécurité dans les systèmes temps réel

Comme nous l'avons mentionné dans le chapitre 1, dans les systèmes embarqués qui utilisent un réseau, nous devons à la fois respecter les contraintes d'échéances, tout en assurant la confidentialité des données, l'intégrité et l'authentification. Mais malheureusement, l'utilisation des algorithmes de cryptographie amène souvent au non-respect des contraintes d'échéances, surtout pour des systèmes embarqués qui sont limités en ressources pour des raisons de coût et de consommation.

Les travaux sur la sécurité et sur les systèmes temps réel ont été étudiés la plupart du temps séparément. Il n'existe que très peu de travaux étudiant le problème de la sécurité sous des contraintes d'échéance. En étudiant les travaux et articles rédigés à propos de la sécurité dans les systèmes temps réel, nous remarquons que ceux-ci se basent généralement sur les concepts de qualité de service (QoS), qui ont déjà été plus largement analysés dans la littérature. Le rapport de recherche [14] reprend différents mécanismes de gestion de la qualité de service dans les systèmes temps réel.

Souvent, différents « niveaux de service » sont appliqués afin de respecter au mieux les échéances tout en sécurisant le plus possible le système. Une certaine valeur est associée à chaque niveau selon son importance, l'objectif étant de maximiser la valeur totale du système.

Ce chapitre présente des méthodes que nous allons analyser et éventuellement critiquer.

En cryptographie, il est bien connu qu'en augmentant le nombre de bits dont est constitué une clé qui servira à chiffrer les données, un attaquant mettra plus de temps à casser le chiffrement [17]. La complexité pour casser le chiffrement est donc exponentielle en fonction de la longueur de la clé.

Il est donc nécessaire d'utiliser une clé de taille suffisante. Une clé formée de £ bits appartient à un espace de clés constitué de 2 clés possibles. Un attaquant qui est capable de tester m clés par seconde, mettrait donc en moyenne 2^e_1 /m secondes pour trouver la bonne clé par une attaque de type brute-force (2`/m secondes au pire des cas).

Brute-force est une recherche exhaustive sur tout l'espace des clés. Il est donc indispensable que le temps mis pour casser la sécurité par ce type d'attaque soit trop important par rapport à la valeur des données et que le système de chiffrement soit robuste, c'est à dire que le seul moyen d'attaquer le système soit d'appliquer une attaque brute-force.

AES, par exemple, utilise des clés de 128, 192, ou 256 bits [21] donc la quantité de clés possibles avec ces dimensions est relativement importante. De plus, AES est un algorithme de chiffrement robuste puisqu' aucune attaque sur les versions standards d'AES n'a été découverte à ce jour¹, il pourrait donc tout à fait être utilisé dans ce cadre.

Cependant, employer toujours la plus longue clé provoque une augmentation du temps de calcul utilisé par l'algorithme de chiffrement et donc il en résulte un besoin de dégrader la qualité de service. Cette diminution de la qualité de service permet de diminuer le temps d'exécution de manière à ce que les échéances soient encore toutes respectées.

Kyoung Don Kang et Sang H. Son dans leur étude [9] que nous allons présenter dans cette section, essayent de maximiser la qualité de service tout en garantissant que le système soit suffisamment sécurisé. Les auteurs, présentent leur méthode avec DES, mais ce n'est pas un algorithme de chiffrement robuste, DES a été cassé en 22 heures et 15 minutes lors du 3^e« DES Challenge » en janvier 1999 [19]. Nous préfèrerons donc présenter cette méthode en nous basant sur l'algorithme de chiffrement AES.

¹Il existe néanmoins des attaques sur AES en diminuant le nombre de tours à 5, 6 ou 7 [22].

Le modèle sur lequel nous nous basons ici est constitué d'un ou de plusieurs systèmes embarqués temps réel (SETR), par exemple des capteurs, comme représenté sur la figure 3.1. Ce SETR doit échanger ses informations avec un centre de contrôle (CC).

FIG. 3.1 - Schéma représentant le modèle SETR--CC Le SETR est constitué de n tâches T1, T2, ... T_n.

La longueur de la clé £ est augmentée en fonction du risque encouru. Ce risque est transmis par un détecteur d'intrusion (IDS : « Intrusion Detection System ») installé sur le SETR et sur le CC. Lorsqu'une intrusion est détectée, le niveau de risque est augmenté. Le SETR va devoir alors augmenter la taille de la clé avec laquelle il chiffre ses données. Cela entraînera une diminution de la qualité de service de certaines tâches. La notion de qualité de service utilisée ici n'est pas définie dans [9] mais nous pouvons supposer qu'il s'agit de la fréquence des prises d'informations par les capteurs. Cette diminution correspond

donc à une diminution du facteur d'utilisation de ces tâches. En effet, la qualité de service étant plus faible, moins de traitements sont nécessaires et Ci est diminué. Cela permet d'éviter de rater des échéances à cause du coût en temps trop élevé dû à la mise en place de la sécurité.

Trois niveaux de risques sont définis dans [9] : faible: R= 1, moyen: R=2, élevé: R=3.

Le niveau de défense S(L) se calcule en fonction de la longueur de la clé L. En nous basant sur les possibilités offertes par AES par rapport à la taille des clés, nous posons donc:

Le but est de maximiser la qualité de service globale du système (QoS) qui augmente en fonction de la qualité de service Q(i) des différentes tâches.

où Q(i) et max Q(i) sont respectivement la qualité de service courante et maximum pour la tâche Ti. Nous définissons la variable S par 3.3

Ce qui signifie (voir équation 3.2) que si le niveau de défense (S(L)) est inférieur au niveau de risque (R) envoyé par l'IDS, la qualité de service du système est nulle.

Nous calculons l'utilisation de la tâche Ti en tenant compte de _Ci,e(`), l'utilisation du système, ne pouvant pas (pour rappel) dépasser une certaine borne d'utilisation (B), par exemple 100% pour EDF (Earliest Deadline First) sinon le système n'est plus ordonnançable.

Un algorithme hors-ligne (algorithme 1) calcule premièrement la qualité de service optimale pour chaque tâche Ti à utiliser en fonction de la longueur de la clé L et d'une fonction gi.

En effet, chaque tâche Ti possède une fonction gi : ui -* qi qui associe à un facteur d'utilisation ui un certain niveau de qualité de service qi, le but de

l'algorithme étant de choisir le niveau de qualité de service adéquat en tenant compte du facteur d'utilisation imposé par la mise en place de la sécurité.

L'algorithme retourne donc un tableau Q_List[e][i] qui représente la QoS optimale à choisir pour la tâche Ti lorsque la clé £ est utilisée. Les étapes qui suivent sont exécutées pour chaque longueur de clé de manière à fournir les différentes lignes Q_List[e] du tableau.

Etape 1 : Pour chaque tâche, on calcule à l'aide de gi et selon la longueur de la clé, l'enveloppe convexe des différentes paires < Utilisation, QoS> pour tous les niveaux discrets de QoS (voir figure 3.3). Le but étant de sélectionner les points sur gi garantissant une qualité de service maximum avec un facteur d'utilisation minimum.

Cela permet d'enlever les paires < uij, qij > qui ne sont clairement pas optimales, où j est le niveau de QoS et _uij est le facteur d'utilisation requis pour la tâche Ti avec ce niveauj de QoS et avec la clé £. Il nous reste alors par exemple (figure 3.3) un ensemble de paires Hi = {< ui1, qi1 >, < ui3, qi3 >, ...}

Etape 2 : Les ensembles Hi ?Ti sont fusionnés et triés par ordre croissant d'utilisation excepté les paires < ui1, qi1 > qui correspondent à la QoS minimum qui devra être garantie à l'étape 5. Le résultat de ce tri/fusion est la liste H_List.

/*Fusion triée des enveloppes convexes de toutes les tâches par ordre non-décroissant sur l'utilisation*/

Algorithme 1: Ajustement optimal de la qualité de service en fonction de la longueur de la clé

Etape 4: U^r représente tout au long de l'exécution de l'algorithme l'utilisa-

tion disponible restante, et est initialisé à la borne d'utilisation maximale B de la politique d'ordonnancement utilisée.

Etape 5 : On va maintenant initialiser Q_List[L] pour que le système supporte au moins le niveau minimum de QoS pour chaque tâche avec une clé de L bits. Si l'utilisation restante U^r est suffisante pour garantir ce niveau de service, on fixe Q_List[L][i] = qi1 et on soustrait _ui1 à U^r, autrement l'algorithme se termine par une erreur puisqu'on dépasse la borne d'utilisation B même avec la QoS minimum.

Etape 6 : Et pour terminer, on procède à l'augmentation au maximum de la QoS de chaque tâche. Pour effectuer cela, on se base sur l'ensemble H_L ist obtenu à l'étape 2. On sélectionne la première tâche Tid = H_List[i].id, c.-à-d. celle qui possède la plus faible utilisation. On calcule le facteur d'utilisation supplémentaire äU nécessaire pour augmenter le niveau de QoS de _Tid. Si celui-ci ne dépasse pas U^r, on augmente le niveau de QoS à la valeur H_List[i].q et on soustrait äU à l'utilisation restante U^r. On passe à l'élément suivant dans H_List jusqu'à ce que U^r soit insuffisant pour augmenter encore la QoS d'une tâche.

La longueur des clés et le niveau de qualité de service sont ajustés en ligne à l'aide du tableau Q_L ist[L][i] fourni par l'algorithme exécuté hors-ligne.

L'IDS envoie périodiquement le niveau de risque courant R, si R> S(l), on passe à une clé L' > L de façon à ce que S(L') = R, ensuite la qualité de service des tâches Ti est diminuée selon Q_List[L'][i] de manière à ne rater aucune échéance.

Nous remarquons qu'un grand intérêt de cet algorithme est que la modification en ligne de la qualité de service pour ajuster le temps d'exécution se fait avec une complexité constante (O(1)) grâce au précalcul effectué hors-ligne par l'algorithme 1.

La complexité de l'algorithme 1 se calcule par rapport au nombre des différentes tailles de clés possibles (K, ici K = 3), au nombre de niveau de QoS (L) et au nombre de tâches (n). On exécute K fois le tri-fusion de L. n paires < Utilisation, QoS >. La complexité du tri-fusion étant de O(nlogn), la complexité de l'algorithme hors-ligne est donc de O(K. Ln. log Ln) qui peut se réduire à O(nlogn) étant donné que K est constant (128, 192 ou 256 bits) tout

Nous allons maintenant analyser la façon dont d'autres auteurs voient le problème, ne se basant plus sur la longueur des clés mais en utilisant différents niveaux de sécurité, qu'ils déterminent soit par différents algorithmes cryptographiques, soit en rajoutant différents services selon le temps disponible et l'importance des tâches.

Tao Xie, dans son étude [27] expose une technique qui établit certains « niveaux de sécurité ».

Les niveaux de sécurité sont définis comme étant une combinaison du transport de l'information sur le réseau, des garanties sur le chiffrement de cette dernière et de l'authentification du client.

Les niveaux choisis dans [27] qui se basent sur différents modes fournis par le protocole de sécurité SSL (« Secure Sockets Layers ») sont:

Plus le niveau de sécurité augmente, plus le temps supplémentaire nécessaire pour établir la sécurité est important.

Chaque tâche possède comme paramètre, en plus de son échéance, un domaine de sécurité, c.-à-d. une borne inférieure et supérieure, qui sont les valeurs minimales et maximales admises comme niveau de sécurité de cette tâche.

A leur arrivée, les tâches sont prises en charge par un contrôleur d'admission, qui fixe le niveau de sécurité et décide si oui ou non la tâche peut être exécutée.

Le contrôleur de sécurité entre alors en jeu. Il augmente le plus possible le niveau de sécurité de chaque tâche dans la file des tâches acceptées en respectant deux contraintes, augmenter le niveau de sécurité ne doit pas:

Il choisira de façon optimale le niveau de sécurité parmi les valeurs dans le domaine de sécurité de la tâche.

EDF ordonnancera ensuite les tâches, en prenant la tâche au sommet de la queue, c.-à-d. la tâche ayant l'échéance la plus proche. Le schéma de fonctionnement de cette méthode et les structures utilisées sont représentés sur la figure 3.4.

La notion de « Success Ratio » (SR) est établie. SR est défini comme étant le rapport entre le nombre de tâches acceptées (N_a) par le contrôleur d'admission et le nombre de tâches reçues (N_r).

Le but étant de maximiser SR tout en maximisant la valeur en sécurité du système, il compare 4 algorithmes utilisant tous EDF comme politique d'ordonnancement:

· EDF_MINS : le plus petit niveau de sécurité spécifié par la tâche est auto-

met donc d'obtenir la plus importante proportion de tâches respectant leur échéance (SR) mais il néglige la sécurité.

Malheureusement, cette technique autorise certaines tâches à ne pas être acceptées à cause d'une augmentation de la sécurité sur d'autres tâches, c'est ce qu'on appelle des systèmes temps réel souples (soft real-time). Nous souhaitons plutôt nous intéresser ici à des systèmes qui tentent d'atteindre un niveau maximum de sécurité sans rejeter de tâches, c'est pourquoi nous ne rentrons pas dans le détail de l'optimisation apportée par l'algorithme EDF_OPTS, le lecteur intéressé par cette méthode peut consulter [27]. Cette méthode nous permet d'approcher la notion de niveau de sécurité que l'on retrouve dans les différents travaux analysés dans ce chapitre. La section suivante établit les niveaux de sécurité en fonction de l'algorithme utilisé, nous analyserons cette méthode et nous donnerons notre opinion sur la pertinence d'un tel choix.

Nous allons donc maintenant présenter une technique étudiée dans [26], appelée SASES (Security-Aware Scheduling for Embedded Systems).

Cet algorithme tente de fournir une bonne sécurité au système tout en tenant compte cette fois de l'importance du respect de toutes les échéances (système temps réel strict).

Nous nous concentrerons sur l'étude de tâches temps réel périodiques qui sont indépendantes l'une de l'autre et nous supposerons que les tâches sont à échéance sur requête et à départ simultané. Donc le système sera ordonnançable par une politique d'ordonnancement EDF si la contrainte U 1 est satisfaite (voir chapitre 2).

nous utiliserons pour désigner ces services respectivement les notations a,c,g. Le modèle permet de rajouter d'autres services.

Chaque tâche est composée d'un ensemble de paramètres, Ti = (Ci, Pi, Li, Si, Wi):

Ci : son pire temps d'exécution (worst-case execution time), sans tenir compte de la sécurité;

Si : un ensemble de bornes définissant le niveau de sécurité minimum et maximum à fournir à Ti pour les différents services de sécurité.

Wi: un vecteur ~wa i , wc i , wg ] contenant les poids des différents services k les

uns par rapport aux autres. Ces poids sont attribués par l'utilisateur selon l'importance de la sécurité de ces services pour la tâche.

Il n'est pas précisé dans [26] comment Li est fixé mais nous supposons que l'utilisateur fournit le débit de traitement des données qu'il souhaite imposer pour chaque tâche Ti. Nous noterons par Debi ce débit exprimé en Ko/s. Il est

alors possible par la formule 3.5 de calculer la taille des données à traiter pour chaque travail de la tâche Ti. La quantité de données que nous noterons Li exprimée en Ko se calcule en fonction de la période Pi exprimée en nombre de tics d'horloge du processeur.

Chaque service possède une borne inférieure et supérieure pour le niveau de sécurité.

où Sa i , S^c_i et S^g_i dénotent respectivement pour Ti les bornes pour le service d'authentification, de confidentialité et d'intégrité. Le niveau de sécurité peut s'étendre de 0 à 1. Le but de l'ordonnanceur sera donc de choisir le niveau de sécurité si le plus approprié dans le domaine Si, c.-à-d. si = (sa _i , sc i , sg i ) où sk i E Sk i V k E {a, c, g}.

Posons seci, le temps d'exécution utilisé pour la sécurisation d'un travail de la tâche Ti.

C'est donc la somme des sec^k i(sk _i ), c.-à-d. la somme des temps d'exécution nécessaires pour l'application de chaque service de sécurité k en fonction du niveau de sécurité choisi par l'ordonnanceur pour chacun d'eux.

La méthode pour calculer les temps de calcul seck _i (sk _i ) pour chaque service de sécurité est peu définie dans [26]. Nous avons donc analysé et critiqué la méthode d'un autre article [25] des mêmes auteurs.

Dans [25], chaque niveau de sécurité correspond à un algorithme cryptographique (algorithme de chiffrement, fonction de hachage ou méthode d'authentification). Selon ce même travail, plus le niveau de sécurité est important, plus le débit de traitement de l'algorithme associé à ce niveau est faible et donc le temps dépensé pour appliquer la sécurité sera plus important. Par la suite, nous expliquerons pourquoi nous ne sommes pas entièrement du même avis que l'auteur de [25].

A l'aide des tests de performance fournis dans la librairie crypto++ [4], nous avons calculé le débit de différents algorithmes sur notre processeur, Intel Pentium M Processor 735 - 1.7 GHz. Pour chaque service nous avons choisi une liste d'algorithmes de manière à répartir correctement la valeur des niveaux de sécurité en nous basant sur le choix fait par Tao Xie et Xiao Qin dans [25].

Nous allons maintenant montrer comment est calculé le temps d'exécution nécessaire pour les différents services.

Imaginons qu'un système embarqué temps réel, que nous noterons SETR, veuille transmettre une information (P) à un serveur, que nous noterons CC (centre de commande).

Le service de confidentialité est indispensable pour rendre les données circulant entre ce SETR et le CC inintelligibles.

Le SETR va chiffrer (voir 3.8) cette information grâce à un algorithme de chiffrement (E), en utilisant la clé de chiffrement (K_e) lui ayant été fournie par le CC pour l'algorithme E. Afin de réduire le coût en temps, nous pouvons supposer qu'il n'y a pas de négociation des clés en ligne et que l'enregistrement des clés se fait lors de la maintenance du système.

Le chiffrement est symétrique, ce qui signifie que chaque entité (source et destination) possède la même clé secrète que ce soit pour chiffrer ou déchiffrer les données. Un chiffrement symétrique est utilisé car il est plus rapide qu'un chiffrement asymétrique [16], ce qui est utile dans les systèmes temps réel pour diminuer le temps d'exécution requis par la mise en place de la sécurité.

Un compteur Cpt est inclus dans le message à chiffrer, il permet d'éviter une attaque par rejeu, c'est à dire une attaque où l'attaquant renvoie une copie d'un ancien message. Il est incrémenté à chaque message P envoyé par le SETR, s'il ne l'est pas, le CC va rejeter P.

Il existe plusieurs manières de chiffrer un message. Chaque algorithme de chiffrement correspond à un niveau de sécurité sc l et possède un certain débit de chiffrement i(s^c_l), c.-à-d. la quantité de données que l'algorithme à ce niveau peut traiter par unité de temps. Ce débit dépend de la rapidité du processeur et de l'algorithme utilisé, autrement dit du niveau de sécurité choisi.

Selon la quantité de données Li à traiter dans chaque travail de la tâche Ti, on peut calculer la durée du chiffrement sec^c_ipour un travail de Ti grâce à l'équation 3.9.

où u(s^c_i) est une fonction qui donne le débit i(sc _l ) de l'algorithme dont le niveau de sécurité est le plus proche et sc i .

Nous avons testé onze algorithmes de chiffrement différents. En fonction des performances de ces différents algorithmes nous établissons un niveau de sécurité sc l pour chacun d'eux qui se situe entre 0, 16 et 1, l étant le numéro de l'algorithme dans la liste 3.1.

La valeur 1 est attribuée à IDEA, l'algorithme le plus « fort » selon [25], mais possédant aussi le débit le plus faible (= 4,44 Ko/ms) et donc le temps d'exécution le plus important pour une même quantité de données. Le niveau de sécurité des autres algorithmes est déduit de celui-ci, par la formule 3.10.

Nous fournissons dans le tableau 3.1, la liste des algorithmes de chiffrement que nous avons obtenus grâce aux tests de performance, triés en ordre croissant par rapport au niveau de sécurité avec leurs performances respectives (le débit) et le niveau de sécurité qui en découle. Ils seront utilisés pour garantir la confidentialité des données.

Algorithmes de chiffrement	Niveau de sécurité sc l	Débit u^c_l (en Ko/ms)
Rijndael (128 bits)	0,16	27,04
SEAL-3.0-BE	0,22	19,72
Salsa20	0,38	11,52
Blowfish	0,49	9,09
RC6	0,53	8,44
Twofish	0,65	6,87
DES	0,75	5,93
Camellia (256 bits)	0,87	5,11
Shacal-2 (128 bits)	0,90	4,93
IDEA	1,00	4,44

Nous remarquons que la façon dont les algorithmes sont classés est étonnante. En effet, Xie et Qin évaluent les performances d'un algorithme cryptographique en fonction du débit de celui-ci. Mais d'après nos tests, nous observons par exemple, que le débit de l'algorithme Rijndael-128 bits (AES) est plus important que celui de DES ce qui rejoint les résultats obtenus dans [25]. AES utilisera donc moins de temps pour le chiffrement et recevra un niveau de sécurité inférieur.

Or, la valeur en sécurité d'un algorithme ne dépend pas uniquement du débit de celui-ci mais de sa complexité et de la longueur des clés utilisées (comme nous l'avons mentionné à la section 3.2.1). Le chiffrement DES, à cause de la faible longueur de la clé (56 bits), a été cassé en 1999 en moins d'un jour. Rijndael quant à lui, utilise des clés de minimum 128 bits, ce qui est usuellement admis comme étant la limite inférieure acceptable pour la taille des clés d'un algorithme cryptographique permettant d'atteindre une sécurité satisfaisante (du moins jusqu'à ce jour) [2].

Il n'est donc pas logique de poser pour l'algorithme DES, un niveau de sécurité supérieur à AES. Lorsqu'on dispose de plus de temps lors de l'ordonnancement, on passerait à un algorithme moins performant aussi bien en terme de débit que de résistance aux attaques.

Nous allons néanmoins continuer à expliquer l'idée exposée dans cette étude. Elle pourrait être intéressante à appliquer en définissant autrement les niveaux de sécurité. Il est possible de définir le niveau de sécurité par rapport à la longueur des clés en utilisant le même algorithme pour les différents niveaux de sécurité, ce qui réduirait la quantité de ressources nécessaires pour implémenter ces différents algorithmes dans le système embarqué. Citons par exemple,

l'idée exposée dans [10], qui est d'utiliser les variantes 128, 192, 256 bits d'AES.

Le service d'intégrité sert à garantir que les données n'ont pas été modifiées entre le SETR et le CC.

Le temps d'exécutionsecg _i nécessaire pour ajouter le contrôle d'intégrité au temps normal d'exécution est calculé dans [25] à partir d'un tableau fournissant les débits de différentes fonctions de hachage de la même manière que pour le service de confidentialité (par l'équation 3.11).

Nous avons calculé le débit de neuf fonctions de hachage différentes (voir tableau 3.2) et avons ensuite établi un niveau de sécurité pour chacune de celles-ci par rapport à leurs performances dans la mesure où plus le hachage est long, plus la sécurité est renforcée mais le débit de traitement est plus faible.

Le calcul du niveau de sécurité des différentes fonctions s'effectue de manière analogue au service de confidentialité, nous comparons grâce à la formule 3.12 les différentes fonctions de hachage par rapport aux performances de SHA-256 (possédant le plus faible débit : 8,98 Ko/ms) dont le niveau de sécurité est fixé à 1. Le niveau de sécurité s^g_l varie entre 0, 05 et 1.

A nouveau, l'auteur suppose qu'une fonction de hachage dont le temps de calcul est plus important (plus faible débit), sera de meilleure qualité, ce qui est probable mais n'est pas prouvé. Nous n'avons pas trouvé de contre-exemple comme nous l'avons fait avec AES par rapport à DES dans le cadre de la confidentialité.

Remarque: On ne peut garantir l'intégrité des données en appliquant uniquement sur celles-ci une simple fonction de hachage à sens unique sans clé comme une des fonctions du tableau 3.2. Il est important de chiffrer le message dont on désire garantir l'intégrité avec une clé secrète connue uniquement par le

Fonctions de hachage	Niveau de sécurité sg l	Débit u^g_l (en Ko/ms)
Adler-32	0,05	170,00
CRC-32	0,08	117,98
MD5	0,15	58,99
RIPE-MD128	0,35	25,36
Tiger	0,39	22,69
SHA-1	0,43	20,71
RIPE-MD160	0,56	16,05
HAVAL-5	0,63	14,36
SHA-256	1,00	8,98

TAB. 3.2 - Intégrité - Niveaux de sécurité et débits des fonctions de hachage

SETR et le CC, car autrement un attaquant pourrait modifier le message et hacher à nouveau celui-ci. Etant donné que le message correspondra au résultat de la fonction de hachage, il sera accepté alors que celui-ci a été modifié.

On peut supposer ici que la fonction de hachage est appliquée et ensuite chiffrée par le service de confidentialité. Mais si seule l'intégrité doit être garantie, cette méthode ne convient pas, il est préférable d'utiliser des MAC (Message Authentication Code) qui garantissent à la fois l'authentification et l'intégrité des données.

Il est indispensable de vérifier l'authenticité des données circulant dans le système, c.-à-d. qu'il faut garantir que c'est bien la source concernée qui envoie les données. Dans ce but, nous utilisons des codes d'authentification de message (MAC).

Le service d'authentification est divisé dans [25] en 3 classes qui utilisent chacune une méthode d'authentification différente :

Chaque classe a besoin d'un certain temps de calcul. Ces temps sont listés dans le tableau 3.3 issu de [25], la différence de niveau est calculée à partir de ces temps de calcul.

Méthodes d'authentification	Niveau de sécurité s^a_l	Temps de calcul u^a_l (en ms)
HMAC-MD5	0,55	90
HMAC-SHA-1	0,91	148
CBC-MAC/AES	1 ,00	163

TAB. 3.3 - Authentification - Niveaux de sécurité et temps de calcul des différentes méthodes

On obtient sec^a_i = ual(sa _i ) comme étant le temps nécessaire pour garantir l'authenticité des données au niveau s^a_i (faible, acceptable, fort).

Les services d'intégrité et d'authentification sont séparés, or un MAC garantit à la fois l'intégrité et l'authentification des données. Il est donc, selon nous, inutile d'utiliser le service d'intégrité comme il est décrit dans [25]. Il serait préférable de lier ces deux services en un seul.

Voici comment appliquer un service qui garantit l'authentification et l'intégrité par une méthode de type HMAC (keyed-hash message authentication code) utilisée avec une fonction de hachage à sens unique comme SHA-1 ou MD5:

Après avoir chiffré l'information afin d'en garantir la confidentialité, il nous faut garantir que cette information n'a pas été modifiée et provient effectivement du SETR. Dans ce but, un code d'authentification du message (MAC que nous noterons ici M) sera calculé et rajouté à la suite du message:

Une méthode d'authentification (H) du tableau 3.3 est appliquée avec la clé K_m sur la concaténation de l'adresse de la source (S: le SETR), de la destination (D: le CC), du message chiffré et du compteur Cpt. Nous tenons a préciser que la clé K_m doit être choisie comme différente de K_e (la clé utilisée pour le chiffrement). En effet, pour des raisons de sécurité [17], il est préférable d'utiliser des clés différentes pour l'algorithme de chiffrement et la fonction de hachage. Ensuite le SETR envoie le message crypté Msg et le résultat du hachage du message M vers le CC, ce transfert est donc constitué de:

Si un opposant, que nous appellerons Oscar, intercepte et modifie le message, le CC s'en rendra compte, à moins qu'Oscar n'arrive à modifier le résultat

M produit par la fonction de hachage pour que celui-ci corresponde à la modification effectuée sur Msg, ce qui voudrait dire qu'Oscar possède la clé K_m.

L'authentification est également garantie par la connaissance de K_m étant donné que l'adresse de la source et de la destination sont intégrées au code, Oscar ne peut modifier ces adresses sans que le code M ne soit erroné si celui-ci ne dispose pas de K_m.

Le récepteur du message, ici le CC calcule le code M' = H(Msg)K_m, si M' =6 M le CC va rejeter le message. Si M' = M, cela veut dire que le message n'a pas été altéré et il va donc extraire C et le déchiffrer. Notons, que le même algorithme peut être utilisé pour le chiffrement et la fonction de hachage sans affecter la sûreté du système [17], ce qui peut à nouveau être intéressant pour limiter la quantité de ressources à installer sur le système embarqué.

SASES utilise une fonction pour calculer le bénéfice en sécurité accru par une tâche Ti:

où bi = Pi P , c.-à-d. le nombre de travaux de cette tâche que l'on peut ordonnancer jusqu'à l'hyperpériode P, w^k_i est le poids spécifié par l'utilisateur pour le service k de la tâche Ti et sk i est le niveau de sécurité du k^e service qui est identique pour tous les travaux de la tâche.

- les échéances _dij= j. Pi sont toutes respectées. Cela est le cas si les
tâches sont planifiées avec une politique d'ordonnancement EDF et que
le facteur d'utilisation U < 1 (cf. équation 3.19), suivant l'hypothèse selon
laquelle les tâches sont périodiques et à échéance sur requête. Cela re-
vient à dire que la somme des rapports entre le temps d'exécution total
(temps nécessaire pour la sécurisation seci ajouté au temps d'exécution
normal Ci) et la période Pi de chaque tâche n'est pas supérieur à 100%.
Le problème peut donc s'écrire comme une maximisation d'un niveau de sécu-
rité global (SV), étant la somme des niveaux de sécurité des n tâches formant

etque U=

_>.ⁿ

i=1

[ ]

Ci + > k?{a,c,i} seck _i (sk _i )

1. (3.19)

Nous allons montrer maintenant comment, à partir des caractéristiques des tâches (Ci, Pi, Li, Si), le niveau de sécurité est augmenté le plus possible en tenant compte du poids w^k_i de la sécurité de chaque service de celles-ci. Nous avons repris l'idée de l'algorithme présenté dans [26] en le modifiant quelque peu pour le rendre plus compréhensible (voir algorithme 2).

= maxiE[1,n], kEa,c,g {wk i Äsk i / [seck _i (sk _i + Äsk _i ) - seck _i (sk

Nous avons présenté dans cette section l'algorithme SASES permettant de sélectionner un ensemble de moyens cryptographiques pour sécuriser les données de chaque tâche tout en respectant leurs échéances. L'algorithme que nous exposerons dans la section suivante est une autre façon de choisir les services les plus appropriés de manière plus efficace que le parcours effectué par l'algorithme SASES.

Man Lin et Laurence T.Yang dans leur étude [12], représentent chaque principe de sécurité par un groupe de services. Par exemple, il y aura un groupe pour les différentes méthodes d'authentification, un autre pour les algorithmes de chiffrement,. . . Ces différentes méthodes seront ici appelées « services ».

De la même manière que dans l'algorithme SASES, chaque groupe i possède un certain poids Wi par rapport aux autres, et dans chacun des Ng groupes, les services ont une certaine qualité, autrement dit une valeur qui leur est propre. Nous noterons _Qij, la qualité du service j dans le groupe i.

Les services sont représentés comme étant les noeuds d'un graphe, le noeud < i,j > représentant le service j du groupe i. Bien entendu, un seul service maximum dans chaque groupe peut-être sélectionné à la fois de manière à former un ensemble de services qui seront utilisés pour sécuriser le système, nous appellerons cet ensemble un chemin. Dans la figure 3.5, un exemple de chemin P = {< 1,1 >; <2,2>; <3,2 >} est représenté en gris.

Les services sont classés par ordre décroissant par rapport à leur qualité (par exemple: Q1,1 > Q1,2). Nous noterons _secik le temps nécessaire à la sécurisation de la tâche Ti par le service sélectionné dans le groupe k. Lorsque la qualité d'un groupe est diminuée, _secik sera moins important également, ce qui permet donc d'ajuster la qualité de service pour respecter les échéances.

La vérification du respect des échéances se fait sur base de la condition d'ordonnançabilité nécessaire et suffisante imposée par EDF, selon laquelle la somme des facteurs d'utilisation des n tâches dont est composé le système doit

Nous tenons compte dans le calcul du facteur d'utilisation, du temps d'exécution normal Ci et de la mise en place de la sécurité pour chaque groupe.

Le but est de sélectionner dans chaque groupe, le service qui permettra de maximiser la qualité globale Q(P) du chemin P tout en respectant les échéances.

De plus, la qualité Qi (la valeur inscrite dans le noeud) d'un groupe doit être supérieure à une borne inférieure Min Qi, la qualité minimale acceptée pour chaque groupe de services.

Il est proposé dans [12], une méthode de recherche par un parcours de graphe en profondeur ( depth-first ») qui permet de choisir les meilleurs services permettant de garantir que le système soit toujours ordonnançable en utilisant ceux-ci. La recherche est améliorée afin de ne pas devoir tester toutes les possibilités de manière exhaustive. Nous allons présenter maintenant ces améliorations du parcours du graphe.

En effet, il existe trois moyens d'élaguer le graphe afin de restreindre l'espace de recherche:

pas non plus respectée avec un chemin plus long formé par le même préfixe, on peut donc élaguer les chemins ([d], [e] et [f]). On continue alors le parcours en profondeur comme s'il n'y avait pas de noeuds fils (voir [c]), la qualité de service du groupe courant est donc baissée, autrement dit on passe directement au noeud suivant dans le groupe, sans être descendu dans le graphe.

3. Il est encore possible de supprimer des branches en évitant d'analyser des chemins qui ne donneront pas une meilleure qualité de service. Soit un chemin P de longueur Ng faisable, avec une qualité de service Q(P) accrue par celui-ci.

- On remarque que diminuer la qualité du dernier groupe Ng sur P ne mènera pas à une augmentation de Q(P) (dans l'exemple présenté à la

figure 3.8 Ng = 4). On poursuit alors le parcours en profondeur en remontant au niveau (groupe) Ng - 1 et en diminuant la qualité de service à ce niveau (voir figure 3.8[a']) pour tester à nouveau le niveau Ng par après.

- Lorsque la qualité Qi de tous les niveaux i entre L et Ng est au maximum et que le chemin est faisable, on peut directement remonter au niveau L - 2 et continuer le parcours pour essayer de trouver un meilleur chemin.

Dans la figure 3.8, sont représentés 3 exemples de chemins faisables ([a], [b] et [c]) et les chemins analysés respectivement juste après ceux-ci ([a'], [b'], [c']) dans l'ordre du parcours en profondeur du graphe.

Pour [c], la recherche se termine car il n'y a plus moyen d'augmenter la qualité de service.

Remarquons que contrairement à l'algorithme SASES, cette méthode attribue le même algorithme cryptographique (service) dans un groupe pour toutes les tâches. Cela rend le calcul plus rapide mais est selon nous moins performant au niveau de la valeur en sécurité du système étant donné que lorsque l'algorithme augmente la sécurité de toutes les tâches en même temps, il est probable que le système ne soit plus ordonnançable et donc qu'on doive baisser le niveau de sécurité de toute les tâches de manière à ne rater aucune

échéance. Cela n'aurait sans doute pas été le cas en modifiant la qualité de service tâche par tâche. Malgré sa complexité supérieure, SASES permet une granularité plus importante au niveau de la sécurité et est donc selon nous plus approprié à ce problème d'optimisation de la sécurité.

Nous avons dans ce chapitre développé plusieurs méthodes existantes dans la littérature permettant de choisir le meilleur moyen de sécuriser le système, nous avons décrit les algorithmes utilisés, les points forts et les points faibles de ces différentes techniques.

Comme nous l'avons fait remarquer dans ce chapitre, le fait d'établir le niveau de sécurité par rapport au débit des algorithmes n'est pas adapté, il serait préférable de garder le même algorithme et de faire varier la taille de la clé ou le nombre de tours de l'algorithme cryptographique selon le temps disponible de manière à représenter la valeur en sécurité comme une évolution de la sécurité en fonction du temps et d'attribuer une récompense à cette évolution.

Nous nous sommes donc intéressés plus particulièrement aux travaux de H. Aydin [3] qui a développé une méthode qui attribue une récompense selon un supplément de temps d'exécution de manière à profiter au maximum du temps disponible pour exécuter une partie optionnelle qui sera dans notre cas destinée à la sécurité.

Le reste de ce mémoire sera consacré à cette méthode (chapitre 4) et à la façon dont nous avons implémenté celle-ci (chapitre 5) de manière à en évaluer les performances.

Sécurité dans les systèmes temps réel

Chapitre 3

Etat de l'art