conception et réalisation d ˇun agl pour la …car, lors de la conception fonctionnelle, on ne...

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université d’Oran Es-Sénia

Faculté des Sciences Département d’Informatique

Ecole doctorale Sciences et Technologies de l'Information et de la Communication

S.T.I.C

Thèse pour l’obtention du magistère en informatique

Présentée par

Mr BOUADJEM I Abdelkrim

Soutenu publiquement devant le jury :

Pr HAFFAF Hafid Professeur à l’université d’Oran Président

Dr LEBBAH Yahia Maître de conférences à l’université d’Oran Examinateur

Dr YAGOUBI Belabbès Maître de conférences à l’université d’Oran Examinateur

Pr RAHMOUNI Mustapha-Kamel Professeur à l’université d’Oran Encadreur

Année 2009

Conception et réalisation d’un AGL pour la sécurisation d’intranet sécurisé selon un CdC pré-

défini

http://www.pdfcomplete.com/cms/hppl/tabid/108/Default.aspx?r=q8b3uige22

Remerciements

Je remercie Monsieur HAFFAF Hafid, Professeur à l’université

d’Oran qui me fait l’honneur de présider le jury.

De même, je remercie respectivement Monsieur LEBAH Yahia,

Maître de conférences à l’université d’Oran et Monsieur YAGOUBI

Belabbès Maître de conférences à l’université d’Oran d’avoir

accepter d’être membres examinateurs de mon mémoire de magistère.

Je tiens à remercier sincèrement mon encadreur, le Professeur

RAHMOUNI Mustapha-Kamel d’avoir accepter de diriger ma thèse,

pour sa disponibilité, l’orientation, conseils et critiques théoriques et

pratiques ainsi que la mise à ma disposition tout ce qui est nécessaire

pendant la recherche et la rédaction de la présente thèse.

Aussi un grand remerciement à tous les enseignants intervenants

durant l’année théorique.


Dédicaces

A mes parents qu’ils trouvent ici le témoignage de ma gratitude,

A ma sœur et mes frères,

A ma grand-mère,

A toute ma famille,

Enfin, à tous ceux qui me sont chers.

Abdelkrim.B


Résumé

Face à l’évolution des systèmes d’informations et à la complexité des services utilisés dans le monde des intranets, les organismes et les particuliers rencontrent de plus en plus de problèmes de sécurité.

L’aspect sécurité constitue pour les concepteurs de ces systèmes d’informations un challenge car, lors de la conception fonctionnelle, on ne prend pas en considération l’aspect sécurité, ce qui induit à des solutions à posteriori (ex : anti-virus, firewalls, etc.). Mais l’enjeu de la sécurité est au-delà, il est dans l’établissement d’une véritable politique de sécurité qui permet de garantir les objectifs de sécurité désirés.

Dans cette perspective inhérente à notre thèse, l’approche consiste à proposer un intranet sécurisé capable de garantir les objectifs de sécurité (disponibilité, confidentialité, intégrité, etc.). L’idée est de concevoir un atelier de génie logiciel AGL, à partir d’un intranet fonctionnel et des exigences de sécurité (contraintes de sécurité). Nous proposons un cycle de développement nouveau avec l’introduction du cahier de charges sécurité (CdC Secure) à tous les niveaux de développement (CdC Secure évolutif), en plus de l’utilisation de la modélisation formelle à chaque niveau de développement pour modéliser le système.

Le résultat de cette démarche est un automate de sécurité A-S capable de garantir la politique de sécurité désirée.

« Ce ne sont pas les murs qui protègent la citadelle, mais l’esprit de ses habitants » THUCYDIDE


Abstract

Given the evolution of information systems and complexity of services used in the world of intranets, organizations and individuals are confronted to security issues.

The safety aspect is, for the designers of these systems of information, a true challenge. At the functional level, we do not take into account the security aspect, which leads to à posteriori solutions. But the issue of security lies beyond, we must establish a true security policy that ensures the desired security objectives.

In this perspective inherent to our thesis, the approach is to provide a secure intranet that can guarantee the security objectives (availability, confidentiality, integrity, etc.). The idea is to design a software engineering workshop SIW, from a functional intranet and security requirements (security constraints). We propose a new cycle of development which introduces the introduction of the Security Specifications (CdC) at all levels of development (Scalable CdC), in addition to the use of formal modeling at each level of development to model the system.

The result of this approach is a safety controller which can guarantee the desired security policy.


Table des matières

Introduction générale I. Les aspects généraux de la sécurité 1. Introduction …………………………………………………………………….. 2. Définition de la sécurité ………………………………………………………... 3. La notion de sécurité de l’information ……...…………………………………. 4. Les notions de l’insécurité ……………………………………………………...

Menace ……………………………………………………………………... Vulnérabilité ………………………………………………………………... Risque ………………………………………………………………………

5. Les objectifs de la sécurité ……………………………………………………... Disponibilité ……………………………………………………................... Confidentialité ……………………………………………………............... Intégrité …………………………………………………….......................... Non-répudiation…………………………………………………….............. Authentification …………………………………………………...............

6. Approche méthodologique de la sécurité ………………………………………. 7. Conclusion ……………………………………………………...........................

II. Les attaques et les techniques de sécurité I. Introduction ……………………………………………………………………..

II. Les attaques …………………………………………………….......................... 1. Définition du hacking ……………………………………………………........... 2. Les types d’attaques …………………………………………………….............

Les attaques directes ……………………………………………………...... Les attaques indirectes par rebond …………………………………………. Les attaques indirectes par réponse …………………………………………

3. Classification des attaques ……………………………………………………... Les attaques de modification …………………………………………………...

a. Les virus ……………………………………………………......................... b. Les vers …………………………………………………….......................... c. Les chevaux de troie ……………………………………………………......

Les attaques d’accès ……………………………………………………............ a. Le sniffing ……………………………………………………...................... b. Les chevaux de troie ……………………………………………………...... c. Les portes dérobées ……………………………………………………........ d. L’ingénierie sociale ……………………………………………………........

Les attaques de mots de passe …………………………………………………. a. Dictionnary cracking ……………………………………………………...... b. Brute force cracking …………………………………………………….......

Les attaques par saturation ……………………………………………………..

12 13 13 14 14 14 16 16 16 17 17 17 18 18 18 19

20 20 20 21 21 21 22 22 23 23 23 24 24 24 24 25 25 26 26 26 27


a. Le floading ……………………………………………………..................... b. Le smurf ……………………………………………………......................... c. Le TCP-SYN floading ……………………………………………………... d. Le débordement de tampon ………………………………………………… e. Les virus ……………………………………………………......................... f. L’attaque par fragmentation ………………………………………………...

Les attaques d’application ……………………………………………………... a. Les buffers overflow ……………………………………………………...... b. Les rootkits ……………………………………………………....................

Les attaques de reconnaissance ………………………………………………... a. Balayage de ports ……………………………………………………...........

Les attaques de répudiation ……………………………………………………. a. L’usurpation d’adresses ……………………………………………………. b. Le vol de session ……………………………………………………............

III. Les techniques de sécurité …………………………………………………….... 1. La cryptographie ……………………………………………………..................

Introduction …………………………………………………….................... Terminologie …………………………………………………….................. Les objectifs ……………………………………………………................... La cryptographie classique ………………………………………………… La cryptographie moderne ………………………………………………….

Les clés cryptographiques ………………………………………….. La cryptographie symétrique ………………………………………… La cryptographie asymétrique ………………………………………... La cryptographie hybride ………………………..…………………… Le Hachage ……………………………………………………........... La signature numérique ……………………………………………… La cryptographie quantique …………………………………………..

Applications de la cryptographie …………………………………………... 2. Les anti-virus ……………………………………………………........................ 3. Les pare-feux ……………………………………………………........................ 4. Les IDS ……………………………………………………................................ 5. Les protocoles de sécurité ……………………………………………………....

L’IP security ……………………………………………………................... Les VPNs ……………………………………………………....................... Les SSL ……………………………………………………..........................

IV. Conclusion ……………………………………………………………………...

III. Politique de sécurité 1. Introduction …………………………………………………….......................... 2. Définition ……………………………………………………............................. 3. Les modèles de sécurité ……………………………………………………....... 4. Les contrôles d’accès ……………………………………………………........... 5. Les phases d’élaboration d’un système de contrôle d’accès ……………………

27 28 28 29 29 29 30 30 30 30 30 30 30 31 31 31 31 32 32 34 38 38 39 43 47 47 49 53 54 56 58 59 61 61 62 64 65

66 66 67 68 71


6. Les politiques et modèles de sécurité …………………………………………... La politique discrétionnaire DAC ………………………………………….. La politique obligatoires MAC …………………………………………….. Les politiques et les modèles basés sur les rôles……………….....................

7. Conclusion ……………………………………………………...........................

IV. Modélisation Formelle I. Modélisation formelle …………………………………………………….......... 1. Introduction …………………………………………………….......................... 2. Méthodologie formelle de développement …………………………………….. 3. Méthodes formelles …………………………………………………….............. 4. Evaluation de la confiance ……………………………………………………... 5. Pratiques de développement ……………………………………………………. 6. Maîtrise de la méthode formelle ……………………………………………….. 7. Théorèmes de la logique ……………………………………………………......

Cohérence de la logique ……………………………………………………. Correction des résultats logiques …………………………………………... Cohérence des sémantiques ………………………………………………...

II. Le langage B ……………………………………………………......................... 1. Introduction …………………………………………………….......................... 2. Le langage de substitution généralisé ………………………………………….. 3. La machine abstraite ……………………………………………………............ 4. Les appels d’opérations ……………………………………………………........ 5. Le raffinement ……………………………………………………...................... 6. Les obligations de preuves des raffinements …………………………………... 7. L’implémentation ……………………………………………………................. 8. L’architecture de projet B ………………………………………………………

III. Conclusion……………………………………………………………………….

V. Conception et Modélisation 1. Introduction …………………………………………………………………….. 2. Les objectifs ……………………………………………………………………. 3. Le cycle de développement du processus ……………………………………… 4. L’explication du cycle de développement ……………………………………… 5. L’architecture sécurisée ………………………………………………………... 6. La politique de sécurité ………………………………………………………… 7. Le choix de modélisation ………………………………………………………. 8. La politique de disponibilité …………………………………………………… 9. La politique de confidentialité …………………………………………………. 10. La politique d’intégrité …………………………………………………………. 11. La description du modèle ………………………...…………………………….

Les niveaux de développement du système ……………………………… Le résultat obtenu du développement ……………………………………. Principe ……………………………………………………………….

71 72 75 80 83

84 84 84 85 85 86 86 88 88 88 89 89 89 90 91 93 93 94 94 95 95

96 96 97 99 100 100 102 103 103 103 103 104 112 112


Mise en œuvre d’une politique de sécurité …………………………... Automate de sécurité …………………………………………………. Transition dans l’automate …………………………………………… Propriétés de l’automate de sécurité …………………………………. Explications …………………………………………………………...

12. Conclusion ……………………………………………………………………...

Conclusion générale ……………………………………………………...

Annexe A : L’intranet et ces fonctionnalités …………………………………...

Annexe B : Le tableau des symboles du langage B …………………………….

Annexe C : Le langage FoCaL …………………………………………………

Bibliographie et webographie……….………………………………… Acronymes ……………………………………………………………………..

113 113 113 114 114 115

115 116 123 124 135 138


Liste des figures Figure 2.1 Attaque directe Figure 2.2 Attaque indirecte par rebond Figure 2.3 Attaque indirecte par réponse Figure 2.4 Méthode de brute force cracking distribué (1) Figure 2.5 Méthode de brute force cracking distribué (2) Figure 2.6 Attaque SMURF Figure 2.7 Principes de base de la cryptologie Figure 2.8 Protocole d’authentification Challenger-response Figure 2.9 Application d’une transposition Figure 2.10 Cryptographie à clé asymétrique Figure 2.11 Deux exemples d’EC Figure 2.12 Le principe de hachage Figure 2.13 L’authentification par MAC Figure 2.14 La confidentialité par MAC (1) Figure 2.15 La confidentialité par MAC (2) Figure 2.16 Authentification par signature digitale avec arbitre Figure 2.17 Rondes du SHA-1 Figure 3.1 Les opérations primitives du modèle HRU Figure 3.2 Un exemple de cheval de Troie Figure 3.3 Un exemple d’un treillis de sécurité Figure 3.4 Le modèle RBAC Figure 4.1 L’architecture d’une machine abstraite en B Figure 5.1 Le cas idéal du système Figure 5.2 Cycle de développement de la démarche (1) Figure 5.3 Cycle de développement de la démarche (2) Figure 5.4 Architecture sécurisée proposée Figure 5.5 L’incohérence et l’incomplétude dans une politique restrictive Figure 5.6 Principe de fonctionnement de l’automate Figure 5.7 Schéma montrant le principe de l’automate sécurisé Figure A.1 Typologie des intranets Figure C.1 Hiérarchie FoCaL


Liste de tableaux Tableau 2.1 Application du carré de Vigenère Tableau 2.2 Le carré de Vigenère Tableau 2.3 Tableau synthèse des différents protocoles Tableau 2.4 Taille des clés pour un effort de cassage similaire Tableau 3.1 La matrice d’accès du modèle Lampson Tableau 4.1 Les notations en B Tableau A.1 Table de comparaison entre l’intranet et l’internet


Introduction générale

La prise en compte des aspects sécurité dans les SI constitue l’un des principaux challenges pour les concepteurs de larges systèmes d’information, particulièrement lorsqu’ils sont connectés au web. Les spécifications fonctionnelles du système une fois obtenues, la conception et l’implémentation de ces SI ne tient pas compte à priori des aspects sécurité (intégrité, confidentialité, non-répudiation, disponibilité, etc.). Ce n’est que lorsque que le système est déployé et que les problèmes de sécurité apparaissent, qu’ils sont résolus dans la mesure du possible et au fur et à mesure de leur apparition. Cette protection à posteriori peut donner des résultats (firewall, antivirus, etc.) mais elle ne peut constituer une véritable politique de sécurité.

Nous pensons que l’élaboration d’une politique de sécurité (sous la forme d’un Cahier des Charges, CDC, sécurité) pour le SI à réaliser qui est un intranet doit se faire en même temps que le traitement du CDC fonctionnel, et que le modèle d’intranet final obtenu doit intégrer à la fois les spécifications fonctionnelles et de sécurité.

L’objectif de notre travail consiste à proposer un système final sécurisé, et pour cela nous allons développer ce travail sur cinq chapitres.

Le premier chapitre est une étude superficielle des aspects de sécurité.

Le chapitre deux présente un état de l’art exhaustif sur les attaques et les techniques de sécurité.

Le troisième chapitre est consacré à la politique de sécurité ainsi qu’aux modèles de sécurité.

Le chapitre quatre concerne les méthodes formelles ainsi qu’une étude sur la modélisation formelle.

Le chapitre cinq est consacré à l’approche proposée ainsi qu’à la modélisation du système.


Chapitre I Aspects généraux de la sécurité

1. Introduction

La sécurité informatique est une notion de plus en plus présente dans le monde actuel. Le concept de sécurité recouvre un ensemble de méthodes, techniques et outils chargés de protéger les ressources. Dans ce chapitre, nous essayons de donner une idée générale sur la sécurité ainsi que sur l’ensemble des aspects engendrés par la sécurité. On fournira le vocabulaire usuel utilisé dans ce domaine.

Pour comprendre la sécurité, il est essentiel d’introduire tout d’abord les aspects généraux de la sécurité regroupant l’environnement de la sécurité, l’ensemble des définitions et la terminologie appropriée.

Nous partons de la simple définition jusqu'à l’audit de la sécurité et ce, afin de proposer enfin quelques méthodes et techniques capables de protéger l’information et d’assurer la confidentialité des données.

2. Définition de la sécurité

La sécurité informatique c'est l'ensemble des moyens, techniques, outils et ressources mis en oeuvre pour minimiser la vulnérabilité d'un système ou, si cela est possible, de le protéger contre des menaces accidentelles ou intentionnelles. [01]

En anglais, il existe deux termes différents: [02]

• Sécurité = "Safety"

Cette notion recouvre la protection des systèmes informatiques contre les accidents dus à l'environnement, aux défauts du système.

Domaine d'élection : les systèmes informatiques contrôlant des procédés temps réels et mettant en danger des vies humaines (transports, énergie,).

• Sécurité = "Security"

C’est la protection des systèmes informatiques contre des actions malveillantes intentionnelles.

Domaine d'élection : les systèmes informatiques réalisant des traitements sensibles ou comprenant des données sensibles. [07].

Résumé Dans ce chapitre et comme son titre l’indique, on a étude exhaustive des aspects de sécurité qui sont les notions fondamentales pour chaque informaticien voulant s’intéresser à la sécurité.



3. La notion de sécurité de l’information

On appelle sécurité de l'information l'état de protection, face aux risques identifiés, qui résulte de l'ensemble des mesures générales et particulières prises pour assurer les objectifs de la sécurité. [03]

4. Les notions de l’insécurité

La sécurité informatique est un ensemble de moyens de protection. Dans ce contexte et pour bien définir ces moyens, on doit tout d’abord comprendre les notions suivantes : menace, vulnérabilité et risque.

4.1 Menace

Une menace est un danger qui existe dans l’environnement d’un système indépendamment de celui-ci. Il représente l'ensemble des actions de l'environnement d'un système pouvant entraîner des pertes financières. Un système informatique sera d’autant plus menacé que les informations qu’il contient auront une valeur à la fois pour leur propriétaire et pour d’autres entités [28]. Il existe deux types de menaces qui sont :

i. Les menaces intentionnelles : c'est l’ensemble des actions malveillantes qui constituent la plus grosse partie du risque et qui doivent être l'objet principal des mesures de protection. On y définit deux catégories :

Ø Les Menaces passives : elles ne modifient pas l’information et portent essentiellement sur la confidentialité.

Ø Les Menaces actives : elles modifient le contenu de l’information ou le comportement des systèmes de traitement, elles portent sur l’intégrité des données.

ii. Les menaces non intentionnelles : ces menaces qui se produisent sans le vouloir concernent les pannes et les erreurs. Parmi les menaces non intentionnelles, citons : les erreurs d’exploitation, l’oubli de sauvegarde, les erreurs de manipulation des informations, les erreurs de transmission, les erreurs de conception des applications.

Des menaces différentes peuvent avoir les mêmes effets. Nous proposons une liste de catégories des menaces parmi les plus courantes.

Ø L’espionnage

Cette menace concerne particulièrement les informations stratégiques d’une entreprise. L’espionnage va tenter d’enfreindre les mesures de sécurité qui protègent la confidentialité des informations.



Ø La perturbation

L’agresseur va essayer de fausser le comportement du SI ou de l’empêcher de fonctionner en le saturant, en modifiant ses temps de réponse ou en provoquant des erreurs. L’agresseur veut désorganiser, affaiblir ou ralentir le système ciblé.

La perturbation va influer sur la disponibilité et l’intégrité des services et des informations d’un SI.

Ø Le vol

Le vol, visible quand l’objet du délit est matériel, est difficile à détecter quand il s’agit de données et encore plus de ressources informatiques.

En effet une simple copie suffit pour s’approprier une information. Cette opération n’est pas toujours facile à déceler. Le vol de données va permettre d’enfreindre les mesures de sécurité qui protègent la confidentialité des informations. Le vol de ressources est plus insidieux, car il se peut qu’il soit réalisé sans porter atteinte à la confidentialité, à l’intégrité ou à la disponibilité des informations et des services.

Ø La fraude physique

Elle peut consister à récupérer les informations oubliées ou non détruite par l’adversaire ou le concurrent. L’attaquant portera une attention particulière aux supports physiques usagés (bandes magnétiques, disquettes, disques classiques ou optiques, etc.), et s’intéressera aux poubelles, aux armoires, aux tiroirs et aux dossiers des organismes visés.

Comme l’espionnage, la fraude physique va tenter d’enfreindre les mesures de sécurité qui protègent la confidentialité des informations.

Ø Le chantage

Soutirer de l’argent à un organisme ou à une personne est d’autant plus tentant que de nombreuses données concernant la vie privée des personnes ou les activités d’une organisation sont sauvegardées sur des ordinateurs.

Le chantage peut aussi porter sur une menace de sabotage à l’encontre des installations d’une organisation.

Le chantage peut mettre en cause aussi bien la confidentialité, l’intégrité que la disponibilité des informations et des services.

Ø Le sabotage

Plus fort que la perturbation, le sabotage a pour but de mettre hors service un SI ou une de ses composantes.



Le sabotage porte atteinte à l’intégrité des informations mais surtout à la disponibilité des services.

Ø Les accès illégitimes

Cette menace est le fait d’une personne qui se fait passer pour une autre en usurpant son identité. Les accès illégitimes portent atteinte à la confidentialité des informations.

4.2 La vulnérabilité

Une vulnérabilité est une erreur ou faille dans un système informatique permettant à un attaquant de porter atteinte à la sécurité de ce système, c-à-d, à son fonctionnement normal, à la disponibilité, à la confidentialité et à l'intégrité des données. Ces vulnérabilités sont la conséquence de faiblesses dans la conception, la mise en œuvre ou l'utilisation d'un composant matériel ou logiciel du système.

La vulnérabilité porte sur l’une des défaillances suivantes :

Ø L’inconscience des dirigeants Ø Le Social Engineering (l’Ingénierie Sociale) Ø La défaillance des algorithmes cryptographiques Ø Les bugs dans les systèmes d’exploitations Ø L’utilisation de logiciels piratés Ø Une mauvaise politique de sécurité Ø La complexité des techniques de sécurité qui induit des défaillances

4.3 Le risque

Le risque est la probabilité qu’une menace particulière puisse exploiter une vulnérabilité donnée du système, c-à-d, que, en l’absence de menaces, le système ne court aucun risque, de même, en l’absence de vulnérabilités le système ne court aucun risque. En utilisant un formalisme mathématique, le risque peut être exprimé selon la formule suivante :

Risque = ∑i Ri = ∑i (Mi x ∑jVij)

Parmi les risques on peut citer :

Ø Le Social engineering Ø Le Déni de service Ø Le Vol d’informations Ø L’Usurpation d’identité Ø La Destruction ou corruption des informations

5. Les objectifs de la sécurité

N’importe quel système informatique à sécuriser doit supporter ou garantir une notion fondamentale qu’on appelle objectif de sécurité.



Les objectifs doivent être satisfaits selon une stratégie appelée politique de sécurité. Parfois on doit même déterminer la priorité de chaque objectif par rapport aux autres ; ces objectifs sont :

5.1 La disponibilité

La disponibilité concerne les services (ordinateurs, réseaux, périphériques, applications, etc.) et les informations (données, fichiers, etc.) doivent être accessibles aux personnes autorisées quand elles en ont besoin : le système doit donc rester fonctionnel malgré la survenue d’erreurs, malicieuses ou accidentelles. De même, la disponibilité concerne les données qui ne doivent pas être supprimées ou devenir inaccessibles.

Maintenant on va citer quelques risques qui portent atteinte à la disponibilité :

Ø La paralysie du système (considérée ensuite comme un exploit par les pirates qui l’ont réalisée).

Ø La saturation d’une ressource (serveur, imprimante, etc.). Ø Les virus et vers informatiques.

5.2 La confidentialité

Les informations n’appartiennent pas à tout le monde : seuls peuvent y accéder ceux qui en ont le droit, selon des conditions prédéfinies. Donc, le système ne doit pas divulguer des informations à une personne qui n’a pas le droit d’y avoir accès.

Selon la norme ISO 7498-2, La confidentialité est la propriété qu’une information n’est ni disponible ni divulguée aux personnes, entités ou processus non autorisés.

Maintenant on va citer quelques risques qui portent atteinte à la confidentialité des informations :

Ø La récupération d’informations sensibles (mots de passe, articles avant publication, données personnelles, etc.).

Ø La fouille des messages, des données, des répertoires, des ressources réseaux, etc. Ø L’usurpation d’identité.

5.3 L’intégrité

Les services et les informations (fichiers, messages, etc.) ne peuvent être modifiés que par les personnes autorisées (administrateurs, propriétaires…) ; donc, le système ne doit pas être modifié par une personne qui n’en a pas les droits. C'est la propriété qui assure qu'une information n'est modifiée que dans des conditions prédéfinies (selon des contraintes précises).

Selon la norme ISO 7498-2, l’intégrité est la prévention d’une modification non autorisée de l’information.

Maintenant on va citer quelques risques qui portent atteinte à l’intégrité du système :



Ø Le piégeage de systèmes (bombes logiques, chevaux de Troie, sniffers, etc.) afin de nuire à l’entreprise ou de se donner les moyens d’y accéder plus tard.

Ø La modification des informations afin de porter atteinte à l’image du laboratoire (exemple : modification des pages web de L’entreprise).

Ø L’utilisation des ressources du site visé. Ø Une intrusion en vue "d’attaques par rebond ", c’est-à-dire, qu’une autre cible est visée, le

système actuel servant seulement de "point de passage". Le laboratoire est alors complice involontaire du piratage.

5.4 La non-répudiation

La non-répudiation est la propriété qui assure que l'auteur d'un acte ne peut ensuite dénier l'avoir commis.

Deux aspects spécifiques de la non-répudiation dans les transactions électroniques:

Ø La preuve d'origine : un message (une transaction) ne peut être déniée par son émetteur. Ø La preuve de réception : un récepteur ne peut ultérieurement nier avoir reçu un ordre s'il

ne lui a pas plu de l'exécuter alors qu'il le devait juridiquement.

Il y a différentes techniques pour assurer la non-répudiation qui sont la signature numérique et le certificat numérique.

5.5 L’authentification

L’authentification est la propriété qui assure que seules les entités autorisées ont accès au système. L’authentification protége de l’usurpation d’identité, c'est un moyen clé de la sécurité pour assurer la confidentialité, l’intégrité et la non-répudiation.

6. Approche méthodologique de la sécurité

Dans toute étude de la sécurité il faut définir en premier lieu les exigences du système, puis l’élaboration d’une approche méthodologique.

6.1 Définition des exigences en matière de sécurité

La première question qu'il convient de se poser lorsque l'on parle de sécurité des réseaux et des systèmes d’information est la suivante : pourquoi a-t-on besoin d'une telle sécurité? Il va de soi qu'il faut assurer la sécurité des réseaux et du système afin que ceux-ci soient soumis aux politiques de sécurité de l'organisation. Toutefois, il faut tenir compte d'autres facteurs pour répondre à cette question. Par exemple, quels actifs informatiques importants du réseau doivent être protégés? Quelles sont les menaces qui pèsent sur le réseau? Quel est son degré de vulnérabilité? Quels sont les risques que ces menaces puissent nuire au réseau, compte-tenu de ses points vulnérables et des incidences possibles d'une telle nuisance? Quels sont les risques acceptables? Répondre à ces questions peut prendre plusieurs jours, voire plusieurs semaines, tout dépendant de la complexité du réseau et du système. Lorsque les exigences touchant à la sécurité du réseau ont été clairement



définies, il est alors beaucoup plus facile de mettre en place des mécanismes ou des procédures de sécurité qui répondent efficacement à ces exigences. [05]

6.2 Élaboration d’une approche méthodologique

Une "approche méthodologique" consiste à élaborer des modèles, définir des procédures, caractériser des "cycles de vie", etc. Un système se construit toujours suivant des modèles.

En revanche, si les modèles sont construits, les décisions sont cohérentes et raisonnées. Elles peuvent être mauvaises si la modélisation est fausse, mais on peut alors l’adapter, pour cela on va utiliser des méthodes pour savoir "ce qu’on veut".

Les modèles définissent, à chaque moment du cycle de vie du système d’information, des règles sur "les ressources", les "contraintes", les "fonctions" et les "produits".

Ils expriment :

Ø Ce qu’on veut protéger et pourquoi, Ø Le niveau de protection dont on a besoin,

Toute partie d’un modèle, qui est une manière de poser correctement le problème, aboutit à ce qu’il faut faire et donne les moyens de mesurer les écarts entre ce que l’on souhaite et ce que l’on a réellement obtenu, par exemple l’utilisation d’un outil de simulation ou de génération de cas pour faciliter l’évaluation des menaces et des risques. [05]

7. Conclusion

Par notre étude des aspects de la sécurité, on constate bien que la sécurité est influencée par le triplet (Risque, Menace, Vulnérabilité) de même que tous les efforts fournis par les spécialistes tendent à satisfaire des objectifs qui sont la disponibilité, l’intégrité et la confidentialité.


Chapitre II Les attaques et les techniques de sécurité

I. Introduction

Depuis l’ère ancienne, il existait des conflits entre les chefs, les tribus, … pour cela chacune des parties essayait d’inventer de nouvelles techniques d’attaques et de protection (sécurité).

II. Les attaques

1. Définition du hacking

Le hacking est un ensemble de techniques informatiques, visant à attaquer un réseau, un site, etc. Ces attaques sont diverses. On y retrouve :

Ø L'envoi de "bombes" logicielles. Ø L'envoi et la recherche de chevaux de Troie. Ø La recherche de failles de sécurité. Ø Le détournement d'identité. Ø La surcharge provoquée d'un système d'information (Flooding de Yahoo, eBay, etc.). Ø Le Changement des droits utilisateur d'un ordinateur. Ø La génération d'erreurs non gérées. Ø Etc.

Les attaques peuvent être locales (sur le même ordinateur, voire sur le même réseau) ou distantes (sur Internet, par télécommunication).

Le hacking à des objectifs à satisfaire, selon les hackers on y trouve :

Ø La Vérification de la sécurisation d'un système. Ø Le Vol d'informations (fiches de paye...). Ø Le Terrorisme. Ø L’Espionnage "classique ou industriel". Ø Le Chantage. Ø La Manifestation politique. Ø Le simple jeu, le défi. Ø L’apprentissage Ø Etc.

Résumé Dans la sécurité informatique, on trouve les notions de techniques d’attaques et de protections. Selon leur importance, on a fait une étude des attaques et on a essayé de les classifier selon leurs impacts sur les systèmes. En deuxième point, on a étudié les différentes techniques de préventions, leurs techniques de fonctionnement et le motif de leur utilisation.



2. Les types d’attaques

Les hackers utilisent plusieurs techniques d'attaques. Ces attaques peuvent être regroupées en trois familles différentes :

Ø Les attaques directes. Ø Les attaques indirectes par rebond. Ø Les attaques indirectes par réponse.

Les attaques directes

Ce sont les plus simples des attaques. Le hacker attaque directement sa victime à partir de son ordinateur

La plupart des "script kiddies" utilisent cette technique. En effet, les programmes de hack qu'ils utilisent ne sont que faiblement paramétrables, et un grand nombre de ces logiciels envoient directement les paquets à la victime.

Figure 2.1 Attaque directe

Si on se fait attaquer de la sorte, il y a de grandes chances pour qu’on puisse remonter à l'origine de l'attaque, identifiant par la même occasion l'identité de l'attaquant.

Les attaques indirectes par rebond

Cette attaque est très prisée des hackers. En effet, le rebond a deux avantages :

Ø Masquer l'identité (l'adresse IP) du hacker. Ø Éventuellement, utiliser les ressources de l'ordinateur intermédiaire car il est plus puissant

(CPU, bande passante, etc.) pour attaquer.

Le principe en lui-même est simple : les paquets d'attaque sont envoyés à l'ordinateur intermédiaire, qui répercute l'attaque vers la victime. D'où le terme de rebond.

Victime

Attaquant



Figure 2.2 Attaque indirecte par rebond

Si on est victime de ce genre d'attaque, il n'est pas facile de remonter à la source. Au mieux, on remonte à l'ordinateur intermédiaire.

Les attaques indirectes par réponse

Cette attaque est un dérivé de l'attaque par rebond. Elle offre les mêmes avantages, du point de vue du hacker. Mais au lieu d'envoyer une attaque à l'ordinateur intermédiaire pour qu'il la répercute, l'attaquant va lui envoyer une requête. Et c'est cette réponse à la requête qui va être envoyée à l'ordinateur victime.

Figure 2.3 Attaque indirecte par réponse

Là aussi, il n'est pas aisé de remonter à la source.

3. Classification des attaques

Dans le domaine de la sécurité on est confronté à des attaques qui portent atteinte au système et aux objectifs de la sécurité. Ces attaques ne sont pas de même nature, n’ont pas le même procédé de fonctionnement et ne produisent pas les mêmes dégâts.

Intermédiaire

Attaquant Victime

Intermédiaire

Attaquant Victime



Dans ce domaine, on a essayé de faire une étude plus au moins exhaustive et qui a permis la classification suivante :

3.1. Les attaques de modification

a. Les virus informatiques

Les virus sont des programmes parasites auto-reproductibles. Ces petits bouts de programme sont dépendants du système d'exploitation ou d'un logiciel. Ils se propagent, comme toutes données binaires, par disquettes, CD-ROM, réseaux (LAN ou WAN). Leur nombre est sans cesse croissant depuis leur création. Dans le cadre de la sécurité informatique, les virus sont des logiciels à part.

Cependant ils sont rarement propagés volontairement. Il s'agit souvent d'une négligence de la part de l'utilisateur.

