ipsec - University of St. Thomas

Download Report

Transcript ipsec - University of St. Thomas

CISC 210 - Class Today
•
•
•
•
•
•
Homework
Project Schedule
Lab
Recap
Protecting packet integrity
IPSEC
March 2005
R. Smith - University of St Thomas - Minnesota
1
Recap
• Protocols and Layering
– The funnel
• Lots of Applications
• Narrow middle for the “protocol stack”
• Lots of device drivers for different network hardware
• Network Encryption
– Link vs Network vs Application
• Different protection afforded at different layers
– Let’s bring up Wireshark for a moment
March 2005
R. Smith - University of St Thomas - Minnesota
2
Project Schedule
• April 20: Next Monday
– Project Proposal DUE
– You want to start working on the project NOW
– You want to have your team in place ASAP
• April 27: Twelve Days from Today
– Project OUTLINE Due
– The outline is a bit of work
• If you’re a group, figure out how to divide it up
• Hand in combined outline and combined reference list
– It counts for a chunk of the assignment (20% or so)
– DON’T MESS IT UP
March 2005
R. Smith - University of St Thomas - Minnesota
3
The Lab
• How are people doing?
– Due Next Wednesday
– Don’t get wrapped around the Loopback: 127.0.0.1
• Where to do it
– Lab down the hall – OSS 429
• When to do it
– Do I need to schedule some time?
– Do enough people have card access?
4/4/2016
R. Smith - University of St Thomas - Minnesota
4
Protecting Packet Integrity
• Tools at our disposal
– Encryption, checksums, CRCs, one-way hash
• Threats
– Fabricating new packets – forgery
– Changing packet contents – tricking the application
– Changing packet addresses – redirecting the packet
March 2005
R. Smith - University of St Thomas - Minnesota
5
Checksums for packet protection
• Incorporating a secret for protection
March 2005
R. Smith - University of St Thomas - Minnesota
6
Attacking the simple checksum
• The checksum isn’t sensitive to position
March 2005
R. Smith - University of St Thomas - Minnesota
7
Practical problems
• The secret information isn’t very much
– Trial-and-error can generate a working checksum
• The checksum isn’t very sensitive
– Obvious errors aren’t detected
– Designed to detect simple, random errors
– Not really designed to protect against clever people
• What tool(s) can improve this?
March 2005
R. Smith - University of St Thomas - Minnesota
8
Keyed Hash
• Use one-way hash with a shared secret
– Hash included in message
– Recipient verifies the message with the shared secret
March 2005
R. Smith - University of St Thomas - Minnesota
9
Issues with Keyed Hashes
• One-way hashes aren’t perfect
– Research has found ways to fiddle with them
– In particular, some aren’t sensitive enough to ‘truncation’
• Alternative #1: put secret on front and back
– Initial strategy used in the IPSEC protocols
• Still sensitive to other hash vulnerabilities
– Designers sought a way to cover weaknesses
– Apply hash multiple times to cover various problems
March 2005
R. Smith - University of St Thomas - Minnesota
10
Keyed Hash on Steroids - HMAC
• State of the art in keyed hashing
March 2005
R. Smith - University of St Thomas - Minnesota
11
IP Security Protocol – IPSEC
• Security protection that’s IP routable
• We authenticate the IP addresses
• We encrypt everything inside the IP header
March 2005
R. Smith - University of St Thomas - Minnesota
12
Separate Headers
• AH – Authentication Header
– Keeps the packet intact
• ESP – Encapsulating Security Payload
– A ‘generic’ security format, originally just for encryption
– Now does both encryption and authentication
March 2005
R. Smith - University of St Thomas - Minnesota
13
Practical question for network geeks
• What parts of the IP packet MUST be modified?
• What happens during routing?
• MAC addressing
• Hop-per-hop
March 2005
R. Smith - University of St Thomas - Minnesota
14
Authentication Header – ‘AH’
• Protects unchanging bits of the IP header
• “SPI” – Security Parameter Index
– Identifies the keying and hash algorithm to use
March 2005
R. Smith - University of St Thomas - Minnesota
15
That’s it
• Questions?
Creative Commons License
This work is licensed under the Creative Commons Attribution-Share Alike 3.0 United
States License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/us/ or send a letter to Creative
Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
March 2005
R. Smith - University of St Thomas - Minnesota
16