1 / 42

E-commerce Security

E-commerce Security. Albert Levi Oregon State University Information Security Lab Corvallis, Oregon, USA levi@security.ece.orst.edu. E-commerce. Performing commercial transactions over the Internet 4 legs consumer merchant consumer’s bank merchant’s bank. E-commerce. 96

david-wilcox
Download Presentation

E-commerce Security

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. E-commerce Security Albert Levi Oregon State University Information Security Lab Corvallis, Oregon, USA levi@security.ece.orst.edu Albert Levi, E-commerce security and PKIs

  2. E-commerce • Performing commercial transactions over the Internet • 4 legs • consumer • merchant • consumer’s bank • merchant’s bank Albert Levi, E-commerce security and PKIs

  3. E-commerce 96 Percentage of the Turkish Internet users who are afraid of sending their credit card numbers over the Internet according to daily Milliyet Albert Levi, E-commerce security and PKIs

  4. E-commerce Security • Why? • Everybody says so • They do not trust the Internet • They do not know what is going on at the merchant’s site • They think that some hands are in their wallets • They do not trust people in the process Albert Levi, E-commerce security and PKIs

  5. Security Requirements • Confidentiality • unauthorized parties must not see the data transmitted • Authentication • parties must make sure each other’s identity Albert Levi, E-commerce security and PKIs

  6. Security Requirements • Non-repudiation • nobody should be able to deny sending a message or initiating a transaction later • any possible dispute must be resolved fairly • Integrity • nobody should be able to alter the data while in transit • if altered, that must be sensed Albert Levi, E-commerce security and PKIs

  7. Security Mechanisms • Encryption • encode the data so that only the intended party could decode • For confidentiality Albert Levi, E-commerce security and PKIs

  8. Security Mechanisms • Digital Signatures • a digital information that can be produced only by the sender • The receiver must be able to verify that signature • For authentication, non-repudiation, integrity Albert Levi, E-commerce security and PKIs

  9. Public key Cryptography (PKC) • PKC is the solution to both encryption and digital signatures • One key pair per user • public key • everybody can know it • private key • must be kept secret Albert Levi, E-commerce security and PKIs

  10. PKC - Encryption Alice Bob Albert Levi, E-commerce security and PKIs

  11. PKC - Digital Signatures Alice Bob Albert Levi, E-commerce security and PKIs

  12. Public Key Distribution • Public directories/databases • everybody posts his/her public key • everybody can get others’ public key • everybody can say that “I am Madonna” • Name spoofing problem Albert Levi, E-commerce security and PKIs

  13. Public Key Distribution • There must be a trusted binding between the public key and the identity of its owner • “Digital Certificates” are such bindings • issued by trusted Certificate Authorities (CA) after an identity control Albert Levi, E-commerce security and PKIs

  14. Certificates Certificate Authority (CA) Certified Entity Certificate Issuance Certificate Albert Levi Albert Levi Albert Levi Certificate Verification Verifier Albert Levi, E-commerce security and PKIs

  15. E-commerce Security • Practical solution is SSL (Secure Socket Layer) • Security layer over TCP/IP • mostly for HTTP connections • encrypted and authenticated sessions between web servers and web browsers (clients) • web servers must have certificate • client certificate is optional Albert Levi, E-commerce security and PKIs

  16. Using SSL in E-commerce • By using SSL we can • make sure about the merchant’s name (assuming the CA of the merchant is trusted) • authentication • make sure that nobody can see the traffic (especially the card number) between consumer and merchant • confidentiality Albert Levi, E-commerce security and PKIs

  17. Using SSL in E-commerce • By using SSL we can NOT • provide privacy • merchant sees all information including the card number and name • provide non-repudiation • both parties knows the session key • charge-back cost for merchant’s • guarantee that merchant will behave honestly Albert Levi, E-commerce security and PKIs

  18. Practical Issues on SSL Albert Levi, E-commerce security and PKIs

  19. Practical Issues on SSL Albert Levi, E-commerce security and PKIs

  20. Practical Issues on SSL Albert Levi, E-commerce security and PKIs

  21. Practical Issues on SSL Albert Levi, E-commerce security and PKIs

  22. Using SSL in E-commerce • SSL is not the perfect solution for secure E-commerce • but it is a convenient solution • no need for consumer certificate • just type the card number • minimal change in current business models Albert Levi, E-commerce security and PKIs

  23. SET (Secure Electronic Transaction) • More secure card payment protocol • Efforts started in 1996 by the leadership of Visa and Mastercard • Still not common! Albert Levi, E-commerce security and PKIs

  24. SET (Secure Electronic Transaction) • Secure, but so complex: not convenient • need-to-know • dual signatures • everybody needs certificates • consumers need to register • 5 level PKI • CAs will get a piece from the cake • time consuming PKC operations Albert Levi, E-commerce security and PKIs

  25. A Practical Solution • We need to balance the security vs convenience trade-off • ANSI X9.59 Standard • Standardization effort on Electronic Commerce for Financial Services Industry • Financial Institutions (FIs) will take place of the CAs • AIM: no certificates issued by CAs Albert Levi, E-commerce security and PKIs

  26. ANSI X9.59 Aim • Primary aim is to eliminate Certificate Authority (CA) based digital signatures • CAs are “extra” in the current business models ==> extra cost, complex system • No CA means no change in the current business models ==> no extra cost, simple system Albert Levi, E-commerce security and PKIs

  27. ANSI X9.59 - Basic Characteristics • No consumer certificate • FIs keep the consumer public-keys in their account records • Consumer signature is verified by its FI, not by the merchant • CFI sends an acknowledgment to merchant Albert Levi, E-commerce security and PKIs

  28. ANSI X9.59 - Basic Characteristics • X9.59 does not offer encrypted communication. • Challenging? Here is the justification: • X9.59 uses X9.59-specific PRC (Payment Routing Code) instead of account/card numbers. PRCs are not valid without an accompanying digital signature Albert Levi, E-commerce security and PKIs

  29. ANSI X9.59 - The Model • Outside the scope of X9.59 • mostly part of the current payment infrastructure • a few extra fields are necessary ==> minor modification on the current payment infrastructure Albert Levi, E-commerce security and PKIs

  30. ANSI X9.59 - The Model • “Signed Payment Object” created and signed by consumer to show the intent of payment • contains: hash of the order detail, consumer and merchant PRC values, payment amount and payment details Albert Levi, E-commerce security and PKIs

  31. ANSI X9.59 - The Model • Merchant does NOT check the signature over SigPayObject, • but repacks it as a standard “Authorization Request Object” and sends it to MFI Albert Levi, E-commerce security and PKIs

  32. ANSI X9.59 - The Model • MFI transfers the authentication request to CFI • CFI performs • fund allocation for the transaction • reconstruction of SigPayObject to verify consumer’s signature. CFI uses the public key of the consumer stored in the account records for this verification. Albert Levi, E-commerce security and PKIs

  33. ANSI X9.59 - The Model • CFI responds to MFI with positive or negative acknowledgment Albert Levi, E-commerce security and PKIs

  34. ANSI X9.59 - The Model • MFI forwards this acknowledgment back to the merchant as “Authorization Acknowledgment Object” Albert Levi, E-commerce security and PKIs

  35. ANSI X9.59 - The Model • Merchant signs the authorization response using its private key, • sends it to consumer as “Signed Payment Acknowledgment Object” • This object contains the merchant’s certificate in order to allow the consumer to verify the signature over it Albert Levi, E-commerce security and PKIs

  36. ANSI X9.59 - Two Remaining Problems • Merchant certificates are still in use • X9.59 offers X.509 certificates and a corresponding PKI is necessary • Lack of encryption • No names exist on objects but PRC - consumer/merchant bindings are not secret • Payment amount is sent in cleartext Albert Levi, E-commerce security and PKIs

  37. ANSI X9.59 - Our Approach • X9.59 based e-payment protocol for the Internet • with solution to merchant certificate problem • with optional encryption extensions • COPSEPP (COnvenient and Practically Secure E-Payment Protocol) • our research in going on Albert Levi, E-commerce security and PKIs

  38. COPSEPP • Solution to merchant certificate problem • no pre-generated certificates • MFI sends the merchant’s certificate upon request • Attachments to authorization messages • no extra messages • Only one extra signature is sufficient Albert Levi, E-commerce security and PKIs

  39. COPSEPP Solution to merchant certificate problem • 1 and 2: payment infrastructure authorization messages • 3: AutAckObject • 4: SigPayAckObject Albert Levi, E-commerce security and PKIs

  40. COPSEPP • Optional encryption extensions • between merchant and MFI • easy, they know each other’s public key • between customer and merchant • difficult but possible without extra messages other than the existing authorization messages Albert Levi, E-commerce security and PKIs

  41. COPSEPP - Merchant to Consumer Encryption • 1: payment infrastructure authorization message • 2: AutAckObject Albert Levi, E-commerce security and PKIs

  42. COPSEPP - Consumer to Merchant Encryption • Encrypting SigPayObject • Ongoing research • consumer needs to know Merchant’s PK at the beginning • impossible without using extra message rounds • we think a system where Consumer encrypts the object using CFI’s public key and CFI returns the decrypted object to merchant • no extra messages Albert Levi, E-commerce security and PKIs

More Related