N’importe qui peut provoquer cette attaque, volontairement ou non. Volontairement si la personne a au moins un virus en réserve, ou un logiciel permettant de générer des virus. Involontairement si la personne rapatrie d'internet des archives non sûres ou non certifiées par l'entreprise (99% des cas).

Les conséquences (dégâts causés par les virus) sont multiples :

Ø Ralentissement système. Ø Blocage système. Ø Crash système. Ø Perte de données. Ø Etc.

b. Les vers informatiques

Les vers sont des programmes parasites. Il ne sont pas forcément auto-reproductibles mais utilisent le protocole TCP/IP pour se propager dans le réseau. Son but est de grignoter des ressources système (CPU, mémoire, espace disque, bande passante, etc.). Ces petits bouts de programme sont dépendants du système d'exploitation ou d'un logiciel. Ils se propagent, comme toutes données binaires, par disquettes, CD-ROM, réseaux (LAN ou WAN). Depuis la démocratisation des virus (due notamment à la prolifération des générateurs de virus), le nombre de nouveaux vers est en net recul. Cependant, il en existe toujours. Pour les prévenir, on utilise très généralement la même stratégie que celle qui est adoptée contre les virus.

N’importe qui peut provoquer cette attaque, volontairement ou involontairement. Volontairement si la personne a au moins un ver en réserve, ou un logiciel permettant de générer des vers. Involontairement si la personne rapatrie d'Internet des archives non sûres ou non certifiées par l'entreprise (99% des cas).

Les conséquences (dégâts causés par les vers) sont multiples :

Ø Ralentissement système.



Ø Blocage système. Ø Crash système. Ø Pertes de données. Ø Etc.

c. Les chevaux de troie

Les chevaux de Troie "Trojan horses" ou "Trojans" tirent leur nom de la célèbre légende mythologique. Comme dans cette dernière, ils utilisent une ruse pour agir de façon invisible, le plus souvent en se greffant sur un programme anodin.

Ils font partie des grandes menaces que l'on peut rencontrer sur le web, parmi les virus et autres vers. Pourtant, contrairement à ceux-ci, les chevaux de Troie ne se reproduisent pas (en tout cas, ce n'est pas leur objectif premier). Ce sont à la base de simples programmes destinés à être exécutés à l'insu de l'utilisateur.

Leur objectif est le plus souvent d'ouvrir une porte dérobée "backdoor" sur le système cible, permettant par la suite à l'attaquant de revenir à loisir épier, collecter des données, les corrompre, contrôler, voire même détruire le système. Certains chevaux de Troie sont d'ailleurs tellement évolués qu'ils sont devenus de véritables outils de prise en main et d'administration à distance.

Leur mode opératoire est souvent le même. Ils doivent tout d'abord être introduits dans le système cible le plus discrètement possible. Les moyens sont variés et exploitent le vaste éventail des failles de sécurité, du simple économiseur d'écran piégé (envoyé par mail ou autre, du type cadeau.exe, snow.exe, etc.), jusqu’à l'exploitation plus complexe d'un buffer overflow. Après leur introduction dans le système, ils se cachent dans des répertoires système ou se lient à des exécutables. Ils modifient le système d'exploitation cible (sous Windows, la base des registres) pour pouvoir démarrer en même temps que la machine. De plus, ils sont actifs en permanence (car un cheval de Troie est un véritable serveur, il reste à l'écoute des connections provenant de l'attaquant pour recevoir des instructions) mais ils restent furtifs et sont rarement détectables par l'utilisateur. Ainsi, un listing des tâches courantes ne fournira pas d'indication suffisante : soit le cheval de Troie y sera invisible, soit son nom sera tout ce qu'il y a de plus banal ("Patch.exe", ".exe", "winamp34.exe", "winrar.exe", "setup.exe", "rundlls").

3.2. Les attaques d’accès

a. Le sniffing

Cette technique consiste à écouter une ligne de transmission par laquelle transitent des données pour les récupérer à la volée. Elle peut être utilisée en interne pour le débuggage ou de manière abusive par un pirate cherchant par exemple à se procurer des mots de passe. [08]



b. Les chevaux de troie

Les chevaux de troie, en plus d’être une attaque de modification, sont aussi considérés comme une attaque d’accès

c. Portes dérobées (Backdoors)

Depuis que les intrusions informatiques existent, leurs adeptes ont mis au point un certains nombre de techniques leur facilitant l’accès aux systèmes pénétrés. La technique la plus connue, et sans doute la plus utilisée, est celle des Backdoors (portes dérobées ou portes de service). Elles permettent, à celui qui en connaît l’existence et le fonctionnement, de revenir sur un système de façon détournée, c’est-à-dire sans passer par les méthodes d’authentification habituelles.

En règle générale, les Backdoors permettent différents types d’actions sur le système ou elles sont installées:

Ø Se reconnecter sur la machine même après un changement de mots de passe ou d’ajouts de systèmes de sécurité.

Ø Rendre invisible les connections et les actions réalisées. Ø Faciliter l’accès à la station sans avoir à utiliser des trous de sécurité existants

(securityholes). Ø Déranger le travail des utilisateurs par l’envoi de messages, la modification de fichiers,

l’affichage d’images, la lecture de fichiers son, etc. Ø Exécuter certaines commandes bien ciblées permettant d’avoir une vision de l’état de la

station (processus, connections réseau, utilisateurs, etc.) ou de modifier le contenu de certains fichiers de configuration (mots de passe, réseau, etc.).

d. Ingénierie sociale

Lorsque quelqu’un désire pénétrer dans un système information, sa première arme est le ”baratin”. Il n’y a généralement pas d’attaques réussies sans relations humaines. On appelle cela l’ingénierie sociale (social engineering), et elle est basée sur quatre grands principes :

Ø Le contexte: avoir une bonne connaissance de l’organigramme de l’entreprise permet à l’agresseur d’avoir d’ores et déjà un pied dans l’entreprise. Le but en général est de connaître quelles sont les personnes qui sont en droit de demander telles ou telles informations, et également à qui les demander, dans le but de se faire ultérieurement passer pour elles.

Ø L’audace ou le bluff : le bagout et l’art de la parole sont deux qualités indispensables lorsque l’on veut utiliser le ”social engineering”. Il s’agit ici d’avoir suffisamment d’aplomb et de connaissances techniques afin de faire croire à l’interlocuteur qu’il a affaire à un responsable technique de l’entreprise (ou d’un fournisseur de services). Tout ceci afin qu’il lui transmette les informations demandées sans aucun problème.



Ø La chance : la chance joue également un rôle important dans le ”social engineering”, mais cela ne marche pas à chaque fois! Il faut de la pratique afin de bien maîtriser le séquencement du dialogue à établir.

Ø La patience calculée: il faut de plus savoir se montrer patient afin d’obtenir les informations désirées. Malgré tout, la méthode du ”social engineering” demande une certaine rapidité (max. 1 heure) pour obtenir les informations voulues, passé ce délai, il est préférable de changer d’entreprise ou d’attendre quelques jours afin de ne pas éveiller les soupçons.

En général, les personnes ne sont pas formées à la notion de sécurité informatique, ce qui entraîne des situations qui auraient facilement pût être évitées.

3.3. Les attaques de mots de passe

a. Dictionnary cracking

Généralement les mots de passe de la plupart des logiciels sont stockés sous forme cryptée dans un fichier. Pour obtenir un mot de passe, il suffit de récupérer ce fichier et de lancer un logiciel de dictionary cracking. Ce procédé consiste à utiliser un logiciel qui va tester un nombre limité de mots, de manière à trouver un mot de passe. Chaque mot est en fait un mot d'usage courant, un prénom, un nom, ou une abréviation. Tous les mots utilisés sont regroupés dans un seul fichier qui est un dictionnaire. D'où le nom de cette attaque.

N’importe qui peut provoquer cette attaque, du moment qu'il possède un logiciel permettant de le faire et qu'il a récupéré le fichier de mots de passe.

La conséquence d’une telle attaque est que le mot de passe sera rapidement trouvé s'il est emprunté au langage courant.

b. Brute force cracking

Généralement les mots de passe de la plupart des logiciels sont stockés sous forme cryptée dans un fichier. Pour obtenir un mot de passe, il suffit de récupérer ce fichier et de lancer un logiciel de brute force cracking. Ce procédé consiste à tester de façon exhaustive toutes les combinaisons possibles de caractères (alphanumériques + symboles), de manière à trouver au moins un mot de passe valide. Cette attaque se base sur le fait que n'importe quel mot de passe est crackable. Ce n'est qu'une question de temps.

N’importe qui peut provoquer cette attaque, du moment qu'il possède un logiciel permettant de le faire et qu'il a récupéré le fichier de mots de passe.

Les protections par mot de passe classique (de type login Unix) sont vouées à disparaître dans un futur proche.

Exemple : distributed.net



Le RSA, organisme américain chargé entre autres de tester les systèmes de sécurité, a lancé un défi à la planète entière : L'organisation donnera 10000 dollars à quiconque décrypterait un message codé avec une clé RC5 de 64 bits. Le RC5 est un algorithme de cryptage. Le codage se faisant sur 64 bits, il y a donc au total 264 clés (1bit=0 ou 1), ce qui représente 18,446,744,073,709,551,616 possibilités! Une autre organisation distributed.net, a décidé de relever le défi, en se basant sur une méthode de brute force cracking distribué. Cela veut dire que toutes les clés sont testées. Pour effectuer cela, le nombre total de clés est divisé en de multiples petits paquets, qui sont ensuite envoyés à des ordinateurs clients. Ces clients calculeront chacun les paquets de clés reçus, en utilisant un logiciel nommé DNETC fourni par distributed.net.

Figure 2.4 Méthode de brute force cracking distribué (1)

Une fois qu'un client a fini de calculer un paquet, il renvoie son résultat et reprend un autre paquet à calculer. Et ceci jusqu'à ce que la clé unique qui permet de décrypter le message soit trouvée.

Figure 2.5 Méthode de brute force cracking distribué (2)



3.4. Les attaques par saturation

a. Le Flooding (Inondation)

Le flood ou flooding est, en informatique, une action généralement malveillante qui consiste à envoyer une grande quantité de données inutiles dans un réseau, afin de le rendre inutilisable, par exemple en saturant sa bande passante ou en provoquant le plantage des machines du réseau.

b. Le Smurf [06]

C'est un "déni de service" ICMP. Cette attaque ICMP consiste à envoyer un "ping" (paquet ICMP: echo request) en broadcast sur tout un réseau (appelé "amplificateur de smurf") avec l'adresse IP de leur cible comme adresse de retour. Toutes les machines sur le réseau relais vont renvoyer un paquet ICMP (echo response) à la cible en réponse à cette requête. Le réseau amplificateur de smurf ainsi que la machine de retour seront inondés par des paquets ICMP. Pour plus d'efficacité l'attaquant utilise souvent de nombreux réseaux relais. [09]

Figure 2.6 Attaque SMURF

c. Le TCP-SYN Flooding

L'attaque SYN appelée également "TCP-SYN Flooding" est une attaque réseau par saturation (déni de service) exploitant le mécanisme de poignée de main en trois temps (en anglais Three-ways handshake) du protocole TCP. Le mécanisme de poignée de main en trois temps est la manière selon laquelle toute connexion "fiable" à internet (utilisant le protocole TCP) s'effectue.

Les machines vulnérables aux attaques SYN mettent en file d'attente, dans une structure de données en mémoire, les connexions ainsi ouvertes, et attendent de recevoir un paquet ACK. Il existe un



mécanisme d'expiration permettant de rejeter les paquets au bout d'un certain délai. Néanmoins, avec un nombre de paquets SYN très important, si les ressources utilisées par la machine cible pour stocker les requêtes en attente sont épuisées, elle risque d'entrer dans un état instable pouvant conduire à un plantage ou un redémarrage.

d. Le Débordement de Tampon (Buffer Overflow)

Un buffer overflow est une attaque très efficace et assez compliquée à réaliser. Elle vise à exploiter une faille, une faiblesse dans une application (type browser, logiciel de mail, etc.) pour exécuter un code arbitraire qui compromettra la cible (acquisition des droits administrateur, etc.).

Le fonctionnement général d'un buffer overflow est de faire crasher un programme en écrivant dans un buffer plus de données qu'il ne peut en contenir (un buffer est une zone mémoire temporaire utilisée par une application), dans le but d'écraser des parties du code de l'application et d'injecter des données utiles pour exploiter le crash de l'application. Cela permet donc en résumé d'exécuter du code arbitraire sur la machine où tourne l'application vulnérable.

L'intérêt de ce type d'attaque est qu'il ne nécessite pas d'accès au système, ou dans le cas contraire, un accès restreint suffit. Il s'agit donc d'une attaque redoutable. D'un autre côté, il reste difficile à mettre en oeuvre car il requiert des connaissances avancées en programmation; de plus, bien que les nouvelles failles soient largement publiées sur le web, les codes ne sont pas ou peu portables. Une attaque par buffer overflow signifie en général que l'on a affaire à des attaquants doués plutôt qu'à des "script kiddies".

Le problème réside dans le fait que l'application crashe plutôt que de gérer l'accès illégal à la mémoire qui a été fait. Elle essaye en fait d'accéder (lire, exécuter) à des données qui ne lui appartiennent pas puisque le buffer overflow a décalé la portion de mémoire utile à l'application, ce qui a pour effet (très rapidement) de la faire planter.

e. Les virus informatiques

Les virus informatiques, en plus d’être considérés comme des outils d’attaques de modification, aussi des attaques de saturation

f. L’attaque par fragmentation (Teardroop)

Une "attaque par fragmentation" est une attaque réseau exploitant le principe de fragmentation du protocole IP.

En effet, le protocole IP est prévu pour fragmenter les paquets de taille importante en plusieurs paquets IP possédant chacun un numéro de séquence et un numéro d'identification commun. A la réception des données, le destinataire réassemble les paquets grâce aux valeurs de décalage (offset) qu'ils contiennent.

L'attaque par fragmentation la plus célèbre est l'attaque Teardrop. Le principe de l'attaque Teardrop consiste à insérer dans des paquets fragmentés des informations de décalage erronées.



Ainsi, lors du réassemblage il existe des vides ou des recoupements (overlapping), pouvant provoquer une instabilité du système.

3.5. Les attaques d’applications

a. Les buffers overflow

Déjà abordé dans les attaques par saturation.

b. Les Rootkits

Les Rootkits permettent à son possesseur de prendre le contrôle du système et de cacher son activité à l’administrateur, la plupart du temps en remplaçant les binaires communs, tels que ls, netstat, w, last, ps, top. Il peut de ce fait agir en toute impunité, sans se soucier d’une éventuelle intervention du propriétaire.

Le moyen le plus efficace pour se rendre compte de cette infraction est de surveiller les binaires essentiels du système par un hids.

3.6. Les attaques de reconnaissances

a. Le balayage de ports (Ports scan)

Le balayage de port est une technique pour rechercher les ports ouverts chez un hôte du réseau. Elle est souvent utilisée par les administrateurs pour contrôler la sécurité des hôtes de leurs réseaux, et par les pirates informatiques pour tenter de la compromettre. Un balayage de ports effectué sur un système tiers est généralement considéré comme une tentative d'intrusion dans la mesure où un balayage de port sert souvent à préparer une intrusion.

Le balayage de ports est une des activités considérées comme suspectes par un Système de Détection d'Intrusions (IDS). Celui-ci peut être réglé à différents niveaux de sensibilité. Un niveau de sensibilité haut génèrera plus de fausses alertes, un niveau de sensibilité bas risque de laisser passer les balayages effectués avec les options "paranoïaques" des outils comme Nmap.

Pour tromper la vigilance des systèmes de détection, les balayages peuvent se faire dans un ordre aléatoire, avec une vitesse excessivement lente, ou à partir de plusieurs adresses IP.

Les balayages de ports se font usuellement sur le protocole TCP; néanmoins certains logiciels permettent aussi d'effectuer des balayages UDP. Cette dernière fonctionnalité est néanmoins beaucoup moins fiable, UDP étant orienté sans connexion, par conséquent le service ne répondra que si la requête correspond à un modèle précis variant selon le logiciel serveur utilisé.



3.7. Les attaques de répudiation

a. L’usurpation d’adresses (IP Spoofing)

L'usurpation d'adresse IP est une technique de hacking consistant à utiliser l'adresse IP d'une machine, ou d'un équipement, afin d'en usurper l'identité. Elle permet de récupérer l'accès à des informations en se faisant passer pour la machine dont on spoofe l'adresse IP. De manière plus précise, cette technique permet la création de paquets IP avec une adresse IP source appartenant à quelqu'un d'autre.

b. Vol de session

Le "vol de session TCP" (également appelé détournement de session TCP ou en anglais TCP session hijacking) est une technique consistant à intercepter une session TCP initiée entre deux machines afin de la détourner.

Dans la mesure où le contrôle d'authentification s'effectue uniquement à l'ouverture de la session, un pirate réussissant cette attaque parvient à prendre possession de la connexion pendant toute la durée de la session.

III. Les techniques de sécurité 1. La cryptographie

Introduction

La cryptologie, étymologiquement la science du secret, ne peut être vraiment considérée comme une science que depuis peu de temps. Cette science est une science mathématique qui comporte deux branches, la cryptographie et la cryptanalyse.

La cryptographie s’attache à protéger des messages (assurant confidentialité et/ou authenticité) en s’aidant souvent de secrets ou clés. Elle est utilisée depuis l’Antiquité, mais certaines de ses méthodes les plus importantes, comme la cryptographie asymétrique, n’ont que quelques dizaines d’années d’existence.

La cryptanalyse s’oppose, en quelque sorte, à la cryptographie. En effet, si déchiffrer consiste à retrouver le message clair au moyen d’une clé, cryptanalyser c’est tenter de se passer de cette dernière.



Figure 2.7 Principes de base de la cryptologie

Terminologie

a. La cryptographie

Cryptographie se scinde en deux parties nettement différenciées : [10]

Ø D’une part la cryptographie à clé secrète, encore appelée symétrique ou bien classique, Ø D’autre part la cryptographie à clé publique, dite également asymétrique ou moderne.

La première est la plus ancienne, on peut la faire remonter à l’Égypte de l’an 2000 av. J-C.en passant par Jules César ; la seconde remonte à l’article de Whitfield Diffie et Martin E.Hellman, « New directions in cryptography », daté de 1976.

Toutes les deux visent à assurer la confidentialité de l’information, mais la cryptographie à clé secrète nécessite au préalable la mise en commun entre les destinataires d’une certaine information, la clé (symétrique), nécessaire au chiffrement ainsi qu’au déchiffrement des messages. Dans le cadre de la cryptographie à clé publique, ce n’est plus nécessaire. En effet, les clés sont alors différentes, ne peuvent se déduire l’une de l’autre, et servent à faire des opérations opposées, d’où l’asymétrie entre les opérations de chiffrement et de déchiffrement.

Bien que beaucoup plus récente et malgré d’énormes avantages, signature numérique, échange de clés... — la cryptographie à clé publique ne remplace pas totalement celle à clé secrète qui, pour des raisons de vitesse de chiffrement et parfois de simplicité, reste présente. À ce titre, signalons la sortie du dernier standard américain en la matière, l’AES, en décembre 2001, ce qui prouve la vitalité encore actuelle de la cryptographie symétrique.

b. La cryptanalyse

La cryptanalyse, à l'inverse, est l'étude des procédés cryptographiques dans le but de trouver des faiblesses et, en particulier, de pouvoir décrypter des textes chiffrés. Le décryptement est l'action consistant à retrouver le texte en clair sans connaître la clé de déchiffrement.



Les objectifs de la cryptographie

Les spécialistes de la sécurité utilisent les systèmes cryptographiques pour satisfaire quatre objectifs : confidentialité, intégrité, authentification et non-répudiation. La réalisation de chacun de ces objectifs exige la satisfaction d’un certain nombre d’exigences de conception (design), et les systèmes cryptographiques ne sont pas tous destinés à atteindre ces quatre objectifs.

i. La confidentialité

La confidentialité garantit que le message reste privé lors de la transmission entre deux ou plusieurs parties. C’est l’objectif le plus largement cité parmi les autres objectifs de la cryptographie pour la facilitation du secret des communications entre les individus et les groupes. Il existe deux principaux types de systèmes de chiffrement (cryptosystèmes) qui appliquent la confidentialité.

La cryptographie à clé symétrique fait usage d'une clé secrète partagée disponible pour tous les utilisateurs du cryptosystème. La cryptographie à clé publique utilise des combinaisons individuelles de clés publiques et privées pour chaque utilisateur du système.

ii. L’intégrité

L'intégrité assure que le message n'est pas modifié pendant le transit. Si les mécanismes d'intégrité sont en place, le destinataire d'un message peut être certain que le message reçu est identique au message envoyé. Ceci protège contre toutes les formes d’altération par un tiers tentant d’insérer de fausses informations. L’intégrité du message est assurée par l’utilisation de la signature numérique de messages créée à la transmission d’un message. Le destinataire du message vérifie simplement que le message élaboré et la signature sont valables, en veillant à ce que le message n’a pas été modifié en transmission. L’intégrité ne peut être exécutée par le cryptosystème à clé publique et à clé secrète (privée).

iii. L’authentification

L’Authentification vérifie l'identité déclarée par les utilisateurs du réseau et elle est une des principales fonctions du cryptosystème. Par exemple, supposons que Jim veut établir une session de communication avec Bob et que tous les deux participent à un secret partagé du système de communication. Jim peut utiliser une technique d'authentification défi-réponse (challenge-response) pour veiller à ce que Bob est bien celui qu’il prétend être.

La figure suivante montre à quel point ce protocole de défi-réponse peut fonctionner. Dans cet exemple, le code secret partagé utilisé par Jim et Bob est très simple, les lettres de chaque mot sont simplement inversées. Bob contacte en premier Jim et s’identifie; Jim envoie alors un message de défi (challenge message) à Bob, lui demandant de chiffrer un message court en utilisant le code secret connu seulement de Jim et Bob. Bob répond avec le message chiffré.

Ensuite, Jim vérifie que le message chiffré est correct, il saura vraiment que c’est Bob qui est à l'autre extrémité de la connexion.



Figure 2.8 Protocole d’authentification Challenge-response

iv. La non-répudiation

La non-répudiation garantit au destinataire que le message a effectivement été émis par l'expéditeur et non par une tierce personne se faisant passer pour l'expéditeur.

Il empêche l'expéditeur de nier qu’il ait jamais envoyé le message en premier lieu, c’est-à-dire renier le message "repudiating the message". Clé secrète, ou clé symétrique, des systèmes de chiffrement (comme le chiffre ROT3) ne prévoient pas cette garantie de non-répudiation. Si Jim et Bob participent à un système de communication à clé secrète, ils peuvent produire le même message chiffré en utilisant leur clé secrète partagée. La Non-répudiation est offerte uniquement par des cryptosystèmes à clé publique, ou asymétrique.

La cryptographie classique

i. Code et chiffrement

Les gens utilisent souvent le code de mots (words code) et le chiffrement interchangeable (cipher interchangeable), mais techniquement, ils ne sont pas interchangeables. Il y a d’importantes distinctions entre les deux concepts.

Codes : ce sont des systèmes cryptographiques de symboles et qui représentent des mots ou des phrases, et sont parfois secrets, mais ils ne sont pas nécessairement destinés à fournir la confidentialité. Dans le cadre de ce système, la phrase "J’ai reçu votre communication et j’ai compris le contenu", est représentée par le code 10-4. Ce code est généralement connu du public, Certains codes sont secrets, ils doivent utiliser des fonctions mathématiques ou un dictionnaire secret pour transmettre des messages confidentiels soit par mots, par phrases ou par paragraphes. Par exemple, un espion (spy) peut transmettre la phrase "l'aigle a atterri" pour signaler l'arrivée d'un avion ennemi.

Procédés de chiffrement : ils sont toujours destinés à cacher la véritable signification d'un message. Ils utilisent une variété de techniques visant à modifier et/ou réorganiser les caractères ou les bits d'un message pour atteindre la confidentialité. Les procédés de chiffrement convertissent les messages en clair en un texte chiffré sur la base de bits (c’est-à-dire un seul chiffre du code binaire), personnage "character basis" (c’est-à-dire, un seul caractère du message ASCII), ou à base de bloc (c’est-à-dire, un seul segment de longueur fixe d’un message généralement exprimé en nombre de bits).



ii. La transposition de procédés de chiffrement

La transposition consiste, par définition, à changer l’ordre des lettres. C’est un système simple, mais peu sûr pour de très brefs messages car il y a peu de variantes. Ainsi, un mot de trois lettres ne pourra être transposé que dans 6 (=3!) positions différentes. Un algorithme de décryptage inversera simplement la transformation de cryptage (encryption transformation) pour récupérer le message d’origine.

Lorsque le nombre de lettres croît, il devient de plus en plus difficile de retrouver le texte original sans connaître le procédé de brouillage. Ainsi, une phrase de 35 lettres peut être disposée de 35! = 1040 manières différentes. Ce chiffrement nécessite un procédé rigoureux convenu auparavant entre les parties.

Une transposition rectangulaire consiste à écrire le message dans une grille rectangulaire, puis à arranger les colonnes de cette grille selon un mot de passe donné (le rang des lettres dans l’alphabet donne l’agencement des colonnes).

A la figure suivante, on a choisi comme clé GRAIN pour chiffrer le message SALUT LES PETITS POTS. En remplissant la grille, on constate qu’il reste deux cases vides, que l’on peut remplir avec des nulles (ou pas, selon les désirs des correspondants).

Figure 2.9 Application d’une transposition

iii. La substitution de procédés de chiffrement

La substitution de procédés de chiffrement est un procédé de remplacement qui se divise en deux parties. La première est la substitution monoalphabétique, la deuxième est la substitution polyalphabétique.

La substitution monoalphabétique

Dans la substitution monoalphabétique, chaque lettre est remplacée par une autre lettre ou symbole. Parmi les plus connues, on citera le chiffre de César, le chiffre affine, ou encore les chiffres désordonnés. Tous ces chiffres sont sensibles à l’analyse de fréquence d’apparition des lettres (nombre de fois qu’apparaît une même lettre dans un texte). De nos jours, ces chiffres sont utilisés pour le grand public, pour les énigmes des revues ou des journaux.



Chiffre de César (50 av. J-C)

Il s’agit du plus simple et plus ancien chiffre classique ayant existé. Son principe est un décalage des lettres de l’alphabet. Dans les formules ci-dessous, p est l’indice de la lettre de l’alphabet, k est le décalage.

Pour le chiffrement, on aura la formule :

C = E(p) = (p + k) mod 26

Pour le déchiffrement, il viendra

p = D(C) = (C − k) mod 26

Si on connaît l’algorithme utilisé, la cryptanalyse par force brute est très facile. Dans le cas du chiffre de César, seules 25 ( !) clés sont possibles.

La substitution polyalphabétique

Chiffre de Vigenère

C’est une amélioration décisive du chiffre de César. Sa force réside dans l’utilisation non pas d’un, mais de 26 alphabets décalés pour chiffrer un message. On parle du carré de Vigenère. Ce chiffre utilise une clé qui définit le décalage pour chaque lettre du message (A : décalage de 0 cran, B : 1 cran, C : 2 crans, ..., Z : 25 crans).

Dans l’exemple suivant on va chiffré le texte "CHIFFRE DE VIGENERE" avec la clé "BACHELIER" (cette clé est éventuellement répétée plusieurs fois pour être aussi longue que le texte clair).

Clair C H I F F R E D E V I G E N E R E Clé B A C H E L I E R B A C H E L I E Décalage 1 0 2 7 4 11 8 4 17 1 0 2 7 4 11 8 4 Chiffré D H K M J C M H V W I I L R P Z I

Tableau 2.1 Application du carré de Vigenère

Pour utiliser le chiffrement de Vigenère, on a recours au Carré de Vigenère, illustré dans le tableau précédent.



Tableau 2.2 Le carré de Vigenère

La lettre de la clé est dans la colonne la plus à gauche, la lettre du message clair est dans la ligne tout en haut. La lettre chiffrée est à l’intersection des deux.

L’emploi du carré de Vigenère est souvent sujet à erreurs : la lecture en est pénible et, à la longue, fatigante. Beaucoup de cryptologues préfèrent se servir d’une "réglette", facile à construire, et d’un maniement plus rapide.

Notons que la carte (chart) est tout simplement l’alphabet écrit à mainte reprises (26 fois) sous l’autorité du capitaine rubrique (master heading) déplaçant une lettre à chaque fois. On a besoin d’une clé pour utiliser le système de Vigenère. Par exemple, la clé peut être secrète. Ensuite, on peut effectuer le processus de cryptage suivant :

Ø Écrire le texte en clair suivi de la touche (key). Ø Répéter la touche (key) autant de fois que nécessaire pour établir une ligne de texte qui a

la même longueur que le texte en clair. Ø Convertir chaque position de la lettre du texte en clair vers le texte chiffré. Ø Repérer la colonne dirigée par le premier caractère de texte en clair (a). Ø Ensuite, trouver la ligne dirigée par le premier caractère mot-clé (s).



Ø Enfin, localiser l’intersection de ces deux points (items) et écrire la lettre qui apparaît (s), c’est le message chiffré pour cette lettre.

Ø Répéter les étapes 1 à 3 pour chaque lettre dans le texte en clair.

Plaintext: a t t a c k a t d a w n

Key Word: s e c r e t s e c r e t

Ciphertext: s x v r g d s x f r a g

Bien que la substitution polyalphabétique protége contre l’analyse directe de fréquence, elle est vulnérable à une deuxième forme de commande (second-order form) de fréquence d’analyse appelée période d’analyse, qui est un examen de la fréquence basé sur l’utilisation répétée de la touche (key).

La cryptographie moderne

Les cryptosystèmes moderne utilisent des algorithmes de calcul complexes et ont de longues clés cryptographiques pour répondre aux objectifs de la cryptographie.

Les clés cryptographiques

Dans les premiers jours de la sécurité, les professionnels de la sécurité ont estimé que la meilleure façon de garder l’algorithme de chiffrement sûr (sécurisé) était de cacher (masquer) les détails de l’algorithme de l’extérieur. Les anciens cryptosystèmes nécessitent des parties de communication pour maintenir l’algorithme utilisé pour crypter et décrypter des messages secrets vers des tiers. Toute divulgation de l’algorithme pourrait conduire à la compromission du système en entier par un adversaire.

Les cryptosystèmes modernes ne se reposent pas sur le secret de leurs algorithmes. En fait, les algorithmes de la plupart des systèmes cryptographiques sont largement disponibles pour examen public (Public Review) dans une documentation correspondante (accompagnante) et sur Internet. Cela améliore effectivement la sécurité des algorithmes en les ouvrant pour test au public (Public Scruting). La généralisation des algorithmes d’analyse par la communauté de la sécurité informatique permet aux praticiens de découvrir et de corriger les failles de sécurité potentielles et de veiller à ce que les algorithmes qu’ils utilisent pour protéger leurs communications soient aussi sûrs que possible.

Au lieu de s’en remettre à des algorithmes secrets, les cryptosystèmes modernes se fondent sur le secret d’une ou plusieurs clés cryptographiques utilisées pour personnaliser l’algorithme de certains utilisateurs ou groupes d’utilisateurs. L’algorithme de transposition de colonnes peut être utilisé pour communiquer de manière sécurisée entre les parties tant que le mot-clé n’est pas trouvé par un étranger. Tant que la sécurité de ce mot-clé n’est pas divulguée, il n’est pas question que les tiers puissent en connaître les détails de l’algorithme. (Il convient toutefois de noter que la transposition de colonnes possède plusieurs faiblesses inhérentes qui rendent vulnérables à la cryptanalyse et donc utilisent une mauvaise technologie pour l’utilisation de la communication sécurisé moderne).



La cryptographie symétrique

La cryptographie symétrique utilise la même clé pour les processus de codage et de décodage; cette clé est le plus souvent appelée "secrète" (en opposition à "privée") car toute la sécurité de l'ensemble est directement liée au fait que cette clé n'est connue que par l'expéditeur et le destinataire. La cryptographie symétrique est très utilisée et se caractérise par une grande rapidité (cryptage à la volée, "on-the-fly"), des implémentations aussi bien software (Krypto Zone, firewalls logiciels type Firewall-1 et VPN-1 de Checkpoint) que hardware (cartes dédiées, processeurs cryptos 8 à 32 bits, algorithmes câblés, etc.) ce qui accélère nettement les débits et autorise son utilisation massive. Ce type de cryptographie fonctionne habituellement suivant deux procédés différents, le cryptage par blocs et le cryptage par flot "stream".

a. Les algorithmes de chiffrement en continu

