Chapter 8 Key Distribution, SSL, IPSEC

1
Chapter 8Key Distribution, SSL, IPSEC

• Professor Rick Han
• University of Colorado at Boulder
• rhan_at_cs.colorado.edu

2
Announcements

• Programming Assignment 4 due May 1
• Final Exam May 6, 1030 am 1 pm
• Comprehensive
• In this room
• Review next week
• Last weeks lectures, midterm on the Web soon
• Grade summaries soon
• Need a volunteer for FCQs.
• Next, Key Distribution, SSL, IPSEC

3
Recap of Previous Lecture

• Public key cryptography
• Based on one-way functions difficulty of
  factoring product of two large prime s
• If X want to send to Y, X requests Ys public
  key.
• Only I can decrypt with my private key
• Authentication via Digital Signatures
• Even repeating an encrypted password is subject
  to replay attacks
• Hash the document, encrypt the hash with your
  private key
• Hash is one-way cryptographic function
• Data Integrity via One-Way Cryptographic Hashes

4
Digital signature Signed message digest

• Alice verifies signature and integrity of
  digitally signed message

• Bob sends digitally signed message

5
Authentication Other Methods

• The method of authentication via digital
  signatures just described is classified in
  section 8.2 as MD5 with RSA Signature
• Textbook discusses 3 other useful techniques for
  authentication where one or both sides choose
  random s. Youre responsible for knowing
  these
• 3-way handshake
• Trusted 3rd party (Kerberos)
• Public-key authentication

6
Non-Repudiation via Digital Signatures

• Digital Signatures provide authentication,
  integrity, and non-repudiation
• At receiver, if MDA MDB then receiver knows
  that
• Only the senders private key could have created
  this signature (Non-repudiation Authentication)
• Sender cant deny sending message

MDA
MDB
7
Key Distribution Certification

• Public keys which are not securely certified can
  suffer from a man-in-the-middle attack
• X wishes to send to Z, but Y transparently sits
  in the middle between X and Z

Z Please send me your public key
Z Please send me your public key
Ys public key, Y says its Zs
Zs public key
Xs data encrypted with Ys public key
Xs data encrypted with Zs public key
Y decrypts With Ys Private key
X and Z never know that Y has seen their data
8
Key Distribution Certification (2)

• Another type of attack on non-certified public
  keys
• Y pretends to be X. Y advertises a public key
  under the name of X.

I am X, here is my public key (provides Ys
public key)
Key Database
Retrieve public key of X
Send a pizza to X, Heres Xs signature
(provides Ys signature)
Xs signature Verified!
Pizza sent to X
Whats this?
9
Key Distribution Certification (3)

• Basic problem exploited by both attacks
• The public key was not certified as belonging to
  an entity (a person, a router, a company, etc.)
• Use a trusted Certification Authority (CA) to
  bind a key to an entity
• Public key of CA is available at a well-known
  address that cant be spoofed
• Or, public key of CA is pre-installed, e.g.
  Netscape browser has embedded public key of the
  Netscape CA
• Assume there exists an out-of-band procedure
  (perhaps non-electronic), where an entity
  registers its public key with a CA in a
  verifiable way
• Trust the CA to have verified all public keys and
  have removed the possibility of spoofing an
  identity

10
Key Distribution Certification (4)

• Use a trusted Certification Authority (CA) to
  bind a key to an entity (cont.)
• When host X wants to securely talk with host Y,
  host X first asks host Y (or CA) for host Ys
  public key
• Host Y returns host Ys public key, signed with
  the CAs signature
• This is host Ys public key, signed by the
  trusted CA
• Constitutes a digital certificate (conforms to
  X.509 standard)
• Host X receives the CAs digital certificate and
  uses CAs public key to verify that the
  certificate was signed by the trusted CA
• Now, host X has the verified public key for host
  Y for secure communication

11
SSL/TLS

• Secure Sockets Layer (SSL) and its follow-on
  Transport Layer Security (TLS)
• Phase 1 Handshake phase
• Negotiate an encryption algorithm (e.g. DES)
• Authenticate the server to the client
• Decide on keys
• Phase 2 Data transfer phase via a record
  protocol

HTTPS
SSL/TLS
TCP
IP
12
SSL/TLS (2)

• Handshake protocol public key, then common case
  is symmetric key
• Client (browser) sends a Hello to Server (Web),
  including clients cryptographic preferences
• Server replies with Hello servers certificate
• Client uses CAs public key to verify servers
  certificate, extracts servers public key
  server is now authenticated
• Client generates a symmetric session key
  (actually a pre-master secret), encrypts it with
  the servers public key, and sends it back to
  server
• Both sides now have symmetric session key and can
  use DES-like encryption/decryption.
• Some additional messaging to complete SSL
  handshake. Also, supports client authentication.

13
SSL/TLS (3)

• Any application-layer protocol can use SSL, e.g.
  http, smtp, ftp, telnet, ssh, etc.
