Cmsc 414 computer and network security lecture 26
Download
1 / 22

CMSC 414 Computer and Network Security Lecture 26 - PowerPoint PPT Presentation


  • 123 Views
  • Uploaded on

CMSC 414 Computer and Network Security Lecture 26. Jonathan Katz. Administrivia. Final exam reminder + study guide DSS students contact me. Network security protocols in practice. Network layers. Application Transport Network Data link Physical. Roughly….

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' CMSC 414 Computer and Network Security Lecture 26' - dorian-yang


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Cmsc 414 computer and network security lecture 26

CMSC 414Computer and Network SecurityLecture 26

Jonathan Katz


Administrivia
Administrivia

  • Final exam reminder + study guide

    • DSS students contact me



Network layers
Network layers

  • Application

  • Transport

  • Network

  • Data link

  • Physical


Roughly
Roughly…

  • Application layer: the communicating processes themselves and the actual ‘content’ transmitted

  • Transport layer (TCP/UDP): “end-to-end” communication; reliability; flow control

  • Network layer (IP): “host-to-host” communication; routing

  • Data link layer (Ethernet/WiFi): transmission of frames over a single hop


Example security protocols
Example security protocols

  • Application layer: PGP, SSH

  • Transport layer: SSL/TLS

  • Network layer: IPsec

  • Data link layer: IEEE 802.11 (WEP, WPA)


Security in what layer
Security in what layer?

  • Depends on the purpose…

    • How are keys provisioned/shared?

    • Should the (human) user be involved?

    • Semantics: authenticate user-to-user, or host-to-host?


Security in what layer1
Security in what layer?

  • Depends on what’s available

    • E.g., consider a user connecting to a website from a café (over a wireless network)

    • End-to-end encryption might be unavailable (e.g., if website does not support encryption)

    • Eavesdropping on Internet backbone less likely than eavesdropping on wireless link in café

    • Encrypt link from user to wireless router

    • Link-layer encryption more appropriate

      • Link-layer authentication also possible


Security in what layer2
Security in what layer?

  • Depends on the threat model/what threats are being addressed

    • What information needs to be protected? (Ports, IP addresses?)

    • E.g., network-layer authentication will not prevent DoS attacks at link level (e.g., ARP spoofing, replay disconnect messages, overloading access point)

    • E.g., an application-layer protocol cannot protect IP header information

    • End-to-end, or hop-by-hop?


Security in what layer3
Security in what layer?

  • Security interactions with various layers

    • E.g., if TCP accepts a packet which is rejected by the application above it, then TCP will reject the “correct” packet (detecting a replay) when it arrives!

    • E.g., if higher-layer header data is used by a firewall to make decisions, this is incompatible with network-layer encryption (if it encrypts headers)


Generally
Generally…

  • When security is placed at lower levels, it can provide automatic, “blanket” coverage…

    • …but it can take a long time before it is widely adopted

    • Can be inefficient to encrypt everything

  • When security is placed at higher levels, individual users can choose when to use it…

    • …but users who are not security-conscious may not take advantage of it

    • Can encrypt only what is necessary


Example pgp vs ssl vs ipsec
Example: PGP vs. SSL vs. IPsec

  • PGP is an application-level protocol for “secure email”

    • Can provide security over insecure networks

    • Users choose when to use PGP; user must be involved

    • Alice’s signature on an email proves that Alice actually generated the message, and it was received unaltered; also non-repudiation

      • In contrast, SSL secures “the connection” from Alice’s computer; would need additional mechanisms to authenticate the user

    • Communication with off-line party (i.e., email)


Example pgp vs ssl vs ipsec1
Example: PGP vs. SSL vs. IPsec

  • SSL sits at the transport layer, “above” TCP

    • Packet stream authenticated/encrypted

    • End-to-end security, best for connection-oriented sessions (e.g., http traffic)

    • User does not need to be involved

    • The OS does not have to change, but applications do if they want to communicate securely


Example pgp vs ssl vs ipsec2
Example: PGP vs. SSL vs. IPsec

  • IPsec sits at the network layer

    • Individual packets authenticated/encrypted

    • End-to-end or hop-by-hop security

    • Need to modify OS

    • All applications “protected” by default, without requiring any change to applications or actions on behalf of users

    • Only authenticates hosts, not users

    • User can be completely unaware that IPsec is running



Brief history
Brief history…

  • SSLv2 deployed in Netscape 1.1 (1995)

  • Modified version of SSLv3 standardized as TLS

  • This overview will not focus on the differences; I just say “SSL” for convenience

  • SSL is a major success story!

    • Used extensively and (almost) exclusively to secure web traffic


Broad overview
Broad overview

  • SSL runs on top of TCP

    • Advantage: does not require changes to TCP

  • From the programmer’s point of view, it sits at the transport layer

    • Same API as for TCP

    • Runs only with TCP, not UDP

  • Primarily used for HTTP traffic


Ssl overview
SSL overview

  • Three phases

    • Handshake

    • Key derivation

    • Data transfer


Handshake key derivation
Handshake + key derivation

  • Client sends list of supported crypto algorithms and nonce RC

  • Server sends a certificate, selects a crypto algorithm, and sends nonce RS

    • Nonce protects against client impersonation

  • Client encrypts random K with server’s public key

  • Client/server derive session keys from RC, RS, K

    • Prevents replay attacks

  • Client sends a MAC of the handshake; server responds with the same


Sessions and connections
Sessions and connections

  • One session may have multiple simultaneous connections

  • Can derive per-connections keys by exchanging fresh RC, RS, and using session (master) key K


Data transfer
Data transfer

  • Client and server use K to establish four keys: encryption and authentication, for each direction

  • SSL breaks data stream into records; appends a MAC to each record; and then encrypts the result

    • Mac-then-encrypt…

    • What would have been a better choice?

  • The MAC is computed over the record plus a sequence number

    • Prevents replay, re-ordering, or dropping packets


Ssl security
SSL security

  • Provides confidentiality, integrity, and unidirectional authentication

    • Client wants to make sure they are talking to the right merchant; merchant does not care who client is

  • Mutual authentication supported

    • If server requests it, and client has a certificate

    • Note that mutual authentication may be done at application level (e.g., password-based login)


ad