Pour comprendre le cryptage en continu, il suffit de connaître par exemple les vidéos au format RealVideo très répandues sur internet, on visualise l'image au fur et à mesure que les données sont reçues. Le principe est le même dans le cas de "stream-ciphers"; le cryptage est effectué bit-à-bit sans attendre la réception complète des données à crypter. Une technique de chiffrement, du nom de "One-Time Pad" est utilisée pour chiffrer les flux. C'est le chiffrement inconditionnel le plus sûr. Pour cela, on a besoin d'une chaîne aléatoire de la même longueur que le message d'origine, ce qui n'est pas pratique. Le but d'un stream cipher est de générer une chaîne aléatoire à partir d'une clé de longueur courte. Une autre technique consiste à "xorer", c'est-à-dire à appliquer un OU exclusif (XOR) au message avec un autre message prédéfini. Bien entendu, cela nécessite que le destinataire (La personne qui décrypte) connaisse le message prédéfini et donc cela rajoute de la complexité au schéma général. Les stream-ciphers sont utilisés aujourd'hui par différentes applications. Pour chiffrer les flux, l'algorithme RC4 est très utilisé.

b. Les algorithmes de chiffrement par blocs

Le cryptage en blocs (blockcipher) est au contraire beaucoup plus utilisé et permet une meilleure sécurité. Les algorithmes concernés sont également plus connus (DES, AES, Skipjack, etc.); leur nom leur vient du fait qu'ils s'appliquent à des blocs de données et non à des flux de bits (stream-ciphers). Ces blocs sont habituellement de 64 bits mais cela dépend entièrement de l'algorithme utilisé et de son implémentation. De même, la taille de la clé varie suivant l'algorithme et suivant le niveau de sécurité requis; ainsi, un cryptage de 40 bits (c'est-à-dire utilisant une clé longueur de 40 bits) pourra être déclaré faible puisque aisément cassable. Un cryptage de 56 bits (qui est le standard dans le cas du DES) est qualifié de moyen puisqu’il est cassable mais nécessitant beaucoup de moyens pour être exploitable (vis-à-vis du temps requis et de la valeur des données). Enfin, un cryptage de 128 bits (valeur standard utilisée par Rijndael alias AES) est plutôt puissant à l'heure actuelle. La Loi de Moore prévoit le doublement de la puissance de calcul des processeurs tous les 18 mois (Loi toujours vérifiée de la fin des années 70 à nos jours). Il faut savoir que le cassage de cryptages nécessite essentiellement des ressources processeur, RAM et éventuellement ROM ou disque dur si le cassage se fait par pré-calcul.



Quatre modes de chiffrement par bloc sont utilisés : Electronic CodeBook (ECB), Cipher Block Chaining (CBC), Cipher FeedBack (CFB) ou Output FeedBack (OFB).

c. Les mécanismes cryptographiques i. Data Encryption Standard DES

Le D.E.S (Data Encryption Standard, ou Standard de Chiffrement de Données) est un standard mondial depuis la fin des années 1970.

Au début de cette décennie, le développement des communications entre ordinateurs a nécessité la mise en place d’un standard de chiffrement de données pour limiter la prolifération d’algorithmes différents ne pouvant pas communiquer entre eux. Pour résoudre ce problème, L’Agence Nationale de Sécurité américaine (N.S.A.) a lancé des appels d’offres. La société I.B.M. a développé alors un algorithme nommé Lucifer, relativement complexe et sophistiqué. Après quelques années de discussions et de modifications (applications de S-Boxes et réduction des clés à 56 bits), cet algorithme, devenu alors D.E.S., fut adopté au niveau fédéral le 23 novembre 1976.

Le DES comporte plusieurs avantages qui en ont fait l’algorithme de chiffrement symétrique standard pendant longtemps, jusqu’il y a quelques années. En voici quelques-uns :

Ø Il possède un haut niveau de sécurité, Ø Il est complètement spécifié et facile à comprendre, Ø La sécurité est indépendante de l’algorithme lui-même, Ø Il est rendu disponible à tous, par le fait qu’il est public, Ø Il est adaptable à diverses applications (logicielles et matérielles), Ø Il est rapide et exportable, Ø Il repose sur une clé relativement petite, qui sert à la fois au chiffrement et au déchiffrement, Ø Il est facile à implémenter.

Le DES est un cryptosystème agissant par blocs. Cela signifie que DES ne chiffre pas les données à la volée quand les caractères arrivent, mais il découpe virtuellement le texte clair en blocs de 64 bits qu’il code séparément, puis qu’il concatène. Un bloc de 64 bits du texte clair entre par un coté de l’algorithme et un bloc de 64 bits de texte chiffré sort de l’autre coté. L’algorithme est assez simple puisqu’il ne combine en fait que des permutations et des substitutions.

C’est un algorithme de chiffrement à clé secrète. Cette clé a ici une longueur de 64 bits, c’est-à-dire 8 caractères, mais dont seulement 56 bits sont utilisés.

L’entière sécurité de l’algorithme repose sur les clés puisque l’algorithme est parfaitement connu de tous. La clé de 64 bits est utilisée pour générer 16 autres clés de 48 bits chacune qu’on utilisera lors de chacune des 16 itérations du DES. Ces clés sont les mêmes quel que soit le bloc qu’on code dans un message.



ii. Triple DES (3DES)

Le Data Encryption Standard 56 bits n’est plus considérée comme adéquat en face des techniques modernes de cryptanalyse et de pouvoirs de l’informatique. Toutefois, une version adaptée de DES, Triple DES (3DES), utilise le même algorithme pour avoir un chiffrement plus sûr. Il existe quatre versions de 3DES :

La première chiffre simplement le texte en clair trois fois, au moyen de trois clés différentes: K1, K2 et K3. Il est connu sous le nom de DES-EEE3 mode (Es indique qu’il y a trois opérations de cryptage, tandis que le chiffre trois indique que trois différentes clés sont utilisées). DES-EEE3 peut être exprimé en utilisant la notation suivante, ou E(K,P) représente le cryptage du texte en clair P avec la clé K :

E(K1,E(K2,E(K3,P)))

DES-EEE3 a une clé de longueur effective de 168 bits.

La deuxième variante (DES-EDE3) utilise aussi trois clés mais remplace la deuxième opération de chiffrement (encryption) avec la description suivante :

E(K1,D((K2,E(K3,P)))

La troisième version du 3DES (DES-EEE2) utilise uniquement deux clés mais utilise l’opération de déchiffrement au milieu :

E(K1,D(K2,E(K2,P)))

Les troisième et quatrième variantes ont une longueur de clé effective de 112 bits.

Ces quatre variantes de 3DES ont été élaborées au fil des ans, parce que plusieurs cryptologues ont mis en avant les théories qu’une variante est plus sûre que les autres. Toutefois, la conviction actuelle est que tous les modes sont égaux en sécurité.

iii. Advanced Encryption Standard (AES)

En Octobre 2000, l'Institut National des Standards et de la Technologie (NIST) à annoncé que le chiffrage par bloc Rijndael (prononcer "Rhin-poupée") a été choisi comme remplaçant pour le DES.

Le procédé de chiffrement Rijndael, permet l'utilisation de trois clés fortes: 128 bits, 192 bits et 256 bits. La spécification originale pour AES appelait au traitement de blocs de 128 bits, mais Rijndael dépasse cette spécification, permettant aux cryptographes d'utiliser une taille de bloc égale à la longueur de clé.

Le nombre de tours (séries) de cryptage dépend de la longueur de clé choisie :

Ø Clés de 128-bit nécessitant 9 séries de cryptage.



Ø Clés de 192-bit nécessitant 11 séries de cryptage. Ø Clés de 256-bit nécessitant 13 séries de cryptage.

L'algorithme de Rijndael utilise trois couches de transformations pour crypter/décrypter des blocs du message texte :

Ø Transformation linéaire mixte (Linear Mix Transform) Ø Transformation non linéaire (Nonlinear Transform) Ø Transformation à clé additionnelle (key Addition Transform)

Le nombre total de bits ronde clé (round key bits) nécessaire est égal à ce qui suit:

Block length * number of rounds + 1

Par exemple, avec une longueur de bloc de 128 bits et 13 séries de cryptage, 1,792 séries de clé bits (round key bits) sont nécessaires.

iv. International Data Encryption Algorithm (IDEA)

Les procédés de chiffrement par bloc IDEA ont été développées en réponse aux plaintes concernant l’insuffisance de la longueur de la clé de l’algorithme DES. A l’instar de DES, IDEA opère sur des blocs de 64 bits de plain/ciphertext. Toutefois, il commence son mode de fonctionnement avec une clé de 128 bits. Cette clé est alors divisée en une série d’opérations en 52 sous-clés de 16 bits. Puis les sous-clés agissent sur le texte en utilisant une combinaison de XOR et du module d’opérations (modulus operations) pour produire la version cryptée/décryptée du message. IDEA est capable de fonctionner dans les mêmes modes utilisées par DES, qui sont ECB, CBC, CFB et OFB.

v. Tableau de synthèse

Name Block size Key size Data encryption standard (DES) 64 56 Triple DES (3DES) 64 128 Advanced encryption standard (AES), Rijudael Variable 128, 192, 256 Twofish 128 1- 256 Blowfish (often used in SSH) Variable 1-448 IDEA (used in PGP) 64 128 Rivest cipher 5 (RC5), based on RSA 32,64,128 0 -2048 Rivest cipher 4 (RC4), based on RSA Streaming 128 Rivest cipher 2 (RC2), based on RSA 64 128 Skipjack / 80

Tableau 2.3 Tableau synthèse des différents protocoles



La cryptographie asymétrique

Pour faire face aux problèmes liés à la distribution des clés dans le cryptage à clé privée, la cryptographie à clé publique a été mise au point.

Ce concept a été introduit par Whitfield Diffie et Martin Hellman en 1975, même s'il est communément accepté que les services secrets britanniques avaient déjà fait cette même découverte plusieurs années auparavant, mais avaient protégé ce secret militaire.

i. Les clés publiques et privées

La cryptographie à clé publique repose sur des paires de clés attribuées à chaque utilisateur. Chaque utilisateur possède à la fois une clé publique et une clé privée. La simple possession de la clé publique par des tiers ne fait pas la faiblesse du système de chiffrement. En contre-partie, la clé privée est réservée à l’usage exclusif de l’individu.

Figure 2.10 Cryptographie à clé asymétrique

On note que le processus ne nécessite pas le partage des clés privées. L’expéditeur chiffre le message en clair (P) avec la clé publique du récepteur pour créer le message texte chiffré (C).

Le destinataire ouvre le message chiffré (C), il déchiffre ce dernier à l’aide de sa clé privée et recrée le message en clair. Une fois que l’émetteur chiffre le message avec la clé publique du destinataire, aucun utilisateur (y compris l’expéditeur) ne peut décrypter le message sans avoir la clé privée du destinataire.

La cryptographie à clé publique implique un degré de complexité plus élevé. Les clés utilisées dans les systèmes à clés publiques doivent être plus longues que celles utilisées dans les systèmes à clé privée pour produire des Cryptosystèmes de forces équivalentes.

ii. Les mécanismes cryptographiques

a. RSA

Le plus célèbre système de chiffrement à clé publique est nommé d’après ses créateurs, Ronald Rivest, Adi Shamir et Leonard Adleman "RSA" en 1977; ces derniers ont proposé l’algorithme à



clé publique qui reste une norme mondiale. Aujourd’hui, RSA est breveté, il constitue la pierre de sécurité (sécurité backbone) d’un grand nombre d’infrastructures de sécurité produites par des sociétés connues Microsoft, Nokia et Cisco.

L’algorithme RSA permet à chaque utilisateur du cryptosystème de générer une paire de clés publiques et privées en utilisant l’algorithme décrit dans les étapes suivantes :

1. Choisir deux grands nombres premiers (environ 200 caractères chacun), marqué P et Q. 2. Calculer le produit de ces deux nombres n=p*q. 3. Sélectionner un certain nombre e qui satisfait les deux conditions suivantes :

a. e est inférieur à n. b. e et (n-1)(q-1) sont relativement premier, c-à-d, les deux nombres n’ont pas de

facteurs communs autres que 1. 4. Trouver un certain nombre d, de sorte que (ed-1) mod (p-1)(q-1)=0. 5. Distribuer e et n comme une clé publique à tous les utilisateurs du cryptosystème, garder D

secret comme la clé privée.

Si Alice souhaite envoyer un message crypté à Bob, elle génère le texte chiffré (C) a partir du texte brut (P) en utilisant la formule suivante (même e est la clé publique de Bob et b est le produit de p et q créer au cours du processus de généralisation de la clé) :

C=Pe mod n

Quand Bob reçoit le message, il effectue le calcul suivant pour récupérer le message brut :

P=Cd mod n

b. ELGAMAL

C’est un algorithme à clé publique présent à la base de la norme U.S de signature électronique. Il fut inventé par Taher ElGamal en 1984. Il est basé sur la difficulté de calculer des logarithmes discrets.

Le problème du logarithme discret consiste à retrouver un entier λ tel que

h = gλ mod p.

Principe du chiffrement

Soit un entier premier p très grand et p − 1 doit avoir un grand facteur premier. On produit :

Une clé secrète s, telle que s appartient à (1...p − 2),

Une clé publique reposant sur l’entier p, un entier a premier avec p, et l’entier P tel que :

P = as mod p

Le nombre a est pris tel que a appartient à (0... p−1) et quelques soit k appartient à (1... p − 2) :



ak ≠ 1 mod p

Soit un message M, avec M < p. On détermine un nombre aléatoire k qui n’est connu que de celui qui chiffre et différent à chaque message. On calcule alors

C1 = ak mod p

C2 = M.Pk mod p

On obtient alors le message chiffré C = (C1, C2). Le message chiffré est alors deux fois plus long que le message original.

Principe du déchiffrement

A la réception, on calcule

R1 = (C1)s mod p

= ask mod p

= Pk mod p

Le destinataire possède la clé privée (s). Ayant Pk, on divise C2 par cette valeur :

DK(C) = C2/(R1)

= M.Pk mod p/Pk mod p

= M

Pk est donc considéré comme un masque appliqué sous forme multiplicative à M.

Pour décrypter le message, il faudra soit trouver directement un masque jetable, soit trouver la clé privée s, solution de P = as mod p (et donc trouver le logarithme discret).

El Gamal est deux fois plus lent que le RSA. L’inconvénient majeur reste la taille des données chiffrées qui représente deux fois celle des données en clair.

c. Courbes elliptiques (Elliptic Curves)

Il s’agit d’un concept proposé en 1985 par deux chercheurs Miller et Klobitz, de façon totalement indépendante. Ce type de cryptographie, toujours basé sur le modèle asymétrique permet aussi bien de chiffrer que de signer. On utilise souvent l’abréviation ECC, pour Elliptic Curve Cryptography. Les clés utilisées sont plus courtes pour une sécurité égale ou supérieure. La théorie sous-jacente, ainsi que l’implémentation sont plus complexes, ce qui explique le fait que cette technologie soit moins répandue. Toutefois, de par la nécessité de traiter plus rapidement l’information, de gérer des



quantités de données importantes et de miniaturiser au maximum, les avantages de cette technique poussent la recherche.

D’une manière générale, sur R, les courbes elliptiques seront considérées comme l’ensemble des couples (x,y) tels que

y2 = x3 + ax + b

Dont le discriminant −(4a3 + 27b2) est non nul.

Pour la dessiner, pour a et b fixés, on calcule y tel que

y = √(x3 + ax + b) tel que √ est la racine carrée

(a) y2 =x3 – x (b) y2 =x3 + x +1

Figure 2.11 Deux exemples d’EC

La cryptographie sur courbes elliptiques (ECC)

Pour utiliser les courbes elliptiques en cryptographie, il faut trouver un problème difficile (tel que la factorisation d’un produit en ses facteurs premiers dans le cas du RSA).

Considérons l’équation Q = kP où Q, P appatient à Ep(a, b) et k < p.

Il est facile de calculer Q connaissant k et P, mais il est difficile de déterminer k si on connaît Q et P. Il s’agit du problème du logarithme discret pour les courbes elliptiques : log P (Q).

Dans une utilisation réelle, le k est très grand, rendant l’attaque par force brute inutilisable (rappelons qu’a priori, l’attaque par force brute est toujours possible. . .).



Sécurité de l’ECC

Si on compare la sécurité du RSA à l’ECC, en se basant sur des techniques de cryptanalyse récentes, on obtient les résultats donnés dans le tableau suivant :

Symmetric scheme

(taille de la clé en bits)

ECC based scheme

(taille de n en bits)

RSA /DSA

(modulus size in bits) 56 112 512 80 160 1024

112 224 2048 128 256 3072 92 384 7680

256 512 15360

Tableau 2.4 Taille des clés pour un effort de cassage similaire

La cryptographie hybride

Les algorithmes de chiffrement asymétriques ont cependant également un désavantage, ils sont généralement beaucoup plus lents que les algorithmes symétriques. Ils ne conviennent donc guère au chiffrement des longs messages. Le moyen d'éviter ce désagrément est de combiner les mécanismes symétrique et asymétrique de chiffrement. Cette combinaison est appelée cryptographie hybride ou "enveloppe digitale". De nombreux biens cryptographiques fonctionnent sur ce principe, à l'exemple du logiciel culte PGP [11]. Le principe de la clé de session consiste à générer aléatoirement une clé de session de taille raisonnable, et de chiffrer celle-ci à l'aide d'un algorithme de chiffrement à clé publique. Une clé secrète est générée automatiquement pour la session et utilisée pour crypter le message. Cette même clé est à son tour cryptée avec la clé publique du destinataire. L'ensemble (message crypté + clé privée cryptée) est envoyé au destinataire. Le Destinataire commence par le décryptage de la clé cryptée avec sa clé privée puis utilise le résultat (la clé partagée) pour déchiffrer le message. La figure suivante illustre ce principe. [60].

Le hachage

Le hachage est appelé aussi fonction de condensation ou fonction de hachage, qui est une fonction mathématique facilement calculable qui convertit une chaîne de longueur quelconque en une chaîne de taille inférieure et généralement fixe

On utilise les fonctions de hachage cryptographie pour :

Ø Fournir un condensé de taille fixe Ø Représenter précisément les données : la détection des changements dans le message est

simplifiée.



Cela permet l’utilisation de la cryptographie asymétrique sans engendrer trop de ralentissement et d’assurer la provenance d’un fichier ainsi que son intégrité.

On parle de "haché", de "résumé", ou de "condensé" pour nommer la caractéristique d’un texte ou de données uniques. La probabilité d’avoir deux messages avec le même haché doit être extrêmement faible. Le haché ne contient pas assez d’informations en lui-même pour permettre la reconstitution du texte original. L’objectif est d’être représentatif d’une donnée particulière et bien définie (en l’occurrence le message).

Les fonctions de hachage ont plusieurs propriétés :

Ø Elles peuvent s’appliquer à n’importe quelle longueur de message M Ø Elles produisent un résultat de longueur constante Ø Il doit être facile de calculer h = H(M) pour n’importe quel message M Ø Pour un h donné, il est impossible de trouver x tel que H(x) = h. On parle de propriété à

sens unique. Ø Pour un x donné, il est impossible de trouver y tel que H(y) = H(x) ==> résistance faible de

collision Ø Il est impossible de trouver x, y tels que H(y) = H(x) ==> résistance forte de collision

Figure 2.12 Le principe de hachage

i. MAC - Message Authentication Code

Le concept est relativement semblable aux fonctions de hachage. Il s’agit ici aussi d’algorithmes qui créent un petit bloc authentificateur de taille fixe. La grande différence est que ce bloc authentificateur ne se base plus uniquement sur le message, mais également sur une clé secrète.

Tout comme les fonctions de hachage, les MAC n’ont pas besoin d’être réversibles. En effet, le récepteur exécutera le même calcul sur le message et le comparera avec le MAC reçu.



Les techniques de base utilisant MAC

Premièrement garantir l’authentification du message (de la source A). En effet, le message est envoyé en clair sur le réseau, et le MAC lui est concaténé. Cependant, par l’utilisation d’une clé secrète, et comme seul A connaît cette clé, le destinataire B est sûr que l’expéditeur est bien A. A la réception du message, B applique la fonction MAC sur le message en clair, et vérifie que le MAC résultant correspondant à celui concaténé au message transmis.

Figure 2.13 L’authentification par MAC

Deuxièmement, garantir la confidentialité. Le MAC est concaténé au message, et le tout est chiffré et envoyé à B.

Figure 2.14 La confidentialité par MAC (1)

La troisième technique garantit aussi la confidentialité des données. La technique est que seul le message est chiffré. Le MAC est concaténé par la suite, et le tout est envoyé à B.

Figure 2.15 La confidentialité par MAC (2)



La signature numérique

L’authentification de message protège les deux entités communicantes d’un intrus. Cependant, cela ne les protège en rien l’un de l’autre, c’est le cas de manque de confiance.

Parmi les scénarios existants, on peut citer le cas de non-répudiation, deux exemples illustrent ce principe :

Ø L’entité A pourrait falsifier un message donné et dire qu’il vient de B. Il lui suffit pour cela de créer un message et lui appliquer un MAC en utilisant la clé qu’ils ont en commun.

Ø Le cas inverse peut également exister. B peut nier le fait d’avoir envoyer un message, pour la simple raison que la construction expliquée au point précédent est possible. Il est donc impossible de prouver qu’un tel message a été ou non envoyé par B plutôt que par A.

i. Les caractéristiques des signatures numériques

Une signature numérique doit :

Ø dépendre du message signé Ø employer une information unique propre à l’expéditeur pour empêcher la contrefaçon et le

démenti Ø être relativement facile à produire, à reconnaître et à vérifier Ø être mathématiquement impossible à falsifier (par construction de nouveaux messages pour

une signature numérique existante, ou par construction d’une signature numérique frauduleuse pour un message donné)

Ø être facile à stocker

ii. Les types de signature numérique

a. Signature numérique directe

Ce type de signature implique uniquement l’expéditeur et le récepteur. On suppose que le récepteur dispose de la clé publique de l’expéditeur.

La signature numérique est faite par l’expéditeur en signant le message entier ou le condensé avec sa clé privée. Par la suite, le message signé pourra être chiffré en utilisant la clé publique du récepteur. Il est important de signer d’abord et de chiffrer ensuite le message et la signature. La sécurité dépend de la clé privée de l’expéditeur.

b. Signature numérique arbitrée

La signature numérique utilise la notion d’arbitre. Un arbitre A est présent et validera n’importe quel message signé, le datera et l’enverra au destinataire.

Ce système exige un niveau approprié de confiance en l’arbitre. Il peut être mis en application avec des algorithmes symétriques ou à clé publique. L’arbitre peut ou ne peut pas voir le message.



Notation X = Sender M = Message

Y = Recipient T = Timestamp A = Arbiter

Figure 2.16 Authentification par signature digitale avec arbitre

iii. Mécanismes de signature numérique

Plusieurs algorithmes adoptent la signature numérique, les plus répondus sont :

a. MD5

Cet algorithme établi par Ronald Rivest (le R dans RSA), c’est le dernier d’une série (MD2, MD4). Cet algorithme produit un condensé de 128 bits. Il était il y a encore quelques temps l’algorithme de hachage le plus largement répandu. La cryptanalyse et l’attaque par force brute l’ont affaibli en 2004.

Le MD5 est un algorithme illustré dans les étapes suivantes :

1. Complétion : ajout de padding si nécessaire afin que le message ait une longueur de 448 mod 512. Cet ajout a toujours lieu.

2. Ajout de la longueur : on ajoute la longueur réelle du message (sur 64 bits) après les 448 bits. En conséquence, la taille totale du bloc atteint 512 bits. Si la longueur nécessite plus de 64 bits, on ne note que les 64 bits de poids faible.

3. Initialisation : initialiser 4 buffers de 32 bits chacun (A,B,C,D), qui constitue l’IV. 4. Calcul itératif : traiter le message par blocs de 512 bits. Il y a 4 rondes de 16 opérations :

fonction du bloc (512), des buffers et de fonctions primitives. 5. Le résultat final est obtenu en concaténant les résultats des additions des registres A,B,C,D

avec la valeur de CVq.

b. SHA-1

SHA (Secure Hash Algorithm) est le fruit d’une collaboration entre NIST et NSA en 1993, et révisé en 1995 pour étendre ses capacités en matière de sécurité. L’algorithme est le SHA, la norme est



SHS (Secure Hash Standard). Contrairement au MD5 qui produit des condensés de 128 bits, le SHA produit des valeurs condensées de 160 bits. Jusqu’à 2005, il était l’algorithme généralement préféré pour le hachage, mais des rumeurs de cassage le font peu à peu évoluer vers des versions plus sophistiquées. Le SHA-1 est basé sur le design du MD4.

Complétion : le message condensé doit être de longueur 448 mod 512

Ajout de la longueur : une valeur codée sur 64 bits

Initialisation : Initialiser 5 buffers de 32 bits (= 160 bits) - A,B,C,D,E

Calcul itératif : 4 rondes de 20 itérations chacune. Ces rondes ont une structure similaire mais utilisent des fonctions primitives différentes (f1, f2, f3, f4). Le SHA utilise des constantes additives Kt(0 =< t =< 79). Le résultat est utilisé pour initialiser les buffers du bloc suivant.

Le condensé final constitue le condensé attendu.

Figure 2.17 Rondes du SHA-1

c. El Gamal

Soit un nombre p premier et une clé privée SK = x (où x < p).

Soit la clé publique PK = (y, g, p) où y = gx mod p avec g < p.

La signature représentée par (a, b) est calculée comme suit :

Ø soit un nombre entier k gardé secret tel que (k, p − 1) = 1 Ø on calcule a = gk mod p Ø on calcule b tel que M = (xa + kb) mod (p − 1)



Lors de la vérification, on pourra déterminer une signature valide si

yaab mod p = gM mod p.

Pour assurer la sécurité de la méthode, il faudra utiliser un nouveau k à chaque signature ou chiffrement.

Si on utilise plusieurs fois le même k, il est possible de retrouver x aisément.

La cryptographie quantique

Le calculateur quantique (ou ordinateur quantique) utilise les particules élémentaires électrons, protons et photons) qui portent le nom de "quanta". A la différence de l’ordinateur classique, utilisant des bits et agissant de manière séquentielle, le calculateur quantique utilise les qubits (ou qbits). Un qubit (QUatum Bit), ou bit quantique, est un état quantique représentant la plus petite unité de stockage d’information quantique. A la différence du bit qui prend une valeur 0 ou 1, le qubit peut identifier une valeur intermédiaire, un "mélange" des états 0 et 1.

i. Ordinateur quantique vs ordinateur classique

Le calculateur quantique devance l’ordinateur classique sur plusieurs points :

Ø La résolution de problèmes complexes. Ø L’aide aux physiciens dans les calculs quantiques, souvent trop complexes. Ø La recherche accélérée dans des bases de données.

ii. Principe

La cryptographie quantique repose sur trois domaines distincts :

Ø La cryptographie, en ce sens qu’elle permet de garantir la confidentialité d’une clé. Ø La physique quantique, et plus particulièrement la mécanique quantique. Ø La théorie de l’information, car elle fournit un “système” inconditionnellement sûr.

Dans la cryptographie ordinaire (classique et moderne), on se préoccupe du problème de transfert de la clé entre les parties communicantes, mais dans la cryptographie quantique on n’émet aucune hypothèse sur la sécurité du canal employé. La raison en est que la cryptographie repose sur le principe d’Heisenberg.

Certaines quantités subatomiques ne peuvent être simultanément mesurées

La conséquence de ce principe est qu’il est impossible de mesurer ces particules sans les modifier. Il est donc possible de construire un canal de communication que nul ne peut espionner sans modifier la transmission de manière détectable. Ainsi, il est possible de transmettre une clé secrète entre deux personnes sans qu’elles disposent d’informations secrètes communes préalables.



Pour transporter une clé, la technique consistera en l’envoi de photons. On utilisera la technique dite de Polarisation de photons.

Application de la cryptographie

Il existe des applications de la cryptographie pour résoudre les problèmes de communication connus; nous allons examiner l’usage de la cryptographie pour garantir le courrier électronique, web services, le commerce électronique et la mise en réseau.

a. Le courrier électronique

La sécurité doit être rentable, pour le courrier électronique, la simplicité est le coût le plus efficace (the most cost-effective option)

Voici quelques règles simples sur le cryptage de l’E-mail :

Ø Si on a besoin de confidentialité lors de l'envoi d'un message e-mail, alors on doit chiffrer le message.

Ø Si notre message doit maintenir l'intégrité, alors on doit hacher le message. Ø Si notre message à besoin d'authentification et d'intégrité, alors on doit signer

numériquement le message. Ø Si notre message exige la confidentialité, l'intégrité, l'authentification, et non-répudiation,

alors on doit chiffrer et signer numériquement le message.

Il est toujours de la responsabilité de l'expéditeur de veiller à ce que des mécanismes sont en place pour veiller à ce que la sécurité (c'est-à-dire, la confidentialité, l'intégrité, l'authenticité, et non-répudiation) et la vie privée (privacy) d'un message ou la transmission sont maintenues.

L'une des applications les plus demandées de la cryptographie est le chiffrement et la signature de messages de courrier électronique. Jusqu'à récemment, cryptée e-mail requis l'utilisation de logiciel complexe, un logiciel gênant qui nécessite une intervention manuelle complexe et procédures d'échange de clés.

Pretty good privacy PGP

Le système d’E-mail sécurisé Pretty Good Privacy PGP de Phil Zimmerman est apparu sur la scène de sécurité des ordinateurs (computer security scene) en 1991. Il est fondé sur le concept de «la toile de confiance (web confiance)», où on doit être digne de confiance (become trusted) par un ou plusieurs utilisateurs de PGP pour commencer à utiliser le système. On peut alors accepter leurs jugements en ce qui concerne la validité des autres utilisateurs et, par extension, confiant a multi niveaux d’utilisateurs « web » (trust of multilevel) descendants a partir de notre jugement initial de confiance.

PGP est disponible en deux versions. La version commerciale utilise RSA pour l’échange de clés, IDEA pour le cryptage/décryptage, et MD5 pour digérer la production de message (message digest production). La version gratuite utilise l’échange de clés Diffie-Hellman, l’algorithme de



cryptage/décryptage Carlisle Adams/Stafford Tavares (CAST) 128 bits, et la fonction de hachage SHA-1.

i. Privacy Enhanced Mail

Renforcement de la protection des renseignements personnels Mail (PEM) est un standard qui traite la mise en oeuvre des lignes directrices (guidelines) pour assurer la sécurité du courrier électronique dans une variété de documents RFC (Request For Comments) d’internet. RFC 1421 décrit une architecture qui offre les services suivants :

Ø Divulgation de protection Ø Authenticité originaire (Originator authenticity) Ø L'intégrité du message Ø Non-répudiation (si la cryptographie asymétrique est utilisée)

Toutefois, la même RFC note également que le PEM n'a pas pour but de fournir les services suivants:

Ø Contrôle d'accès Ø La fluidité de la circulation confidentielle Ø Liste d'adresses de précision Ø Le contrôle de routage Ø Assurance de la réception de message et de la non-déniabilité (non-deniability) de réception Ø Association automatique des accusés de réception avec les messages auxquels ils se réfèrent Ø Replay protection

Les administrateurs de la sécurité qui souhaitent un des services énumérés doivent mettre en oeuvre de contrôles supplémentaires au delà de celles prévues par PEM confiant électronic mail system. Une importante distinction entre PEM et PGP, c’est que PEM fait appel a une hiérarchie de CA-managed (CA-managed hierarchy) des certificats numériques, considérant que PGP repose sur la toile de confiance entre les utilisateurs du système.

ii. MOSS

L’objet MIME de services de sécurité MOSS, est une autre norme pour la sécurité du courrier électronique, destiné à remplacer la vie privée renforcée Mail (PEM). À l'instar de PGP, MOSS ne nécessite pas l'usage des certificats numériques et permet un accès facile à des associations entre les certificats et les adresses e-mail. Il permet également l'échange sécurisé de pièces jointes à des emails. Toutefois, MOSS ne fournit pas d'interopérabilité avec PGP ou PEM.

iii. S/MIME

Le Secure Multipurpose Internet Mail Extensions S/MIME, est un protocole qui est apparu comme un probable futur standard pour le courrier électronique crypté efforts (future encrypted electronic mail efforts). S/MIME utilise l'algorithme de cryptage RSA et a reçu le soutien des principaux



acteurs de l'industrie, y compris RSA Security. S/MIME a déjà été intégré dans un grand nombre de produits commerciaux, y compris les suivants:

Ø Microsoft Outlook et Outlook Express Ø Netscape Communicator Ø Lotus Notes Ø VeriSign Digital ID Ø Eudora WorldSecure

2. Les anti-virus

Les antivirus sont des programmes capables de détecter la présence de virus sur un ordinateur, ainsi que de nettoyer celui-ci dans la mesure du possible si jamais un ou des virus s’y trouvent. Nettoyer signifie supprimer le virus du fichier sans endommager ce dernier. Mais parfois, ce nettoyage simple n’est pas possible.

i. Les types d’anti-virus

On dénombre bien sûr deux types d’antivirus. Les scanners, exécutés à la demande (On-Demand Scanners), et les moniteurs, toujours actifs à l'arrière-plan (On-Access Scanners).

Les moniteurs de comportement observent l'ordinateur en arrière-plan (en permanence, de manière transparente), pour détecter toute activité de type virale. Ils peuvent entre autres détecter les tentatives d'ouverture en écriture des fichiers exécutables, les tentatives d'écriture sur les secteurs d’amorçage, ou les tentatives d’un exécutable à devenir résident.