• HTTP over SSL is called HTTPS
• A secure URL is often preceded by https//
• Other technologies
• S-HTTP (or Secure HTTP) differs from HTTPS
• Message-based transactions (SSL is
  connection-based)
• Specific to HTTP (SSL works with all application
  layer protocols). URL is preceded by shttp//
• Less popular than HTTPS
• SET (Secure Electronic Transactions)
• Public-key technology for secure financial
  payments by VISA. Technically, can work on top
  of SSL.

14
Symmetric Key Distribution

• Key distribution
• Public key via trusted Certificate Authorities
• Symmetric key?
• Diffie-Helman Key Exchange
• Public key, then secret key (e.g. SSL)
• Symmetric Key distribution via a KDC (Key
  Distribution Center)

15
Symmetric Key Distribution (2)

• Symmetric Key distribution via a KDC (Key
  Distribution Center)
• KDC is a server (trusted 3rd party) sharing a
  different symmetric key with each registered user
• Alice wants to talk with Bob, and sends encrypted
  request to KDC, KA-KDC(Alice,Bob)
• KDC generates a one-time shared secret key R1
• KDC encrypts Alices identity and R1 with Bobs
  secret key, let m KB-KDC(Alice,R1)
• KDC sends to both Alice R1 and m, encrypted with
  Alices key i.e. KA-KDC(R1, KB-KDC(Alice,R1))
• Alice decrypts message, extracting R1 and m.
  Alice sends m to Bob.
• Bob decrypts m and now has the session key R1

16
Symmetric Key Distribution (3)
m

• Kerberos authentication basically follows this
  KDC trusted 3rd party approach
• In Kerberos, the message m is called a ticket and
  has an expiration time

17
IPsec

• IP security protocol is a suite of protocols for
  security at the network layer
• Provides data confidentiality/secrecy Encrypt
  the IP payload (not header, except when
  tunneling)
• All higher layer information is encrypted,
  including TCP/UDP port s
• Called the Encapsulation Security Payload (ESP)
  protocol
• Provides source authentication and data integrity
• Authenticates the source to make sure the sender
  is not spoofing IP addresses
• Called the Authentication Header (AH) protocol

18
IPsec (2)

• ESP protocol provides network-layer secrecy,
  source host authentication and data integrity
• TCP/UDP segment is surrounded by header and
  trailer fields
• DES-CBC encryption of TCP/UDP segment trailer
• Trailer lists the Protocol of the segment (TCP,
  or UDP, or ). Hidden from observers.
• Normal IP routing using IP header. Destination
  sees protocol50 and decrypts ESP packet

19
IPsec (3)

• Authentication field contains digital signature
  of entire original IP datagram (same as AH
  signature)
• Signed message hash over IP header TCP/UDP
  segment, including IP source address
• Cant spoof an IP address or tamper with the IP
  header without being detected

20
IPsec (4)

• AH protocol provides source authentication and
  data integrity, but not secrecy
• Insert an AH header between IP header (indicated
  by Protocol 51)
• Next Header field indicates whether segment is
  TCP, UDP, etc.
• Authentication Data field contains a digital
  signature, or signed message digest calculated
  over the original IP datagram
• Provides source authentication
• Provides datagram integrity tamper check
• Digital signature could be DES, MD5, or SHA -
  negotiated

21
IPsec (5)
Logical Security Agreement

• The two IP endpoints set up a logical connection
  called a Security Agreement (SA)
• Simplex/unidirectional end-to-end security
• Uniquely identified by 3-tuple the security
  protocol (AH or ESP), source IP address, and a
  32-bit ID called Security Parameter Index (SPI)
• Key management in an SA governed either by
  Internet Key Exchange (IKE) algorithm or Internet
  Security Association and Key Management Protocol
  (ISAKMP)

22
IPsec (6)
Encrypted IP datagrams

• Some implications
• NATs will no longer work when dealing with
  IPsec-encrypted IP datagrams why?
• NATs are transparent yet also require knowledge
  of TCP source port this is encrypted by IPsec!
• Also, NATs require changing the source port and
  source IP address, but NAT cant modify the
  digital signature (which prevents undetectable
  tampering)

23
IPsec (7)
Secure Intranet
Secure Intranet
Secure Tunnel over Insecure IP routing

• Some implications
• Virtual Private Networks (VPNs) are created and
  connected using IPsec
• Create IPsec gateways that tunnel/encapsulate
  across the insecure Internet Virtual
• IPsec provides confidentiality Private

24
IPsec (8)

• May want to use IPsec over your corporate
  intranet, even though the intranet is protected
  by a firewall
• Protects against eavesdropping, tampering, and
  spoofing from the inside, i.e. disgruntled
  employees
• IPsec has been proposed as part of wireless
  solution to overcome WEPs security flaws
• How widely deployed?
• In Windows 2000/XP, some Linux flavors (Suse 8.0,
  patch others with open source IPsec
  implementation called FreeSWAN), firewalls, Cisco
  routers
• Philosophy if I have SSL end-to-end security why
  do I need IPsec end-to-end security?
• Headers still exposed and could reveal info