Transcript EE579S Computer Security

EE579T / CS525T
Network Security
6: SSL and SET
Prof. Richard A. Stanley
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #1
If IPSec is So Good...
• Why do we need anything else?
– One could also ask, if C++ is such a good
programming language, why do we need Java?
– SSL provides another choice for achieving
security over insecure networks (e.g. Internet)
• Where they are:
– IPSec operates at the network level
– SSL operates at the transport level
– Other protocols operate at the application level
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #2
Network Level Security
HTTP
FTP
SMTP
TCP
IP/IPSec
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #3
Transport Level Security
HTTP
FTP
SMTP
SSL / TLS
TCP
IP/(IPSec)
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #4
Application Level Security
S/MIME
Kerberos
UDP
PGP
SMTP
SET
HTTP
TCP
IP/(IPSec)
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #5
What’s a Socket?
• The name, Secure Sockets Layer, implies
we are securing something called a socket.
What is that?
• Remember that IP applications separate
themselves by listening on one or more of
64K possible ports (i.e. addresses)
• A socket is a fully-specified IP address, e.g.
10.1.7.203:80 or 192.168.5.7:23
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #6
Well-Known Ports
• Many common IP services operate on what
are routinely called well-known ports
–
–
–
–
–
Port 80: HTTP
Ports 20, 21: FTP
Port 23: Telnet
Port 25: SMTP
Port 119: NNTP
• SSL operates on Port 443
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #7
SSL Factoids
• Developed by Netscape
• Current version is SSLv3, dates to mid-90’s
• Many efforts along the way to develop a
multi-vendor approach, all of which have
led to dead ends (i.e. Microsoft did not
succeed in moving Netscape to their point
of view)
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #8
SSL Provides
• Confidentiality
– Using symmetric key cryptography
• Integrity
– Using asymmetric key cryptography and
hashing
• Authenticity
– Using digital signatures and certificates on
server, and optionally, on client side
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #9
SSL Architecture
• Two layers of protocols on top of TCP
– Top level
• SSL Handshake protocol
• SSL ChangeCipherSpec protocol
• SSL Alert protocol
– SSL Record Protocol
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #10
SSL Architecture Overview
SSL
Handshake
SSL Cipher
Change Spec
SSL Alert
HTTP
SSL Record Protocol
TCP
IP/(IPSec)
NB: This diagram does not infer the order in which the protocols are applied.
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #11
Sessions and Connections
• An SSL session is a client/server
association
– Created by Handshake protocol
– Defined security parameters
• An SSL connection is a transport that
provides a service (e.g., HTTP)
– Connections are transient
– Many connections can exist within a single
session
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #12
SSL Handshake Protocol
•
•
•
•
•
•
Most complex part of SSL
Starts when client connects to server
Sets up session protocols
Selects crypto system to be used
Authenticates client and server
Sets up basis for shared secret key, the
MasterSecret
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #13
SSL Handshake Overview
Server
Client
1. Supported ciphers, random number
2. Cipher choice, certificate, random number
Verify certificate,
Generate
PreMasterSecret
3. PreMasterSecret (encrypted in server’s public key)
4. Generate keys
4. Generate keys
5. HMAC over handshake messages sent
6. HMAC over handshake messages received
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #14
Key Generation
Server random number
Client random number
Key Generator
PreMasterSecret
Label information
MasterSecret
SSL session keys
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #15
Client/Server
Random Numbers
• Consist of
– 32-bit timestamp
– 28-byte random number generated by secure
RNG
– So, 32 bytes long overall
• These random numbers serve as nonces
• Protect against replay attacks
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #16
PreMasterSecret
• Key to setting up secure exchange
• 48-byte random value, generated by client’s
secure RNG
• Sent to server encrypted with server’s
public key (from certificate sent in Step 2)
• Provides the secure basis for computing the
MasterSecret
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #17
SSL-Supported Ciphers
Block Ciphers
Algorithm
IDEA
RC2-40
DES-40
DES
3DES (TDEA)
Fortezza
Spring 2003
© 2000-2003, Richard A. Stanley
Stream Ciphers
Key
Length
128
40
40
56
168
80
Algorithm
RC4-40
RC4-128
Key
Length
40
128
EE579T/6 #18
SSL Keys
• The MasterSecret allows calculation of four
symmetric keys, used as follows:
–
–
–
–
Authentication key for client to server data
Authentication key for server to client data
Encryption key for client to server data
Encryption key for server to client data
• Use of symmetric keys in these areas allows
for faster data transfer than asymmetric key
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #19
HMAC Revisited
• Hashed Message Authentication Code is a
recursive MAC
– I.e., it is a hash of data that includes a hash
– Both hash functions inputs padded by repeated
instances of 5C hex (opad) or 36 hex (ipad)
– Both the “internal” and “external” hash is
computed using a secret key, developed from
the MasterSecret
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #20
SSL ChangeCipherSpec
• This protocol is used to change from one
encryption algorithm to another
– Called “strategies” in the RFC
• To change ciphers, client and server negotiate a
new CipherSpec and keys
– Then send ChangeCipherSpec message, which triggers
use of the new algorithm and keys
• CipherSpec usually changed at end of SSL
handshake, but can be done anytime
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #21
SSL Alert Protocol
• Used to provide connection management
• Involves messages such as\
– Digital certificate status
– Handshake failure
– MD failure
• Two levels of alert
– Warning: nonfatal problem
– Fatal: immediately terminates session
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #22
SSL Record Protocol
• Provides two SSL services:
– Confidentiality
• Using shared symmetric keys from MasterSecret
– Message integrity
• Using MAC generated using shared symmetric keys
from MasterSecret
• Also provides for message fragmentation
and (optionally) compression (lossless)
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #23
SSL Overview
• At a minimum, SSL authenticates the server
to the client and establishes a secure data
session (confidentiality + integrity)
– This is what happens when the lock closes on
your browser while you are eShopping
– Careful--JavaScript can make the lock close!
• Optionally, if the client has a certificate
acceptable to the server, the session can be
authenticated in both directions
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #24
SSL Versions
• Current version is Version 3.0
• Version 2.0 was the first version to actually
see commercial service
– Contains many security flaws
– Don’t use it unless absolutely necessary!
• Current browsers all support SSL 3.0
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #25
How Do You Get It?
• SSL comes pre-configured on modern
browsers, which also have a large suite of
root certificates
• SSL must be enabled on the appropriate
server during the server configuration
process
– Easy on IIS -- check boxes to select parameters
– A completely different build for Apache
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #26
How Do You Know If
You Have It?
• SSL is identified by the mnemonics HTTPS,
FTPS, SMTPS
• Operates on port 443 rather than port 80
(used by HTTP)
• When operating with an HTTP connection,
the URL will begin https://...
• Conversely, if SSL is enabled, it can be
accessed by addressing https://...
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #27
After SSL: TLS
• Transmission Level Security (TLS) is an
IETF approach to creating a “non-vendor
specific” SSL
• TLS 1.0 is actually SSL v3.1, and the SSL
handshake so identifies it
– TLS uses a different suite of ciphers
– TLS uses HMAC differently from SSL
• Supported by all current browsers
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #28
Before SSL: S-HTTP
• Before SSL was developed and fielded,
another secure system was developed for
signing and encrypting HTTP information
• S-HTTP includes some features that SSL
omits, such as having previously signed
documents on a server
• For all intents and purposes, S-HTTP is a
dead-end protocol, not implemented in
current browsers or other clients
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #29
SSL Summary
• SSL provides a means for secure transport
layer communications in TCP/IP networks
• SSL is a commonly used protocol,
developed by Netscape, but ubiquitously
used in browsers, etc.
• The key element of SSL is the handshake
protocol
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #30
SET: Secure Electronic
Transaction
• Security specification to protect credit card
transactions conducted over the Internet
• Product of MasterCard and Visa call for
proposals to develop such a standard
• Differs from encryption standards so far
discussed in its intent and implementation
• Introduced the concept of a dual digital
signature, which can have other uses
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #31
SET Services
• Secure communications among all parties
involved in a transaction
• Authentication using X.509v3 certificates
• Privacy, as only the information required by
each party to the transaction is provided to
that party
– We will see some details of how this works
later
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #32
Key Concepts
• Order information (OI) and payment
information (PI) are separate, but linked
– Vendor needs order information to process the
order, but does not need payment information
• Vendor needs to be paid, but doesn’t need the details
of the payment (e.g. credit card number)
– Payor does not need order information, but
needs to be able to link order to payment info to
prevent fraud
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #33
SET Overview
• Confidentiality of PI and OI
• Integrity of all transmitted data
• Authentication
– Card user is legitimate user of card
– Merchant is authorized to accept card
• Independent of transport security
• Independent of platform, O/S, etc.
• Use well-reviewed cryptographic protocols
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #34
SET Cryptography
• Confidentiality
– DES
• Data integrity
– SHA-1
• Authentication
– X.509v3 certificates, RSA digital signatures
• No choices! This is a single application
with a single purpose, not a GP protocol
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #35
The Players
•
•
•
•
Cardholder (the customer!)
Merchant (sells the goods or services)
Issuer (of the customer’s credit card)
Acquirer (has account with merchant, provides
card authorization, EFT)
• Payment gateway (processes merchant payment
messages)
• Certification Authority (CA)
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #36
Sequence of Events - 1
• Customer opens SET-capable account
• Customer receives digital certificate
• Merchant obtains certificates
– Certificate for signing messages
– Certificate for public key exchange
– Payment gateway’s public key certificate
• Customer places order
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #37
Sequence of Events - 2
•
•
•
•
•
•
Merchant verified to customer
Order and payment info sent to merchant
Merchant requests payment authorization
Merchant confirms order
Merchant provides goods and services
Merchant requests payment
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #38
Dual Signature: Why?
• Merchant needs to know customer can pay
for the goods, but does not need to know the
details of the payment information
• Issuer of card needs to know payment
information, but does not need to know the
details of the order
• The order and payment info must be linked
to prevent fraud
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #39
Dual Signature
PI
Bank
Hash
PIMD