Pour détecter ces tentatives, les logiciels antivirus saisissent les principales interruptions de l'ordinateur, en les remplaçant par l'adresse de leur code. Ainsi, dès qu'un virus tente d'écrire sur le secteur d’amorçage ou sur le disque, c'est l'antivirus qui est d'abord appelé, et non le système directement.

Un moniteur résident analyse ainsi toute l'activité du PC, que ce soit les fichiers entrants et sortants de l'ordinateur, le logiciel de messagerie électronique, les exécutables, et même souvent tous les fichiers accédés en lecture ou en écriture. Les moniteurs actuels sont également capables de parcourir les fichiers compressés auquel on accède, afin de vérifier qu’aucun des fichiers ne contiennent de virus.

Un tel moniteur est extrêmement important, surtout pour les machines connectées à un réseau, et à fortiori à l’Internet, ce qui est de plus en plus fréquent.

Bien sûr, les détracteurs de ce genre de logiciel arguent du fait qu’ils ralentissent la machine, diminuent les performances. C’est une évidence, dans la mesure où ils analysent de nombreux événements du système. Néanmoins, sur des machines récentes, cela est beaucoup moins gênant pour l’utilisateur. Et c’est le prix à payer pour une tranquillité plus importante.



ii. Les techniques d’analyse (de protection) a. Signature virale

Les virus infectant des applications copient leur code dans ces programmes. Et les virus sont programmés pour ne pas infecter plusieurs fois le même fichier. Dès lors, ils intègrent dans l'application infectée une signature virale, c’est-à-dire une suite d’octets significative, qui leur permet de vérifier si tel ou tel programme est déjà infecté.

La méthode de base utilisée par les antivirus est donc de détecter cette signature propre à chaque virus. Evidemment, cette méthode n'est fiable que si l'antivirus possède une base virale à jour, contenant les signatures de tous les virus connus. Néanmoins, ce mécanisme ne permet pas la détection des virus « inconnus », c’est-à-dire, n'ayant pas encore été répertoriés par les éditeurs. En outre, n’oublions pas que les virus polymorphes, dont nous avons déjà parlé, sont capables de se camoufler, c’est-à-dire, de rendre leur signature indétectable (en la cryptant et en la modifiant à chaque copie).

b. Contrôleur d’intégrité des programmes

Puisque les virus modifient les programmes qu’ils infectent, certains antivirus utilisent un contrôleur d'intégrité pour vérifier si les fichiers de la machine ont été modifiés. Ainsi, une base de données est construite, qui contient des détails sur les fichiers exécutables du système, comme leur taille ou leur date de modification, et éventuellement un checksum. Dès lors, si une de ces caractéristiques change pour un exécutable, l'antivirus s’en aperçoit.

c. Analyse heuristique

L'analyse heuristique est relative à la recherche de code informatique correspondant à des fonctions de virus. C’est-à-dire, qu’elle est vouée à découvrir des virus encore inconnus. L'analyse heuristique est passive. Elle considère le code comme une simple donnée, et n'autorise jamais son exécution. Un analyseur heuristique recherche du code dont l'action pourrait s’avérer suspecte. En l’occurrence, il ne cherche pas des séquences fixes d'instructions spécifiques à un virus, mais un type d'instruction. Par exemple, des instructions visant la modification d’un fichier.

Cette méthode se dirige vers une démarche « intelligente » de recherche de virus. Cela dit, elle est loin d’être totalement efficace. Elle fonctionne bien pour les macro-virus, moins bien pour les autres. Les plus sensibles des antivirus heuristiques produisent un certain nombre de fausses alertes, et les moins agressifs rateront à coup sûr de véritables virus.

d. Analyse spectrale

L’analyse spectrale repose sur le postulat que tout code généré automatiquement contiendra des signes révélateurs du compilateur utilisé. De même, on part du principe qu’il est impossible de retrouver dans un vrai programme exécutable compilé certaines séquences de code. L’analyse spectrale vise donc elle aussi à repérer les virus polymorphes ou inconnus. Lorsqu'un virus polymorphe crypte son code, la séquence résultante contient certaines associations d'instructions



que l'on ne trouverait pas dans un vrai programme. C'est ce que l'analyse spectrale tente de détecter. Par exemple, si dans un programme exécutable, l'antivirus trouve une instruction de lecture d'un octet au delà de la taille limite de la mémoire, on sera probablement en présence de code crypté, donc d'un virus polymorphe.

3. Les firewalls

Un firewall, pare-feu ou garde-barrière, est un outil permettant de protéger un ordinateur connecté à un réseau ou à l’Internet. Il protège d’attaques externes (filtrage entrant) et souvent de connexions illégitimes à destination de l’extérieur (filtrage sortant) initialisées par des programmes ou des personnes. [50]

Le pare-feu a pour but de protéger contre plusieurs types de menaces : [50]

Ø les intrusions sur l’ordinateur, depuis l’Internet; Ø certains virus et certains vers (infection et propagation) ; Ø l’effet de chevaux de Troie en stoppant l’envoi d’informations vers l’Internet ou en privant

un intrus de l’accès à un ordinateur par une porte dérobée.

Le pare-feu permet également de limiter et filtrer l’accès aux services utilisés et proposés. Un service peut être accessible depuis l’ordinateur protégé, depuis tout l’Internet, par quelques adresses seulement.

Un pare-feu simple n’est cependant pas un véritable antivirus ; s’il peut bloquer des tentatives de propagation de virus et d’accès (vers l’extérieur ou vers l’ordinateur) par différents programmes malveillants, il ne supprime pas ces derniers.

Il existe trois types de firewalls :

Ø Les systèmes à filtrage de paquets sans état : analyse les paquets les uns après les autres, de manière totalement indépendante.

Ø Les systèmes à maintien d’état (stateful) : vérifient que les paquets appartiennent à une session régulière. Ce type de firewall possède une table d’états où est stocké un suivi de chaque connexion établie, ce qui permet au firewall de prendre des décisions adaptées à la situation.

Ces firewalls peuvent cependant être floués en faisant croire que les paquets appartiennent à une session déjà établie.

Ø Les firewalls de type proxy : Le firewall s’intercale dans la session et analyse l’information afin de vérifier que les échanges protocolaires sont conformes aux normes.

Le mode de fonctionnement

Un pare-feu accepte ou rejette les flux d’informations qui le traversent en fonction de règles définies par défaut ou par l’utilisateur :



Ø source et destination de l’information ; Ø services (navigation internet, messagerie instantanée, courrier électronique, etc.).

Le pare-feu peut conserver la trace de son activité : communications autorisées, rejetée, ignorée, etc.

4. Les systèmes de détection d’intrusion

Afin de détecter les attaques que peut subir un système, il est nécessaire de disposer d’un logiciel spécialisé dont le rôle est de surveiller les données qui transitent sur ce système, et qui serait capable de réagir si des données semblent suspectes. Plus communément appelé IDS (Intrusion Detection Systems), les systèmes de détection d’intrusions conviennent parfaitement pour réaliser cette tâche. [51]

IDS est un système combinant logiciel et matériel, qui permet de détecter en temps réel les tentatives d'intrusion sur un réseau interne ou sur un seul ordinateur hôte, de neutraliser ces attaques réseaux ou systèmes et d'assurer ainsi la sécurité du réseau... Deux méthodes sont principalement utilisées par les SDI : la reconnaissance de signatures et la détection d'anomalies. La reconnaissance de signatures est une approche consistant à rechercher dans l'activité de l'élément surveillé les signatures (ou empreintes) d'attaques connues. Le SDI fait appel à une bibliothèque de signatures (base de données) et ne peut alors détecter que les attaques dont il possède la signature. De son côté, la détection d'anomalies utilise l'analyse de statistiques du système : changement de mémoire, utilisation excessive du CPU, etc. Le SDI signalera les divergences par rapport au fonctionnement normal (ou de référence) des éléments surveillés. Contrairement au pare-feu qui traite des requêtes et les interdit, un système de détection d'intrusion les analyse de façon continue et ne réagit qu'en cas d'anomalies.

Les différents types d’IDS

Les systèmes de détection d’intrusion ont plusieurs modes de détection et d’analyse, on peut les classer comme suit : [51]

i. Les IDS

L’IDS est un ensemble de composants logiciels et matériels dont la fonction principale est de détecter et analyser toute tentative d’effraction (volontaire ou non).

Le mode fonctionnement est la détection des techniques de sondage (balayages de ports, fingerprinting), des tentatives de compromission de systèmes, d’activités suspectes internes, des activités virales ou encore l’audit des fichiers de journaux (logs).

ii. Les systèmes de détection d’intrusions « réseaux » (NIDS)

L’objectif de NIDS est d’analyser de manière passive les flux en transit sur le réseau et détecter les intrusions en temps réel.



Un NIDS écoute donc tout le trafic réseau, puis l’analyse et génère des alertes si des paquets semblent dangereux.

Les NIDS étant les IDS plus intéressants et les plus utiles du fait de l’omniprésence des réseaux dans notre vie quotidienne, ce document se concentrera essentiellement sur ce type d’IDS.

iii. Les systèmes de détection d’intrusions de type hôte (HIDS)

Un HIDS se base sur une unique machine, n’analysant cette fois plus le trafic réseau mais l’activité de cette machine elle-même. Il analyse en temps réel les flux relatifs à une machine ainsi que les journaux.

Un HIDS a besoin d’un système sain pour vérifier l’intégrité des donnés. Si le système a été compromis par un pirate, le HIDS ne sera plus efficace. Pour parer à ces attaques, il existe des KIDS (Kernel Intrusion Detection System) et KIPS (Kernel Intrusion Prevention System) qui sont fortement liés au noyau. Ces types d’IDS sont décrits un peu plus loin.

iv. Les systèmes de détection d’intrusions « hybrides »

Généralement utilisés dans un environnement décentralisé, ils permettent de réunir les informations de diverses sondes placées sur le réseau. Leur appellation « hybride » provient du fait qu’ils sont capables de réunir aussi bien des informations provenant d’un système HIDS qu’un NIDS.

L’exemple le plus connu dans le monde Open-Source est Prelude. Ce framework permet de stocker dans une base de données des alertes provenant de différents systèmes relativement variés. Utilisant Snort comme NIDS, et d’autres logiciels tels que Samhain en tant que HIDS, il permet de combiner des outils puissants tous ensemble pour permettre une visualisation centralisée des attaques.

v. Les systèmes de prévention d’intrusions (IPS)

L’IPS est un ensemble de composants logiciels et matériels dont la fonction principale est d’empêcher toute activité suspecte détectée au sein d’un système.

Contrairement aux IDS simples, les IPS sont des outils aux fonctions « actives », qui en plus de détecter une intrusion, tentent de la bloquer. Cependant, les IPS ne sont pas la solution parfaite comme on pourrait le penser.

Un IPS possède de nombreux inconvénients. Le premier est qu’il bloque toute activité qui lui semble suspecte. Or, il est impossible d’assurer une fiabilité à 100% dans l’identification des attaques. Un IPS peut donc malencontreusement bloquer du trafic inoffensif ! Par exemple, un IPS peut détecter une tentative de déni de service alors qu’il s’agit simplement d’une période chargée en trafic. Les faux positifs sont donc très dangereux pour les IPS.

Le deuxième inconvénient est qu’un pirate peut utiliser sa fonctionnalité de blocage pour mettre hors service un système. Prenons l’exemple d’un individu mal intentionné qui attaque un système



protégé par un IPS, tout en spoofant son adresse IP. Si l’adresse IP spoofée est celle d’un noeud important du réseau (routeur, service Web, etc.), les conséquences seront catastrophiques. Pour palier ce problème, de nombreux IPS disposent des « white lists », c’est-à-dire des listes d’adresses réseaux qu’il ne faut en aucun cas bloquer.

Enfin, le troisième inconvénient et non le moindre ; un IPS est peu discret. En effet, à chaque blocage d’attaque, il montre sa présence. Cela peut paraître anodin, mais si un pirate remarque la présence d’un IPS, il tentera de trouver une faille dans celui-ci afin de réintégrer son attaque... mais cette fois en passant inaperçu.

5. Les protocoles de sécurité

Parmi les protocoles de réseau existant, il y a des protocoles dédiés spécialement pour la sécurité, on va citer quelques uns (les plus répondus) :

IP Security

IPSec est une norme qui définit une extension de sécurité pour le protocole IP afin de permettre la sécurisation des réseaux basés sur ce protocole. IPSec se place au niveau de la couche réseau.

IPSec, définit par la RFC 2401: "est un protocole qui vise à sécuriser l'échange de données au niveau de la couche réseau."

Les grands services d'IPSec : [52]

Ø Protection et sécurisation les accès distants d'un réseau Ø IPSec sert à mettre en place des réseaux privés virtuels (VPN : Virtual Private Network

IPSec fournit également des services comme ci-dessous : [52]

Confidentialité : aucune information ne circule en clair sur le réseau

Protection contre l’analyse du trafic : le mécanisme qui permet de faire le chiffrement des données

Authentification : l’authentification permet de vérifier que l’origine de donnée est bien celle déclarée

Intégrité des données : ce service permet de garantir que les données n’ont pas été modifiées avant d’être reçues.

Ø Intégrité en mode non connecté permet de détecter des modifications sur un datagramme individuel, mais pas sur l’ordre des datagrammes.

Ø L’intégrité en mode connecté permet en plus de détecter la perte de paquets ou leur ordonnancement.



Principe de fonctionnement

La transmission sécurisée de l'IPSec se fait par le biais de deux protocoles AH (Authentication Header) et ESP (Encapsulating Security Payload)

Ø AH assure l'intégrité des datagrammes et l'authentification de la source. Le principe de AH est d'ajouter une signature digitale (code d'authentification) dans le datagramme qui permet à la réception de vérifier l'authenticité des données incluses.

Ø ESP assure la confidentialité des données. A partir d'un datagramme IP normal, ESP utilise un moyen de cryptage symétrique pour chiffrer les données.

Pour chacun de ses protocoles, il existe deux modes : le mode "transport" et le mode "tunnel".

Mode Tunnel : IPSec crée un tunnel pour la communication entre deux machines pour bien sécuriser les données. Le mode tunnel est très utilisé par le protocole IPSec dans le réseau de type LAN to LAN car il offre une protection contre l'analyse de trafic, les adresses de la source et l'adresse de destinataire sont toutes masquées

Mode Transport : Si l'on ne veut sécuriser que les données, on va choisir d'utiliser le mode transport. Il est généralement utilisé pour acheminer les données de type Host-to-Host.

Les VPNs

Le VPN (pour Virtual Private Network) est une technologie de "Réseau Privé Virtuel". Il permet à un ordinateur distant d'avoir, via Internet, un accès direct et totalement sécurisé à un autre ordinateur ou à un réseau local.

Principe de fonctionnement

Un réseau VPN repose sur un protocole appelé "protocole de tunneling". Ce protocole permet de faire circuler les informations de l'entreprise de façon cryptée d'un bout à l'autre du tunnel. Ainsi, les utilisateurs ont l'impression de se connecter directement sur le réseau de leur entreprise.

Le principe de tunneling consiste à construire un chemin virtuel après avoir identifié l'émetteur et le destinataire. Par la suite, la source chiffre les données et les achemine en empruntant ce chemin virtuel. Afin d'assurer un accès aisé et peu coûteux aux intranets ou aux extranets d'entreprise, les réseaux privés virtuels d'accès simulent un réseau privé, alors qu'ils utilisent en réalité une infrastructure d'accès partagée, comme Internet.

Les données à transmettre peuvent être prises en charge par un protocole différent d'IP. Dans Ce cas, le protocole de tunneling encapsule les données en ajoutant un en-tête. Le tunneling est l'ensemble des processus d'encapsulation, de transmission et de désencapsulation. [53]



Fonctionnalités des VPN

Il existe trois types standard d'utilisation des VPN. En étudiant ces schémas d'utilisation, il est possible d'isoler les fonctionnalités indispensables des VPN. [53]

a. Le VPN d’accès

Le VPN d'accès est utilisé pour permettre à des utilisateurs itinérants d'accéder au réseau privé. L'utilisateur se sert d'une connexion Internet pour établir la connexion VPN. Il existe deux cas:

Ø L'utilisateur demande au fournisseur d'accès de lui établir une connexion cryptée vers le serveur distant : il communique avec le NAS (Network Access Server) du fournisseur d'accès et c'est le NAS qui établit la connexion cryptée.

Ø L'utilisateur possède son propre logiciel client pour le VPN auquel cas il établit directement la communication de manière cryptée vers le réseau de l'entreprise.

Les deux méthodes possèdent chacune leurs avantages et leurs inconvénients :

Ø La première permet à l'utilisateur de communiquer sur plusieurs réseaux en créant plusieurs tunnels, mais nécessite un fournisseur d'accès proposant un NAS compatible avec la solution VPN choisie par l'entreprise. De plus, la demande de connexion par le NAS n'est pas cryptée, ce qui peut poser des problèmes de sécurité.

Ø Sur la deuxième méthode, ce problème disparaît puisque l'intégralité des informations sera cryptée dès l'établissement de la connexion. Par contre, cette solution nécessite que chaque client transporte avec lui le logiciel, lui permettant d'établir une communication cryptée. Nous verrons que, pour pallier à ce problème, certaines entreprises mettent en place des VPN à base de SSL, technologie implémentée dans la majorité des navigateurs Internet du marché.

Quelle que soit la méthode de connexion choisie, ce type d'utilisation montre bien l'importance dans le VPN d'avoir une authentification forte des utilisateurs. Cette authentification peut se faire par une vérification "login / mot de passe", par un algorithme dit "Tokens sécurisés" (utilisation de mots de passe aléatoires) ou par certificats numériques.

b. L’intranet VPN

L'intranet VPN est utilisé pour relier au moins deux intranets entre eux. Ce type de réseau est particulièrement utile au sein d'une entreprise possédant plusieurs sites distants. Le plus important dans ce type de réseau est de garantir la sécurité et l'intégrité des données. Certaines données très sensibles peuvent être amenées à transiter sur le VPN (base de données clients, informations financières, etc.). Des techniques de cryptographie sont mises en oeuvre pour vérifier que les données n'ont pas été altérées. Il s'agit d'une authentification au niveau paquet pour assurer la validité des données, de l'identification de leur source ainsi que leur non-répudiation. La plupart des algorithmes utilisés font appel à des signatures numériques qui sont ajoutées aux paquets. La confidentialité des données est, elle aussi, basée sur des algorithmes de cryptographie. La



technologie en la matière est suffisamment avancée pour permettre une sécurité quasi-parfaite. Le coût matériel des équipements de cryptage et décryptage ainsi que les limites légales interdisent l'utilisation d'un codage " infaillible ". Généralement pour la confidentialité, le codage en lui-même pourra être moyen à faible, mais sera combiné avec d'autres techniques comme l'encapsulation IP dans IP pour assurer une sécurité raisonnable.

c. L’extranet VPN

Une entreprise peut utiliser le VPN pour communiquer avec ses clients et ses partenaires. Elle ouvre alors son réseau local à ces derniers. Dans ce cadre, il est fondamental que l'administrateur du VPN puisse suivre les clients sur le réseau et gérer les droits de chacun sur celui-ci.

SSL (Secure Socket Layer)

SSL est un protocole de couche 4 (niveau transport) utilisé par une application pour établir un canal de communication sécurisé avec une autre application.

SSL a deux grandes fonctionnalités : l'authentification du serveur et du client à l'établissement de la connexion et le chiffrement des données durant la connexion.

C'est un système qui permet d'échanger des informations entre deux ordinateurs de façon sûre. SSL assure trois choses: [54]

• Confidentialité: Il est impossible d'espionner les informations échangées. • Intégrité: Il est impossible de truquer les informations échangées. • Authentification: Il permet de s'assurer de l'identité du programme, de la personne ou de

l'entreprise avec lesquels on communique.

a. Principe de fonctionnement

Le protocole SSL Handshake débute une communication SSL. Suite à la requête du client, le serveur envoie son certificat ainsi que la liste des algorithmes qu'il souhaite utiliser. Le client commence par vérifier la validité du certificat du serveur. Cela se fait à l'aide de la clé publique de l'autorité de certification contenue dans le navigateur du client. Le client vérifie aussi la date de validité du certificat et peut également consulter une CRL (Certificate Revocation List). Si toutes les vérifications sont passées, le client génère une clé symétrique et l'envoie au serveur. Le serveur peut alors envoyer un test au client, que le client doit signer avec sa clé privée correspondant à son propre certificat. Ceci est fait de façon à ce que le serveur puisse authentifier le client.

De nombreux paramètres sont échangés durant cette phase : type de clé, valeur de la clé, algorithme de chiffrage, etc.

La phase suivante consiste en l'échange de données cryptées (protocole SSL Records). Les clés générées avec le protocole Handshake sont utilisées pour garantir l'intégrité et la confidentialité des données échangées. Les différentes phases du protocole sont :



Ø Segmentation des paquets en paquets de taille fixe Ø Compression (mais peu implémenté dans la réalité) Ø Ajout du résultat de la fonction de hachage composé de la clé de cryptage, du numéro de

message, de la longueur du message, des données ... Ø Chiffrement des paquets et du résultat du hachage à l'aide de la clé symétrique générée lors

du Handshake. Ø Ajout d'un en-tête SSL au paquet.

b. Les utilisation de SSL: HTTPS, SSH, FTPS, POPS...

SSL peut être utilisé pour sécuriser pratiquement n'importe quel protocole utilisant TCP/IP.

Certains protocoles ont été spécialement modifiés pour supporter SSL: [54]

Ø HTTPS: c'est HTTP+SSL. Ce protocole est inclus dans pratiquement tous les navigateurs, et vous permet (par exemple) de consulter vos comptes bancaires par le web de façon sécurisée.

Ø FTPS est une extension de FTP (File Transfer Protocol) utilisant SSL. Ø SSH (Secure Shell): c'est une sorte de telnet (ou rlogin) sécurisé. Cela permet de se

connecter à un ordinateur distant de façon sûre et d'avoir une ligne de commande. SSH possède des extensions pour sécuriser d'autres protocoles (FTP, POP3 ou même X Windows).

Il est possible de sécuriser des protocoles en créant des tunnels SSL. Une fois le tunnel créé, vous pouvez faire passer n'importe quel protocole dedans (SMTP, POP3, HTTP, NNTP...). Toutes les données échangées sont automatiquement chiffrées.

IV. Conclusion

Dans ce chapitre, nous avons essayé de faire une étude exhaustive sur les attaques et sur les techniques de protection.

Pour les attaques, on a essayé de donner une classification selon leurs impacts sur le système, et concernant les techniques de sécurité, on a fait une étude sur les techniques les plus réputées et les plus utilisées.

.


Chapitre III Politique de sécurité

1. Introduction

Une politique de sécurité traduit la « marche à suivre » afin de réaliser un système sécurisé. Dans le but d’être compréhensible de tous, la politique est exprimée en langage naturel et ce, afin d’être compréhensible par les informaticiens et les non informaticiens. Elle est donc informelle et sujette à des ambiguïtés.

En premier lieu, on ne va pas donner une définition proprement dite, mais faire un tour d’horizon sur ce que doit être une politique de sécurité. Ce tour d’horizon, qui prend en compte des mécanismes de sécurité physiques (protection par gardiennage, enceintes blindées, etc.), organisationnels (nomination d’un administrateur de sécurité, etc.) ou logiques (qui sont liés aux données informatiques contenues dans le système) est basé sue la définition suivante :

C’est l’ensemble des lois, règles et pratiques qui régissent la façon de gérer, protéger et diffuser les informations et autres ressources sensibles au sein d’une organisation [29]

2. Définitions

Sterne propose une définition en « trois temps » de la politique de sécurité. Il avance que la politique de sécurité est constituée de trois éléments fondamentaux et complémentaires qui sont : l’objectif de la politique de sécurité, la politique de sécurité organisationnelle et la politique de sécurité automatisée (qui peut être vue comme la politique de sécurité logique du NRC). Il les définit de la façon suivante :

Objectif de la politique de sécurité

Déclaration de l’intention de protéger une ressource identifiée contre une utilisation non autorisée. Cette déclaration doit identifier les utilisations qui sont permises. La ressource identifiée doit être tangible ou posséder une certaine forme tangible. Un objectif de politique de sécurité n’a de sens pour une organisation que si celle-ci possède ou contrôle les ressources à protéger.

Politique de sécurité organisationnelle

C’est l’ensemble des lois, règles et pratiques d’une organisation qui régissent la façon de gérer, protéger et diffuser les ressources afin d’atteindre les objectifs de la politique de sécurité. Ces lois, règles et pratiques doivent identifier les critères d’attribution de privilèges aux individus et les conditions sous lesquelles ils sont autorisés à exercer ou déléguer leurs privilèges. Afin d’être

Résumé Dans le cadre de notre thèse, la notion fondamentale est la politique de sécurité. Dans ce chapitre, nous abordons ce point en commençant par donner une définition de ce qu’est un modèle de sécurité et nous terminons par la classification des attaques.



efficientes, ces lois, règles et pratiques doivent donner aux individus la capacité de déterminer si leurs actions violent ou sont conformes à la politique de sécurité.

La politique de sécurité organisationnelle est dite politique générale ou de « haut niveau ».

Politique de sécurité automatisée

C’est l’ensemble des contraintes et des propriétés qui spécifient la façon dont un système informatique va prévenir l’utilisation de l’information et des ressources dans un but de violation de la politique de sécurité organisationnelle. Afin que cet ensemble soit considéré comme une politique de sécurité automatisée, il doit exister des arguments d’ingénierie persuasifs qui démontrent que ces contraintes et ces propriétés jouent un rôle clé dans la mise en œuvre effective de la politique de sécurité organisationnelle.

Schneider dans [30] donne une définition d’une politique de sécurité qui s’applique plus au contrôle des applications (programmes, codes exécutables) que des systèmes. Cette définition est la suivante :

Une politique de sécurité définit les exécutions (d’une application) qui pour une raison ou une autre ont été jugées inacceptables [30].

Cette définition regroupe l’ensemble des politiques de sécurité qui régissent le comportement des applications s’exécutant dans un environnement que l’on souhaite sécuritaire. Un exemple d’une telle politique est le suivant: « Il est interdit (à une application) d’envoyer de l’information provenant d’un fichier se trouvant dans le répertoire secret ». En fonction des ressources que l’on souhaite protéger et de ce que l’on considère comme un comportement correct, il est ainsi possible de créer un très grand nombre de politiques de sécurité.

3. Les modèles de sécurité

On va présenter une définition simple du modèle de sécurité :

Un modèle de sécurité est une expression formelle d’une politique de sécurité [32], qui a pour objectif de décrire, et éventuellement de vérifier la sécurité du système [31].

Un modèle de sécurité se compose [31, 33] :

1. de la propriété de sécurité du système informatique, qui est une interprétation de la politique de sécurité et est donnée par un ensemble d’axiomes, ou invariants de sécurité, définissant un état sûr du système,

2. la modélisation du système informatique, expression du système dans un modèle mathématique (par exemple, une machine d’états finis), utilisé afin de décrire l’évolution de l’état du système dans le temps. Il permet de vérifier que le système est sûr au regard de la condition de sécurité.



Il est à noter que le caractère formel d’un modèle de sécurité, versus l’aspect informel du langage naturel utilisé pour décrire une politique de sécurité, est la raison principale qui fait que l’on doit clairement établir la distinction entre les deux concepts : le premier formalise le second.

McLean précise que l’expression modèle de sécurité a été utilisée pour décrire « tout énoncé formel des exigences de confidentialité, de disponibilité de service et d’intégrité d’un système » [34].

4. Le contrôle d’accès

Le contrôle d’accès se base sur une politique appelée politique de contrôle d’accès. Une politique de contrôle d’accès permet de caractériser les états d’un système et de spécifier ce qui un état sûr en fonction d’informations de sécurité associés aux entités du système.

i. Entités

Le contrôle des accès d'un système permet de régir les accès entre deux ensembles d'entités. Le premier est l'ensemble S des sujets, aussi appelés entités actives, qui initient les actions du système. Il peut s'agir d'utilisateurs, de processus, etc. Le second est l'ensemble O des objets, aussi appelés entités passives, sur lesquels les actions sont effectuées. Il peut s'agir de fichiers, de ressources, de processus, etc. [40]

ii. Accès

Nous caractérisons ici la notion d'accès. Pour cela, nous introduisons un ensemble X des modes d'accès qui permettent de spécifier la manière avec laquelle un sujet accède à un objet. Les modes d'accès classiques sont lire, écrire, exécuter, etc. Une approche possible consiste à décrire un accès par un triplet (s, o, x) exprimant qu'un sujet s accède à un objet o selon le mode x. On note A l'ensemble des accès : [40,41]

A = S × O × X

iii. Paramètres de sécurité

Les politiques de contrôle d'accès font intervenir des informations de sécurité associées aux sujets et/ou aux objets. Ces informations serviront à déterminer si un accès respecte ou non la politique. Ces informations peuvent être, par exemple, un ensemble d'habilitations ou de classes de conflits d'intérêt. Elles constituent ce que l'on appellera dans la suite le paramètre de sécurité de la politique. Il n'est bien sûr pas possible de décrire le « type » de ce paramètre à ce niveau de spécification. Nous noterons ce paramètre ρ. [40]

iv. Etats

Les systèmes sur lesquels s'appliquent les politiques de contrôle d'accès sont considérés comme des machines abstraites à états et l'on note Σ l'ensemble des états d'un système. Un état représente le système à un instant donné. Il décrit l'ensemble des accès courants du système. La fonction Λ :Σ → δ(A) permet d'associer à chaque état σ appartenant à Σ, l'ensemble Λ(σ) des accès courants



du système dans cette état. De plus, un état contient des fonctions de sécurité, permettant de donner des informations, concernant le paramètre de sécurité, associées aux sujets et aux objets. Si l'on note SF l'ensemble des fonctions de sécurité, la fonction γ: Σ → SF permet d'obtenir les fonctions de sécurité d'un état. [40,41]

v. Prédicats de sécurité

Les états sûrs d'un système sont caractérisés par un prédicat de sécurité noté Ω. C'est ce prédicat qui définit la politique de contrôle d'accès. On utilise ici la logique du premier ordre pour définir ce prédicat. L'ensemble des états sûrs {σ∈Σ|Ω(σ)} est noté Σ|Ω [40]

vi. Politique de sécurité

Les systèmes de contrôle d’accès sont modélisés sous la forme de machine à états. Un état représente le système à un instant donné et contient au moins une description de l’ensemble des accès courants, c-à-d, de tous les accès qui ont été acceptés et qui n’ont pas encore été relâchés. Ces accès sont donc supposés être effectués simultanément dans le système. L’ensemble des états est noté Σ dans φ(A)).

Une politique de contrôle d’accès permet de spécifier un sous-ensemble de Σ contenant les états sûrs, c-à-d, les états qui vérifient la politique. Afin de déterminer si un état est sûr, les entités du système sont associées à des informations de sécurité :

Ø Le paramètre de sécurité, noté ρ, décrit les informations de sécurité statiques de la politique, c-à-d, les informations de sécurité qui ne changeront pas durant la vie du système.

Ø Les fonctions de sécurité décrivent les informations de sécurité dynamiques de la politique, c-à-d, les informations de sécurité susceptibles d’évoluer durant la vie du système (étant donné un état σ, on note γ(σ) les fonctions de sécurité associées à l’état σ).

A partir des informations dynamiques décrites par un état (ensemble des accès courants et fonctions de sécurité) et des informations statiques du système (paramètre de sécurité), les états sûrs sont caractérisées par un prédicat Ω sur les états. On note Σ|Ω l’ensemble {σ∈Σ|Ω(σ)} des états sûrs.

vii. Modèles de contrôle d’accès

Le modèle de contrôle d’accès permet de spécifier comment passer d’un état du système à un autre.

Requête

La notion de politique de contrôle d'accès introduite à la section précédente permet de spécifier quelles sont les entités du système et quels sont les états sûrs du système. Les transformations des états du système sont dues à un ou plusieurs sujets qui soumettent une ou plusieurs requêtes afin d'accéder aux objets. On note R l'ensemble des requêtes.

Requêtes d’accès En général, on considère deux types de requêtes : [41]



Ø le sujet s demande à exercer une action selon la permission ρ= (x,o), c'est-à-dire selon le mode d'accès x sur l'objet o, notée (+, s, o, x) ;

Ø le sujet s demande d’arrêter une action selon la permission ρ=(x,o), c-à-d selon le mode d’accès x sur l’objet o, notée (-,s,o,x)

On note Racc cet ensemble de requêtes :

Racc ={(+,s,o,x),(-,s,o,x)}

Sémantique

Etant donné l'ensemble R de requêtes, la « signification » de ses éléments doit être spécifiée. En effet, raisonner sur les implantations d'une politique n'a de sens que si l'on dispose d'une sémantique pour les requêtes. Ainsi, la relation :

[R]Σ ⊆ R×Σ

