1 / 62

ARCHITECTURE WEB – COURS II

ARCHITECTURE WEB – COURS II. ARCHITECTURE WEB. Laurent.granie@free.fr Franck.legendre@lip6.fr (01 44 27 88 77). OBJECTIFS. Introduction à la sécurité dans les systèmes d’informations (SI) Maîtriser les principes et protocoles employés par les architectures Web commerciales

haruki
Download Presentation

ARCHITECTURE WEB – COURS II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ARCHITECTURE WEB – COURS II ARCHITECTURE WEB Laurent.granie@free.fr Franck.legendre@lip6.fr (01 44 27 88 77) Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  2. OBJECTIFS • Introduction à la sécurité dans les systèmes d’informations (SI) • Maîtriser les principes et protocoles employés par les architectures Web commerciales • Montrer l’importance de la cryptographie dans les SI Web • sécurisation des transactions Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  3. PLAN • Sécurité des SI • Historique de la cryptographie, définitions et objectifs • La cryptographie à clé secrète • La cryptographie à clé publique • Les signatures et la certification • Le Web commercial et le télécommerce, SSL Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  4. Sécurité des SI • Sécurité des SI • Historique de la cryptographie, définitions et objectifs • La cryptographie à clé secrète • La cryptographie à clé publique • Les signatures et la certification • Le Web commercial et le télécommerce, SSL Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  5. Sécurité des SI • 3 causes • Accident (feu, inondation) 25% • Erreurs 15% • Malveillance 60% • 3 conséquences: DIC • Disponibilité: aptitude d’un système à fournir ses services dans des conditions prévues à l’avance • Intégrité: aptitude à produire des infos exactes, valides, complètes et fiables • Confidentialité: aptitude à maintenir l’information à un « groupe » restreint à l’avance Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  6. Sécurité des SI (2) • La sécurité d’un SI est un système de prévention contre les risques et les menaces pouvant entraîner des pertes directes ou indirectes • Postulats • La sécurité maximale n’existe pas • La sécurité coûte chère: ingénieurs, logiciels, matériel (firewall), formations • La sécurité va à l’encontre de la convivialité • La sécurité est un état d’esprit • Une menace est une attaque potentielle sur un SI Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  7. Sécurité des SI (3) • Postulats (suite) • Le risque est la probabilité de réalisation d’une menace • La sévérité est le coût direct ou indirect d’une menace réalisée • La vulnérabilité est la faiblesse d’un système pouvant être exploitée par une menace • La faisabilité correspond aux moyens/compétences pour réaliser une menace • Types de menaces • Involontaires (accidents, erreurs) • Volontaires • Passives (sans altération du SI) • Actives (avec altération du SI) Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  8. Historique de la cryptographie, définitions et objectifs • Sécurité des SI • Historique de la cryptographie, définitions et objectifs • La cryptographie à clé secrète • La cryptographie à clé publique • Les signatures et la certification • Le Web commercial et le télécommerce, SSL Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  9. Historique de la cryptographie • Kryptos: secret et Graphein: écrire • Technologie militaire César, Enigma, téléphone rouge • Méthode de chiffrement par substitution • Ex: Le chiffre de César Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  10. Évolution des systèmes de chiffrement • Systèmes de chiffrement classiques • Par substitution (le chiffre de César) • Par transposition (la technique Assyrienne, 600 av. JC) • Systèmes modernes • A clé publique (1975) • A clé secrète (1973) • Système de chiffrement future • Chiffrement quantique (1984) Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  11. Définitions • Cryptologie • Cryptographie + cryptanalyse • Cryptographie • Chiffrement ou déchiffrement en connaissant la clé • Cryptanalyse • Action de casser une clé (déchiffrement illégitime = décryptage) • Chiffrement • Transformation d’un texte pour en cacher le sens Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  12. Définitions • Cryptogramme • Message chiffré • Cryptosystème • Algorithme de chiffrement ou de déchiffrement • Restreint: l’algorithme est secret, la sécurité repose sur le confidentialité de l’algorithme • Général: l’algorithme est connu, la sécurité repose sur une clef • Stéganographie • Dissimulation d’un message à l’intérieur d’un autre (exemples: encre invisible, premières lettres de tous les mots d’un texte et le codage dans une image numérique) Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  13. Principaux besoins de sécurité • E1: le message ne doit être connu que de son destinataire • E2: le message doit parvenir au bon destinataire • E3: le message émis doit être identique au message reçu • E4: le destinataire ne doit pas nier avoir reçu le message Vue de l’émetteur Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  14. Principaux besoins de sécurité • D1: le message doit être connu que de lui (et de l’émetteur) • D2: l’émetteur du message doit être connu avec certitude • D3: le message reçu doit être identique au message émis • D4: l’émetteur ne doit pas nier avoir reçu le message Vue du destinataire Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  15. Principaux besoins de sécurité • Confidentialité • Propriété d’une information qui n’est ni disponible ni divulguée aux personnes ou entités non autorisées • Besoins d’authentification • Confirmation qu’une entité homologue d’une association est bien l’identité déclarée (que ce n’est pas une autre) Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  16. Principaux besoins de sécurité • Intégrité • Repérer une altération fortuite ou intentionnelle de l’information • Non répudiation • Garantie qu’aucune des entités homologues d’une association ne pourra nier la transaction • Contrôle d’accès • Assurer qu’un accès à une ressource est autorisée Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  17. La cryptographie à clé secrète • Sécurité des SI • Historique de la cryptographie, définitions et objectifs • La cryptographie à clé secrète • La cryptographie à clé publique • Les signatures et la certification • Le Web commercial et le télécommerce, SSL Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  18. Systèmes à clé secrète • Ces systèmes utilisent une clé unique pour chiffrer et déchiffrer • Principe: serrure de porte • Mathématiques • Soit une clé k et un texte en clair P • C est le texte chiffré obtenu par l’application de l’algorithme f sur P • C=fk(P) • P=f’k(C) • Algorithme symétrique: la clé de chiffrement est la même que celle utilisée pour le déchiffrement Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  19. Principe Alice Bob Message codé C  Chiffrement de P par la fonction f au moyen de la clé privée k Envoie du message sur le canal non sécurisé Déchiffrement du message par la fonction f’ au moyen de la même clé k f’ f   Clé k Clé k Texte P Texte P Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  20. Problèmes des systèmes à clé secrète • L’échange préalable à toute communication sécurisée d’un secret: la clé (« distribution de clé ») • La sécurité de ce système réside entièrement dans le secret de la clé! • Dans un réseau de N entités susceptibles de communiquer secrètement, il faut distribuer N*(N-1)/2 clés Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  21. Systèmes à clé secrète • DES (Data Encryption Standard), clé de 56 bits • IDEA (International Data Encryption Algorithm, 1992), utilisés par PGP, clé de 128 bits • Triple DES, deux clés de 56 bits utilisées alternativement • AES (Advanced Encryption Standard, 2000), 128, 192, 256 bits • Lucifer (ancêtre de DES), RC2-RC4-RC5 (Rivest Code, 1987), Vernam, … Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  22. La cryptographie à clé publique • Sécurité des SI • Historique de la cryptographie, définitions et objectifs • La cryptographie à clé secrète • La cryptographie à clé publique • Les signatures et la certification • Le Web commercial et le télécommerce, SSL Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  23. Systèmes à clé publique • 1975: Diffie et Hellman révolutionnent la cryptographie en proposant un système à clé publique • Il n’y a plus une mais deux clés • Une sert au chiffrement et l’autre au déchiffrement • La clé publique peut être diffusée dans des annuaires • La clé privée doit rester secrète • Principe: boîte aux lettres • La boîte est accessible publiquement: tout le monde peut y déposer des lettres • Son contenu n’est accessible que par une et une seule personne, son propriétaire Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  24. Systèmes à clé publique • Mathématiques • Soit le texte en clair P • Une clé privée pr et une clé publique pu • Algorithme f • C est le texte chiffré • C=fpu1(P) C’=f pr2(P’) • P=fpr1(C) P’=fpu2(C’) • Algorithme asymétrique: deux clés distinctes Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  25. Systèmes à clé publique (2) • La relation fonctionne dans un sens: il est simple à partir de la clé privée de générer la clé publique mais l’inverse est considéré comme très difficile • La clé privée permet de déchiffrer un message chiffré avec la clé publique mais l’inverse est possible également Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  26. Principe Chaque entité génère deux clés: une publique et une privée Alice Bob Clés connues d’Alice Clés connues de Bob Clé pu_A Clé pr_A Clé pu_B Clé pu_B Clé pr_B Clé pu_A Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  27. Systèmes à clé publique (3) Alice Bob RSA Demande de clé Envoi de sa clé en clair Clé pu_B {Clé pu_A } Confidentialité: Alice et Bob peuvent désormais échanger des informations de manière sécurisée Alice possède sa clé privée, c’est donc bien elle qui m’envoie ce message Intégrité? Et authentification? Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  28. Systèmes à clé publique (4) • RSA (Ravest, Shamir, Adleman, 1976) basé sur la difficulté à factoriser de grands nombres • Diffie-Hellman • Les fonctions « sac à dos » ou Knapstack • Rabin • Feige-Fiat-Shamir • Autres Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  29. Les signatures et la certificaton • Sécurité des SI • Historique de la cryptographie, définitions et objectifs • La cryptographie à clé secrète • La cryptographie à clé publique • Les signatures et la certification • Le Web commercial et le télécommerce, SSL Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  30. Principe des signatures • Génération d’un Message Digest (MD) par l’émetteur: le MD identifie son message • Chiffrement du MD par la clé privée de l’émetteur • A la réception, génération d’un Message Digest par le destinataire du message reçu et comparaison avec le MD envoyé • Seul l’émetteur a pu envoyer le Message Digest car il est le seul à détenir sa clé privée Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  31. Principe des signatures (2) • Mathématiques • Soit M un message de taille arbitraire et H une fonction • h est le résultat de l’application de H sur M: h=H(M), avec h de longueur m • H est une fonction « trappe » ou de hachage • Objectif: fournir un identificateur unique pour un message Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  32. Principe des signatures (3) Message M fonction de hachage Message Digest ou emprunte numérique Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  33. Système de signatures - Exemple Alice Bob RSA Clé pu_B {M} + Clé pr_A {Message Digest} Bob reçoit le message et le déchiffre avec sa clé privée, pr_B. Il calcule le Message Digest du message M. Déchiffre le Message Digest avec la clé publique d’Alice, pu_A Si idem: OK! Confirmation OK Authentification: seul Alice possède sa clé privée, c’est donc bien elle qui m’envoie ce message Intégrité: même Message Digest => le message n’a pas été altéré Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  34. Systèmes de signatures (4) • La famille des MD inventée par Ron Rivest: MD2, MD4 et MD5, empreinte de 128 bits • N-Hash (128 bits) • Snefru (128 et 256 bits) • SHA (Secure Hash Algorithm), 160 bits Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  35. Problèmes des systèmes à clé publique • Algorithme lent • Solution: • Échanger une clé privée, clé de session, après la phase d’authentification • Utilisée par un algorithme de chiffrement symétrique tel que DES ou Vernam Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  36. Problèmes des systèmes à clé publique (2) • Attaque de « l’homme du milieu » • Problème • Alice veut échanger des informations secrètes avec Bob • Alice demande sa clé publique à Bob • Un pirate P intercepte la demande de clé d’Alice et se fait passer pour Bob en lui renvoyant une clé publique pirate • Alice croit discuter avec Bob mais en réalité elle échange des informations avec le Pirate • Solution: on doit s’assurer qu’une clé est bien associée à son propriétaire grâce à un tiers de confiance, l’organisme de certification Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  37. Certification • Un certificat permet au détenteur d’une clé publique d’attester qu’il en est bien le propriétaire • C’est en quelque sorte une carte d’identité de la clé publique, délivré par un organisme appelé autorité de certification (ou CA) • Un certificat est composé • D’informations et la clé publique • Signature de l’autorité de certification Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  38. Certification – un certificat • Informations • Autorité de certification (Verisign, Thawte, …) • Nom du propriétaire • Mèl • Période de validité • Clef publique • Algorithme de cryptage fonction de hachage MD Signature 5d:4f:9a:88:c5:c7 Clé pr_CA {Message Digest des informations de certifications} Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  39. Certification - Principe Alice Bob CA Demande de certificat Envoi du certificat de Bob 1-: Déchiffrement de la signature du certificat avec la clé publique du CA si disponible sinon  2-: Application de la fonction de hachage sur les informations du certificat de Bob 3-: Comparaison. Si OK: c’est bien Bob!! Demande du certificat du CA (contient la clé publique du CA) Envoi du certificat du CA Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  40. Web commercial et télécommerce (SSL) • Sécurité des SI • Historique de la cryptographie, définitions et objectifs • La cryptographie à clé secrète • La cryptographie à clé publique • Les signatures et la certification • Le Web commercial et le télécommerce, SSL Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  41. Commerce Électronique • Existe depuis longtemps • AOL et Compuserve aux US • Difficultés d’envol • Sociétés investissent peu • Craintes liées aux problèmes de sécurité (Faux problème: pas plus de risques que de donner son numéro de CB à une téléopératrice) • Craintes liées à la télévente (qualité, confiance) • Solutions • Communications sécurisées: • Authentification, chiffrement, intégrité • Tiers de confiance et monnaies virtuelles Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  42. Étapes de conception d’un site commercial • Concevoir: marketing, études de marchés, ergonomie • Réaliser: esthétique (graphisme), développement web (html, Java, .Net), hébergement • Sécuriser: interfaces monétiques, systèmes de sécurité à clé publique, autres systèmes • Exploiter: administration du serveur, gestion des commandes, des paiements, des livraisons • Faire connaître: référencement, promotions Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  43. Sécurisation de l’interface monétiques • Méthode par carte bancaire • SSL mais nécessite de faire une demande de certificat • CB: paiement sécurisé avec un émission du numéro de CB • e-CB: paiement par un numéro unique de CB/transaction • S-HTTP peu utilisé • SET (Secure Electronic Transaction) et C-SET • Netscape, Microsoft, Visa MasterCard uniquement • Anonymat moins fort qu’avec Digicash • Passerelle: applet Java coté client ou contrôle ActiveX • PayPal • Le client crédite Paypal (tiers de confiance) qui reverse la somme au vendeur Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  44. Sécurisation de l’interface monétiques (2) • Autres méthodes: monnaie virtuelle • First Virtual • Digicash • Cybercash • NetCash Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  45. Sécurisation de l’interface monétiques (3) • First Virtual • Utilisateur commande un PIN à First Virtual en lui fournissant son numéro de CB par téléphone • Lors d’un achat, il fourni son code PIN • First Virtual envoie un mail de confirmation à l’utilisateur • Si il accepte, sa CB est débitée • Passerelle CGI est utilisée • DigiCash • Utilisateur achète des CyberBucks auprès de Digicash • Les CyberBucks sont représentés par des numéros de série • Anonyme mais besoin d’installer un logiciel coté client et serveur Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  46. Sécurisation de l’interface monétiques (4) • Avantages/inconvénients • Anonymat • État des dépenses on-line • État du compte • CB stockée ou non sur le serveur • Débit immédiat/différé • CB acceptée (Visa, MasterCard) Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  47. Sécurisation de l’interface monétiques (5) • Coûts • SSL: gratuit mais frais de certification • SET et C-SET: 750 €/commerçants et 75 €/terminal • Paypal: commissions sur les transactions • First Virtual: 1,29 € + 2% montant/transactions Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  48. Exploitation et gestion des paiements • Méthode manuelle • Location ou achat d’un TPE (Terminal de Paiement Électronique) • Méthode automatique • Services clé en main offerts par les banques Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  49. Architecture du commerce électronique Serveur Web commercial Serveur Banque porteur Serveur Banque commerciale  Serveur Paiements  R.C.B    Internet  Requête de paiement Info carte bancaire par SSL Demande vers la banque Ticket de réponse SSL Retour vers le site du commerçant Réponse automatique (transaction bonne ou non) TPE Client Web Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

  50. SSL • Protocole SSL Record • Basé sur TCP/IP: encapsulation des protocoles supérieurs • Protocole SSL Handshake • Authentification entre le client et le serveur et négociation sur l’algorithme de chiffrement utilisé • Authentification par clef publique (certificat) • Intégrité assuré par une emprunte numérique (SHA,MD5) • Confidentialité : chiffrement par clé secrète pour la session (DES, RC4) • Utilisable par HTTP, FTP, telnet, … et utilisé dans SSH Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB

More Related