Cette section présente la formalisation de notre système. Nous expliquons comment la confiance est modélisée et comment une décision est prise pour établir une relation de confiance entre les entités du système.
5.2.1 Formalisation des événements
Les événenements utilisés dans le système sont prédéfinis et nous avons besoin d’un mécanisme pour les formaliser. Comme nous l’avons vu, toutes les actions et toutes les données échangées par le système sont observées et transformées en événements. Il est donc indispensable de pouvoir les identifier. Dans le cadre d’une application particulière, nous devons décrire l’ensemble des événements qui sont utiles.
Bien entendu, chaque application peut interpréter ses observations comme elle le désire, mais nous avons identifié un certain nombre de données qui apparaissent de manière récurrente et nous proposons de les intégrer de manière standard dans notre modèle. Nous avons retenu les informations concernant les qualifications, les recommandations, l’expérience et les risques; elles sont modélisées directement par les événements correspondants.
Toutes les interactions observées par le système sont traitées par les composants Application Interface et Event Analyzer qui se chargent de les transformer en événements correspondants. Comme les événements sont organisés et contraints par une structure d’événements, s’ils ne sont pas indépendants, ils doivent respecter les relations de causalité et ne pas provoquer de conflits.
Les événements sont à la base de la construction de l’historique et la politique. Ils sont considérés comme des atomes des prédicats de la politique. Lors d’une transaction, les événements sont sauvegardés dans une session de l’historique en respectant les contraintes induites par la structure d’événements définie pour l’application.
Nous détaillons ci-dessous les différents types pour la formalisation des événements en classe différentes.
Actions : Toutes les actions observées doivent respecter les relations définies dans la structure d’événements.
Les actions que nous pouvons modéliser comme des événements sont des demandes de services, des propositions d’échanges, des contre-propositions ou des confirmations de la demande. . .
Par exemple, dans le cas du scénario d’une transaction d’e-commerce entre un client et un vendeur, le client peut observer les actions suivantes :
passer_commande : l’action de passer sa commande auprès du site marchand,
paiement : le client paie les produits demandées au site marchand,
ignore : le client ignore la demande de paiement.
Le vendeur, de son côté, peut observer les actions suivantes :
order_request : l’événement indiquant que le client a passé une commande au marchand,
confirmer_commande_paiement : le site confirme la commande et demande d’un paiement.
Notons que nous ne nous intéressons qu’aux actions-clés de l’application pour la formalisation des événements, celles qui peuvent concerner l’évaluation de la transaction.
D’autres événements sont construits à partir des qualifications, des recommandations ou du risque échangés pendant la transaction. Pour quantifier ou qualifier des données, nous utilisons comme moyen de transformation un pré-traitement qui est soit un calcul, soit une vérification.
Qualification : les qualifications (credentials ) indiquent quelles sont les compétences ou les actions autorisées au propriétaire. La validité de ces qualifications est vérifiée par le module Credential_Verification dès qu’elles sont reçues d’un partenaire. Ce module génère des événements en indiquant leur validité; par exemple : valid_cert, invalid_cert, unknown_cert.
Risque : l’entité évalue le risque sur la transaction en utilisant le mécanisme qui lui semble le plus adapté, comme par exemple le calcul du coût des conséquences de l’action entreprise. Cette tâche est assurée par le module Risk_Evaluation. Ce module génère des événements concernant le niveau de risque : high_risk, low_risk, medium_risk.
Recommandation : les recommandations des autres acteurs du système peuvent également être observées en tant qu’événements. L’entité peut définir et prendre en compte dans sa politique des événements concernant la recommandation (par exemple :positive_recommendation, negative_recommendation, neutre_recommendation ).
Nous pouvons constater que ces types d’événements sont utilisables dans des applications différentes. Par exemple, pour les applications qui utilisent des qualifications, nous pouvons définir un ensemble d’événements dédié à cet usage : valid_cert, invalid_cert, unknown_cert.
5.2.2 Structure des événements
Les événements que nous avons formalisés doivent respecter la structure d’événements (relations de conflit et de causalité). C’est grâce à cette structure d’événements que nous pouvons définir nos politiques et construire l’historique des événements observés.
La structure d’évènement doit obligatoirement être adaptée à l’application qui l’utilise.
5.2.3 Historique
Les événements de toutes les transactions passées sont sauvegardés dans l’historique. L’historique est composé de plusieurs sessions où chaque session représente une transaction. Une session est un ensemble d’événements, qui est une configuration telle que présentée au chapitre 4.
5.2.4 Politique de confiance
L’utilisation de la structure des événements et de la logique PP-LTL présentée au chapitre précédent, nous permet de spécifier la politique de confiance de l’entité sous la forme d’une formule logique. Cette formule présente les conditions sous lesquelles l’entité fournit l’accès à ses ressources ou accède à des ressources.
L’intérêt pour chaque entité de disposer de sa propre politique est de pouvoir protéger ses ressources et sa sécurité de la manière qui lui semble la plus adaptée.
Pour protéger une ressource, l’entité peut placer différentes contraintes concernant la ressource telles que : des droits d’accès à la ressource, des contraintes d’intégrité, etc. La politique exprime toutes ces contraintes.
-Contrôle de l’accès aux ressources
Pour protéger ses ressources, l’entité ne fournit pas d’accès sans discernement. Le droit d’accéder n’est fourni qu’aux entités qui satisfont les conditions requises par l’entité. Par exemple, un utilisateur peut accéder à la base des articles de IEEE s’il est abonné au service et ce droit d’accès ne lui sera concédé qu’après son authentification par login/password
-Accès au service
Pour se protéger, l’entité n’est pas prête à accéder à un service ou à répondre à une proposition dans n’importe quelles conditions; elle va chercher à minimiser les risques qu’elle prend. Par exemple, un utilisateur peut adopter une politique qui indique qu’il n’accède jamais à un site dont l’adresse appartient à une certaine liste noire. Il considère qu’accéder à un tel site est prendre un risque trop important de recevoir des malwares ou des virus.
-Contraintes d’intégrité
Nous pouvons imposer à notre politique de respecter des contraintes d’intégrité sur les ressources. Par exemple, indiquer qu’il n’est pas possible d’ouvrir un fichier tant que celui-ci n’a pas été créé.
Après avoir réalisé l’analyse de toutes ces contraintes, il est possible à chaque entité de proposer sa propre politique en l’exprimant en logique PP-LTL.
5.2.5 Décision de la confiance
Le module de vérification de la politique est basé sur le dynamic model checking [59]. L’objectif de ce module est de vérifier la conformité de la politique et de l’historique. Chaque nouvel événement observé lors d’une transaction est ajouté à son historique et le module vérifie que la politique est toujours satisfaite.
Lire le mémoire complet ==> <(a title=»Infrastructure de gestion de la confiance sur Internet » href=»https://wikimemoires.net/2013/02/infrastructure-de-gestion-de-la-confiance-sur-internet/»>Infrastructure de gestion de la confiance sur Internet )
Thèse pour obtenir le grade de Docteur – Spécialité : Informatique
École Nationale Supérieure des Mines de Saint-Étienne