Permet de spécifier la sémantique des requêtes. Etant donnés une requête R et un état σ, l'énoncé (R, σ) ∈ [R]Σ permet de caractériser les propriétés qu'un état σ doit satisfaire quand il est obtenu à partir d'un état en appliquant avec succès la requête R. Par exemple, la sémantique de l'ensemble Racc peut être exprimée de la manière suivante :

((+,s,o,x),σ) ∈ [Racc] ⇔ (s,o,x) ∈ Λ(σ) ((-,s,o,x),σ) ∈ [Racc] ⇔ (s,o,x) ∉ Λ(σ)

Parallèlement la partition suivante de R est introduite :

R = R ∪ R ∪ R

Cette partition permet de spécifier la variation des accès potentiels lors de l'application des requêtes. L'ensemble R (resp. R ) contient les requêtes élargissant (resp. rétrécissant), au sens de l'inclusion, les accès potentiels, tandis que R contient les autres requêtes. Par exemple, si le fait d'appliquer avec succès une requête R appartenant à R à partir d'un état σ conduit à un état σ2 alors on doit avoir W(σ2) ⊆ W(σ1).

Modèles et implantation

Définition (Modèle de contrôle d'accès) Etant donné un paramètre de sécurité p, un modèle de contrôle d'accès M[p] est défini par un couple M[p] = (P[p]; [R]Σ) où P[p] = (S,O,A,Σ,Ω ) est une politique de contrôle d'accès, R est un ensemble de requêtes, et [R]Σ ⊆ R × Σ est une relation spécifiant la sémantique des requêtes. [41]

Implanter un modèle de contrôle d'accès M[p] par une machine abstraite à états consiste à définir un ensemble ΣI d'états initiaux et une fonction de transition τ qui permet de passer d'un état du système à un autre suivant une requête dans R. On peut ainsi donner la définition d'une implantation.



Définition (Implantation) : Une implantation d'un modèle de contrôle d'accès M[p] = (P[p], [R]Σ) basé sur une politique P[p] = (S,O,A,Σ,Ω ) et un couple (τ,ΣI ) où ΣI est un ensemble d'états initiaux et où τ = R × Σ → D × Σ est une fonction de transition avec D = {yes, no}.

On note Гnt(I) (resp. Гt (I)), l'ensemble des états atteignables du système en appliquant n fois (resp.

un nombre fini de fois) la fonction τ depuis un état initial σ appartenant à I. Ainsi, il est possible de définir des propriétés pouvant être satisfaites par une implantation ou une fonction de transition. [41]

5. Les phases d’élaboration d’un système de contrôle d’accès

L’élaboration d’un système de contrôle d’accès s’effectue par une approche multi-phase (ou à phase multiple) basée sur les concepts suivants:

Ø Les politiques de sécurité : elles définissent les règles de haut niveau qui régissent les accès et décident lesquels sont autorisés pour garantir un système sûr.

Ø Les modèles de sécurité : ces modèles décrivent une représentation formelle des politiques de sécurité et de leur fonctionnement.

Ø Les mécanismes de sécurité : les mécanismes définissent les fonctions bas niveau (logiciels et matériels) permettant d’implémenter les contrôles imposés par la politique de sécurité.

Ces trois concepts se rapportent à différents niveaux d’abstraction liés au développement d’un système de contrôle d’accès. D’abord, ceci permet d’aborder les exigences de sécurité indépendamment de leur implémentation et rend possible la comparaison entre différentes politiques de sécurité. Enfin, cela permet de mettre en œuvre des mécanismes implémentant des politiques de sécurité multiples. Ce dernier avantage apporte plus de flexibilité au système de contrôle d’accès. En effet, le mécanisme n’étant pas lié à une politique de sécurité spécifique, le changement de cette dernière n’impose pas le changement de tout le système de contrôle d’accès.

6. Les politiques et modèles de sécurité

Une politique de sécurité doit prendre en considération les règlements qui doivent être appliqués ainsi que les menaces éventuelles.

Les politiques du contrôle d’accès peuvent être groupées en trois principales classes : [36]

Ø Les politiques discrétionnaires (DAC) : les politiques discrétionnaires accordent au propriétaire de l’information, généralement le créateur, tous les droits d’accès ainsi que la possibilité de les propager aux autres selon sa discrétion.

Ø Les politiques obligatoires (MAC) : ces politiques décrètent des règles incontournables qui régissent les droits des sujets et des objets. Elles permettent de restreindre les privilèges que possèdent les sujets sur les objets qui leur appartiennent.

Ø Les politiques basées sur les rôles (RBAC) : ces politiques sont les plus récentes, elles servent à décrire d’une manière plus expressive et plus puissante les fonctionnalités dans les organisations. Les droits d’accès sont accordés aux rôles, tâches dans l’organisation, ils sont attribués aux sujets en fonction des rôles qu’ils jouent.



6.1. Politique discrétionnaire (DAC)

Une politique est dite discrétionnaire si les sujets qui possèdent les objets disposent du droit de passer librement (à leur discrétion) les autorisations qu’ils détiennent sur ces derniers. L’accord ou la révocation des privilèges est régulé par une politique administrative. La gestion des accès aux fichiers du système d’exploitation UNIX constitue un exemple classique de mécanisme de contrôle d’accès basé sur une politique discrétionnaire. Nous exposons par la suite le modèle discrétionnaire le plus connu, il s’agit du modèle de la matrice d’accès. [36]

i. Le modèle Lampson

L’état courant d’un système dans ce modèle est défini par une matrice d’accès et un triplet (S,O,M) représentant les autorisations. Le terme S désigne l’ensemble des sujets, O l’ensemble des objets et M la matrice d’accès.

Chaque cellule M [s,o] de la matrice contient les droits d’accès que possède le sujet s sur l’objet o. Chaque sujet occupe une ligne de la matrice tandis qu’une colonne est assignée à un sujet ou un objet. Les droits d’accès sont lire (read), écrire (write), exécuter (execute), contrôler (control) et posséder (own). Une bannière * (flag) contrôle le transfert des droits d’accès effectué entre les sujets, elle signifie que l’autorisation concernée peut être transférée à d’autres sujets. Un exemple de matrice d’accès est donné dans le tableau 3.1.

La matrice n’étant pas figée celle-ci peut être mise à jour par la création de nouveaux objets ou sujets, par la destruction de ces derniers ainsi que par l’ajout ou la suppression des droits d’accès.

Tableau 3.1 La matrice d’accès du modèle Lampson

ii. Le modèle Graham et Dening

Graham et Dening ont précisé huit commandes qui permettent de mettre à jour la matrice d’accès du modèle Lampson. Ces commandes traitent la création et la destruction des objets par les sujets ainsi que le transfert des autorisations entre les sujets. Ces commandes ainsi que la matrice d’accès forment la pierre angulaire du système de protection établi en définissant les évolutions futures de l’état de la matrice [14].

Fichier 1 Fichier 2 Sujet 3 Processus 1 Ann Bob

*own Read Write read

*read Write *control

Execute

Sujet 3 Read Own control

Execute Read



iii. Le modèle HRU

Dans ce modèle, les auteurs se sont intéressés aux propriétés vérifiées par un système de contrôle d’accès lorsque son état change. Ce changement s’effectue par l’intermédiaire des commandes exécutant des opérations primitives sur les autorisations sous des conditions spécifiées.

La figure 3.1 [15] offre une présentation ces opérations primitives avec leurs conditions d’application ainsi que le nouvel état du système résultant après l’exécution de ces opérations :

Figure 3.1 Les opérations primitives du modèle HRU

Une commande HRU possède une partie conditionnelle facultative ainsi qu’un corps, elle a le format suivant :

command c(x1,…,xk) if a1 in M [s1,o1]

a2 in M [s2,o2] . . an in M [sm,om]

then op1 op2 . . opn

end



Avec n>0, m≥ 0, a1, am sont des autorisations, op1… opn sont des opérations primitives.

Une commande HRU peut ne pas avoir de condition. Le cas échéant m vaut 0.

iv. Les vulnérabilités des politiques discrétionnaires

Dans le cadre de ces politiques, les demandes d’accès aux objets effectués par les utilisateurs ont été vérifiées selon les autorisations de ces derniers. Il est incontestable que toute demande d’accès est due aux actions des utilisateurs. Cependant une analyse plus précise du problème de contrôle d’accès fait surgir l’utilité d’établir la distinction entre sujets et utilisateurs. Le terme utilisateurs désigne des entités passives possédant des autorisations et qui se connectent au système. Un utilisateur connecté au système génère un sujet ou un processus qui effectue à son compte les demandes au système.

Les politiques discrétionnaires ignorent la distinction entre utilisateurs et sujets. Ajoutons à cela le fait qu’elles ne contrôlent pas les flots d’information acquis par un sujet, ce qui peut causer une fuite d’informations pour des sujets non autorisés. Précisément, les politiques discrétionnaires sont vulnérables vis-à-vis des chevaux de Troie qui sont des processus exécutant des fonctions illicites cachées dans des fonctions légitimes.

Exemple le fonctionnement d’un cheval de Troie

Figure 3.2 Un exemple de cheval de Troie

Supposons par exemple que Vicky, un manager de l’entreprise, crée un fichier secret ‘Market’ contenant des informations importantes sur le lancement de nouveaux produits sur le marché. Selon les règlements de l’entreprise, ces informations délicates ne doivent pas être divulguées à une personne autre que Vicky.

Considérons maintenant John, un des subordonnés de Vicky, qui veut s’emparer de ces informations pour les vendre à une entreprise concurrente. Dans ce but, John crée un fichier ‘Stolen’ et accorde à Vicky le droit d’écriture dans ce fichier, celle-ci n’est même pas censée connaître l’existence de ce fichier. John modifie aussi une application généralement utilisée par Vicky pour y inclure deux opérations cachées, une opération lire sur le fichier Market et écrire dans Stolen, il donne ensuite cette nouvelle application à sa manager Vicky. Lorsque Vicky exécute cette



application, les droits d’accès sont vérifiés et en particulier les deux opérations lire et écrire sont autorisées. Par conséquence, durant l’exécution, les informations délicates seront transmises du fichier Market vers le fichier Stolen que John possède.

Nous pouvons bien nous rendre compte de l’importance d’établir la distinction entre sujets et utilisateurs : tandis que Vicky est chargée de préserver la confidentialité des informations qu’elle connaît, le processus exécuté pour son compte ne peut pas avoir le même degré de confiance.

6.2. Les politiques obligatoires (MAC)

Les politiques obligatoires décrètent des règles pour contrôler les flots d’informations, afin de contrer le transfert illégal et les fuites. Ces politiques sont généralement des politiques multi-niveaux basées sur une classification des sujets et des objets imposée par une autorité centrale. [36]

i. Les politiques multi-niveaux

Les politiques multi-niveaux effectuent un classement des sujets et des objets. Elles introduisent la notion de classe d’accès. Une classe d’accès est affectée à chaque sujet et objet. Une relation d’ordre partiel est définie sur l’ensemble des classes d’accès, il s’agit de la relation de dominance symbolisée par ≥ .

Une classe d’accès est formée de deux composants :

Ø Un niveau de sécurité Ø Un ensemble de catégories

Le niveau de sécurité est un élément d’un ensemble totalement ordonné, par exemple top secret (TS), secret (S), confidentiel (C) et non classifié (N) où TS ≥ S ≥ C ≥ N. L’ensemble des catégories décrit les divers domaines des systèmes en étude. Par exemple dans les systèmes militaires, cet ensemble peut contenir les catégories : nucléaire et armée, dans les systèmes commerciaux les catégories sont plutôt : financier, administratif, mercatique …

Etant données deux classes d’accès ac1 et ac2, la relation de dominance ≥ se définit ainsi : ac1 domine ac2 ou ac1 ≥ ac2 si :

Ø le niveau de sécurité de ac1 est plus grand ou égal à celui de ac2 Ø les catégories de ac1 incluent celles de ac2

Formellement cette relation de dominance est définie de la façon suivante :

Soit L, l’ensemble des niveaux de sécurité, muni de la relation d’ordre partiel ≥ et C, un ensemble de catégories, muni de la relation d’ordre partiel ⊇ . Soit l1, l2 deux niveaux et c1, c2 deux catégories tels que l1 ∈L, l2 ∈ L , c1 ∈ C et c2 ∈ C.

∀ ac1 = (l1,c1), ac2 = (l2,c2) : ac1 ≥ ac2 ⇔ l1 ≥ l2 ∧ c1 ⊇ c2.



Deux classes d’accès ac1 et ac2 sont dites incomparables si on ne peut ni vérifier ac1 ≥ ac2, ni ac2 ≥ ac1.

L’ensemble de classes d’accès muni de la relation d’ordre partiel ( ≥ ) possède une borne inférieure et une borne supérieure. La structure de cet ensemble forme un treillis [16]. La figure 3.3 illustre un exemple de treillis de sécurité pour le système militaire [15].

Figure 3.3 Un exemple d’un treillis de sécurité

ii. Les politiques basées sur la confidentialité et le modèle Bell-LaPadula

Ces politiques visent à préserver la confidentialité des données c'est-à-dire que celles-ci ne sont accessibles que pour les utilisateurs autorisés.

Pour maintenir la confidentialité, des restrictions sont à imposer sur les opérations de lecture et d’écriture, qui permettent de transférer des informations. Ces restrictions se traduisent par les deux principes suivants :

Ø No read up : Un sujet ne peut lire un objet que si la classe d’accès du sujet domine celle de l’objet (un sujet ne doit pas apprendre des informations qui ne lui sont pas autorisées).

Ø No write down : Un sujet ne peut écrire dans un objet que si la classe d’accès de l’objet domine celle du sujet (un sujet ne doit pas révéler des secrets).

Dans le cadre de ces politiques, le niveau de sécurité ou classification associé à un objet reflète l’importance des informations qu’il contient ainsi que le danger causé par la divulgation de celles-ci. Le niveau de sécurité associé à un sujet, appelé aussi autorisation, est un moyen de représenter la confiance qui lui est accordée.

Les utilisateurs se connectent au système à une classe d’accès quelconque dominée par leurs autorisations et génèrent des sujets appartenant à cette classe d’accès. Par exemple, un utilisateur possédant l’autorisation (TS,{Nuclear}) peut se connecter au système en tant que (TS,{Nuclear}), (S,{Nuclear}), (TS,Ø) ou (S,Ø). Les demandes d’accès d’un sujet à un objet sont contrôlées selon les relations de dominance entre les classes d’accès correspondantes.

La satisfaction des deux principes (No read up, No write down) empêche les flots d’informations de se propager d’un niveau de sécurité élevé vers d’autres niveaux de sécurité plus bas.



Montrons comment travaille un cheval de Troie (exemple précédent). Considérons les niveaux de sécurité suivants : Secret pour Vicky et son fichier Market et non classifié pour John et son fichier Stolen. Si Vicky se connecte au système au niveau Secret ou Confidentiel, le sujet ou l’application va être exécuté à un niveau Secret ou Confidentiel et l’opération d’écriture dans Stolen sera bloquée selon le principe No write down. Si Vicky se connecte au système en tant que sujet non classifié et exécute l’application à ce niveau, l’opération de lecture dans le fichier Market sera bloquée selon le principe No read up.

a. Le modèle Bell-LaPadula

Le modèle Bell-Lapadula décrit formellement les contrôles d’accès pour préserver la confidentialité.

Ce modèle a été proposé pour la première fois par David Bell et Leonard Lapadula en 1973 [17]. Par la suite, différentes variantes ont été élaborées pour la prise en compte de nouvelles propriétés [17] et aussi pour adapter ce modèle à d’autres environnements spécifiques [20].

A travers ce modèle, les auteurs tracent une définition formelle des concepts d’une sécurité militaire applicable dans les systèmes informatiques. Le modèle est fondé sur la notion de treillis, il utilise aussi une matrice d’accès identique à celle du modèle HRU pour présenter les autorisations auxquelles s’ajoutent les niveaux de sécurité d’un système militaire.

Selon Bell et Lapadula, le système est composé d’un ensemble de sujets S, d’un ensemble d’objets O, d’un ensemble d’autorisations A (lire et écrire) et d’un ensemble de classification I ( des classes d’accès ). A un moment donné, l’état d’un système est exprimé par un ensemble formé de trois composants qui sont :

Ø L’ensemble des accès courants d’un sujet sur un objet noté b. Un accès courant est représenté par un triplet (s, o, a) signifiant que le sujet « s » possède l’accès courant « a » sur l’objet « o » dans un état du système.

Ø La matrice d’accès M (la même que celle du modèle HRU) formée de i lignes et j colonnes. Chaque cellule Mij enregistre les modes d’accès que possède le sujet si sur l’objet oj. Ainsi, les entrées de M sont des sous-ensembles de l’ensemble des accès possibles A.

Ø La fonction λ : S ∪ O → I qui appliquée aux sujets et aux objets retourne la classification de ces derniers.

L’état du système est ainsi représenté par un triplet (b, M,λ ).

La description formelle des deux principes No read up et No write down se traduit par les axiomes suivants :

Ø Propriété simple : Un sujet s ne peut lire un objet o que si son autorisation domine la classification de l’objet : ∀ s ∈ S, o ∈ O : (s, o, lire) ∈b ⇒ λ (s) ≥ λ (o).

Ø Propriété étoile : Un sujet s ne peut écrire (écrire est utilisée pour signifier écriture seule ou ajout) dans un objet o que si la classification de l’objet domine l’autorisation du sujet : ∀s ∈ S, o ∈ O : (s, o, écrire) ∈b ⇒ λ (o) ≥ λ (s).



Les auteurs précisent cependant que la propriété "étoile" ne s’applique pas aux sujets de confiance « trusted subjects », ceux-ci étant des sujets qui, pour des raisons de bon fonctionnement de l’organisation, sont autorisés à violer les restrictions imposées.

Une autre propriété doit être vérifiée, c’est la propriété discrétionnaire dénotée ds-property qui stipule que tous les accès courants des sujets aux objets sont des éléments de la matrice d’accès Mij : ∀ (si, oj, a) ∈b⇒ a ∈ Mij (avec a ∈A).

Les auteurs formalisent un théorème qui annonce que la sécurité d’un système peut être garantie systématiquement si, pour tout ajout d’un triplet (sujet, objet, accès) dans l’ensemble b, les trois propriétés évoquées ci-dessus sont vérifiées. Ce théorème est appelé le théorème basique de sécurité (BST : Basic Security Theorem).

Un état du système symbolisé par v ∈ V, où V est l’ensemble des états, est défini par un triplet (b, M, λ ). L’état initial du système est noté v0. L’état du système change suite à l’ensemble des demandes. Celles-ci peuvent référer à des acquisitions ou des libérations d’accès, des ajouts ou des suppressions d’autorisations ainsi qu’aux changements de classification des sujets et des objets. La fonction de transition T fait parvenir le système d’un état vers un autre, elle est définie de la manière suivante T : V×R → V où R représente l’ensemble des demandes effectuées par les sujets.

iii. Les politiques basées sur l’intégrité et le modèle Biba

Maintenir l’intégrité des données est nécessaire afin de garantir qu’aucun sujet de niveau inférieur ne puisse modifier indirectement des objets appartenant à un niveau supérieur. Ken Biba [21] propose une politique duale de celle de Bell et Lapadula pour assurer l’intégrité.

Chaque sujet et objet possèdent une classification d’intégrité. Le niveau d’intégrité est un élément d’un ensemble totalement ordonné ; par exemple Crucial (C), Important (I) et Non classifié (N). Le niveau d’intégrité associé à un sujet reflète la confiance qui lui est accordée concernant la modification, l’ajout ou la suppression des données. Pour un objet cette classification d’intégrité est un moyen de représenter le danger que peut constituer la modification de l’information contenue dans ce dernier.

Le contrôle d’accès est imposé par deux principes :

Ø No read down : un sujet peut lire un objet si la classe d’accès de l’objet domine celle du sujet.

Ø No write up : un sujet peut écrire dans un objet si la classe d’accès du sujet domine celle de l’objet.

La satisfaction de ces deux principes empêche la circulation des informations des sujets ou objets de niveau d’intégrité inférieur (moins fiable) vers des sujets ou objets de niveau d’intégrité plus élevé. Ces deux principes étant trop restrictifs, Biba propose un alternative plus flexible pour préserver l’intégrité :



Low water mark pour les sujets : Ce principe vise à contraindre l’opération d’écriture selon le principe No write up. Un sujet peut lire des objets appartenant à un niveau inférieur au sien, mais par conséquence, son niveau d’intégrité diminue vers la borne inférieure de son niveau d’intégrité et de celui de l’objet : λ ’(s) = inf( λ (s), λ (o)).

Low water mark pour les objets : Ce principe vise à contraindre l’opération de lecture selon le principe No read down. Un sujet peut écrire dans un objet de niveau inférieur, mais par conséquence, le niveau d’intégrité de l’objet modifié diminue vers la borne inférieure de son niveau d’intégrité et de celui de l’objet : λ ’(o) = inf ( λ (s), λ (o)).

iv. Les vulnérabilités des MAC

Les politiques obligatoires peuvent être contrées (ou détournées) par les canaux cachés. Ces derniers sont des canaux non désignés pour la communication normale mais qui peuvent être exploités pour transférer des informations.

D’une manière générale, on distingue deux types de canaux cachés : les canaux de mémoire et les canaux temporels. Les canaux de mémoire sont des moyens de mémorisation partagés entre des utilisateurs d’habilitations différentes tels que la mémoire partagée, le partage des fichiers, etc. Les canaux temporels sont par contre difficiles à identifier et analyser. En effet la seule existence d’une ressource matérielle (unité centrale, mémoire, etc.) ou logicielle (verrou, sémaphore, etc.) partagée entre des utilisateurs d’habilitations différentes et d’une horloge commune, suffit pour créer un canal temporel par la modulation de l’usage de la ressource.

Pour illustrer comment les canaux cachés peuvent causer des fuites d’informations, nous considérons la demande effectuée par un sujet d’un niveau spécifique pour écrire dans un fichier non existant d’un niveau plus élevé. L’opération est légitime, selon le principe No Write down. Dès lors, deux comportements systèmes sont à traiter : si le système renvoie une erreur, alors, il risque d’être exploité par des fuites malicieuses dues aux processus haut niveau, créant et détruisant des fichiers pour signaler des informations aux processus de niveau plus bas. Si le système n’informe pas le sujet de bas niveau de l’erreur, celui-ci ne saura pas les erreurs possibles dues à des essais légitimes de tentatives d’écriture (exemple : les erreurs de frappe).

L’analyse des canaux cachés est souvent reportée à la phase d’implémentation. Plusieurs techniques sont utilisées, étudier les traces des flux d’informations dans les programmes [16], vérifier les ressources communes dans un programme susceptibles d’être utilisées pour le transfert d’informations, vérifier l’horloge du système pour les canaux temporels. Par ailleurs, les politiques de contrôle d’interfaces spécifient des restrictions sur les entrées et les sorties du système qui doivent être satisfaites pour se préserver contre les canaux cachés, nous ne les traitons pas dans le cadre de notre étude. Le concept de base pour ce type de politiques est le principe de non-interférence proposé par Goguen et Meseguer [22] qui stipule que les entrées d’un niveau haut ne doivent pas interférer avec les sorties d’un niveau plus bas.



6.3. Les politiques et les modèles basés sur les rôles

Le modèle RBAC est principalement issu d’Internet afin de prendre en compte des applications déployées sur de vastes organisations ou des applications inter-organisations (Extranet par exemple) [23]. Cependant, ce n’est que dans les années 1990 que RBAC fait son apparition en tant que modèle assez mûr à l’instar des traditionnels MAC et DAC. [36]

En effet, les politiques obligatoires et notamment les politiques multi-niveaux sont trop contraignantes pour les systèmes informatiques des organisations, et leur utilisation est généralement limitée au domaine militaire. Les politiques discrétionnaires, quant à elles, confient les autorisations sur les objets à la discrétion de leurs possesseurs. Cependant, dans la plupart des organisations, les utilisateurs finaux d’une information n’en sont pas généralement les propriétaires et le contrôle d’accès est plutôt relatif aux fonctions et aux responsabilités des employés (leurs rôles). D’où l’avènement de l’idée de base de RBAC : il s’agit d’intercaler des rôles entre les utilisateurs et les permissions. D’un côté des permissions sont accordées aux rôles, de l’autre, les utilisateurs se voient affecter un ou plusieurs rôles. Ils obtiennent ainsi les permissions accordées aux rôles qu’ils jouent [24].

La figure 3.4 illustre le modèle RBAC tel qu’il est proposé par NIST [25].

Figure 3.4 Le modèle RBAC

Les concepts utilisés dans le modèle RBAC sont:

Les utilisateurs (USERS) : Ce terme fait en général référence à un être humain mais il peut aussi désigner des machines, networks ou des agents intelligents.

Les rôles (ROLES) : Un rôle est une fonction d’un emploi dans une organisation faisant allusion aux autorités et aux responsabilités accordés aux utilisateurs.

Les opérations (OPS) : une opération représente l’image exécutable d’un programme. L’appel de cette dernière exécute des fonctions pour l’utilisateur. Par exemple, dans la protection d’un système de fichiers les opérations peuvent être lire, écrire, exécuter ; dans un système de gestion de bases de données, les opérations sont : insérer, supprimer, ajouter et mettre à jour. Les permissions symbolisées par PRMS sont matérialisées par des opérations effectuées sur les objets.



PRMS ⊆ OPS ×OBS. Comme le montre la figure, les utilisateurs sont assignés à des rôles via la relation UA / UA ⊆ USERS × ROLES.

Le côté dynamique du modèle est matérialisé par la notion de session. Une session est attribuée à un utilisateur qui, en l’activant, exerce un ou un ensemble de rôles qu’il assume. Un utilisateur peut ouvrir plusieurs sessions en même temps, cependant à un instant donné, un utilisateur exerce un seul rôle. C’est la notion de rôle actif. Le contrôle d’accès se déroule au cours d’une session. Un utilisateur a le droit d’exécuter sur les objets les seules opérations que son rôle activé lui autorise.

a. L’hiérarchie des rôles

Le concept d’hiérarchie est introduit entre les rôles. Il reflète la hiérarchie naturelle qui existe dans l’entreprise. Cette hiérarchie a été décrite dans [26] en terme de permissions : un rôle r1 hérite du rôle r2 si toutes les permissions de r2 sont aussi des permissions pour r1. Les auteurs [25] mettent en exergue l’existence de deux types de hiérarchie : la hiérarchie générale des rôles et la hiérarchie limitée.

Ø La hiérarchie générale : RH ⊆ ROLES × ROLES définit un ordre partiel sur l’ensemble des rôles, symbolisé par ≥ . Elle intègre aussi le concept de l’héritage multiple. Etant donnés deux rôles r1 et r2 : r1 ≥ r2 ⇒ authorized-permissions (r2) ⊆authorized-permissions (r1) ∧ authorized-users (r1) ⊆ authorized-users (r2), avec authorized-users (r)={u∈USERS,(u,r)∈UA} (r étant un rôle) et authorizedpermissions (r) = { p ∈ PRMS, ( p,r) ∈PA} ( p étant une permission) .

Ø La hiérarchie limitée se base sur les mêmes principes que l’hiérarchie génerale, cependant elle ne supporte pas l’héritage multiple, ceci est traduit formellement par la contrainte suivante :

∀ r, r1, r3 ∈ ROLES, r ≥ r1 ∧ r ≥ r2 ⇒ r1 = r2.

b. Les contraintes dans RBAC

Ultérieurement, la notion de séparation de tâches a été ajoutée dans le modèle RBAC. Celle-ci stipule qu’aucun utilisateur ne possède assez de privilèges pour abuser seul du système, afin d’assurer que les fraudes et les erreurs majeures ne peuvent avoir lieu que par une collaboration préméditée de plusieurs utilisateurs. Au sein des organisations, ceci se traduit par le fait d’empêcher l’utilisateur de jouer des rôles conflictuels ou aussi de restreindre le nombre de rôles associés aux utilisateurs d’une façon statique ou dynamique.

Les auteurs dans [25] distinguent deux types de séparation de tâches. La séparation statique (SSD) et la séparation dynamique (DSD), la première définit les rôles conflictuels ne pouvant pas être attribués à un même utilisateur. La seconde impose ce contrôle dynamiquement par une contrainte sur les rôles lors de l’activation d’une session donnée. Par ailleurs, les auteurs [25] définissent aussi des fonctions administratives qui assurent la création et la maintenance des divers éléments et relations du modèle proposé.



c. Les atouts du RBAC

L’approche d’un contrôle d’accès basé sur les rôles présente des avantages incontestables sur différents plans :

Ø L’administration des autorisations : celle-ci s’effectue en deux étapes : Ø L’attribution des rôles aux utilisateurs Ø L’allocation des autorisations aux rôles pour permettre l’accès aux objets.

Ceci facilite l’administration de la politique de sécurité dans l’entreprise et la rend plus adaptée aux fluctuations occurrentes. Par exemple, quand un nouvel utilisateur rejoint l’entreprise, l’administrateur doit uniquement lui affecter les rôles correspondants à son emploi ; quand la fonction d’un utilisateur change, l’administrateur doit modifier les rôles qui lui sont associés. Lorsqu’un nouvel emploi est crée dans l’organisation, l’administrateur doit uniquement décider quels rôles sont aptes à l’exécuter.

Ø La hiérarchie des rôles pour mieux s’adapter à l’organisation hiérarchique des entreprises.

Ø Le concept du moindre privilège : ce concept stipule que les utilisateurs sont assignés aux seuls rôles nécessaires pour assumer leurs tâches. Dans RBAC ceci se manifeste de la façon suivante : les utilisateurs peuvent choisir les rôles qu’ils souhaitent activer. Ainsi, ceux qui détiennent des rôles puissants ne les activent que dans les cas de nécessités ; ceci minimise les dégâts causés par les chevaux de Troie et les intrusions.

Ø La séparation des tâches et la spécification des contraintes qui permettent d’affermir la sécurité des systèmes.

Ø RBAC peut englober les traditionnels DAC et MAC par une construction systématique.

d. Les critiques du RBAC

RBAC a été critiqué dans [24] pour les raisons suivantes :

Ø L’absence de structure générique de permissions. Celles-ci sont considérées comme dépendantes de l’application concrète du modèle.

Ø Le concept de hiérarchie de rôle est quelque peu ambigu. En général, la hiérarchie des rôles ne correspond pas tout à fait à la hiérarchie organisationnelle. Par exemple, le directeur de l’hôpital a un rôle administratif supérieur au rôle de médecin. Pour autant, un directeur de l’hôpital n’est pas nécessairement un médecin, ainsi il n’est pas faisable d’accorder au directeur les permissions du médecin.

Ø La distinction entre le concept de rôle et celui de groupe est floue. Ø L’impossibilité d’exprimer des permissions et notamment des permissions qui

dépendent du contexte. Par conséquent, il serait difficile de spécifier qu’un médecin n’a la permission d’accéder au dossier médical d’un patient que si ce dernier est son patient.



Pour faire face aux limites de RBAC, un modèle ORBAC (Organisation Based Access Control) a été proposé [24]. Ce modèle étend le modèle RBAC et attribue les permissions, obligations, recommandations et interdictions pour réaliser des activités à un rôle dans une organisation, sur un groupe d’objets dans un contexte donné [27]. La motivation était de sécuriser les systèmes d’information et de communication dans le domaine de santé.

Sachant que le but ultime de la spécification des politiques de sécurité est que celles-ci soient vérifiées, nous présentons, dans la section suivante, les mécanismes d’implémentation des politiques de sécurité où nous abordons les deux techniques de vérification statique et dynamique.

7. Conclusion

Dans ce chapitre, nous avons abordé la politique de sécurité qui sera la base de notre travail (chapitre 5). Par cette étude, on comprend l’enjeu de l’utilisation de la politique de sécurité pour la réalisation de systèmes sécurisés, et le risque encouru suite à l’adoption d’une mauvaise politique de sécurité, voire la non-utilisation de la politique de sécurité.


Chapitre IV Modélisation formelle

I. La modélisation formelle

1. Introduction

Les spécifications formelles ont une importance majeure dans les sciences informatiques. Commençant par Turing dans les années quarante. A la fin des années soixante, Floyd, Hoare et Naur ont introduit la notion de spécification. Ce fut le point de départ d'un tout nouveau domaine de recherche visant à la spécification-in-the-large. L'intérêt des spécifications formelles et de leurs multiples applications dans le génie logiciel a connu une croissance continue depuis ce moment-là.

2. Méthodologie formelle de développement

Une démarche standard de développement vise, en partant d’un cahier des charges informel, à la production d’un système en passant par plusieurs étapes intermédiaires, telles que la décomposition en modules, la conception, etc. Entre deux étapes, une démarche standard préconise également une ou plusieurs formes de vérification permettant de s’assurer que les produits de l’étape sont conformes à ce qui est attendu – par exemple sous la forme de documents justificatifs, de relectures croisées, ou de tests.

Une méthodologie formelle de développement respecte ce schéma général, en proposant des étapes et des opérations de vérification basées sur des formalismes logiques et mathématiques rigoureux rendus exploitables par l’utilisation de langages dont la sémantique est explicite, claire et non ambiguë, permettant notamment d’éviter les problèmes d’interprétation.

