Ecommerce Security

1
E-commerce Security

• Albert Levi
• Oregon State University
• Information Security Lab
• Corvallis, Oregon, USA
• levi_at_security.ece.orst.edu

2
E-commerce

• Performing commercial transactions over the
  Internet
• 4 legs
• consumer
• merchant
• consumers bank
• merchants bank

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

4
E-commerce Security

• Why?
• Everybody says so
• They do not trust the Internet
• They do not know what is going on at the
  merchants site
• They think that some hands are in their wallets
• They do not trust people in the process

5
Security Requirements

• Confidentiality
• unauthorized parties must not see the data
  transmitted
• Authentication
• parties must make sure each others identity

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

7
Security Mechanisms

• Encryption
• encode the data so that only the intended party
  could decode
• For confidentiality

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

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

10
PKC - Encryption
Alice
Bob
11
PKC - Digital Signatures
Alice
Bob
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

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

14
Certificates
Certificate Authority (CA)
Certified Entity
Certificate Issuance
Certificate
Albert Levi
Albert Levi
Albert Levi
Certificate Verification
Verifier
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

16
Using SSL in E-commerce

• By using SSL we can
• make sure about the merchants 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

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 merchants
• guarantee that merchant will behave honestly

18
Practical Issues on SSL
19
Practical Issues on SSL
20
Practical Issues on SSL
21
Practical Issues on SSL
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

23
SET (Secure Electronic Transaction)

• More secure card payment protocol
• Efforts started in 1996 by the leadership of Visa
  and Mastercard
• Still not common!

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

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

26
ANSI X9.59 Aim

• Primary aim is to eliminate Certificate Authority
  (CA) based digital signatures
• CAs are extra in the current business models
  gt extra cost, complex system
• No CA means no change in the current business
  models gt no extra cost, simple system

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

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

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 gt minor
  modification on the current payment infrastructure

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

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

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
  consumers signature. CFI uses the public key of
  the consumer stored in the account records for
  this verification.

33
ANSI X9.59 - The Model

• CFI responds to MFI with positive or negative
  acknowledgment

34
ANSI X9.59 - The Model

• MFI forwards this acknowledgment back to the
  merchant as Authorization Acknowledgment Object

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 merchants certificate
  in order to allow the consumer to verify the
  signature over it

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

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

38
COPSEPP

• Solution to merchant certificate problem
• no pre-generated certificates
• MFI sends the merchants certificate upon request
• Attachments to authorization messages
• no extra messages
• Only one extra signature is sufficient

39
COPSEPP

• Solution to merchant certificate problem

• 1 and 2 payment infrastructure authorization
  messages
• 3 AutAckObject
• 4 SigPayAckObject

40
COPSEPP

• Optional encryption extensions
• between merchant and MFI
• easy, they know each others public key
• between customer and merchant
• difficult but possible without extra messages
  other than the existing authorization messages

41
COPSEPP - Merchant to Consumer Encryption

• 1 payment infrastructure authorization message
• 2 AutAckObject

42
COPSEPP - Consumer to Merchant Encryption

• Encrypting SigPayObject
• Ongoing research
• consumer needs to know Merchants PK at the
  beginning
• impossible without using extra message rounds
• we think a system where Consumer encrypts the
  object using CFIs public key and CFI returns the
  decrypted object to merchant
• no extra messages