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 (Secure Socket Layer)

• transport layer security service
• protocol vs API
• originally developed by Netscape
• version 3 designed with public input
• subsequently became Internet standard known as
  TLS (Transport Layer Security)
• uses TCP to provide a reliable end-to-end service
• SSL has two layers of protocols

5
SSL Architecture
6
SSL Architecture

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

7
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)

8
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

9
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

10
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

11
(No Transcript)
12
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

13
TLS Key Exchange

• Our Key is pre-master secret in documentation
• Static RSA
• client chooses key and sends it encrypted
• 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?

14
TLS Key Exchange

• Anonymous Diffie-Hellman (DH)
• unauthenticated, like project 2
• Static DH
• Servers contribution is fixed in cert
• Ephemeral DH
• server authenticates contribution by signing it
• Fortezza
• PCMCIA smart card
• Skipjack (declassified June 1998)
• Key escrow
• Law Enforcement Access Field (LEAF)
• Key embedded in IV

15
(No Transcript)
16
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
• How to prevent adversary changing cipher from
  server?
• MAC
• where does shared secret come from?

17
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
• 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)

18
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

19
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

20
Performance

• SSL is slow
• Crypto
• Latency (in addition to TCP)
• Session resumption
• Servers have it rough, signing with private key
• Layering woes
• Nagle algorithm, delayed ack
• Client stack waits for ack of old record before
  sending new
• Server stack delays its ack of old record
• Accelerators
• Crypto cards
• Inline HTTP/TLS -gt HTTP

21
Web Servers

• HTTP over SSL usually port 443
• Apache / OpenSSL / mod_ssl very common
• Fairly complicated setup
• Commercial server support
• Example www.estrelladancewear.com

22
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

23
SET Components
24
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

25
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

26
Purchase Request Customer
27
Purchase Request Merchant
28
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

29
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

30
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

31
Summary

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