Upload
haruki
View
31
Download
0
Embed Size (px)
DESCRIPTION
ARCHITECTURE WEB – COURS II. ARCHITECTURE WEB. [email protected] [email protected] (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 - PowerPoint PPT Presentation
Citation preview
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 1 / 62
ARCHITECTURE WEB – COURS II
(01 44 27 88 77)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 2 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 3 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 4 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 5 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 6 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 7 / 62
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)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 8 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 9 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 10 / 62
É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)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 11 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 12 / 62
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)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 13 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 14 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 15 / 62
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)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 16 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 17 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 18 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 19 / 62
Principe
Alice Bob
Clé k
Texte P
f
Message codé C
f’
Texte P
Clé k
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 20 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 21 / 62
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, …
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 22 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 23 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 24 / 62
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=f pu1(P) C’=f pr2(P’)– P=f pr1(C) P’=f pu2(C’)– Algorithme asymétrique: deux clés distinctes
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 25 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 26 / 62
Principe
Alice Bob
Clé pu_A
Chaque entité génère deux clés: une publique et une privée
Clé pr_A
Clé pu_B
Clé pu_B
Clé pr_B
Clé pu_A
Clés connues d’Alice
Clés connues de Bob
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 27 / 62
Systèmes à clé publique (3)
Alice Bob
Demande de clé
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?
RSA
Envoi de sa clé en clair
Clé pu_B {Clé pu_A }
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 28 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 29 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 30 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 31 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 32 / 62
Principe des signatures (3)
Message M
fonction de
hachage
Message Digest ou emprunte numérique
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 33 / 62
Système de signatures - Exemple
Alice Bob
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!
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é
RSA
Confirmation OK
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 34 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 35 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 36 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 37 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 38 / 62
Certification – un certificat
Informations Autorité de certification (Verisign, Thawte, …)
Nom du propriétaire
Mèl
Période de validité
Clef publique
Algorithme de cryptage
Signature
5d:4f:9a:88:c5:c7
fonction de
hachage
Clé pr_CA {Message Digest des informations de certifications}
MD
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 39 / 62
Certification - Principe
Alice Bob
Demande de certificat
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!!
Envoi du certificat de Bob
Demande du certificat du CA (contient la clé publique du CA)
Envoi du certificat du CA
CA
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 40 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 41 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 42 / 62
É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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 43 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 44 / 62
Sécurisation de l’interface monétiques (2)
• Autres méthodes: monnaie virtuelle– First Virtual
– Digicash
– Cybercash
– NetCash
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 45 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 46 / 62
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)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 47 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 48 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 49 / 62
Architecture du commerce électronique
Client Web
Serveur Web commercial
Serveur Paiements
Internet
R.C.B
Serveur Banque commerciale
Serveur Banque porteur
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 50 / 62
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
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 51 / 62
SSL (2)
TCP/IP, SSL{HTTP, HTML}
Client Web Serveur Web
Pages HTML + passerelle
de paiement
Numéro CB
Serveur génère un couple de clé publique et privée
Client idem
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 52 / 62
SSL – Négociation SSL
Client Web Serveur Web
« Client Hello »
SSL
« Server Hello » + Certificat du serveur
Algorithmes supportés par le client
Certificat du client
Négociation terminée
Algorithmes utilisés
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 53 / 62
SSL – Confidentialité et intégrité
Client Web Serveur Web
Clé pu_C {clé de session: pu_sess} Serveur ou le client génèrent une
clé de session utilisée pour toute la session avec l’entité homologue afin de sécuriser la transaction
Le client déchiffre le secret en utilisant la clé de session puis vérifie l’intégrité en déchiffrant la signature du message par la clé secrète commune
Si le MD du message déchiffré est le même que celui calculé sur le secret : OK, le serveur est authentifié et l’intégrité du message respectée
SSL
Clé s_sess{secret + MD {secret}}
Clé s_sess {#CB + MD {#CB} }
Clé s_sess {« Paiement accepté »}
Clé s_sess {OK}
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 54 / 62
Exemple d’authentification simple
Client Web Serveur Web
Demande d’authentification
Serveur envoie le message reçu chiffré avec sa clé privé qu’il est le seul à posséder. C’est donc le seul à pouvoir réaliser cette opérationLe client déchiffre le message M en
utilisant la clé publique du serveur, pu_s
Si idem : OK, le serveur est authentifié
RSA
Envoi clé publique du serveur
Envoi d’un message aléatoire M
Clé pr_S {M}
Clé pu_S {OK}
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 55 / 62
Serveur Apache: fichier de configuration
# Par défaut, on désactiive SSLSSLDisable
# Ecoute sur ports http (80) et https (443)Listen 80Listen 443
# Configuration SSL par défaut#Le certificatSSLCertificateFile /software/sslCerts-1/config/certs/httpsd.pem#La clé privéeSSLCertificateKeyFile /software/sslCerts-1/config/certs/private/httpsd.pem#0-pas de demande de certificat du client, 1-Demande d’un certificat, 2-ObligationSSLVerifyClient 0#Nombre maximum d’appels récursifs aux CA successifs pour vérifier un certificat clientSSLVerifyDepth 10#Cryptosystèmes acceptésSSLRequiredCiphers NULL-MD5:RC4-MD5:EXP-RC4-MD5:RC2-CBC-MD5:IDEA-CBC-MD5:DES-CBC-MD5:DES-CBC-SHA:DES-CBC3-MD5:DES-CBC3-SHA:DES-CFB-M1SSLRequireCipher NULL-MD5 RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 IDEA-CBC-MD5 DES-CBC-MD5 DES-CBC-SHA DES-CBC3-MD5 DES-CBC3-SHA DES-CFB-M1 #Cryptosystèmes non acceptésSSLBanCipher NULL#Fichier de log des connexions SSLSSLLogFile logs/ssl_log
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 56 / 62
Serveur Apache: fichier de configuration (2)
<VirtualHost your-site.uwaterloo.ca:443> #Accès HTTPS avec SSL SSLEnable DocumentRoot /software/wwwapache_server/cover/htdocs/secure ScriptAlias /cgi-bin/ /software/wwwapache_server/data/cgi-bin/secure/ TransferLog logs/secure-access_log ErrorLog logs/secure-error_log</VirtualHost>
<VirtualHost your-site.uwaterloo.ca:80> #Accès normal sans SSLSSLDisable DocumentRoot /software/wwwapache_server/cover/htdocs ScriptAlias /cgi-bin/ /software/wwwapache_server/data/cgi-bin/ ErrorLog logs/error_log TransferLog logs/access_log </VirtualHost>
<Location /secure> #Répertoire sécurisé, aucun accès du Web order allow,deny allow from none deny from all </Location>
<Location /cgi-bin/secure> #idem Répertoire précédentorder allow,deny allow from none deny from all</Location>
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 57 / 62
Exercices
• 1- Politique de sécurité– Expliquez ce qu’il faut retenir de l’approche sécurité dans les entreprises
en général et plus particulièrement sur un Web commercial?
• 2- Gestion des clés– Quelles sont les différences entre les systèmes à clé secrète et à clé
publique?– A quoi sert un certificat de clé publique?
• 3- Attaque de « l’homme du milieu »– Faîtes un diagramme d’une attaque par un pirate de l’échange de clé
entre Bob et Alice
• 4- Services de sécurité– Quels sont les besoins de sécurité que nécessite une application de
courrier électronique?– Expliquez rapidement comment on peut assurer ces besoins?
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 58 / 62
Exercices (2)
• Etude de cas
– XFILE est un protocole sécurisé d’échange télématique de données entre les banques et leurs clients
– Les services de sécurité mis en œuvre sont les suivants:• Confidentialité DES (crypto symétrique)• Authentification réciproque RSA (crypto asymétrique)• Intégrité DES• Non répudiation RSA
– Les bi-clés RSA sont certifiées par la clé privée SKcc du GIE Carte Bancaire et diffusées avec leur accréditation à chaque partenaire
– Soit Alice, un client possédant une bi-clé RSA sous la forme• (Pka, Ska, <<Pka>>, Pkcc)
– Soit Bob, une banque possédant une bi-clé RSA sous la forme• (Pkb, Skb, <<Pkb>>, Pkcc)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 59 / 62
Exercices (3)
– Rappel: <<Pka>>= Ida, TK, Nsa, Pka, [Skcc(hash(Ida, TK, Nsa, Pka))]• Ida Identification de a• TK Type de bi-clé• Nsa Numéro de série de la carte mémoire contenant la bi-clé• Pka Clé publique de a• Skcc Clé privée de certification• Hash() Fonction de hachage (prise d’emprunte)
• Questions
– 1- XFILE met en œuvre l’authentification réciproque par échange de certificats.
• Décrivez cet échange entre Alice et Bob.• Quelles sont les opérations effectuées par Alice?• Quelles sont les opérations effectuées par Bob?
– 2- La phase précédente étant réalisée, Alice envoie à Bob un fichier confidentiel avec contrôle d’intégrité.
• Décrivez l’échange de fichiers entre Alice et Bob• Quelles sont les opérations effectuées par Alice?• Quelles sont les opérations effectuées par Bob?
– 3- Alice veut un accusé de réception non répudiable de Bob• Décrivez la réponse de Bob?• Quelles sont les opérations effectuées par Alice?
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 60 / 62
Bibliographie
• OuvragesCryptologie contemporaine de Gilles Brassard, collection
Logique Mathématiques Informatique, Masson (27.44 euros), concepts récents : DES, clé publique, protocoles, cryptographie quantique, ...
– Cryptographie : théorie et pratique de Douglas Stinson, ITP/Vuibert (45 euros), un ouvrage technique de référence
– Cryptographie appliquée de Bruce Schneier, seconde édition, ITP/Vuibert (55 euros), un ouvrage technique de référence
– Cours de cryptographie de Gilles Zemor, Cassini (25 euros)
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 61 / 62
Bibliographie (2)
• Sites Web– http://perso.wanadoo.fr/gilb/cours-cryptanalyse.
html– http://www.counterpane.com/crypto-gram.html– http://www.rsasecurity.com/rsalabs/faq/– http://www.cacr.math.uwaterloo.ca/hac/
17 / 01 / 2003 Laurent GRANIE & Franck LEGENDRE – MIAGE 3ème année - ARCHITECTURE WEB 62 / 62
Questions
?
?
?
??
??