Cryptography and Network Security

1
Cryptography and Network Security

• Third Edition
• by William Stallings
• Lecture slides by Lawrie Brown
• Modified by David Martin

2
Chapter 17 Web Security

• Use your mentality
• Wake up to reality
• From the song, "I've Got You under My Skin by
  Cole Porter

3
Web Security

• Web now widely used by business, government,
  individuals
• but Internet Web are vulnerable
• have a variety of threats
• integrity
• confidentiality
• denial of service
• authentication
• need added security mechanisms

4
SSL history

• Transport layer security service
• Actually a protocol, not an API, though an API is
  usually nearby
• Popularity really came from Netscapes attempt to
  jumpstart ecommerce
• 1994 Netscape designed and built SSLv2
• and told consumers that they needed SSL credit
  card numbers were too sensitive to let go
  unencrypted
• Only Netscape Commerce Server supported SSL
• It relied on X.509 certificates issued by RSADSI
• Microsoft had PCT (Private Communications
  Technology), backwards-compatible with SSLv2
• Fixed various problems, added some new features
• 1995 SSLv3 (what we will see)

5
SSL history continued

• Microsoft Secure Transport Layer Protocol (STLP)
• Derived from SSLv3
• Supported unreliable transport (UDP), client auth
  via shared secrets
• 1996 IETF Transport Layer Security working group
• to reconcile SSL and PCT/STLP (and others?) into
  an IETF protocol
• SSLv3 "won" and is the basis for TLS
• IESG (steering group) instructed working group to
  add DSS, DH, 3DES
• Big deal because of Netscape's preference for RSA
• But more so because 3DES was not exportable
• 1995 "Danvers doctrine" said to make decisions
  based on good engineering rather than national
  policies
• See RFC 3365, "Strong Security Requirements for
  Internet Engineering Task Force Standard
  Protocols "

6
SSL history continued

• RSADSI provided X.509 certificates for server
  authentication
• RSADSI spun off Verisign
• Others seemed poised to compete but didnt really
• Strongest competitor Thawte was eventually bought
  by Verisign
• Not much competition remains
• Public Key Infrastructure (PKIX) working group
  for IETF standardization of X.509 certs
• TLS depended on this group's work
• TLS published in January 1999 as RFC 2246

7
U.S. Crypto Export control

• NSA made the decisions
• Authentication was generally approved
• Before Sept '98 encryption required export
  license
• up to 40-bit DES, 512-bit key exchange
• RC2 and RC4 particularly favored
• larger sizes available to banks
• After Sept '98
• review still required
• up to 56-bit DES and 1024-bit key exchange
• Traces of all this are visible throughout SSL

8
U.S. Crypto Export control

• After Jan 2000
• open source can just be posted on Internet
• commercial/retail software still formally
  required to undergo review, but generally
  approval follows

9
SSL Architecture
10
SSL Architecture

• SSL session
• an association between client server
• created by the Handshake Protocol
• define a set of cryptographic parameters
• essentially, the master secret
• may be shared by multiple SSL connections
• SSL connection
• a transient, peer-to-peer, communications link,
  typically a TCP connection
• associated with a SSL session

11
SSL Architecture

• A session may outlive any particular connection
• SSL considers TCP sessions partially unreliable
  connections may be broken
• So it's possible to resume sessions without
  having to renegotiate everything
• Big potential performance benefit

12
SSL Record Protocol

• confidentiality
• using symmetric encryption with a shared secret
  key defined by Handshake Protocol
• IDEA, RC2-40, DES-40, DES, 3DES, Fortezza,
  RC4-40, RC4-128
• message is compressed before encryption
• message integrity
• using a MAC with shared secret key
• similar to HMAC but with different padding
• https
• use security bit
• server authenticated, client not (typically)

13
SSL Change Cipher Spec Protocol

• one of 3 SSL specific protocols which use the SSL
  Record protocol
• a single message
• causes pending state to become current
• hence updating the cipher suite in use

14
SSL Alert Protocol

• conveys SSL-related alerts to peer entity
• severity
• warning or fatal
• specific alert
• unexpected message, bad record mac, decompression
  failure, handshake failure, illegal parameter
• close notify, no certificate, bad certificate,
  unsupported certificate, certificate revoked,
  certificate expired, certificate unknown
• compressed encrypted like all SSL data

15
SSL Handshake Protocol

• allows server client to
• authenticate each other
• to negotiate encryption MAC algorithms
• to negotiate cryptographic keys to be used
• comprises a series of messages in phases
• Establish Security Capabilities
• Server Authentication and Key Exchange
• Client Authentication and Key Exchange
• Finish

16
(No Transcript)
17
TLS (Transport Layer Security)

• IETF standard RFC 2246 similar to SSLv3
• with minor differences
• in record format version number
• uses HMAC for MAC
• a pseudo-random function expands secrets
• has additional alert codes
• some changes in supported ciphers
• changes in certificate negotiations
• changes in use of padding

18
TLS Key Exchange

• Our Key is pre-master secret in documentation
• Static RSA
• client chooses key and sends it encrypted under
  public key associated with server cert
• no forward secrecy
• Ephemeral RSA
• server signs newly chosen weak RSA key under
  strong long-term RSA key
• client chooses pre-master secret and transmits it
  under the weak key
• export considerations
• forward secrecy
• what if short-term key is revealed?
• what if long-term key is revealed?

19
TLS Key Exchange

• Anonymous Diffie-Hellman (DH)
• unauthenticated, like project 3 "any" mode, rare
• Static DH
• Servers contribution is fixed in cert, sort of
  like project 3 "fixed" mode, rare
