Cryptography and Network Security

1
Cryptography and Network Security

• 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 bought by
  Verisign in 1999
• Competition went into a slump but picked up in
  recent years
• http//www.whichssl.com/comparisons/compatibility.
  html
• 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
application
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 (AES129, AES256)
• openssl ciphers v
• http//www.iana.org/assignments/tls-parameters
• message is compressed before encryption
• message integrity
• using a MAC with shared secret key and implicit
  record number
• similar to HMAC but with different padding
• https
• use security bit
• server authenticated, client not (typically)

13
SSL Record Protocol Operation
14
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

15
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
• no certificate, bad certificate, unsupported
  certificate, certificate revoked, certificate
  expired, certificate unknown
• close notify for detecting truncation attacks
• HTTP/0.9 does not require Content-length other
  apps?
• compressed encrypted like all SSL data

16
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

17
(No Transcript)
18
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

19
TLS Key Exchange

• The main negotiated key is called the pre-master
  secret in documentation
• Static RSA
• client chooses key and sends it encrypted under
  public key associated with server cert
• 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?

20
TLS Key Exchange

• Anonymous Diffie-Hellman (DH)
• unauthenticated, rare
• Static DH
• Servers contribution is fixed in cert, 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

21
TLS Key Exchange

• Server Gated Crypto / Step-Up
• Historical
• For approved financial transactions
• Special server certs allow clients to use strong
  crypto where they would normally refuse
• www.fortify.net

22
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

23
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 ephemeral 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
• Don't just sign the ephemeral key, but also sign
  ClientHello with the strong signature key
  (protocol change)
• Just stop using the export suites (either side)

24
Netscape PRNG

• Wagner, Goldberg 96
• Disassembly
• Observed that Netscape RNG was seeded from pid,
  ppid, and time of day in SSLv2
• About 47 bits of total randomness
• Guess verify secret
• Speed
• Logged onto machine, 25 secs
• No login, about an hour

25
Client Authentication

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

26
Performance

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

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

• Layering woes Nagle algorithm fighs with delayed
  acks
• Nagle client stack waits for ack of old datagram
  before sending tinygram (size lt maximum segment
  size)
• Such as first client application-layer
  transmission, perhaps
• Though congestion window?
• In order to avoid filling up the network with
  mostly headers
• Delayed acks server stack delays its ack of
  datagram up to 200 ms
• TCP_NODELAY socket option turns off Nagle
  algorithm
• Not default in openssl ?
• Appropriate for Rupdate?
• Accelerators
• Crypto cards
• Inline HTTP/TLS -gt HTTP

30
HTTPS and Web Servers

• HTTP over SSL usually port 443
• 443 means "use SSL"
• No substantial HTTP awareness of SSL underneath
• 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
• Set up your own Certificate Authority and issue a
  server cert for name
• Apache / OpenSSL / mod_ssl very common
  combination
• Fairly complicated setup
• Plenty of commercial server support

31
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

32
Example Amazon 2004-2007

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

33
SMTP over TLS

• RFC 2487
• Uses ordinary SMTP port and STARTTLS message
• Server may also refuse service until STARTTLS
  arrives
• Unless it's last hop towards destination
• MX records for pointing to mail exchangers
  remains unauthenticated
• So active attackers can still seize mail in
  transit
• STARTTLS is good for resisting passive attacks

34
S-HTTP

• RFC 2660 Alternative to HTTPS
• Adds security headers to HTTP requests,
  responses, and links

HTTP/1.0 200 OK Security-Scheme
S-HTTP/1.4 Content-Type text/html
Congratulations, you've won. ltA
href"/prize.html" CRYPTOPTS"Key-Assign
Inband,alice1,reply,des-ecb020406080a0c0e0f
SHTTP-Privacy-Enhancements recv-requiredauth"gtCl
ick here to claim your prizelt/Agt
35
Datagram TLS

• Gaining TLS-like protection over unreliable
  transport
• SIP, gaming protocols
• Described in RFC 4347, April 2006
• Generally, as similar to TLS as possible
• Issues to address
• Handshake is critical and must be reliable
• Chaining in TLS is over entire bytestream
• MAC is over implicit message number
• Denial of service easy to initiate handshakes

36
Datagram TLS Solutions

• Handshake reliability
• Retransmission timers, replay, etc.
• Fragmentation support for handshakes only
• Chaining
• Add IVs to DTLS records
• Add sequence num to DTLS records
• Sliding window (64) for reordering and replay
  detection
• Replays and MAC failures are not necessarily
  malicious
• Stateless cookies for denial of service
  resistance
• HelloVerifyRequest after client_hello
• Path MTU detection to avoid lower-layer
  fragmentation

37
(No Transcript)
38
Datagram TLS status

• Brand new
• OpenSSL implementation apparently broken
• http//www1.ietf.org/mail-archive/web/tls/current/
  msg01631.html

39
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

40
SET Components
41
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

42
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

43
Dual Signature Construction
44
Purchase Request Customer
45
Purchase Request Merchant
46
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

47
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

48
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

49
Summary

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