Hash
POMD
Encrypt
OIMD
OI
Dual Sig.
Customer’s
public key
Customer’s
private key
Hash
Merchant
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #40
Now What?
• Merchant can compute
– Decrypt of dual signature
– Hash of OI (because it has OI) = OIMD
– Hash of OIMD concatenated with PIMD
=POMD = decrypt of DS
– If these are equal, OI and PI are linked
• it is infeasible to create or modify either and
maintain the linkage (hashing basics)
• Bank can do the same with PI
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #41
Payment Processing
• Customer initiates purchase request
– Purchase information (PI)
– Order information (OI)
– Cardholder certificate
• Merchant verifies cardholder certificate and dual
signature, processes order
• Merchant requests payment through gateway, gets
authorization, completes order
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #42
SET Summary
• SET provides a robust set of specialized
protocols to facilitate Internet commerce
• The unique feature of SET is the dual
signature, which could be applied elsewhere
• SET is not required to perform Internet
commerce, and is not ubiquitous
• SET does not deal with security or privacy
of customer data once it is stored
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #43
Homework
• Read Stallings, Chapter 9.1
• Do the following problems from Stallings,
Chapter 7:
– 7.1
– 7.2
Spring 2003
© 2000-2003, Richard A. Stanley
EE579T/6 #44