A partir du cahier des charges, la première étape consiste généralement à écrire une spécification formelle décrivant ce que le système doit faire et garantir. Cette spécification est idéalement déclarative, abstraite, non constructive et non effective – elle se limite à une description du quoi. Elle constitue déjà un objet susceptible d’analyse formelle, puisqu’il est par exemple possible d’en étudier, au moins partiellement, la cohérence.

La méthodologie formelle de développement peut ensuite permettre de décrire la conception voire l’implémentation – i.e. la description du comment. Ici encore la formalisation de la sémantique du langage de développement permet des analyses locales relatives notamment à la cohérence, mais aussi des analyses globales de respect des propriétés spécifiées.

Résumé Le développement de notre travail est accompli par une modélisation formelle, alors dans ce chapitre nous faisons une étude de deux notions fondamentales utilisées dans tout le cycle de développement. Dans la première partie, nous avons élaboré une synthèse sur la modélisation formelle de la méthodologie à la logique théorique et dans la deuxième partie les notions fondamentales du langage B



L’utilisation d’une méthodologie formelle de développement doit reposer sur l’utilisation d’un ensemble d’outils constituant une implémentation de la méthode formelle. Bien qu’il soit envisageable de mener l’ensemble des vérifications à la main, dans la pratique seul l’emploi d’un outil formel qui effectue des validations de manière mécanique apporte un niveau de confiance satisfaisant. [35]

3. Méthodes formelles

Une méthode formelle au sens le plus large est une méthode d’ingénierie pour le développement de systèmes (de logiciels) basée sur des concepts logiques et mathématiques rigoureux et bien identifiés. Une méthode formelle définit généralement un ou plusieurs langages (pour la spécification, le développement, etc.) non ambigus et des principes de raisonnement explicites, justifiés et vérifiables.

Le spectre des méthodes formelles est large. On peut considérer qu’il va des systèmes de typage totalement automatisés aux méthodes imposant de prouver (manuellement) qu’une implémentation proposée respecte les propriétés exigées par la spécification, en passant par l’analyse statique ou encore le Model Checking.

La mise en œuvre de méthodes formelles dans le cadre de la sécurité des systèmes d’information se justifie par la possibilité de garantir qu’un système respecte certaines propriétés attendues. Le choix d’une méthodologie formelle dans un contexte donné dépend des objectifs fixés. Une analyse d’adéquation doit donc être menée au préalable, en prenant par exemple en compte :

Ø la fidélité, i.e. la relation entre la modélisation de l’objet de l’analyse formelle et le système réel,

Ø l’expressivité, i.e. le type de propriétés pouvant être formellement décrites et analysées, Ø la portée, i.e. les étapes du cycle de développement pouvant être couvertes, Ø la simplicité, Ø l’efficacité, i.e. la disponibilité d’outils offrant plus ou moins d’automatisation.

Dans les méthodes formelles considérées, le langage de spécification est généralement un langage logique, permettant de décrire des propositions construites à partir de prédicats, de quantificateurs et d’opérateurs logiques. [35]

4. Evaluation de la confiance

L’emploi d’une méthodologie formelle de développement permet d’envisager de produire un code dont il est prouvé qu’il est conforme à sa spécification. Une telle preuve est une contribution extrêmement importante à la confiance que l’on peut avoir dans le résultat du développement, notamment en raison de son caractère exhaustif.

Pourtant, malgré le caractère absolu d’une preuve formelle, on ne peut généralement pas en déduire que le système réel vérifiera forcément et inconditionnellement les propriétés attendues.



5. Pratiques de développement

Malgré les garanties données par l’utilisation des méthodes formelles, les développeurs doivent continuer à appliquer les pratiques standards du développement ; l’existence de garanties sous la forme de preuves formelles ne justifie pas la disparition de la documentation, le manque de commentaires, l’absence de règles de nommage ou encore une modularisation inadaptée.

Plus particulièrement, la problématique du choix entre une approche offensive et une approche défensive de la programmation doit être considérée avec attention.

Les méthodes formelles peuvent en effet permettre de justifier l’élimination d’un certain nombre de vérifications ; lorsqu’il est possible de démontrer qu’elles sont inutiles (redondantes) par construction. Le style de programmation peut donc évoluer d’une approche défensive vers une approche offensive ; la validité des valeurs manipulées n’est plus testée mais supposée (sous la forme de pré-conditions).

6. Maîtrise de la méthode formelle

Les méthodes formelles reposent sur des concepts et des théories qui, sans être obligatoirement complexes, ne sont pas nécessairement maîtrisés ou mêmes connus par les utilisateurs. L’existence d’outils automatisant les processus et offrant des interfaces homme-machine peut en effet masquer les aspects les plus abstraits. Une compréhension partielle de la théorie d’une méthode formelle, ou du fonctionnement des outils formels associés, peut cependant mener à des erreurs d’interprétation ayant des conséquences potentiellement graves.

Notion d’invariant

Il est fréquent dans une méthode formelle d’utiliser la notion d’invariant, censée décrire une propriété vraie à tout instant de la vie d’un système ou de l’exécution d’un logiciel – tout au moins sous certaines hypothèses d’environnement. Pourtant, la définition exacte d’un invariant est généralement subtilement différente, puisqu’il correspond à une propriété qui n’est vraie qu’à des instants pertinents du point de vue de la méthode formelle employée.

De fait, les états transitoires ne sont généralement pas considérés, ni le temps d’exécution d’un programme ; le B ne garantit que la préservation d’un invariant après la réalisation totale d’une opération (et sous l’hypothèse que l’invariant était vrai avant l’appel de l’opération).

Exemple (Spécification d’un sas en B) On spécifie les commandes d’ouverture et de fermeture des deux portes d’un sas de sous-marin en cherchant à garantir qu’à tout instant, au plus une porte est ouverte. L’état du système est décrit par deux variables, pe pour la porte externe et pi pour la porte interne.

N.B: le symbole égal (=) surmonté d’un chapeau est remplacé par le symbole ⌂.



Cette spécification est cohérente, au sens où elle assure le respect de l’invariant. Pourtant, elle ne permet pas d’assurer la propriété recherchée, en raison de la sémantique associée à la notion d’invariant. En effet, l’invariant est seulement une propriété qui doit être vraie à l’initialisation du système, et maintenue par l’exécution (totale) d’une opération. En particulier l’invariant peut être faux pendant les états transitoires. Ainsi, le raffinement suivant est tout à fait valide:

Ou wait est une commande passive (sans effet sur l’état) mais dont le temps d’exécution est non négligeable, et attack une condition arbitrairement compliquée sur laquelle l’attaquant peut agir à sa guise. Il est donc possible d’implémenter la spécification Sas sous la forme d’un système qui ouvre les deux portes simultanément pendant plusieurs secondes, tout en masquant ce comportement pendant des tests.

MACHINE Sas VARIABLE pe, pi INVARIANT pe, pi ∈{ouvert, fermé} ¬∧ (pi = ouvert pe = ouvert) OPERATION

Ouvree ⌂ IF pi = fermé THEN Pe := ouvert

Fermée ⌂ pe := fermé Ouvrei ⌂

IF pe = fermé THEN pi := ouvert Ferméi ⌂ pi := fermé

REFINEMENT Sasref REFINES Sas VARIABLE

pe, pi INVARIANT

pe, pi {ouvert, fermé} (pi = ouvert pe = ouvert) OPERATION

Ouvree ⌂ IF pi = fermé attack THEN

pi := ouvert ; pe := ouvert ; wait ; pi := fermé Fermée ⌂ pe := fermé Ouvrei ⌂

IF pe = fermé THEN pi := ouvert

Fermei ⌂ pi := fermé



Hypothèses implicites

Un autre problème qui peut se poser est celui de la méconnaissance de la sémantique de certaines constructions formelles, ou encore des hypothèses générales mais implicites. Cette méconnaissance peut se traduire par des spécifications qui, bien qu’en apparence cohérentes, deviennent incohérentes lorsque combinées avec les hypothèses implicites.

Comme souvent, l’incohérence d’une spécification n’est pas évidente à détecter, et si elle n’est pas activement recherchée elle peut même se révéler en pratique confortable puisqu’elle permet de prouver tout résultat attendu en utilisant des raisonnements par l’absurde.

7. Théorème de la logique Cohérence de la logique

La problématique de la cohérence de la théorie est relative à une forme de correction de la syntaxe et de la sémantique d’une logique. L’un des problèmes possibles est l’existence d’un paradoxe qui permet de prouver et de réfuter une proposition donnée. Si un tel paradoxe existe, il conduit à une forme d’effondrement, puisqu’il permet de prouver toute proposition.

Cette question devrait être abordée lors de l’évaluation, mais elle est difficile. L’étude de la cohérence d’une logique non triviale ne pouvant être réalisée que dans une méta-logique.

La solution pratique, dans le cadre du développement d’un produit de sécurité, consiste à se reposer sur les travaux académiques qui ont pu être réalisés à ce sujet, ou tout au moins à admettre la cohérence de la logique d’une méthode formelle dès lors que celle-ci est reconnue par la communauté scientifique et réputée de confiance. Cette approche n’est cependant possible que pour des méthodes éprouvées ; l’utilisation d’une méthode formelle moins connue ou moins ancienne nécessite de se poser la question de la cohérence. [35]

Correction des résultats logiques

Au delà de la cohérence de l’association de la syntaxe et des règles fondamentales de déduction, la théorie logique associée à la méthode formelle peut présenter d’autres problèmes.

Par exemple, un certain nombre de résultats peuvent être présentés comme des théorèmes découlant de ces règles primitives, l’ensemble de ces théorèmes formant une bibliothèque de méthodes de preuve. Ces résultats peuvent être utiles pour proposer des règles de raisonnement plus efficaces et être promus au statut de principes fondamentaux utilisés par exemple pour mener des preuves. Il convient de vérifier la preuve de ces résultats, qui ne doivent en aucun cas être admis.

En effet, l’introduction d’un principe de raisonnement présenté comme un théorème de la logique, mais en réalité non prouvable, se traduit par l’enrichissement de la logique avec de nouvelles règles de déduction, au risque de la rendre incohérente. [35]



Cohérence des sémantiques

Une méthode formelle permet de manipuler, selon des règles mathématiques précises et explicites, des entités abstraites qui représentent parfois certains objets ayant une réalité physique. De fait, la sémantique donnée à une entité abstraite doit être cohérente avec la sémantique de l’objet concret qui lui est associé. Ce problème peut se poser lors d’un développement, lorsque des choix de modélisation de la réalité sont faits, mais aussi de manière plus fondamentale dans la théorie d’une méthode formelle.

Par exemple, certaines méthodes formelles proposent un langage de programmation. Les programmes écrits dans ce langage sont des entités abstraites susceptibles d’analyses (par exemple pour vérifier la conformité à une spécification) et ont donc une sémantique logique. Mais ce sont également des objets concrets qui ont vocation à s’exécuter sur un ordinateur, et ont une sémantique opérationnelle. La cohérence de ces deux sémantiques devrait également être vérifiée.

II. Le langage B

1. Introduction

Le besoin de la modélisation formelle est un besoin de vérification approuvé par des preuves, n’importe quel processus de modélisation formelle est un processus incomplet s’il n’utilise pas de méthode formelle. L'utilisation des méthodes formelles pour la sécurité des systèmes s'est développée ces dernières années de manière très importante, grâce notamment aux nouveaux problèmes de sécurité posés par le développement de l'Internet et du commerce électronique. Dans ce chapitre on va donner un aperçu sur l’une de ces méthodes qui est la méthode B.

La méthode B a été inventée par Jean-Raymond ABRIAL, à partir des travaux de E.W.DIJKSTRA et de C.A.R.HOARE. Le langage B est une évolution du langage Z, adapté à une utilisation industrielle, et à l'ensemble du cycle de développement. Le langage B est fondé sur les concepts mathématiques de la théorie des ensembles.

The B Book (de J.R. ABRIAL, paru en 1996 chez Cambridge University Press) est l'ouvrage de référence sur B. Son sous-titre "Assigning Programs to Meanings" reflète le principe fondamental de B : le logiciel est réalisé à partir de sa sémantique ; il est correct par construction.

La méthode B utilise un langage pour la spécification fondé sur la logique du premier ordre, appelé aussi langage de substitutions généralisées. Elle s’appuie aussi sur des concepts mathématiques de la théorie des ensembles. Un processus de développement en B s’effectue en plusieurs étapes pour accompagner au fur et à mesure la construction du système. Une première spécification abstraite sera ensuite raffinée progressivement jusqu’à aboutir à une spécification déterministe.



2. Le langage de substitution généralisé

Dans une machine B, une substitution est un moyen de représenter une transition. L’état d’une machine B est représenté par les variables qui sont typées dans l’invariant. Les substitutions font passer une machine B d’un état initial pré en un autre état post. Les substitutions en B sont utilisées comme les instructions des langages de programmation. Les substitutions peuvent être considérées comme des transformateurs de prédicats qui portent sur les variables d’état de la machine considérée. Etant donné une substitution S, la transformation d’un prédicat P en un prédicat Q s’écrit de la façon suivante : Q = [S]P qui selon E. W. Djkstra détermine pour une postcondition R et une instruction donnée S, la plus faible pré- condition P qui assure que S termine et que R est vraie après S. La notation [S]P se lit " la substitution S établit le prédicat P ".

En B, des notations verbeuses sont introduites pour faciliter la lecture et introduire des abréviations. Elles sont présentées dans le tableau suivant : [36]



Substitution Notation en B P | S PRE P THEN S END P ==> S SELECT P THEN S END S [] T CHOICE S OR T END @z.S VAR z IN S END W(P, S, J, V)

S

WHILE P DO S

INVARIANT J VARIANT V

END

BEGIN S END P| S==>S ASSERT P THEN S END P==>S [] ¬ P==>T IF P THEN S ELSE T END S[]T[]…[]U CHOICE S OR T … OR U END @z.( P==>S) ANY z WHERE P THEN S END ANY x,…,y WHERE

x=E Ÿ…Ÿy=F

THEN

S

END

LET x,…,y BE

x=E ∧ … ∧ y=F

IN

S

END ANY x’ WHERE x’ ∈E THEN x:=x’ END x : ∈ E ANY x’ WHERE [x$0,x:=x,x’]P THEN x:=x’ END x: P

IF P THEN x:=TRUE ELSE x:=FALSE END x:=bool(P)

f:=f <+ {x |->E} f(x):=E

Tableau 4.1 Les notations en B

3. Machine abstraite [36,37]

Une machine abstraite est la brique de base d’un modèle B. Elle possède des données (appelées variables) et des services (opérations) qui permettent de manipuler ces données encapsulées. Une machine B représente l’abstraction de l’état du système. Cet état est représenté par les variables qui sont typées par des expressions mathématiques ensemblistes dans la clause INVARIANT. Celle-ci contient aussi les propriétés, que les variables doivent vérifier, exprimées au moyen de prédicats en logique du premier ordre. L’initialisation et les opérations sont décrites à l’aide du langage des substitutions généralisées. Les substitutions font passer une machine B d’un état initial pré en un



autre état post. Elles sont utilisées comme les instructions des langages de programmation. Nous présentons par la suite l’architecture d’une machine abstraite B.

Figure 4.1 L’architecture d’une machine abstraite en B

La partie statique de la machine correspond aux déclarations de variables, cependant nous tenons à signaler que les variables en B représentent n’importe quel objet mathématique appartenant à la théorie des ensembles que ce soit des ensembles, des relations, des fonctions ou des suites.

La partie dynamique du système est représentée à travers des opérations effectuant les descriptions d’évolutions du système modélisé. L’initialisation et le corps des opérations matérialisent ces transitions. Le principe d’encapsulation est respecté ; les variables de la machine ne peuvent être modifiées que par l’intermédiaire des opérations.

Les principales clauses d’une machine B sont :

Ø Clause CONSTRAINTS : elle permet de typer les paramètres de la machine, et d’exprimer des propriétés, appelées contraintes, sur ces derniers.

Ø Clause SETS : elle permet de définir des ensembles soit de manière différée, par la simple déclaration de leurs noms via un identifiant, soit en énumérant les éléments qui les composent.

Ø Clause ASSERTIONS : les assertions sont des prédicats qui sont des conséquences logiques des autres axiomes et de l’invariant. Elles sont des lemmes utiles pour les preuves.

MACHINE Partie entête nom de la machine paramètres de la machine → liste de noms CONSTRAINTS contraintes sur les paramètres → prédicats du premier ordre Partie statique SETS déclaration d’ensembles → liste de noms CONSTANTS déclaration de costantes → liste de noms PROPERTIES propriétés des constantes → prédicats du premier ordre VARIABLES variables (état) → liste de noms INVARIANT invariant (caractérisation de l’état) → prédicats du premier ordre ASSERTIONS assertions supplémentaires → prédicats du premier ordre Partie dynamique INITIALISATION initialisation de l’état → substitutions généralisées OPERATIONS Opérations → substitutions généralisées END



Ø Clause CONSTANTS : les constantes sont des données immuables, en B il est possible de déclarer des constantes abstraites qui se transforment au cours des raffinements successives en des données implémentables dans un langage de programmation.

Ø Clause VARIABLES : les variables dans une machine B sont similaires aux variables globales dans les langages de programmation. Une variable est par défaut abstraite mais il est possible de déclarer des variables concrètes qui seront conservées jusqu’à l’implémentation.

Ø Clause INVARIANT: l’invariant est un prédicat qui décrit les propriétés inchangeables que les variables doivent vérifier.

Ø Clause INITIALISATION : dans cette clause, une valeur initiale est affectée à chaque variable.

4. Les appels d’opération

A travers des liens spécifiques, que nous allons détailler par la suite, une machine peut appeler des services ou opérations d’une autre machine. Ceci s’effectue par l’intermédiaire d’une substitution appelée substitution appel d’opération.

Soit op une opération. Une substitution appel d’opération en B s’effectue de la façon suivante:

Paramètres_sorties ← op (paramètres_entrées)

Le terme paramètres_sorties est une liste de noms de données (d’identificateurs) désignant les paramètres effectifs de sortie de op. Leurs types doivent être identiques aux types des paramètres formels de sortie de l’opération op. Le terme paramètres_entrées appelé aussi paramètres_effectifs d’entrée est une liste d’expressions qui doivent avoir des types identiques à ceux des paramètres formels d’entrée de l’opération op.

La substitution appel d’opération permet d’appliquer la substitution d’une opération, en remplaçant les paramètres formels par des paramètres effectifs :

1. Si op est une opération sans paramètre de sortie et sans paramètre d’entrée, définie par op = S, alors la signification d’un appel de op est la substitution S.

2. Si op est une opération sans paramètre de sortie et avec des paramètres d’entrée, définie par op(X) = S, alors la signification de l’appel op(E) est la substitution : X := E ; S.

3. Si op est une opération avec des paramètres de sortie et sans paramètres d’entrée, définie par Y ← op = S, alors la signification de l’appel de R ← op est la substitution : S ; R :=Y.

4. Enfin, si op est une opération avec des paramètres de sortie et des paramètres d’entrée, définie par Y ← op(X) = S, la signification d’un appel de R ← op(E) est : X :=E ; S ; R :=Y.

5. Raffinement

En général, la construction des systèmes complexes sûrs ne s’effectue pas d’une façon monolithique mais à travers des raffinements successifs. Les raffinements permettent de préciser petit à petit l’abstraction tirée du cahier des charges. Lors du raffinement, le non déterminisme et la simultanéité tendent à disparaître. Le raffinement d’une machine s’effectue sans modification de la signature des



opérations, seuls peuvent changer les variables, les ensembles et les substitutions définissant les opérations. Une substitution S est dite raffinée par une substitution T, si T peut être utilisée à la place de S sans que l’utilisateur ne s’en rende compte. [37]

Ainsi, nous pouvons conclure que le raffinement consiste à :

Ø Transformer les structures de données abstraites tels que les ensembles, les relations, les fonctions et les suites en structures de données concrètes proche des langages de programmation. Il y a ainsi introduction des tableaux et des variables scalaires.

Ø Lever progressivement l’indéterminisme des substitutions. Ø Remplacer les substitutions abstraites, les substitutions parallèles et les choix par des

substitutions concrètes tels que les séquencements, les conditions et les boucles.

6. Les obligations de preuve des raffinements

Les obligations de preuve pour les raffinements consistent à prouver la correction d’un raffinement vis-à-vis de ses abstractions. Il s’agit de démontrer que l’initialisation établit l’invariant sans contredire l’initialisation de l’abstraction, et que chaque raffinement d’opération préserve l’invariant sans contredire l’opération de l’abstraction. En effet, comme pour les machines abstraites, la correction de l’initialisation et des opérations des raffinements est assurée par établissement et préservation de l’invariant. Cependant, l’invariant d’un raffinement est un invariant de liaison définissant les propriétés des nouvelles variables par rapport aux variables du composant raffiné. [36]

7. Implémentation

L’implémentation est la dernière phase de raffinement d’une machine abstraite. Elle doit être directement traduisible en langage de programmation. Par conséquent, l’indéterminisme est interdit et toutes les déclarations de données doivent être proches de celles qu’on trouve dans les langages de programmation. Au niveau des implémentations, les seules substitutions permises sont les substitutions déterministes appelées instructions. L’équivalence avec un programme habituel est quasi immédiate. Un composant B qui est une implémentation est écrit à l’aide d’un sous-ensemble du langage B appelé B0.

Dans une implémentation, les variables abstraites doivent être toutes concrétisées. Les variables concrètes, de même que les constantes concrètes doivent avoir un typage concret qui peut être :

Ø un entier représentable Ø une valeur booléenne Ø une valeur d’un ensemble différé ou énuméré Ø un tableau

Les trois premiers items sont des types simples. Un tableau est l’instanciation d’une fonction totale dont le domaine est un type simple ou un produit de types simples, et dont le co-domaine est un type simple. Cette fonction totale peut être en plus injective, surjective ou bijective. Pour instancier un tableau, nous pouvons employer l’opérateur maplet (a ) entre ses termes ou l’opérateur



multiplie * (produit cartésien d’ensembles). Par exemple le tableau ff est représenté de la façon suivante : ff = {0 a 0, 1 a 10, 2 a 21, 3 a 32}.

Comme pour la correction du raffinement, la correction d’une implémentation n’est pas une simple vérification de cohérence interne, mais aussi une assurance que l’implémentation respecte sa spécification. Les obligations de preuve relatives à la correction des implémentations comportent des preuves similaires à celles des raffinements. [36,37]

8. Architecture de projets B

Le développement en B repose sur deux mécanismes essentiels, le mécanisme de raffinement matérialisé par le lien REFINES et le mécanisme de modularité matérialisé soit par le lien INCLUDES (utilisé dans une machine abstraite ou un raffinement) soit par le lien IMPORTS (utilisé dans une implémentation). L’intérêt de l’importation et de l’inclusion réside dans le fait de permettre à la machine d’appeler les services (les opérations) de la machine importée ou incluse. D’autres mécanismes existent pour effectuer des liens entre les composants (SEES, USES). Les règles qui régissent ces mécanismes se trouvent dans les manuels de référence [39] et le manuel de référence du B. [37]

III. Conclusion

La modélisation formelle est à la base de tout projet réussi, parce qu’elle fournit des preuves indiscutables, dans ce chapitre on comprend pourquoi la modélisation formelle est si fiable.

La modélisation formelle utilise des méthodes formelles pour générer des systèmes sûrs (critiques), c’est pour cela qu’on a fait une étude sur le langage B, parce que c’est lui qu’on va utiliser dans le chapitre sur la conception et la modélisation.


Chapitre V Conception et Modélisation

1. Introduction

La sécurité s’impose comme une composante essentielle de la protection des systèmes d’informations. Bien que cela soit difficile à évaluer, l’insécurité à un coût qui se manifeste lors d’incidents ou de dysfonctionnements.

Face aux risques encourus, et dans le contexte fonctionnel, il convient d’identifier ce que doit être protégé, de quantifier l’enjeu correspondant, de formuler des objectifs de sécurité et d’identifier, d’arbitrer et mettre en œuvre les parades adaptées au juste niveau de sécurité retenu. Cela passe prioritairement par la définition et la mise en place d’une politique de sécurité.

En premier lieu, on établit une politique de sécurité dans laquelle on définit les permissions et, par conséquent, toute règle non établie dans la politique est une règle interdite, cette politique s’appelle politique permissive.

Le processus qu’on propose est un processus qui, à partir d’une politique de sécurité (règles établies) établie dans un langage formel, et en utilisant les méthodes formelles, procède à un raffinement par étapes jusqu'au le dernier niveau. Le passage de l’informel au formel permet souvent de détecter des anomalies.

Les méthodes formelles sont des méthodes soutenues par la rigueur mathématique selon P Amey, ces méthodes permettent la non-ambiguïté surtout lorsqu’il s’agit de spécifier ou lorsqu’il s’agit de développer.

Tout le processus se base sur les objectifs de sécurité qu’on doit satisfaire mais par ordre de priorité, c’est-à-dire, qu’en premier lieu, on doit satisfaire la disponibilité puis l’intégrité et la confidentialité ; quand un service est non disponible alors on n’a aucun souci d’intégrité et de confidentialité.

2. Les objectifs

Il faut :

Mettre en œuvre un processus qui utilise les différentes notions du génie logiciel, système d’information, réseau et logique mathématique afin d’aboutir à un système sécurisé. Ce processus est une suite de développements successifs (développement à chaque niveau).

Résumé Dans ce chapitre de conception et développement, on va expliquer notre contribution en commençant par le cycle de développement du processus proposé où on constate que le CdC Secure intervient dans tous les étapes du développement (CdC évolutif). Puis la politique de sécurité proposée, jusqu’à l’automate sécurisé.



Concevoir un cahier de charges de sécurité CdC Secure qui s’adapte au fur et à mesure du développement.

Construire un module par raffinement (automate de sécurité) et le mettre en œuvre afin de garantir les termes de la politique de sécurité.

La politique de sécurité permet de caractériser les états d’un système et de spécifier ce qui est un état sûr du système et le passage d’un état sûr à un autre état sûr.

Mais avec notre processus qui permet de réaliser un système sécurisé, on ne doit pas influencer (sacrifier) la performance du système ; c’est pour cela qu’on doit intégrer la performance dans notre étude et ce, afin d’avoir un équilibre entre la sécurité et la performance de notre système.

Figure 5.1 Le cas idéal du système

Nous devons garantir la propriété (règle) suivante à tous les niveaux de raffinements.

Tous accès ou flux au sein du système doit être vérifié et approuvé au préalable par la politique de sécurité (démarche de dérivation).

3. Cycle de développement du processus

Sécurité Performance

Système



CdC Secure : cahier de charges sécurité. M init : Machine initiale. Mi : Machine au niveau i

Figure 5.2 Cycle de développement de la démarche (1)

Figure 5.3 Cycle de développement de la démarche (2)

CdC Secure

CdC Secure

Machine

Machine

Niveau i

Niveau i-1

CdC Secure

CdC Secure

CdC Secure

CdC Secure

M init

M 1

M 2

M n

Niveau initial

Niveau 2

Niveau n

Niveau 1



Ces deux figures permettent de comprendre (voir) notre démarche qui est :

1. Une démarche séquentielle, c’est-à-dire, qu’on passe d’un niveau au niveau suivant. 2. Une démarche curative, c’est-à-dire, on stoppe l’avancement et on remonte dans le niveau

pour soit :

i. Enrichir le CdC Secure par une règle, ii. Supprimer une règle gênante qui induit à une ambiguïté et/ou à une incohérence,

iii. Modifier une règle mal interprétée.

4. Explication du cycle de développement

L’idée qu’on propose est d’intégrer le cahier de charges de sécurité CdC Secure dans tout le cycle de développement et ce, afin de l’adapter au patron de conception, c'est-à-dire, satisfaire les objectifs un par un.

A chaque niveau on a un CdC Secure établi en un langage formel mais qui se voit interprété en utilisant la modélisation formelle et un langage formel jusqu'à faire sortir la machine correspondante. Ce processus est le même pour tous les niveaux.

La condition qu’on est tenu à vérifier à chaque niveau et de chaque niveau au niveau suivant est la cohérence et la non-ambiguïté.

i. Pour le premier cycle de développement de la démarche

C’est le cas le plus favorable du processus, la démarche suivie est une démarche séquentielle, le passage d’un niveau à un niveau d’ordre inférieur ne génère pas d’ambiguïté ou d’anomalie dans la politique de sécurité.

ii. Pour le deuxième cycle de développement de la démarche

C’est un cas (cycle) plus complexe que le précédent, mais l’idée nous offre des avantages énormes ; parmi ces avantages, on peut modifier une (des) règle (s) au juste niveau avant de persister dans l’erreur et avant d’avoir un système complexe au fur et a mesure du processus de développement.



5. Architecture sécurisée

Figure 5.4 Architecture sécurisée proposée

On peut dire que le module de sécurité joue le rôle d’une barrière. Il permet le passage des événements autorisés et qui ont leurs correspondants en action dans la politique de sécurité.

6. La politique de sécurité de notre système

Notre politique de sécurité joue sur la notion d’Action. Cette dernière peut être autorisée ou interdite. A partir de là, on peut définir la politique de sécurité comme suit :

Une politique de sécurité définie sur un ensemble d’actions est une propriété indiquant pour chaque action si elle est autorisée ou non.

Il existe trois manières différentes pour définir une politique :

Ø Ensemble A+ spécifiant les actions autorisées (politique permissive) Ø Ensemble A- spécifiant les actions interdites (politique restrictive) Ø Ensemble A+ spécifiant les actions autorisées et un ensemble A- spécifiant les actions

interdites

Une politique peut être incomplète de même qu’elle peut être incohérente.

Pour notre cas, on va adopter la politique permissive.

Politique incomplète

Une politique est incomplète s’il existe une action pour laquelle aucune permission ou interdiction n’est spécifiée. Ce problème ne se pose pas dans les cas 1 et 2, car une règle par défaut est utilisée, spécifiant que toute action non autorisée est interdite ou inversement. Par contre dans le cas 3, l’incomplétude est caractérisée par l’existence d’une action qui n’est ni autorisée ni interdite par la politique (A+ ∪ Ai ⊆ Action).

Module de sécurité



Politique incohérente

Une politique est incohérente si une action est à la fois interdite et autorisée par la politique. Ce conflit n’est possible que dans le cas 3, si A+ ∩ A- ≠ Ø. Pour l’éviter, on peut soit interdire que deux règles se contredisent, soit proposer une procédure pour résoudre les conflits.

Il existe un problème de correspondance entre la politique de sécurité et le système réel, c’est-à-dire entre les actions spécifiées par la politique de sécurité et les événements du système.

A ce niveau, nous définissons une fonction qui permet de comprendre la correspondance entre les actions de la politique de sécurité et les événements du système, cette fonction est appelé : mapping

Figure 5.5 L’incohérence et l’incomplétude dans une politique restrictive

Notre définition

Un système correspond à une politique de sécurité si tout évènement du système est lié à une action autorisée de la politique.

Mapping ∈ Event → Action / F(Action)

Cohérence d’une politique de sécurité

La politique de sécurité doit être cohérente, c’est-à-dire, qu’on doit montrer que l’ensemble des règles constituant la politique de sécurité ne contient pas d’exigence conflictuelle.

A+

Event Actions

Ø

Event Actions

mapping

mapping

Incomplétude

Incohérence

A+



7. Choix de modélisation

A la fin on doit avoir un module de sécurité (automate) capable de garantir les termes du cahier de charges sécurité CdC Secure basé sur la politique de sécurité permissive A+

La politique permissive A+ est un ensemble qui ne contient que des actions autorisées A+ ∩ A = Ø

Action est effectuée par un utilisateur User sur une ou des ressources Ressource. De même Event

Action = User × Ressource / niveau Méta

Event = User × Ressource / niveau Physique

Ces deux notions (Action, Event) se spécifient et s’affinent selon les niveaux de raffinement.

Refinesi ∈ Eventi → F(Eventi-1) / i : niveau de raffinement

Refinesi ∈ Actioni → F(Actioni-1)

Dans notre politique, on essaie de mettre en œuvre la correspondance suivante :

Chaque événement du système est lié à une seule action de la politique

Mapping ∈ Event → Action

On obtient alors la formule qui définit la fonction :

Mappingi(ei) = {ai / ∃ ei-1 (ei-1∈refinesi(ei) ∧ a ∈mappingi-1(ei-1))}

On peut représenter la politique de sécurité comme un prédicat selon les définitions suivantes :

Définition

Une politique de sécurité est un prédicat sur l’ensemble des évènements, l’ensemble des évènements E satisfait A+ si et seulement si : A+(E).

Définition

Une politique de sécurité est une propriété si le prédicat P est de la forme :

P(E) = ∈∀σ E, P (σ ) tel que : P est un prédicat sur les évènements

En premier lieu, on doit prouver la disponibilité au sein de notre système, c’est-à-dire, on doit mettre en oeuvre la politique de disponibilité.



