Formalisation de la confiance aux applications

  1. Infrastructure de gestion de la confiance sur Internet
  2. Définitions: Contrôle, Transaction, Authentification et Certificat
  3. La confiance dans les domaines d’application Internet
  4. Risque, Réputation, Recommandation et domaine d’application Internet
  5. Sécurité, Négociation et Gestion de la confiance confiance sur Internet
  6. La gestion de la confiance sur Internet basée sur la politique
  7. Gestion de la confiance au web sémantique basée sur l’expérience
  8. Approches hybrides de la gestion de la confiance sur Internet
  9. Système de négociation de la confiance au web sémantique
  10. Prise en charge du risque pour la gestion de confiance sur Internet
  11. Comparaison des systèmes de gestion de confiance sur Internet
  12. Contraintes pour un système de gestion de la confiance
  13. Modèle global de gestion de la confiance sur Internet
  14. Modèle de confiance de SECURE
  15. Logique temporelle linéaire LTL, Confiance au web
  16. Framework logique pour les systèmes de réputation
  17. Architecture d’un système de gestion de la confiance
  18. Formalisation de la confiance aux applications
  19. Transaction dans le cadre du commerce électronique et la confiance
  20. Évaluation de la contribution d’un utilisateur à Wikipédia
  21. La notion de négociation, Modèle de la négociation de la confiance
  22. Architecture du système de négociation de la confiance
  23. Protocole de négociation, Système de négociation de la confiance
  24. Module de négociation de la confiance
  25. Transaction de e-commerce et Tiers de confiance pour le paiement
  26. Politique de confiance dans une transaction de e-commerce
  27. La gestion de la Stratégie de Négociation – Transaction en ligne
  28. Processus de gestion du risque, Système de gestion de la confiance
  29. Modèle du risque risque et le système de gestion de la confiance
  30. Politique du tiers de paiement, Transaction de commerce électronique
  31. Prototype de négociation de la confiance : Architecture
  32. Politique de confiance: Spécification de la politique en XML
  33. Réalisation du module de vérification de la politique de sécurité
  34. Le système de gestion de la confiance au web

5.2 Formalisation de la confiance
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

Hoan VU

École Nationale Supérieure des Mines de Saint-Étienne - Thèse pour obtenir le grade de Docteur. Spécialité : Informatique

Hoan VU (CV)

Cliquez sur suivant article pour lire la suivante partie de ce mémoire:

Abonnez-vous!
Inscrivez-vous gratuitement à la Newsletter et accédez à des milliers des mémoires de fin d’études !
Publier son mémoire!
WikiMemoires - Publier son mémoire de fin d’études !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *