Application de commerce électronique Août Contraintes : respecter les règles usuelles des transactions commerciales

Transcription

1 Etude de cas : une application de commerce électronique Michel.Riveill@univ-savoie.fr Projet IMAG-INRIA SIRAC 655 avenue de l Europe Montbonnot 1 Commerce électronique Objectifs clients/fournisseurs connectés à un réseau exécutent des transactions commerciales recherche d un produit consultation de catalogues commande simple ou groupée paiement demande de livraison coût de la transaction aussi faible que possible très faible dans la cas présent car utilisable pour des transactions < 10 FF rendre l utilisation de l ensemble le plus simple possible Une transaction commerciale = 2 transferts produit du fournisseur au client transfert de monnaie dans l autre sens 2 1 Copyright Michel RIVEILL,

2 Commerce électronique Contraintes : respecter les règles usuelles des transactions commerciales protection des informations confidentielles client : numéro de carte de crédit, code d accès fournisseur : conditions particulières de ventes respect des règles de concurrence respect des garanties données au client par le fournisseur sincérité de l offre exécution du contrat de vente respect des garanties données au fournisseur par le client identité paiement respect des droits de propriété licence droits d auteurs Les garanties données au client et au fournisseur doivent être assorties de preuves ayant valeur légale, pouvant être exhibées en cas de litige 3 Netbill architecture Réseau Fournisseur Client Banque Netbill 4 2 Copyright Michel RIVEILL,

3 Netbill scénario Un client souhaite acquérir une information de la part d un vendeur information = suite de bits (résultat d une recherche dans une base de données) vente par accès ou pour plusieurs accès Un serveur Netbill contient les comptes pour le client et le vendeur Les comptes gérés par le serveur Netbill sont alimentés par des comptes bancaires (opération qui se fait en dehors du réseau) transfert du compte bancaire client au compte Netbill client transfert du compte Netbill vendeur au compte bancaire vendeurs Une transaction Netbill transfert les information du vendeur au client débite le compte client du montant souhaité crédite le compte vendeur du même montant 5 Netbill protocole protocole spécifique entre Netbill et client/vendeur support pour les transactions mise en oeuvre par deux bibliothèques une pour le client (checkbook - porte-monnaie) une pour le vendeur (till - tiroir-caisse) communication entre les deux bibliothèques sont cryptées respect des règles usuelles pour les transactions commerciales protocole libre entre client et vendeur optimisation des communications respect des protocoles usuels 6 3 Copyright Michel RIVEILL,

4 Netbill protocole client porte-monnaie [1] [2] [3] [4] [5] [8] vendeur tiroir-caisse [6] [7] 1 - demande de prix 2 - offre de prix 3 - demande d achat 4 - envoie du produit (sous forme électronique codée) 5 - envoie de l ordre de paiement 6 - envoie de la facture et de l ordre de paiement 7 - accord de l opération d achat 8 - envoie de la facture acquittée et de la clé de déchiffrement serveur Netbill 7 Généralité sur le cryptage Chiffrement : M -> C = {M} K - Déchiffrement : C -> = [M] K En général : { } = [ ] Utilisation d un code symétrique : K = K en général { } = [ ] (chiffre DES), ce qui donne [[M] K ] K = M partage d un secret entre deux participants : la clé cryptage et authentification : même algorithme Utilisation d un code non-symétrique chaque partenaire possède une clé privé kp et une clé publique KP en général : [{M} kp ] KP = [{M} KP ] kp (chiffre RSA) cryptage : A -> B émission du message {M} KB qui ne pourra être décodé que par B authentification de A émission du message {M} ka qui n a put être produit que par A, mais que tout le monde peut décoder 8 4 Copyright Michel RIVEILL,