• Ephemeral DH
• server authenticates contribution by signing it,
  common
• Fortezza
• PCMCIA smart card
• Skipjack (declassified June 1998)
• Key escrow
• Law Enforcement Access Field (LEAF)
• Key encrypted in IV
• Extremely rare

20
TLS Key Exchange

• Server Gated Crypto (SGC)
• Historical
• For approved financial transactions
• Special server certs allow clients to use strong
  crypto where they would normally refuse
• www.fortify.net

21
From Rescorla, SSL and TLS Designing and
Building Secure Systems, Addison-Wesley 2001

• Server chooses cipher from suite
• Client chooses pre-master secret
• According to selected key exchange method
• MAC of handshakes (over these choices) prevent
  simple cipher suite modification
• MAC shared secret is derived from master secret

22
Moeller Downgrade Attack

• Requires attacker to factor 512-bit RSA
• But works even if client and server are willing
  to use 1024 bits
• Start by forging messages forcing client and
  server to agree on 512-bit export RSA
• Remove all other choices from offered suites
• Problem MAC over agreement
• Attackers factors 512 bits to recover shared
  secret
• Uses it to forge and substitute MACs
• Then listen to rest of session
• Solutions
• Have ServerKeyExchange signature depend on
  ClientHello
• Just stop using the export suites (either side)

23
Netscape PRNG

• Wagner, Goldberg 96
• Disassembly
• Observed that Netscape RNG was seeded from
  process ID and time of day in SSLv2
• Guess verify secret
• Speed
• Logged onto machine, 25 secs
• No login, about an hour

24
Client Authentication

• SSL/TLS, IE, Netscape all support client certs
• Rarely used outside of corporate settings
• Peoplesoft ?
• HTTP Basic authentication within SSL session
• Cleartext password stored on server, but hidden
  on wire

25
Performance

• SSL is slow
• Crypto
• Latency (in addition to TCP)
• Session resumption
• Servers have it rough, signing with private key
  to prove identity

26
From Rescorla, SSL and TLS Designing and
Building Secure Systems, Addison-Wesley 2001
27
From Rescorla, SSL and TLS Designing and
Building Secure Systems, Addison-Wesley 2001
28
Performance

• Layering woes
• Nagle algorithm, delayed ack
• Client stack waits for ack of old record before
  sending tinygram
• Such as first client application-layer
  transmission, perhaps
• Server stack delays its ack of old record up to
  200 ms
• TCP_NODELAY turns off algorithm
• Not default in openssl ?
• Accelerators
• Crypto cards
• Inline HTTP/TLS - HTTP

29
HTTPS and Web Servers

• HTTP over SSL usually port 443
• 443 means "use SSL"
• Web pages typically include a lot of embedded
  content
• potentially fetched over different TCP
  connections
• session resumption is critical for performance
• HTTP persistent connections are very helpful
• Proxies
• A proxy is a man-in-the-middle
• HTTP "CONNECT" method just relays data proxy
  can't examine
• Possible to reconfigure clients so that a real
  man-in-the-middle "attack" on https is possible
• You set up your own CA
• Apache / OpenSSL / mod_ssl very common
  combination
• Fairly complicated setup
• Plenty of commercial server support

30
Original Purpose

• Protecting consumer credit-card info
• Never worked as well as advertised, because of
  ubiquity of redirects
• While some people are trained to look for the
  miniscule lock icon, they alsoneed to verify
  that the URL isreasonable

31
Example Amazon

• Prominent site
• Not even any apparent SSL use on this page
• Though it's really enabled
• "If you receive an error message", please try
  without SSL

32
Secure Electronic Transactions (SET)

• open encryption security specification
• to protect Internet credit card transactions
• developed in 1996 by Mastercard, Visa etc
• not a payment system
• rather a set of security protocols formats
• secure communications amongst parties
• trust from use of X.509v3 certificates
• privacy by restricted info to those who need it

33
SET Components
34
SET Transaction

• customer opens account
• customer receives a certificate
• merchants have their own certificates
• customer places an order
• merchant is verified
• order and payment are sent
• merchant requests payment authorization
• merchant confirms order
• merchant provides goods or service
• merchant requests payment

35
Dual Signature

• customer creates dual messages
• order information (OI) for merchant
• payment information (PI) for bank
• neither party needs details of other
• but must know they are linked
• use a dual signature for this
• signed concatenated hashes of OI PI

36
Purchase Request Customer
37
Purchase Request Merchant
38
Purchase Request Merchant

• verifies cardholder certificates using CA sigs
• verifies dual signature using customer's public
  signature key to ensure order has not been
  tampered with in transit that it was signed
  using cardholder's private signature key
• processes order and forwards the payment
  information to the payment gateway for
  authorization (described later)
• sends a purchase response to cardholder

39
Payment Gateway Authorization

• verifies all certificates
• decrypts digital envelope of authorization block
  to obtain symmetric key then decrypts
  authorization block
• verifies merchant's signature on authorization
  block
• decrypts digital envelope of payment block to
  obtain symmetric key then decrypts payment
  block
• verifies dual signature on payment block
• verifies that transaction ID received from
  merchant matches that in PI received (indirectly)
  from customer
• requests receives an authorization from issuer
• sends authorization response back to merchant

40
Payment Capture

• merchant sends payment gateway a payment capture
  request
• gateway checks request
• then causes funds to be transferred to merchants
  account
• notifies merchant using capture response

41
Summary

• have considered
• need for web security
• SSL/TLS transport layer security protocols
• SET secure credit card payment protocols