On peut définir la propriété de disponibilité comme l’aptitude d’un système à répondre à une demande d’un utilisateur, d’un service ou d’une ressource en garantissant des contraintes de performance et de sécurité.

8. Politique de disponibilité

La politique de disponibilité est la spécification des contraintes qui doivent être garanties. Ces contraintes peuvent dépendre du :

Ø contexte de la demande Ø sujet (utilisateur) ayant fait la demande Ø service (ressource) demandé (e)

Les propriétés de disponibilité à prouver sont dérivées de la politique de disponibilité. Elles permettent de prouver que le système garantit la continuité du service, c’est-à-dire, qu’il a la capacité de fournir des services aux utilisateurs à n’importe quel moment.

9. Politique de confidentialité

La politique de confidentialité ne permet d’accéder aux données qu’à la personne autorisée.

Cette politique se base sur des restrictions qui sont imposés sur les opérations de lecture et écriture :

Ø No read up : Un sujet ne peut lire un objet que si la classe d’accès du sujet domine celle de l’objet (un sujet ne doit pas apprendre des informations qui ne lui sont pas autorisées).

Ø No write down : Un sujet ne peut écrire dans un objet que si la classe d’accès de l’objet domine celle du sujet (un sujet ne doit pas révéler des secrets).

10. Politique d’intégrité

La politique d’intégrité ne permet pas aux personnes non autorisées de modifier des données, c’est-à-dire si la personne est de niveau d’intégrité inférieur au niveau de la donnée.

Pour mettre en œuvre cette politique, chaque sujet et objet doivent posséder une classification d’intégrité.

11. Description du modèle

La description se fait à l’aide d’un cahier de charges sécurité CdC Secure, celui-ci s’établit en utilisant un langage formel pour la spécification.

Ensuite, la spécification change en changeant les niveaux de raffinement.

N.B : notre cahier de charges sécurité change à chaque niveau de développement (raffinement).



11.1. Les niveaux de développement du système

Notre processus se constitue en un développement par niveau comme il est apparent dans le cycle de développement.

On commence par une spécification initiale et on avance dans les niveaux jusqu’au dernier niveau de développement.

Spécification initiale (cahier de charges initial)

1. Le système comprend des utilisateurs et des services (ressources) 2. Chaque ressource est fournie par un serveur 3. Tout client (machine) peut être utilisé(e) par au moins un utilisateur 4. A tout moment, les services doivent être fournis par le (s) serveur (s) 5. A tous moment, les utilisateurs peuvent utiliser les services. 6. Chaque serveur fournit au moins un service

Spécification des notions fondamentales

usr ≠ 0 : l’ensemble des utilisateurs

srv ≠ 0 : l’ensemble des services

csl ∈ usr ↔ srv

dyn ∈ usr → srv

csl : représente un ensemble de couples « utilisateur-service ». Chaque couple relie un utilisateur à un service. Lorsqu’un utilisateur peut accéder à plusieurs services, alors nous retrouvons pour un utilisateur autant de couples qu’il y a de services.

dyn : est une fonction représentant la dynamique des utilisateurs à travers les services : elle contient aussi des couples.

L’invariant du système

Un invariant du système est une règle qui ne change pas, et qui doit être vérifiée à tous les niveaux d’ordres inférieurs.

L’invariant qui intervient à partir de la règle 4 et 5 est le suivant :

A tout moment, les utilisateurs peuvent accéder aux services fournis par les serveurs.

L’invariant par une modélisation formelle se présente comme suit :



∀ u, ∃ s u → s

D’un autre sens, l’ensemble de couples csl doit être vrai à tout moment

Notre politique de sécurité se base sur les objectifs de sécurité qu’on doit satisfaire mais avec priorité.

Dans ce processus, on commence par satisfaire en premier lieu la disponibilité, puis l’intégrité et la confidentialité.

Description formelle

A ce niveau, les éléments apparents sont : utilisateur et service

Les notions : User, Ressource (service), Action, Event, A+ et Mapping sont des notions qui ne changent pas.

Action = User × Ressource A+ ⊆ Action Event User × Ressource

Le cahier de charges forme un ensemble de règles appelées Action, et notre cahier de charges sécurité CdC Secure ne contient que des actions autorisées A+. Mais les deux cahiers de charges peuvent contenir des règles similaires (les mêmes règles). Une règle fonctionnelle peut être une règle de sécurité.

Les deux notions Action et Event sont des notions similaires, mais à des niveaux d’abstraction différents : Action se situe dans les niveaux d’abstraction les plus hauts (niveau méta) qui correspond aux actes de l’utilisateur par rapport au service (s) et vise vice-versa. Event se situe au niveau d’abstraction le plus bas (niveau physique), c’est-à-dire, la représentation du comportement du système.

N.B: le symbole égal (=) surmonté d’un chapeau est remplacé par le symbole ⌂

Set (ensemble) = csl, dyn, Event, A+ Variables: usr, srv, e Initialisation: usr, srv, e := 0,0,0 Invariant: ∀ u, ∃ s u→ s Operation:

Correspondre ⌂ ANY usr, srv WHERE

PRE usr → srv ∈csl THEN ANY e ∈ event THEN Mapping (e) ⊆ A+



On va représenter tout le développement par une machine :

Dans cette machine (Machine Dispo) on veut prouver la disponibilité des services vis-à-vis des utilisateurs.

La disponibilité est la capacité de fournir des services aux utilisateurs à n’importe quel moment, mais dans notre contexte c’est plus strict, c'est-à-dire, que pour chaque utilisateur et pour chaque service, on doit vérifier au préalable s’ils appartiennent à l’ensemble csl, ensuite on vérifie, pour chaque évènement produit entre ces deux entités, s’il ne viole pas la politique de sécurité.

Deuxième niveau

Puisque les utilisateurs travaillent sur des machines et que les services (ressources) sont hébergés dans d’autres machines, alors la spécification va changer pour affiner encore plus la spécification et introduire d’autres termes.

A ce niveau, les termes introduits sont Serveur, Client qui sont des machines, en plus Fournit et Utiliser-par qui sont des fonctions qui permettent de connaître les services fournis par chaque serveur et les utilisateurs qui ont le droit d’accéder à chaque machine.

Ici, à ce niveau, le cahier de charges ne va pas être changé ou modifié, c’est-à-dire, qu’on travaille toujours sur les mêmes règles.

Description formelle

Fournit ∈ Serveur → F(Ressource) ∧ ∀ r ∈ Ressource ∀ s ∈ Serveur r ∈ Fournit (s) ….. (1) ∧ utiliser-par ∈ Client → F(User) ∧ ∀ u ∈ User ∀ c ∈client c∈Utiliser-par (u) ….. (2)

Machine Dispo SET

csl, Event, A+ VARIABLE

usr, srv, e INITIALISATION

usr, srv, e := 0,0,0 INVARIANT

∀ u, ∃ s u → s OPERATION

Correspondre ⌂ ANY usr, srv WHERE PRE usr → srv ∈csl THEN ANY e ∈ event THEN Mapping (e) ⊆ A+

END ;



Dans ces formules, on explique le rôle entre les clients et les serveurs en utilisant les fonctions Fournit et Utiliser-par.

Maintenant, la représentation devient :

Event = Serveur × Client ∧ ∀ (c,s) (c,s) ∈ csl ⇒ refines (c,s) = Utiliser-par (c) × Fournit (s))

Dans cette machine (Dispo 2) qui est relative à la disponibilité, on essaye de prouver la disponibilité des serveurs par rapport aux clients, et comme dans l’ensemble csl on n’a que des couples du genre utilisateur / service (u, s) on ne peut pas vérifier c a s ∈ csl, c’est pour cela qu’on a fait appel aux formules (1) et (2).

Troisième niveau

Dans les deux niveaux précédents, on a mis en œuvre une stratégie qui permet de garantir la disponibilité des services vis-à-vis les utilisateurs à tout moment ; cette stratégie est appelée politique de disponibilité.

A ce niveau, le cahier de charges va être enrichi par d’autres règles qui permettent de consolider la politique de sécurité. Ces règles sont :

7. Chaque utilisateur est autorisé à accéder au service par un nom d’utilisateur (username) et un mot de passe (passeword).

8. Tout utilisateur consultant un service y est bien autorisé 9. A un instant donné, un utilisateur consulte un service au plus

Machine Dispo 2 SET csl, Event, A+ VARIABLE c,s,e INITIALISATION c,s,e := 0,0,0 INVARIANT

c a s ∈csl OPERATION

Correspondre ⌂ ANY c,s WHERE

PRE c a s ∈csl THEN ∧ ∀ u ∈ User ∀ c ∈client c∈Utiliser-par (u) ∧ ∀ r ∈ Ressource ∀ s ∈ Serveur r ∈ Fournit (s)

ANY e ∈event THEN Mapping (e) ∈ A+

END;



La clé de tout accès dans l’univers de l’utilisateur et du service est le nom d’utilisateur et le mot de passe qui sont l’épine dorsale de l’authentification.

L’invariant

On a déjà un invariant qu’on a obtenu de la spécification initiale, mais le besoin et les contraintes de sécurité nous induisent à un deuxième invariant. Ces deux invariants ne doivent pas être en contradiction, mais plutôt complémentaires.

Cet invariant est la règle 8 qui est:

Tout utilisateur utilisant un service est bien autorisé à l’être

∀ usr ∃ srv (usr,srv)∈dyn ⇒ (usr,srv)∈csl

A partir de cette règle on peut comprendre que la fonction dyn est incluse dans la relation csl, c’est-à-dire, si le couple usr a srv appartient à la fonction dyn, alors ce même couple doit aussi appartenir à la relation csl pour que utilisateur "usr" soit bien autorisé à accéder au service "srv".

Après qu’on ait garanti la disponibilité des services, on doit garantir l’authentification des utilisateurs, c’est-à-dire, que personne ne peut accéder sauf s’il est bien celui qu’il prétend être.

La garantie de l’authentification est faite comme suivant :

L’authentification des utilisateurs se base sur la relation csl, c’est-à-dire, que tous les privilèges de chaque utilisateur sont inscrits dans cette relation sous forme de couples.

Machine Authentifier SET

csl, dyn VARIABLE

usr, srv INITIALISATION

usr, srv := 0, 0 INVARIANT

∀ usr ∃ srv (usr,srv)∈dyn ⇒ (usr,srv) ∈ csl OPERATION

Authentifier ⌂ ANY usr,srv WHERE

PRE usr a srv∈csl ∧ dyn (usr) ≠ srv THEN

dyn (usr) := srv END

END;



La machine présentée ici (machine Authentifier) est une machine qui gère l’authentification des utilisateurs. Un utilisateur qui veut s’authentifier ça veut dire qu’il n’est pas dans le système d’où la formule : dyn (usr) ≠ srv

L’authentification se fait à base de la vérification de l’ensemble csl, après l’introduction du bon nom d’utilisateur et du bon mot de passe par l’utilisateur, ce dernier accède au service (s) correspondant (s) selon ses privilèges décrits dans la relation csl sous forme de couples.

Quatrième niveau

On remarque bien qu’a chaque fois qu’on change le niveau, on affine les règles, soit en introduisant de nouvelles règles, soit en éclatant des règles en sous-règles pour mieux prouver les contraintes de sécurité.

A ce niveau, on introduit de nouvelles règles :

10. Un utilisateur ne peut accéder à un service que s’il est authentifié. 11. Tout utilisateur quittant un service doit se déconnecter 12. Si ou bout de quelques temps (ex : t mn), l’utilisateur n’interagit pas avec un service, le

système se déconnecte automatiquement.

A ce niveau, on peut définir deux actions qui sont le résultat généré du niveau de développement (raffinement précédent) :

Ø L’utilisateur est autorisé à accéder Ø L’utilisateur ne l’est pas (bloquer)

Machine Accéder SET

dyn, csl, admis VARIABLE


usr, srv := u,s INVARIANT

∀ usr ∋ srv (usr,srv)∈dyn ⇒ (usr,srv) ∈ csl OPERATION

Accéder ⌂ ANY u,s WHERE

u ∈ usr ∧ s ∈ srv PRE admis (usr, srv) THEN dyn (u) := csl (s) END

END;



N.B: Admis (usr, srv) représente l’authentification de l’utilisateur par rapport au service et qui est le résultat du développement Authentifier.

Dans ce développement, on a initialisé usr et srv à u et s à la suite et ce, afin de donner une vision explicite que l’utilisateur u est bel et bien authentifié et qu’il a les privilèges d’accès au service s.

Le développement de cette machine (Machine Accéder) nous permet de vérifier l’intégrité (politique d’intégrité).

Dans l’opération on vérifie l’état de la machine Authentifier par Admis (usr, srv), si l’état est sûr (Authentifier) alors l’utilisateur u peut accéder au service s.

De la même façon, l’opération de rejet des utilisateurs se produit, l’opération vérifier l’état de la machine Authentifier, tant que l’état est non sûr la machine rejette l’utilisateur

Maintenant, on spécifie la déconnexion

Machine Rejet SET

Admis, dyn, csl VARIABLE


usr, srv := 0,0 INVARIANT

∀ usr ∃ srv (usr,srv)∈dyn ⇒ (usr,srv) ∈ csl OPERATION

Rejeter ⌂ ANY usr, srv WHERE

PRE ¬ Admis (usr,srv) THEN dyn (usr) ∩ csl (srv):= Ø

END;



Pour la déconnection on a deux cas :

Ø Soit l’utilisateur se déconnecte d’une façon manuelle. Ø Soit la déconnexion est automatique (notre cas est de t minutes) afin d’éviter toute utilisation

mal intentionnée, c'est-à-dire, éviter plusieurs types d’attaques qui peuvent se produire à cause de la négligence des utilisateurs : à titre d’exemple l’ingénierie sociale.

Dans la machine Deconnect, l’opération doit vérifier en premier lieu la pré-condition, c'est-à-dire, si l’utilisateur a réellement accédé au service, sans la vérification de cette condition la déconnexion n’a aucun sens. Ensuite, on vérifie la condition du timing qui est de t minutes, si le timer atteint ces t minutes alors le système se déconnecte automatiquement, sinon l’utilisateur reste toujours dans le système (services).

Cinquième niveau

A ce niveau on va parler du blocage du système

Quand l’utilisateur est déjà dans le système, c’est-à-dire, s’il est dans un service et qu’il veut passer à un autre service, on doit procéder à une vérification pour éviter toute intrusion mal intentionnée (usurpation d’adresse, man in the middle, etc.)

Machine Deconnect SET

csl, dyn VARIABLE

usr, srv, T INITIALISATION

usr, srv, T := u, s, 0 INVARIANT

∀ usr ∃ srv (usr,srv)∈dyn ⇒ (usr,srv) ∈ csl OPERATION Deconnecter ANY u WHERE

u ∈ usr ∧ s ∈ srv PRE dyn (u) := csl (s) THEN IF T ≥ t THEN

dyn (usr) ∩ csl (srv):= Ø ELSE

dyn (u):= csl (s) END

END;



On peut considérer que la machine Vérifier est la plus importante dans le développement parce que c’est elle qui procède à la vérification du dynamisme des utilisateurs vis-à-vis des services.

L’opération de la machine s’effectue comme suit, quand un utilisateur est dans un service (s1) et qu’il veut passer à un autre service, le passage ne se fait (autorisé) qu’après la vérification de la pré-condition Admis (usr, srv). Si la re-vérification est fructueuse (c-à-d, si elle donne un état sûr) alors l’utilisateur u peut aller (passer) au service désiré, sinon le système le déconnecte (le fait sortir) automatiquement.

NB : le problème qui peut se poser est le problème d’élévation des privilèges, dans certains cas on a le problème d’incohérence des couples csl.

11.2. Le résultat obtenu du développement

11.2.1. Principe (résultat)

Notre développement nous permet d’avoir un mécanisme capable de garantir la politique de sécurité que nous avons adoptée.

Ce mécanisme a le fonctionnement d’un automate mais dédié spécialement pour la sécurité, c’est pour cela qu’on l’appelle automate de sécurité A-S.

On va donner le principe de base de l’automate de sécurité :

SET csl, dyn

VARIABLE u,s

INITIALISATION u,s = 0, s1

INVARIANT ∀ usr ∃ srv (usr,srv)∈dyn ⇒ (usr,srv) ∈ csl

OPERATION Verifier

ANY u,s WHERE u ∈ usr

∧ s, s1, s2 ∈ srv IF dyn (u) ∩ csl (s):= {s1} THEN PRE admis (usr, srv) THEN

dyn (u) ∩ csl (s):= {s2} ELSE

dyn (u) ∩ csl (s):= Ø END;



Correspond

Correspond

Correspond

Bloque

Aucun évènement aucune action « aucune transition »

Evènement action « transition vérifiée »

Evènement bloqué a / a ∈A - A+ « transition bloquée »

11.2.2. Mettre en œuvre une politique de sécurité

La mise en œuvre de notre politique de sécurité par un mécanisme est le produit final, ce mécanisme va être un automate de sécurité. Cet automate s’active automatiquement avec le système, c’est-à-dire, en fonctionnement parallèle, le mode de fonctionnement est le suivant :

Vérification de la correspondance entre un évènement et une action dans la politique de sécurité

Ø Si Oui → il transite Ø Si Non → il se bloque

Figure 5.6 Principe de fonctionnement de l’automate

11.2.3. Automate de sécurité

Un automate de sécurité A-S est un automate déterministe, c’est-à-dire, qu’il est défini par un triplet (Q, q0, T) tel que :

Ø Q : ensemble des états Ø q0 : état initial Ø T : transition

11.2.4. Transition dans l’automate

La transition dans l’automate de sécurité est la notion la plus fondamentale car c’est elle qui détermine l’état du système.

Après chaque transition on aura soit un :

Ø Etat sûr de l’A-S

Automate

A-S Entrée = Event

Transit



Ø Etat non sûr de l’A-S

11.2.5. Propriétés de l’automate sécurisé A-S

L’automate doit satisfaire deux propriétés :

1. La neutralité : l’automate doit préserver la sémantique (le bon fonctionnement) du système 2. Le blocage : l’automate doit bloquer tout évènement non correspondant à une action dans la

politique de sécurité

11.2.6. Explications

Notre système qui est un système sécurisé passe d’un état sûr à un autre état sûr sans jamais entrer dans un état non sûr, et ce par la satisfaction de la deuxième propriété qui est le blocage. Quand dans l’une des machines développées, l’opération sort avec un état non sûr, la machine bloque immédiatement l’exécution ce qui entraîne que l’évènement se bloque automatiquement.

Le déploiement et la mise en œuvre de cet automate (module) dans une architecture nous garantissent le bon fonctionnement du système sans aucune violation de la politique de sécurité adoptée.

Figure 5.7 Schéma montrant le principe de l’A-S

: État sûr

: État non sûr

: Transition

: État initial



12. Conclusion

Nous sommes partis des notions classiques qui existent déjà et la plus frappante dans notre thèse est le cahier de charges CdC, et une étude des politiques de sécurité.

Notre travail a consisté à élaborer (développer) un processus qui permet d’avoir à la fin un système sécurisé.

Notre démarche consister à concevoir une autre notion (idée) de cahier de charges de sécurité CdC Secure qui est un cahier de charges souple, flexible, et évolutif qui s’enrichit (ajout, suppression, modification, etc.) au fur et à mesure du processus, ce qui est le contraire d’un cahier de charges classique.

Notre processus a été réalisé (rendu possible) grâce à la notion de raffinement (changement de niveau de spécification).

De même, pour que notre démarche ait un sens et soit valide, nous avons fait une correspondance entre les actions de la politique de sécurité (règle) et les événements du système (réel).

Aussi, la spécification de notre système a été faite à l’aide d’un langage formel et par l’utilisation de la logique mathématique qui sont basés sur la rigueur mathématique.

A la fin, on dit que le cahier de charges de sécurité est introduit dans tout le cycle de développement (CdC Secure évolutif).


Conclusion générale

L’évolution des systèmes d’informations porte à s’interroger sur le devenir de la sécurité surtout avec tous les développements des systèmes, l’arrivée du web, la complexité des services,… de même que la conception et l’implémentation de ces systèmes d’information ne prennent pas en compte à priori les aspects de sécurité.

Les approches actuelles essayent de mettre en œuvre des techniques (ex : protocoles) et des outils, et de les incorporer dans les systèmes. Mais ces approches n’apportent aucune certitude sur le niveau de sécurité recherché.

Dans ce travail de recherche, nous avons élaboré un état de l’art sur les attaques et les techniques de protection, et fait de même pour la politique de sécurité.

Notre approche consiste à proposer un cycle de développement par niveau où on trouve le cahier de charges sécurité à chaque niveau, de même on a utilisé la modélisation formelle pour la spécification des termes du cahier de charges sécurité et du système.

En plus des résultats de chaque niveau de développement, qui sont des machines soit à état sûr soit à état non sûr , on a proposé que ces résultats soient incorporés dans un automate (sous forme de module).

Les perspectives futures de cette démarche qu’on peut proposer consistent à introduire ce module dans les serveurs. A titre exemple Apache, Exchange, … pour concevoir et implémenter des serveurs sécurisés selon une politique de sécurité bien spécifique, c'est-à-dire, un serveur sécurisé qui s’adapte au contexte de sécurité et aux besoins des utilisateurs.


Annexe A intranet et ces fonctionnalités

1. Introduction

Le mot Intranet a été proposé par Jim Clark de la société Netscape pour désigner l’Internet de l’intérieur. L’Intranet est le standard Internet adapté au réseau local. Il est exploité au sein d’une organisation pour sa promotion interne et sa communication simple à coût zéro (messages Intranet, consultation des pages internes). L’Intranet est devenu le fruit d’une liaison entre l’Internet et LAN.

Le développement d’un intranet peut jouer un rôle-clé dans l’amélioration de la communication interne au sein de l’organisation (entreprise) et dans la création d’une « corporate identity ». Un intranet bien conçu permet en effet de mettre en place un échange d’informations rapide et structuré entre toutes les directions de l’organisation et ainsi, de développer un système de gestion des connaissances internes.

L'enjeu de l'intranet, en 2009, n'est plus seulement la diffusion de l'information mais sa circulation, en tant que dispositif de transmission et de partage du savoir dans une logique collaborative. Et pour favoriser ces usages, l'interactivité est le maître mot. Des espaces de travail aux applicatifs métiers en passant par les services transversaux, l'intranet doit convaincre de sa pertinence en alliant le confort du collaborateur et l'objectif global d'accroissement de la productivité.

2. Définition

Un intranet est un ensemble de services internet internes à un réseau local, c'est-à-dire accessibles uniquement à partir des postes d'un réseau local, ou bien d'un ensemble de réseaux bien définis (privé), et invisibles (ou inaccessibles) de l'extérieur [46]. Il consiste à utiliser les standards client-serveur de l'internet (en utilisant les protocoles TCP/IP), pour réaliser un système d'information interne à une organisation ou une entreprise.

3. Comment mettre en œuvre un intranet

La réussite d'un projet intranet ne dépend pas uniquement de la maîtrise technologique. En effet, un intranet induit nécessairement des modifications des pratiques professionnelles tant au niveau de l'individu, des groupes d'individus (un service par exemple) que de l'organisation (la collectivité en l'occurrence). En touchant au cœur des habitudes des personnes, à la « culture » et à l'histoire de la collectivité. L’Intranet impose de mettre en place un important travail de spécifications fonctionnelles (y compris de ré-ingénierie des procédures internes) accompagné d'un scénario de changement des pratiques (au centre duquel se trouve le principe d'implication des utilisateurs finaux). Approche fonctionnelle, démarche participative, conduite du changement, agrégation progressive et maîtrise technologique constituent les piliers de la réussite d'un projet intranet.

4. Evolution des intranets

Le concept d'intranet a mûri au cours du temps, grignotant des fonctionnalités du système d'exploitation réseau (adaptation source Forester Research) :



1. 85-90 : fichiers partagés ou transférés sur le réseau local 2. 94-96 : partage d'informations par la messagerie et des sites web statiques : l'intranet

contient des serveurs de fichiers et de messagerie, le NOS gère l'annuaire, d'administration, les fichiers, l'impression

3. 96-2000 : l'intranet institutionnel recouvre l'annuaire système, l'administration, et propose des fonctions de groupware ; le NOS garde la gestion des fichiers et des impressions

4. 2000 : l’intranet a tous les services : annuaire, messagerie, fichiers, impression, administration, objets, sécurité, groupware, l’accueil devient un portail personnalisable. L’intranet fournit des fonctions collaboratives et décisionnelles.

5. Caractéristiques d’un intranet

5.1. Les points forts d’un intranet

Ø L'Intranet dépasse largement le strict plan technologique, car il met en jeu des composantes organisationnelles fortes et offre aux utilisateurs un environnement homogène d'accès à l'information correspondant à leurs propres besoins.

Ø L'Intranet permet de partager et d'échanger des informations : la mise en réseau des acteurs de la collectivité.

Ø L'Intranet permet non seulement de partager des connaissances mais aussi de faire naître de nouvelles compétences au sein des services.

Ø Les contraintes de temps et d'espace sont minimisées.

Ø L'Intranet facilite la réalisation du travail en équipe (approche collaborative) et la concrétisation de projets communs. D'une manière générale, l'Intranet propose une palette d'outils facilitant la mise en œuvre d'applications de travail de groupe et encourage ainsi la communication, la coopération et la coordination.

Ø L'intranet favorise la réactivité et la créativité des acteurs d'une collectivité.

5.2. L’utilité d’un intranet

Un intranet dans un organisme (exemple : entreprise) permet de mettre facilement à la disposition des utilisateurs des documents divers et variés; cela permet d'avoir un accès centralisé et cohérent à la mémoire de l'organisme. On parle ainsi de capitalisation de connaissances. De cette façon, il est généralement nécessaire de définir des droits d'accès pour les utilisateurs de l'intranet aux documents présents sur celui-ci, et par conséquent une authentification de ceux-ci afin de leur permettre un accès personnalisé à certains documents.

Une application Intranet est moins chère à fabriquer, et surtout moins chère à maintenir. Elle est aussi moins longue à développer. Tous ces éléments sont des facteurs d’allégement du coût, quelle que soit l’échelle de temps considérée. Directement dérivée de la première, la deuxième raison est



celle de la satisfaction de l’utilisation, voire le client. Le cycle de vie du logiciel est plus court, l’interface est intuitive, et les éventuels bugs peuvent être corrigés très rapidement.

Des documents de tous types (textes, images, vidéos, sons, ...) peuvent être mis à disposition sur un intranet. De plus, un intranet peut réaliser une fonction de groupware, c'est-à-dire permettre un travail coopératif. Voici quelques unes des fonctions qu'un intranet peut réaliser : [46]