5 Description des messages 1. C -> M : T CM (Identity), E CM (Credentials,ProductRequest, Flags, TID) 2. M -> C : E CM (ProductID, Price, Flags, TID) 3. C -> M : T CM (Identity), E CM (ProductOrder, TID) 4. M -> X : E K (Goods), E CM (CC(E K (Goods)), EPOID) 5. C -> M : T CM (Identity), E CM ([EPO] C ) 6. M -> N : T MN (M), E MN ([[EPO] C, Macct, K] M ) 7. N -> M : E MN ([Receipt] N-DSA,E CN (EPOID, Cacct, Bal, Flags)) 8. M -> C : E CM ([Receipt] N-DSA, E CN (EPOID, Cacct, Bal, Flags)) Principales notations T CM (Identity): ticket de session Kerberos identification de la clé E key (message) : message crypté en utilisant la clé key codage symétrique CC(message) : code d erreur [message] signature : message signé codage asymétrique 9 Sécurité Confidentialité assurer l accès aux informations aux personnes accréditées Intégrité une information doit rester identique à elle-même (sauf en cas de modification explicite) pas de modification du message lors d une communication Authentification garantir que l identité de la personne correspond à celle attendue Outils : cryptographie à clé publique 10 5 Copyright Michel RIVEILL,

6 Exemple de propriétés attendues le destinataire ne peut nier avoir reçu le message l émetteur ne peut nier avoir envoyé le message Le récepteur ne peut pas prétendre avoir reçu un message différent que celui émis l identité de l'émetteur est établie et ne peut être contrefaite contradiction avec anonymat usage de pseudonyme délivré par un serveur indépendant identité réelle dévoilée ou non lors des litiges avec l accord de l intéressé 11 Tolérance aux fautes Le client doit payer si et seulement si il a reçu la marchandise Composants logiciels sur 3 sites site du client, site du serveur, et site du serveur Netbill Serveur Netbill hautement disponible fonctionne en mode transactionnel lien étroit entre la facturation du produit et l accord de paiement (étape 6 et 7) l atomicité des transactions assure que les 2 événements arrivent ou n arrivent pas sa connaissance du protocole ne dépend pas des autres sites : il enregistre et acquitte les ordres de paiement 12 6 Copyright Michel RIVEILL,

7 Panne : point de vue du client étape 1 à 4 aucune transaction financière n a eu lieu le client n a pas accès au produit le vendeur n a pas été payé. message 5 émis : ordre de paiement émis le client a accepté la marchandise en cas de panne i.e... pas de réponse de la part du vendeur le client doit rechercher la cause de la panne : contact avec le vendeur ou avec le serveur Netbill pour connaître l état de la requête cause d erreur possible Ordre de paiement non transmis au serveur Netbill la vente a échoué (l ordre de paiement a une durée de validité) Ordre de paiement transmis et accepté par le serveur Netbill la vente a abouti (le client reçoit la clé de décryptage éventuellement du serveur Netbill qui en a une copie) 13 Panne : point de vue du vendeur étape 1 à 5 aucune transaction financière n a eu lieu le client n a pas accès au produit le vendeur n a pas été payé. message 6 émis le vendeur obtiendra une réponse du serveur Netbill en cas de panne, il doit le reconnaître 14 7 Copyright Michel RIVEILL,

8 Technologies utilisées Serveur Netbill = Serveur transactionnel hautement disponible Transactions Tolérance aux pannes architecture hautement disponible Confidentialité cryptage authentification 15 Intégration au WWW Navigateur 1 2 Serveur httpd Base des produits Serveur de produits Portemonnaie 5 Serveur NetBill 16 8 Copyright Michel RIVEILL,

9 Quelques manques Une fois que le client a reçu l information, il y a peu de moyens techniques pour contrôler ce que fait le client exemple : accès à un journal avec 2 tarifs lecture sur l écran impression comment empêcher un utilisateur ayant payé le tarif lecture de faire une copie papier un vendeur peut choisir d utiliser un logiciel d accès spécifique De manière symétrique il n y pas de moyen technique pour vérifier que le vendeur respecte bien la législation (par exemple sur les copyright) 17 Bibliographie D. K.Gifford, L. C. Stewart, A. C. Payne, G. W. Treese. Payment Switches for Open Networks, Proc. First UsenixWorkshop on Electronic Commerce, New-York, July 11-12, 1995 M. Sirbu, J. D. Tygar. NetBill: An Internet Commerce SystemOptimized for Network Delivered Services, Proc. COMPCON 95, IEEE, March Electronic Payement Over Network OpenMarket Papier généraux Copyright Michel RIVEILL,