CP3397 ECommerce - University of Wolverhampton
Download
Report
Transcript CP3397 ECommerce - University of Wolverhampton
CP3397 ECommerce
Today’s Lecture
Authentication using passwords
SSL / TLS
SET
Secure protocols used over the web
S/MIME
PGP
SET
HTTP
FTP
SMTP
TCP
Secure email
Security can be applied at
several layers of the TCP
model and we look at these
and see how they are
especially used in web
buying
Pretty Good Privacy
Secure transfer of data
IP
Application layer
HTTP
FTP
TCP
HTTP
FTP
SSL/TSL
TCP
IP
Transport Layer
SMTP
IP/IPSec
Network Layer
SMTP
Overview of SLS/TLS
Encryption
Transport Secure Layer protocol 1.0 has
grown out of the Secure Sockets layer
protocol 3.1
SSL/TLS is primarily used to encrypt
confidential data sent over an insecure
network such as the Internet.
In the HTTPS protocol, the types of data
encrypted include the URL, the HTTP header,
cookies, and data submitted through forms.
The SSL/TLS protocol can be divided into two layers.
Handshake Protocol Layer - consists of three sub-protocols: the
Handshake Protocol, the Change Cipher Spec Protocol, and the
Alert protocol.
Record Protocol Layer.
Application Layer
HTTP
FTP
Handshake
Telnet
Change cipher
text
etc
Alert
Handshake Layer
SSL/TSL
Record
Transport layer
TCP/IP
Record Layer
The Handshake Layer
consists of 3 sub-protocols:
Handshake sub protocol - used to negotiate session
information between the client and the server. The
session information consists
session ID;
peer certificates,
the cipher spec to be used,
the compression algorithm to be used,
and a shared secret that is used to generate keys.
The Change Cipher Spec - used to change the keying
material used for encryption between the client and
server. Keying material is raw data that is used to create
keys for cryptographic use.
The Change Cipher Spec sub-protocol consists of a
single message to tell other party in the SSL/TLS
session, who is also known is the peer, that the
sender wants to change to a new set of keys. The
key is computed from the information exchanged by
the Handshake sub-protocol.
Alert messages - used to indicate a change in status
or an error condition to the peer. There are a wide
variety of alerts to notify the peer of both normal and
error conditions. See RFC 2246 . Alerts are
commonly sent when the connection is closed, an
invalid message is received, a message cannot be
decrypted, or the user cancels the operation.
HTTPS Authentication
For authentication purposes, the
Handshake Protocol uses an X.509
certificate to provide strong evidence to a
second party that helps prove the identity
of the party that holds the certificate and
the corresponding private key.
HTTPS Encryption
SSL/TLS uses both symmetric key and asymmetric key encryption.
Symmetric Key - often used for encrypting large amounts of data
because it is computationally faster than asymmetric cryptography.
Typical algorithms include
DES (Data Encryption Standard),
3-DES (Triple DES), RC2, RC4,
AES (Advanced Encryption Standard).
Asymmetric encryption - most common algorithm is RSA (Rivest,
Shamir & Adleman).
SSL/TLS uses Asymmetric encryption to authenticate the server to
the client, and optionally the client to the server. Asymmetric
cryptography is also used to establish a session key. The session key
is used in symmetric algorithms to encrypt the bulk of the data. This
combines the benefit of asymmetric encryption for authentication
with the faster, less processor-intensive symmetric key encryption for
the bulk data.
Purchasing on the web
The growth in web purchases makes this most
common use of cryptography through digital
signatures and encryption
Data transmitted over web is insecure as it passes
through many routers, links computers etc –
encryption solves this
Web store uses SSL – secure layer encrypts traffic
between store and customer
Has high overhead – so only credit card details and
delivery info encrypted
Most risk comes from an attack on the merchant and
their database of credit card details
ECommerce authentication
Thief poses as legit company web site
Authentication solves this – trusted authorities
(Verisign, Thawte) give public keys to your browser
and sign the public keys of web stores
Each vendor has public/private key pair – RSA key
in SSL/TSL – signing authority signs these along
with a digital certificate with the shops name and
address
Their key/certificate identifies them
Your key identifies you with credit numbers from visit to
visit
The encryption will ensure secure
transmission of credit card details and
authentication process.
To authenticate the shopper – must set up
an account with a username and password
- hence future authentication can take place
Electronic transactions over the web
Credit card purchases over the web are
invariably performed using a protocol called
SET
Protocol designed for credit card transactions
used by Mastercard and Visa – features
Confidential
Encryption of account and payment details across
network
Cardholders account and card number hidden from shop
SET
Integrity
Shopper authentication
Based on digital signatures and details of message
cannot be changed in transit
Shop can verify that the client has legitimate card and
is based on X509 certificates
Shop authentication
Shopper can authenticate and verify the shop is
authorised to accept credit cards – based on X509
certificates
Digital Certificates
Extension of an individuals public key
Has extra info that reinforces authenticity
of key
Verified by a trusted third party
X509.3 are now the standard for device
authentication and cornerstone of PKI
It is a system that binds together
identity with a public key
The structure of a X.509 v3
digital certificate is as follows:
Certificate
Version
Serial Number
Algorithm ID
Issuer
Validity
Subject
Subject Public Key Info
Public Key Algorithm
Subject Public Key
Issuer Unique Identifier (Optional)
Subject Unique Identifier (Optional)
Extensions (Optional)
Not Before
Not After
...
Certificate Signature Algorithm
Certificate Signature
Issuer and subject unique identifiers were introduced in Version 2,
Extensions in Version 3.
What is the PKI?
A system of managing certificates
Consist of certificate authorities that issue certificates
There is a hierarchy somewhat like DNS’s
May be based on geography or because the system is
flexible may fit to the companies business rules
There is also Certificate Revocation List CRL used to notify
when a certificate may become invalid
i.e. a subjects private key becomes compromised
Or some info in certificate changes i.e. issuers details change
It is important that user checks with the CRL to ensure a
certificate they have is valid – lots of issues with this
Verisign
introduced the concept of three classes
of digital certificates:
Class 1 for individuals, intended for email;
Class 2 for organizations, for which proof
of identity is required; and
Class 3 for servers and software signing,
for which independent verification and
checking of identity and authority is done
by the issuing certificate authority (CA).
How it works
1. The customer opens a Mastercard or Visa bank account.
Any issuer of a credit card is some kind of bank.
2. The customer receives a digital certificate. This electronic
file functions as a credit card for online purchases or other
transactions. It includes a public key with an expiration
date. It has been digitally signed by the bank to ensure its
validity.
3. Third-party merchants also receive certificates from the
bank. These certificates include the merchant's public key
and the bank's public key.
4. The customer places an order over a Web page,
5. The customer's browser receives and confirms from the
merchant's certificate that the merchant is valid.
6.The browser sends the order information. This message is
encrypted with the merchant's public key, the payment
information, which is encrypted with the bank's public key
(which can't be read by the merchant), and information that
ensures the payment can only be used with this particular
order.
7.The merchant verifies the customer by checking the digital
signature on the customer's certificate. This may be done by
referring the certificate to the bank or to a third-party
verifier.
8.The merchant sends the order message along to the bank.
This includes the bank's public key, the customer's payment
information (which the merchant can't decode), and the
merchant's certificate.
9. The bank verifies the merchant and the
message. The bank uses the digital signature
on the certificate with the message and verifies
the payment part of the message.
10. The bank digitally signs and sends
authorization to the merchant, who can then
fill the order.
SET
Order Info + payment instruction
Shopper
Ask and receive
authorisation
Authorisation
System
Shoppers
Bank
Settlement system
Shop
Submit
Transaction
for settlement
Merchants
Acquirer
bank
SET participants
Customer
Shop
Sells products via web and has relationship with acquirer
Acquirer Bank
Owner of a payment card and wants to buy something
Maintains accounts for merchants
Processes payment card authorisations and payments
Transfers money to the merchant account
Authorisation system
Interface between the internet and existing bankcard
payment system network for authorisation and payment
functions