Ø Mise à disposition d'informations sur l'entreprise (panneau d'affichage)

Ø Mise à disposition de documents techniques

Ø Moteur de recherche de documentations

Ø Un échange de données entre collaborateurs

Ø Annuaire du personnel

Ø Gestion de projet, aide à la décision, agenda, ingénierie assistée par ordinateur

Ø Messagerie électronique

Ø Forum de discussion, liste de diffusion, chat en direct

Ø Visioconférence

Ø Portail vers Internet

Ainsi, un intranet favorise la communication au sein de l'entreprise et limite les erreurs dues à la mauvaise circulation d'une information. L'information disponible sur l'intranet doit être mise à jour en évitant les conflits de version.

2. Avantages d’un intranet

1. Travail des employés : l'intranet aide les employés à trouver et à visualiser rapidement des informations dans des documents électroniques et des applications pertinentes dans leurs domaines de compétences. Via une interface de Navigateur web facile à utiliser, les utilisateurs peuvent accéder aux données de n'importe quelle base de données qu'une organisation veut rendre disponible, n'importe quand, de n'importe où, augmentant par la- même l'habileté des employés dans leur travail.

2. Communication : l'intranet est un puissant moyen de communication à l'intérieur d'une organisation, verticalement et horizontalement.

3. Publipostage Web : l'utilisation d'intranet permet aux informations d'être publiées par des liens au delà du simple hypertexte.

4. Organisation et business : l'intranet est aussi utilisé comme une plateforme pour développer et déployer des applications de support aux transactions informatiques utilisées à des fins financières et décisionnelles, par delà l'entreprise interconnectée...



3. Fonctionnalités de l’intranet

3.1. Typologie d’intranet

Relativement aux diverses fonctionnalités de l’intranet, il est possible de proposer une typologie de ces outils, de manière à avoir une meilleure compréhension de la panoplie des choix offerts à l’entreprise.

Relativement à la typologie proposée par Alin et alii (1998), on peut distinguer différentes catégories d’intranet selon l’objectif que lui assigne l’entreprise en fonction de ses besoins :

Intranet de communication

Les origines de cet intranet émanent de la volonté des informaticiens d’implanter de nouveaux modes de communication ou de responsables fonctionnels qui souhaitent disposer de services d’échanges pour initier une démarche de construction d’un réseau d’entreprises. Son but premier est de communiquer des informations a ses propres collaborateurs, en sortant de la « voix officielle » qui a parfois trop longtemps caractérisé les medias de communication internes classiques. Il peut selon les cas être considéré comme un intranet « libre ».

Intranet documentaire

Sa qualité réside dans un référencement efficace des documents et dans l’offre de modes de recherches multiples offerts aux utilisateurs pour que chacun trouve ce qu’il cherche dans cette vaste bibliothèque virtuelle. L’objectif est de constituer une bibliothèque de références dans laquelle l’unicité des documents et leur intégrité est garantie et ou l’utilisateur disposera d’un ensemble de moyens d’accès (recherche guidée, en texte intégral ou multicritère). L’ambition de l’intranet documentaire peut s’étendre à la gestion de l’ensemble du cycle documentaire et à la mise en œuvre d’un système GED complet.

Intranet applicatif

Il regroupe toutes les applications pouvant être déployées sur intranet pour répondre à des besoins de groupware, de workflow, d’accès à une base de données, de formulaires, d’automatisation de procédures manuelles.

Intranet fédérateur

Il a pour vocation de réunir différents services ou applications intranet, développés et exploités par ailleurs au sein d’un espace de communication et d’accès. Il traduit la volonté d’harmoniser les fonctions pour que l’utilisateur y accède facilement à travers une interface commune. Il est fonctionnellement proche d’un annuaire internet (classement thématique des services, outils de recherche multicritère). L’intranet fédérateur est forcément porté par la direction générale de l’entreprise. Il n’a pas pour objet de tuer les intranets développés pour des communautés restreintes d’utilisateurs, mais se concentre sur les services universels pour l’entreprise et permet de diffuser largement des messages de communication interne.



Intranet de groupware et de workflow

Le groupware et le workflow décrivent des besoins, alors que l’intranet décrit un moyen de satisfaire ces besoins, la clé de la conception d’outils de groupware et de workflow est l’organisation même du travail en commun. On s’intéresse donc au contenu des services mais surtout aux acteurs de ces services (identification, appartenance à des profils prédéfinis, habilitation à réaliser certaines taches ...).

Intranet d’intégration

Il est mis en œuvre quand les besoins des utilisateurs sont satisfaits, mais que des problèmes techniques demeurent (nécessité d’avoir plusieurs postes de travail pour accéder à toutes les applications, l’utilisateur ne peut travailler que sur son poste et personne d’autre ne peut l’utiliser, …). L’objectif est donc d’offrir un contexte applicatif pour partager l’identification, l’échange d’informations entre applications et pour faciliter le développement de nouvelles applications, mais aussi d’identifier l’utilisateur et de partager cette identification entre applications et rendre l’utilisateur indépendant de son poste de travail.

Figure A.1 Typologie des intranets

La typologie présentée ici représente de manière sommaire et non exhaustive différentes catégories d’intranet pouvant être introduit dans les entreprises de manière globale.

3.2. Les services d’intranet

Les services d’un Intranet peuvent être divisées en deux grandes catégories qui permettent : [49] Ø La circulation des données et leurs transformations en connaissances :



• Messagerie électronique : elle permet par exemple de consulter des collègues connus pour leurs compétences.

• Travail de groupe ou groupware : c’est la possibilité de travailler sur un même dossier. mais de manière décalée et en ayant toujours accès à la dernière version.

• Automatisation des procédures workflow : c’est le flux de données et l’automatisation.

• Gestion des connaissances ou knowledge management : c’est la capitalisation et la gestion des compétences.

Ø Le partage des ressources :

• Partage des ressources physiques (planning d’utilisation de salles, de matériels, etc….).

• Partage de l’intelligence (messagerie, gestion de projets, etc…).

• Partage de la connaissance (revues de presse, archives, appels d’offres, veille technologique, etc…).

• Partage du temps (agendas partagés, planning des réunions, etc...).

4. Architecture d’un intranet

Généralement, un réseau Intranet possède une architecture clients/serveur(s) n tiers qui repose sur tout ou partie des composants suivants : [47]

Ø Serveur(s) de fichiers, SAN (pour le partage des données)

Ø Serveur(s) http de l'intranet (semblable(s) à un serveur web)

Ø Serveur(s) de bases de données (pour le stockage des informations)

Ø Serveur(s) de messagerie (pour l'échange de courriers électroniques ou la messagerie instantanée)

Ø Serveur(s) d'authentification (pour l'identification des utilisateurs et le stockage des annuaires)

Ø Serveur(s) et logiciel client de supervision réseau/systèmes (le protocole SNMP est généralement utilisé pour obtenir des informations sur le statut des différents composants du réseau)

Ø Serveur(s) de vidéoconférence

Ø Switches, routeurs, pare-feux (éléments de l'infrastructure)



5. Design d’intranet

Internet et intranet sont deux espaces de fonctionnalités différentes, cela doit se répercuter sur leurs identités graphiques respectives et leurs contenus (source : Jakob Nielsen's Alertbox for September 15, 1997 "The Difference Between Intranet and Internet Design").

On va présenter un tableau qui montre quelques différences (les plus connus) entre l’Intranet et l’Internet : [46,48]

Internet Intranet

Des infrastructures publiques de transmission des données (payées par les opérateurs Internet).

Des infrastructures privées de transmission des données (les réseaux locaux des entreprises ou groupes concernées) + éventuellement l’utilisation de l’Internet comme un réseau étendu privé.

Des outils des protocoles (les protocoles, langages et technologies de l’Internet).

Des outils (une partie des protocoles, langages et technologies de l’Internet).

Des services : ceux fournis par les utilisateurs et entreprises connectées à) l’Internet.

Des services : ceux fournis par les utilisateurs et entreprises connectées à l’Intranet.

Des informations : celles produites par les utilisateurs de l’Internet.

Des informations : celles produites par les utilisateurs de l’Intranet.

Tableau A.1 Table de comparaison entre l’Intranet et l’Internet

10. Conclusion

L’intranet est une solution qui a permis un saut considérable dans les systèmes d’informations. De même qu’il constitue une solution aux organismes et aux particuliers de partager des informations, de communiquer en temps réel sans aucun effort, ni aucun coût.


Annexe B Symboles et mots réservés en B

La méthode B utilise des notations ensemblistes pour spécifier les états, les invariants, les conditions …Cependant la méthode B introduit des symboles spécifiques pour représenter ces notations. Nous présentons ci-dessous des symboles que nous avons utilisés

Symbole

Signification

Syntaxe

Notation

Ø ensemble vide

{}

× produit cartésien

Ensemble × Ensemble

*

a doublet de valeur

Elément a élément |->

P ensemble des sous-ensembles

P(Ensemble)

POW

F ensemble des sous-ensembles finis

F(Ensemble)

FIN

.. intervalle

élément .. élément

..

→ fonction totale

Ensemble → Ensemble

→

∈ appartient

élément ∈Ensemble

:

⊂ inclus Ensemble ⊂ Ensemble

<< :

⊆ inclus ou égal

Ensemble ⊆ Ensemble

< :


Annexe C Langage FoCaL

Le langage FoCaL

1. Introduction

Le projet FoCaL a été lancé en 1998 par T.Hardin et R.Rioboo dans l’objectif d’aider à tous les stades de développement de logiciel critique dans le domaine de la sécurité. Les méthodes utilisées dans ces domaines sont en évolution, les approches Ad-Hoc et empiriques ont été remplacées par des méthodes plus formelles. [01]

Le système FOCAL offre un langage permettant de décrire des spécifications en introduisant des noms et des propriétés et de décrire progressivement des implantations en introduisant des définitions et des preuves des propriétés. Une espèce FOCAL représente une étape d’un développement, rassemblant déclarations, définitions, propriétés et preuves connues à cette étape. Une espèce peut être construite par héritage multiple, liaison retardée, ajout de définitions/preuves, paramétrisation par des (interfaces) d’espèces et passage de paramètres actuels (des espèces complètement définies et ayant subi une abstraction). Le compilateur produit trois fichiers: un exécutable CAML, une preuve en Coq validant toute l’espèce sous certaines hypothèses, un fichier de documentation exploitable par des outils XML, LateX, qui sert aussi à la traduction vers UML. L’atelier offre un outil de démonstration automatique produisant des preuves Coq et plusieurs outils d’aide au développement.

2. Définition

Un langage “inspirant confiance” pour spécifier, développer et vérifier une application par une approche formelle, tout en restant pragmatique. [02]

Un programme Focal est la définition d'une hiérarchie d'espèces terminée par des collections

Ø Compilation vers OCaml pour l'exécutable Ø Compilation vers Coq pour les preuves Ø Compilation vers LaTeX ou XML pour la documentation

Résumé FoCaL est un environnement de programmation actuellement utilisé pour l’implantation de politiques de sécurité. Les développements récents effectués avec l’atelier Focal ont permis d’obtenir un cadre générique dans lequel il est possible d’implanter des politiques de sécurité pour le contrôle d’accès.



Figure C.1 Hiérarchie FoCaL

3. Les données élémentaires du langage focal

Pour développer une librairie dans le domaine de la sécurité (il existe d’autres domaines), on va définir les objets qui sont manipulés dans ce domaine, et les différentes façons dont ils peuvent interagir. Dans le cas su calcul formel, on peut envisager quatre grands types d’objets qui sont :

1. Les éléments des différents ensembles, comme 0, x2+2x+1, les fonctions sur les entiers, etc., nous les appellerons entités

2. Les structures algébriques génériques telles que les groupes, les anneaux, ou les polynômes à coefficients dans un anneau quelconque. Nous appellerons ces structures des espèces. ces structures forment une hiérarchie : un corps est un anneau ou tout élément non nul possède un inverse. De même les polynômes forment eux-mêmes un anneau qui est lui même un groupe abélien possèdant une opération supplémentaire * association et ayant un élément neutre, etc.

3. Les opérations et les propriétés qui définissent ces structures, regroupées sous le nom de méthodes.

4. Les structures particulières, telles que l’anneau des entiers Z, l’anneau des polynômes à coefficients entiers Z[K], l’anneau des polynômes à plusieurs variables et à coefficients entiers, Z[X1,X2,... ,Xn], etc. Nous parlerons alors de collections, c’est dans les collections qu’on manipule effectivement les entités : les espèces sont des vues plus générales et plus abstraites, qui servent à bâtir, pas à pas les collections dont on à besoin.

4. Les structures mathématiques de base

On va définir quelques structures algébriques utilisées en calcul formel :

Ø Un sétoide est un ensemble muni d’une relation algébrique (une égalité) Ø Un semi-groupe est un sétoide muni d’une loi de composition (notée généralement * ou +,

quand elle est commutative, c’est-à-dire x*y=y*x). Cette loi est associative, c’est-à-dire qu’on a (x*y)*z=x*(y*z). On note alors xn=x*x*...*x n fois.



Ø Un monoide est un semi-groupe muni d’un élément neutre, 1(ou 0 quand la loi est notée additivement), vérifiant 1*x=x*1=x.

Ø Un groupe est un monoide ou tous les éléments ont un inverse, c’est-à-dire ∀ x ∀ y x*y=y*x=1, c’est y (unique) est noté x(-1) (-x en notation additive).

5. Les concepts de base

i. Toplevel-definition

On appel toplevel-definition la définition qui apparaît au dessus des espèces et des collections. Ces définitions peuvent être :

Ø Espèces Ø Collections Ø Type définitions Ø Théorèmes généraux (not depending on a species) Ø Fonctions à être directement évaluées

N’importe quel toplevel-definition se termine avec un double point virgule (;;).

ii. Espèces

Les espèces sont des nœuds dans l’hiérarchie focal. Une espèce est une séquence de méthodes et de champs (fields). Chacune d’elle se termine par un point virgule ( ;)

Il y a plusieurs types de méthodes :

La représentation : défini le type des entitées manipulées dans les espèces. La représentation peut être de type variable et il peut être ″ not yet defined ″ ou ″ only declared ″ et il n’est pas explicitement introduit. Il peut être lié à un type défini par un type d’expression complexe pouvant contenir des types variables (introduit par la collecte de paramètres). Soit, ce type de valeur est obtenu par héritage ou est introduit par mot clé représentation suivi de = suivi de type d’expression. Enfin, pour obtenir un espèce complet, la représentation doit être un type entièrement instancier.

Dans le contexte d’une espèce, la représentation est désigné par Self, la représentation n’est jamais de type polymorphique. Quand elle est seulement déclarée, elle est de type variable, qui peut recevoir une seule instance.

iii. La signature

Species name= Meth1 ; Meth2 ; End ;;



Elle introduit les noms des constantes et des fonctions, fournissant uniquement leur type comme type d’expression. Une signature commence par le mot-clé signature suivi par le nom introduit suivi par : suivi d’un type d’expression.

Self représente la représentation (donc un type) de la présente espèce. D’où l’opération de pousser un entier dans une pile prend comme paramètre l’entier de pousser (integer to push), la pile dans laquelle on pousse donne une nouvelle pile, qui est une entité de type Self .

iv. Les fonctions

Ce sont des implémentations des signatures, fournissant un code effectif. Une fonction est introduite par le mot-clé let suivi par le nom suivi de = suivi par une définition. Une fonction récursive est introduite par let rec pour mettre explicitement la récursivité.

Paramètres de la fonction peuvent être des entités (valeurs) de l’espèce elle-même (qui est le type de la représentation, ce qui désigné par Self), entités des collections connus, les valeurs de types connus.

Les fonctions peuvent utilisées dans leurs corps d’autres méthodes des espèces, toplevel-definition des fonctions, méthodes des collections, ou méthodes des paramètres de collection (méthods of collection parameters).

v. Les propriétés

Ce sont des formules contenant des noms déjà introduits. Une propriété peut être considérée comme une déclaration.

Species IntStack= Signature push : int à Self à Self ; End ;;

Species IntStack= Representation = Int List ; Let push (v in int, s in Self) = v ::s ; End ;;

Species IntStack= … property push_returns_nom_empty : all v in int, all s in Self, push (v,s) à is_empty (s) ; end ;;



Les preuves de propriétés peuvent être en retard (can be delayed), qui est ensuite fait en utilisant le champ proof dans l’espèce.

vi. Théorème

Ce sont des propriétés avec leurs preuves. En fait, lors de la définition d’une propriété, on donne seulement la définition du théorème, laissant de coté sa preuve. Un théorème peut être considéré comme une définition.

Paramétrisation

On va décrire le mécanisme de construction pas à pas des espèces à partir des espèces existantes : la paramétrisation.

1) Les paramètres de collection (collection parameters)

Les méthodes ne peuvent pas être polymorphes. Par exemple : comment implémenter un type polymorphe comme de liste ? Grouper les éléments dans une liste ne doit pas dépendre du type de ces éléments. La seule contrainte est que tous les éléments sont de même type. Aussi, la représentation ML-Like de liste doit être :

ǎ est le paramètre du constructeur de type list, qui est effectivement un type ML polymorphe. On Focalize, il y a la création des espèces comme :

Au lieu d’abstraire le type de paramètre et de le laisser libre dans le contexte de l’espèce, en Focalize dans l’exemple, on a paramétré l’espèce par un paramètre appelé Elem:

Species IntStack= …. Theorem push_return_non_empty : All v in int, all s in Self push(v,s) à is_empty (s) ; Proof =…. ; End ;;

Type ǎ liste = | Nil | cons of (ǎ * ǎ list)

Species list = Signature nil : Self ; Signature cons : ǎ à Self à Self ; End;



Les paramètres de collection sont introduits par leurs noms et suivi par leurs mots-clés, suivis par le nom d’interface. Dans l’exemple, Basic_object est une espèce pré-definie de la librairie standard, ne contenant que peu de méthodes et ce nom est utilisé ici pour désigner l’interface de cette espèce. Une collection de paramètres peut être instanciée par n’importe quelle collection dont l’interface est compatible avec celle requise par les espèces paramètres. Dans l’exemple, n’importe quel paramètre instancier Elem est une collection dont l’interface contient au moins les méthodes répertoriées dans l’interface de Basic_object.

Dans l’exemple, on utilise le paramètre Elem pour construire la signature de notre méthode. On note que les noms de collection peuvent être utilisés dans le type d’expression pour désigner la représentation abstraite de la collection. Ici « abstrait » signifie que la représentation n’est pas visible mais on peut se référer à elle comme un type abstrait. En d’autres termes Elem → Self → Self est le type de fonctions :

Ø Dans un premier argument dont le type est la représentation d’une collection ayant une interface compatible avec l’interface Basic_object

Ø Le second argument c’est que le type est la représentation de l’espèce courante Ø Et renvoyant une valeur dont le type est la représentation de l’espèce courante

2) Entity parameter

C’est le deuxième type de paramètre, ce paramètre peut être instancié par l’entité d’une certaine collection.

Par exemple, pour obtenir une espèce offrant modulo additionnel une valeur entière, nous avons besoin de les paramétrer par une entité de collection implémentant les entiers et de donner un moyen de construire une entité représentant des valeurs du modulo. Ce paramètre est appelé paramètre d’entité et il est introduit par le mot clé in.

Species List (Elem is Basic_object )= Signature nil :Self ; Signature cons : Elem à Self à Self ; End ;;

Species AddModN (Number is Interface ForInts, val-mod is number) = Representation = Number ; Let add (x in Self, y in Self) = Number ! modulo (Number ! add (x,y), val_mod) ; End ;; Species ;;



Aussi, toute collection créée à partir de AddModN, l’addition modulo la valeur effective instancier val mod. Il est alors possible de créer plusieurs collections avec une valeur modulo spécifique. Par exemple, en supposant que l’espèce AddModN est complète et a une méthode de int apte à créer une valeur de la représentation d’un entier, on peut créer une collection implémentant addition modulo 42, on suppose aussi que nous avons une collection AcolImplementingInts ayant au moins InterfaceForInts comme interface.

Actuellement, les paramètres de l’entité doivent vivre dans une collection. Il n’est pas permis de spécifier un paramètre entité vivant dans un type de base comme int, string, bool, … cela signifie en particulier que ces types de base doivent être intégrés dans un ensemble si nous voulons utiliser leurs valeurs en tant qu’entité paramétrés.

Héritage et ces paramètres

Le deuxième mécanisme pour construire une espèce complexe se base sur des espèces existantes

Héritage

L’héritage permet de créer des espèces, non pas à partir de zéro, mais en intégrant les méthodes des autres espèces. Le mécanisme d’héritage permet également de redéfinir les méthodes déjà existantes si elles possèdent le même type d’expression. Pour les théorèmes, avoir le même type c’est tout simplement avoir le même état (mais les preuves peuvent être différentes).

Au cours de l’héritage, il est également possible de remplacer la signature par une définition effective (effective definition), de redéfinir une propriété par un théorème et de la même idée, d’ajouter une preuve à une propriété en vue de la redéfinir conceptuellement comme un théorème. En outre de nouvelles méthodes peuvent être ajoutées à l’espèce hérité :

Collection AddModd42 omplements AddModN (AcollImplementingInt, AcollImplementingInts ! frrom_int (42)) ;;

Species IntCouple= Representation = (int*int) ; Let print (x in Self)=… ; Let create (x in int , y in int) = (x,y) ; Let first (c1,c2) = c1 ;

…… end ;; species OrderedIntCouple inherits (IntCouple) = let create (x in int, y in int) = if x<y then (x,y) else (y,x) ; property is_ordered : all c in Self, first (c) <=scnd (c) ; end ;;



6. Installation et compilation

i. Les logiciel exigés ou de base (Requirement software)

Pour pouvoir développer avec l’environnement FoCalize, des outils sont exigés. Tous ces outils peuvent être téléchargés à partir de leurs sites :

Ø The Objective Caml compiler (version ≥3.10.2)

http://caml.inria.fr

Ø The Coq Proof Assistant (version 8.1p14)

http://coq.inria.fr

ii. Les logiciels optionnels

Le compilateur FoCalize peut générer des graphes dépendants à partir du code source compilé. Il les génère dans le format adéquat pour être exécuté et visualisé by les outils du « grapheoiz » package. Si on veut examiner ces graphes, on doit aussi installer ce logiciel à partir de : http://www.graphviz.org

iii. Les systèmes d’exploitations

FoCalize est développé sous Linux en utilisant des logiciels gratuits. Cependant, n’import quel système d’exploitation basé sur Unix doit supporter FoCalize. Les systèmes listés sont : Fedora, Debian, Suse, BSD.

Les utilisateurs Windows peuvent exécuter FoCalize via l’environnement Unix-Like qui est Cygwin. Ce logiciel est distribué gratuitement à partir de : www.cygwin.com

iv. Installation

FoCalize est distribué comme un tarball contenant le code source (whole source code) de l’environnement de développement. On doit en premier éclater (deflate) l’archive (un répertoire va être créée) par :

Tar xvzf focalize-x.x.x.tgz

Après, on va dans le répertoire source :

Cd focalize-x.x.x/

On doit maintenant configurer le processus de consultation (build process) par :

./configure


http://caml.inria.fr/

http://coq.inria.fr/

http://www.graphviz.org/

http://www.cygwin.com/


Le script de configuration alors demande quels sont les répertoires où on doit installer les composants FoCalize. On doit uniquement appuyer sur entrer pour interrompre (keep) l’installation par défaut des répertoires.

Latour :˜/src/focalize$./configure˜/pkg

Où installer les FoCalize binaries ?

Default is /usr/local/bin

Just press enter to use default location

After then configuration ends, just build the system

Make all

And finally, get root priviledges to indtall the FoCalize system

Su Make install

v. Processus de compilation et les sorties (outputs)

On appel unité de compilation (unit compilation) un fichier contenant le code source pour toplevel-definition, species, collection, les rôles de visibilité (visibility rules) sont definies selon les statuts des unités de compilation

i. Outputs

Le développement FoCalize contient à la fois le "code de calcul" (c'est-à-dire le code exécutant certaines opérations qui conduisent à un effet, un résultat) et la logique des propriétés.

Lors de compilation, deux sorties dont générées :

Ø Le « computational code » est compilé dans la source OCaml qui va être compilé dans le compilateur OCaml qui conduit à un exécutable binaire. Dans ce passage, les propriétés logiques sont rejetées car elles ne conduisent pas à un code exécutable.

Ø Le «code de calcul » et les propriétés logiques sont compilées dans un modèle Coq. Ce modèle peut ensuite être envoyé à l'assistant de preuve Coq, qui permettra de vérifier la cohérence du "code de calcul" et la logique des propriétés (dont les preuves doivent être fournies évidemment) du développement FoCalize. Cela signifie que le code Coq généré n'est pas destiné à être utilisé pour générer un code source OCaml par extraction automatique. Comme indiqué ci-dessus, l'exécutable généré est préféré en utilisant directement le code OCaml généré. Dans cette idée, Coq agit comme un évaluateur du développement au lieu d'un générateur de code.



Plus précisément, FoCalize génère d'abord un pré-code Coq, c'est-à-dire un fichier contenant plus de syntaxe Coq "Trous" en place des preuves écrites dans la langue de preuves FoCalize. Ce type de fichiers est suffixé par « .Zv » au lieu de directement ". V". Lors de l'envoi de ce fichier pour Zenon, ces "trous" seront comblés par des codes Coq générés automatiquement par Zenon (si elle réussit à trouver une preuve), ce qui conduit à un pur fichier de code Coq qui peut être compilé par Coq.

ii. La compilation de la source

Compiler un programme FoCalize implique plusieurs étapes qui sont gérées automatiquement par la commande focalizec. À l'aide des options de ligne de commande, il est possible d'ajuster les étapes de génération de code.

i. FoCaLize source compilation. Cette étape prend le code source FoCalize et génère le code OCaml et / ou pré-code Coq. On peut désactiver la génération de code pour l'un de ces langages, ou les deux. Dans ce cas, aucun code n'est produit et qu’on obtient le code objet FoCalize produit sans plus d'autre sortie et le processus se termine à ce point. Si on désactive l'un des langages cibles, on ne peut pas obtenir de fichier généré pour elle, donc il n’est pas nécessaire de s'attaquer à ses processus de compilation décrit ci-dessous.

En supposant qu’on génère le code OCaml et Coq, on obtient deux fichiers générés: source.ml (le code OCaml) et source.zv (le "pré-" Coq de code).

ii. OCaml code compilation. Cette étape prend le code généré OCaml (il s'agit d'un fichier source OCaml) et on le compile. Cela se fait comme toute compilation ordinaire d’OCaml. La seule différence est que le chemin de recherche contenant le chemin d'installation FoCalize et nos propres extra-répertoires de fichiers source FoCalize sont automatiquement transmis au compilateur OCaml. Ainsi, ces étapes se comportent comme un manuel d’invocation (manual invocation):

ocamlc -c -I /usr/local/lib/focalize -I mylibs -I myotherlibs source.ml

Ce produit fichier objet OCaml source.cmo. Notez qu’on peut aussi demander à utiliser le code OCaml dans le mode natif, dans ce cas, la version de la ocamlopt du compilateur OCaml est sélectionnée et l'objet de fichiers est ". Cmx" fichiers au lieu de ". Cmo".

iii. “Pre-”Coq code compilation. Cette étape prend le fichier généré ". Zv" et tente de produire un véritable fichier source Coq ". V" en remplaçant les preuves écrites dans le langage de preuve FoCalize par certaines preuves effective du Langage Coq trouvées par le théorème de preuve Zenon. Notez que si Zenon échoue à trouver une preuve, un trou reste dans le fichier final Coq. V. Ce trou apparaît comme un texte "doivent s'effectuer manuellement." Au lieu de l'efficacité de la preuve. Dans ce cas, Coq échoue dans la compilation du fichier, de sorte que l'utilisateur doit faire la preuve à la main ou modifier son fichier source original FoCalize pour obtenir une preuve. Cette étape fonctionne comme un manuel d'invocation:



zvtov -new source.zv

iv. Coq code compilation. Cette étape prend le code généré ". V" et le compile avec Coq. Cela se fait comme toute compilation régulière Coq. La seule différence est que le chemin de recherche contenant le chemin d'installation FoCalize et de nos propres extra-répertoires de fichiers sources FoCalize (own used extra FoCaLize source files directories) sont automatiquement transmis au compilateur Coq.

coqc -I /usr/local/lib/focalize -I mylibs -I myotherlibs source.v

Une fois cette étape terminée, on a les fichiers objet Coq et on est sûr que Coq a validé le modèle du programme (program model), les propriétés et les preuves. Le dernier "évaluateur" de la chaîne d'outils a accepté votre programme.

Une fois que tous les fichiers distincts sont compilés, pour obtenir un exécutable à partir des fichiers de l'objet OCaml, on doit lier tout l’ensemble, en fournissant le même chemin de recherche ci-dessus et les fichiers ".cmo" correspondant à l'ensemble des fichiers OCaml générés à partir de tous les fichiers FoCalize ".foc". On a besoin d'ajouter les fichiers ".Cmo " correspondant aux modules de la bibliothèque standard qu’on utilise.

ocamlc -I mylibs -I myotherlibs install_dir/ml_builtins.cmo install_dir/basics.cmo install_dir/sets.cmo ... mylibs/src1.cmo mylibs/src2.cmo ... myotherlibs src3.cmo mylibs/src3.cmo ... source1.cmo source2.cmo ... -o exec_name


Biobibliographie et Webographie

Bibliographie [03] PFE Pr.Rahmouni 2002-2003 Sécurité informatique

[04] Mémoire d’Ingénieur d’Etat en Informatique K.Moustefaoui et M.Moussa

Conception et réalisation d’un outil Web pour la messagerie électronique et son intégration dans le

site Web de l’université, 2000

[05] Marc Laroche Sécurité des réseaux analyse et mise en oeuvre 1996.

[06] Mounir Mokhtari "Technologies des réseaux" séminaire février 2001, département

informatique, facultés des sciences, Univ Oran.

[07] Guedach-Nekrouf

[08] [http://www.guideinformatique.com]

[09] [http://www.e-atlantide.com/securite/smurf.htm]

[10] Rudiments de cryptologie Richard LEROY

[11] Virus/Anti-virus nouvelles technologies réseaux Guillaume CHARPENTIER – Olivier

MONTIGNY – Mathieu ROUSSEAU

[12] [http://www.topvirus.com]

[13] ditwww.eplf.ch/SIC/SA/publications

[14] Formal Models for computer security

[15] Pierangela Samarati and Sabrina de Capitani di Vimercati, Access Control: Policies, Models,

and Mechanisms, FOSAD 2000, LNCS 2171, pages 137-196, 2001.

[16] D. E. Denning, A lattice model of secure information flow, Communications of the ACM,

19(5): 236-243, May 1976.

[17] D. E. Bell and L. J. Lapadula, Secure computer systems: Mathematical foundations, Technical

Report ESD-TR-73-278, vol. 1, The Mitre Corp., Bedford, MA, 1973.

[18] D. E. Bell and L. J. Lapadula, Secure computer systems: A mathematical model, Technical

Report ESD-TR-278, vol. 2, The Mitre Corp., Bedford, MA, 1973.

[19] D. E. Bell and L. J. Lapadula, Secure computer systems: Mathematical foundations and model,

M74-244, The Mitre Corp., Bedford, MA, 1974.

[20] D. E. Bell and L. J. Lapadula, Secure computer systems: Unified exposition and multics

interpretation, MTR-2997, The Mitre Corp., Bedford, MA, 1975.

[21] K. J. Biba, Integrity considerations for secure computer systems, Technical Report TR-3153,

The Mitre Corporation, Bedford, MA, April 1997.


[22] J.A Goguen et J. Meseguer, Unwinding and inference control, In Proc. of the 1984 Symposium

on Research in Security and Privacy, pages 75-86, 1984.

[23] Stéphan Hadinger, Le contrôle d’accès au SI, projet IS@ France Télécom,

www.rd.francetelecom.fr/ fr/conseil/mento20/chapitre7.pdf

[24] A. Abou El Kalam, R. Elbaida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A.Miège,

C. Saurel, G. Trouessin, ORBAC : un modèle de contrôle d'accès basé sur les organisations, Cahiers

francophones de la recherche en sécurité de l'information, Numéro II, 1er trimestre 2003, pp30-43.

[25] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn and Ramaswamy

Chandramouli, Proposed NIST Standard for Role-Based Access Control, ACM Transactions on

Information and System Security, volume 4,n.3,August 2001, pages 224-274.

[26] M. Nyanchama and S.Osborn, The graph model and conflicts of interest, ACM Trans. Inf.

Syst. Sec. 2, 1.

[27] Anas Abou El Kalam, Yves Deswarte, Sécurité des systèmes d’information et de

communication dans le domaine de la santé, Sécurité et Architecture Réseaux (SAR'03), Nancy

(France), 30 juin - 4 juillet 2003.

[29] National Research Council. Computers at Risk : Safe Computing in the Information Age, 1991.

National Academy Press.

[30] F. B. Schneider. Enforceable security policies. Information and System Security, 3(1) :30–50,

1998.

[31] C. Bidan. Sécurité des systèmes distribués : apport des architectures logicielles. Thèse de

doctorat, Université de Rennes I, mai 1998.

[32] M. Gasser. Building a secure computer system. Van Hoostrand and Reinhold, 1988.

[33] Department of Defense Standard. Trusted computer system evaluation criteria. Rapport

technique 5200.28-STD, DoD, d´ecembre 1985.

[34] J. McLean. Security models. In Encyclopedia of Software Engineering. Wiley & Sons, 1994. J.

Marciniak édition.

[35] "Remarques relatives à l’emploi des méthodes formelles (déductives) en sécurité des systèmes

d’information", Eric Jaeger

[36] "Modélisation et vérification de politiques de sécurité", Amal HADDAD 2005

[37] Manuel de référence du langage B

[38] "Guarded commands, nondeterminacy and formal derivation of programs" E.W.Djikstra

[39] "Assigning programs to meanings", J.R. ABRIAL

[40] "Formalisation, comparaison et implantation d'un modèle de contrôle d'accès à base de rôles",

Lionel Habib

[41] "Un cadre sémantique pour le contrôle d’accès", Mathieu Jaume Charles Morisset


[42] FoCaLiza reference manual Thérèse Hardin, François Pessaux, Pierre Weis, Damien Doligez

[46] Mémoire de fin d’études " conception et réalisation d’un portail d’entreprise à l’aide du

langage UML : Forum ", Benbadra Kambouche Encadreur Pr M-K RAHMOUNI Univ d’Oran 2007

[48] Mémoire de fin d’études " conception et réalisation d’un portail d’entreprise : Groupware "

Boualga, Toumi Encadreur Pr M-K RAHMOUNI Univ D’Oran

[49] Guide de conception d’un Intranet, Ludovic Barth

[51] Les systèmes de détection d'intrusions David Burgermeister, Jonathan Krier

[55] "Les politiques de sécurité", Therrezinha Fernandes

[56] "Controler le control d’accès : approches formelles", Mathieu Jaune et Charles Morisset

[57] "Descriptions formelles : comprendre, corriger implanter, reutiliser Application au contrôle

d’accès", Mathieu Jaume

[58] "Politiques de contrôle d’accès multi-niveaux : test de conformité vis-à-vis des flots avec

l’outil FoCaL", Mathieu Carlier Catherine Dubois

[59] "La sécurité informatique", Lescop Yves

[60] "Réalisation d’un pare-feu", Mémoire d’ingénieur, khatir & bouchaib, Pr Mustapha-Kamel

RAHMOUNI; Université d’Oran Es-Sénia, (2006).

Webographie [01] sécurité cours, Janvier 2001 G Florin, S Natkin

Site : http://deptinfo.cnam.fr/Ensiegnement/DESS/surete/securite/.

[02] Guide de la sécurité des systèmes d’information à l’usage des directeurs

Robert Longeon, Chargé de mission à la sécurité des systèmes d’information du CNRS

Jean-Luc Archimbaud Chargé de mission à la sécurité des réseaux du CNRS

Site : http://www.cnrs.fr/Infosecu

[28] Robert Longeon & Jean-Luc Archimbaud ; « Guide de la sécurité des systèmes d’information a

l’usage des directeurs », Cours CNRS, Site : http://www.cnrs.fr/Infosecu.

[43] www.secuser.com

[44] www.secusys.com

[45] www.securite.org

[47] www.google.com/les intranets

[50] http://www.securite-informatique.gouv.fr/gp_article41.html

[52] http://www.kh.refer.org/cours_en_lignes/cours_reseau/Page/chap7_lecon3.htm

[53] http://www.frameip.com/vpn/

[54] http://sebsauvage.net/comprendre/ssl/


http://deptinfo.cnam.fr/Ensiegnement/DESS/surete/securite/

http://www.cnrs.fr/Infosecu

http://www.cnrs.fr/Infosecu

http://www.secuser.com/

http://www.secusys.com/

http://www.securite.org/

http://www.securite-informatique.gouv.fr/gp_article41.html

http://www.kh.refer.org/cours_en_lignes/cours_reseau/Page/chap7_lecon3.htm

http://www.frameip.com/vpn/

http://sebsauvage.net/comprendre/ssl/

Les acronymes

ACK

AES

AH

ASCII

BST

CAST

CBC

CdC

CFB

CPU

CRL

DAC

DES

DSA

ECB

ECC

ESP

FTPS

HIDS

HTTPS

IBM

ICMP

IDEA

IDS

IP

IPS

ISO

LAN

MAC

MAC

MD

ACKnowledgement

Advanced Encryption System

Authentication Header

American Standard Code for Information Interchange

Basic Security Theorem

Carlisle Adams/Stafford Tavares

Cipher Block Chaining

Cahier de Charges

Cipher FeedBack

Computer Processor Unit

Certificate Revocation List

Discritionary Access Memory

Digital Encryption System

Digital Signature Algorithm

Electronic CodeBook

Elliptic Curve Cryptography

Encapsulating Security Payload

File Transfer Protocol Secure

Hote Intrusion Detection Systems

HyperText Transfer Protocol Secure

International Business Machines

Internet Control Message Protocol

International Data Encryption Algorithm

Intrusion Detection Systems

Internet Protocol

Intrusion Prevention Systems

International Organization for Standardization

Local Area Network

Message Authentication Code

Mondatory Acces Memory

Message Digest


http://en.wikipedia.org/wiki/International_Organization_for_Standardization

MIME

MOSS

NAS

NIDS

NIST

NNTP

NSA

OFB

ORBAC

PC

PEM

PGP

POP

RAM

RBAC

RC4/5

RFC

ROM

RSA

SHA

SHS

SMTP

SSL

SSH

SYN

S/MIME

TCP

UDP

VPN

WAN

Multipurpose Internet Mail Extensions

Mime Object Security Service

Network Access Server

Network Intrusion Detection Systems

Institut National des Standards et de la Technologie

Network News Transfer Protocol

National Security Agency

Output FeedBack

Organisation Based Access Control

Personal Computer

PErsonnels Mail

Pretty Good privacy

Post Office Protocol

Random Acces Memory

Role Based Access Control

Rivest Cipher

Request For Comments

Read Only Memory

Rivest Shamir Adleman

Secure Hash Algorithm

Secure Hash Standard

Simple Mail Transfer Protocol

Secure Socket Layer

Secure Shell

Synal

Secure Multipurpose Internet Mail Extensions

Transmission Control Protocol

User Datagram Protocol

Virtual Protocol Network

Wide Area Network


conception et réalisation d ˇun agl pour la …car, lors de la conception fonctionnelle, on ne...

Documents