Chapter 8 Authentication, Data Integrity, Public Key Distribution, Firewalls Professor Rick Han...
-
date post
19-Dec-2015 -
Category
Documents
-
view
243 -
download
3
Transcript of Chapter 8 Authentication, Data Integrity, Public Key Distribution, Firewalls Professor Rick Han...
Chapter 8Authentication, Data Integrity,
Public Key Distribution, Firewalls
Professor Rick HanUniversity of Colorado at Boulder
Prof. Rick Han, University of Colorado at Boulder
Authentication (1)• Both sender and receiver need to verify
the identity of the other party in a communication:
Goal: Bob wants Alice to “prove” her identity to himProtocol ap1.0: Alice says “I am Alice”
Failure scenario??
• Trudy says “I am Alice”
Prof. Rick Han, University of Colorado at Boulder
Authentication (2)Protocol ap2.0: Alice says “I am Alice” and sends her IP
address along to “prove” it.
Failure scenario??• Trudy says “I am Alice”, Alice’s IP
address• IP spoofing is easy. Some
router’s don’t forward if IP src addr doesn’t match src LAN, but not all
Prof. Rick Han, University of Colorado at Boulder
Authentication (3)Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.
Failure scenario?
• Trudy says “I am Alice”, Alice’s password
• Telnet sents passwords in the clear
Prof. Rick Han, University of Colorado at Boulder
Authentication (4)
Protocol ap3.1: Alice says “I am Alice” and sends her encrypted secret password to “prove” it.
Failure scenario?
I am Aliceencrypt(password)
• Trudy says “I am Alice”, Alice’s encrypted password
• Replay or playback attack: Trudy replays encrypted password without needing to know actual password
Prof. Rick Han, University of Colorado at Boulder
Authentication via Digital Signatures
• Similar conceptually to handwritten signatures• Uses a property of public-key cryptography:
• m = cd mod n = (me)d mod n = (md)e mod n• Thus, can swap the order: use private key for encryption
and a public key for decryption
• Method I: Bob encrypts entire message with Bob’s private key. This is Bob’s digital signature.
• Bob send both the message and his digital signature
Prof. Rick Han, University of Colorado at Boulder
Authentication via Digital Signatures (2)
• Alice decrypts Bob’s message using Bob’s public key
• If decrypted message matches the message, Alice knows that• The signed message could only have come
from Bob (assuming only Bob knows his private key)
Bob’s message
Bob’s signature
Compare
Decrypt withPublic Key
Prof. Rick Han, University of Colorado at Boulder
Authentication via Digital Signatures (3)
• In Method I, signing the entire document/message is computationally expensive
• Method II: Instead, compute a hash on the document/message• The hash is much smaller than the document,
resembles a CRC. Also called a message digest• Hash function H generates the hash• Use private key to encrypt only the message
digest• Encrypted digest commonly called a digital
signature• Computationally inexpensive
Prof. Rick Han, University of Colorado at Boulder
Authentication via Digital Signatures (4)
• Send both the document and the digitally signed message digest
• At receiver• hash the document = MDA
• decrypt the digital signature = MDB
• If MDA = MDB then receiver knows that:• the identity of sender correctly matches the
advertiser of the public key (Authentication)• that the document hasn’t been tampered
with (Data Integrity)• Caveat: the hash function must be “one-
way” to make these claims
Prof. Rick Han, University of Colorado at Boulder
Digital signature = Signed message digest
Bob sends digitally signed message:
Alice verifies signature and integrity of digitally signed message:
Prof. Rick Han, University of Colorado at Boulder
Data Integrity via One-Way Hash Functions
• The hash function H has the property that it is one-way:1. Given a message digest value MD, it is
computationally infeasible to find a message y such that H(y)=MD,
2. It is computationally infeasible to find any two messages x and y such that H(x)=H(y)
• Otherwise, could substitute a forged message y for original message without changing the hash/MD• Violates Data Integrity – tampering must be
detectable
• MD5 and SHA-1 are examples of one-way hashes
Prof. Rick Han, University of Colorado at Boulder
Data Integrity via One-Way Hash Functions (2)
• Example: the TCP/IP checksum is a hash function that is not one-way• One’s complement 16-bit sum1. Example: Easy to forge the message x with y yet
keep the checksum the same, H(x)=H(y) without detection• flip two bits from different 16-bit blocks but
with the same offset n within a 16-bit block: checksum unchanged
2. Example: Easy to forge the message x with y and modify the checksum H(x) to H(y) without detection
• Lack of one-way hash enables forgery
Prof. Rick Han, University of Colorado at Boulder
Data Integrity via One-Way Hash Functions (3)
• Wireless 802.11b uses a security standard called the Wired Equivalent Privacy (WEP) protocol that has a hash-based security flaw• Given a message m, compute a 32-bit checksum
c(m), and form a packet <m,c(m)>• RC4 stream cipher used to encrypt packet:
• Send ciphertext “RC4(key) XOR <m,c(m)>”• Attacker creates a delta packet: <D,c(D)>• Attacker XOR’s delta packet with ciphertext:
• RC4(key) XOR <m,c(m)> XOR <D,c(D)> = RC4(key) XOR <m XOR D, c(m) XOR c(D)> = RC4(key) XOR <m’, c(m XOR D)> checksum is linear,
not 1-way = RC4(key) XOR <m’, c(m’)> undetectable tampering
of WEP
Prof. Rick Han, University of Colorado at Boulder
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. You’re responsible for knowing these:• 3-way handshake• Trusted 3rd party (Kerberos)• Public-key authentication
Prof. Rick Han, University of Colorado at Boulder
Non-Repudiation via Digital Signatures
• Digital Signatures provide authentication, integrity, and non-repudiation
• At receiver, if MDA = MDB then receiver knows that:• Only the sender’s
private key could have created this signature (Non-repudiation & Authentication)
• Sender can’t deny sending message
MDA MDB
Prof. Rick Han, University of Colorado at Boulder
Public 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 ZX ZY
“Z: Please send meyour public key”
“Z: Please send meyour public key”
Z’s public keyY’s public key, Y says it’s Z’s
X’s data encryptedwith Y’s public keyY decrypts
With Y’sPrivate key
X’s data encryptedwith Z’s public key
X and Z never knowthat Y has seen their data
Prof. Rick Han, University of Colorado at Boulder
Public 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.
Y
X
Z“Send a pizza to X”, Here’s X’s signature (provides Y’s signature)
Key DatabaseI am X, here is mypublic key (providesY’s public key)
Retrieve publickey of “X”
X’s signatureVerified!
Pizza sent to X
What’s this?
Prof. Rick Han, University of Colorado at Boulder
Public 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 can’t 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
Prof. Rick Han, University of Colorado at Boulder
Public 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 Y’s public key
• Host Y returns host Y’s public key, signed with the CA’s signature: • “This is host Y’s public key, signed by the trusted
CA”• Constitutes a digital certificate (conforms to X.509
standard)
• Host X receives the CA’s digital certificate and uses CA’s 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
Prof. Rick Han, University of Colorado at Boulder
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
HTTPSSSL/TLS
TCPIP
Prof. Rick Han, University of Colorado at Boulder
SSL/TLS (2)• Handshake protocol: public key, then
common case is symmetric key• Client (browser) sends a “Hello” to Server
(Web), including client’s cryptographic preferences
• Server replies with Hello + server’s certificate• Client uses CA’s public key to verify server’s
certificate, extracts server’s public key – server is now authenticated
• Client generates a symmetric session key (actually a pre-master secret), encrypts it with the server’s 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.
Prof. Rick Han, University of Colorado at Boulder
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.
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
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 protocol=50 and decrypts ESP packet
Prof. Rick Han, University of Colorado at Boulder
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• Can’t spoof an IP address or tamper with the IP
header without being detected
Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
IPsec (5)
• 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)
IProuter
IPdest
IPsource
Logical Security Agreement
Prof. Rick Han, University of Colorado at Boulder
IPsec (6)
• Some implications:• NAT’s will no longer work when dealing with
IPsec-encrypted IP datagrams – why?• NAT’s are transparent yet also require
knowledge of TCP source port – this is encrypted by IPsec!
• Also, NAT’s require changing the source port and source IP address, but NAT can’t modify the digital signature (which prevents undetectable tampering)
NAT IPdest
IPsource
Encrypted IP datagrams
Prof. Rick Han, University of Colorado at Boulder
IPsec (7)
• Some implications:• Virtual Private Networks (VPN’s) are created and
connected using IPsec• Create IPsec gateways that
tunnel/encapsulate across the insecure Internet = “Virtual”
• IPsec provides confidentiality = “Private”
IPsecgateway
IPdest
IPsource
IPsecgateway
Secure Tunnel overInsecure IP routing
Secure Intranet Secure Intranet
Prof. Rick Han, University of Colorado at Boulder
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 WEP’s 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
Prof. Rick Han, University of Colorado at Boulder
Firewalls• We’ve already seen two kinds of firewalls in
action:• NAT’s act as filter-based firewalls• HTTP proxies can act as proxy-based firewalls
• Firewalls address the Availability problem in security• Guaranteeing access to legitimate users.
Prevention of Denial-of-Service (DOS) attacks to a corporate intranet
Prof. Rick Han, University of Colorado at Boulder
Firewalls (2)• Filter-based firewall can by default
implement a policy that • Admits packets not on a list, OR• Only admits packets on a list
• The firewall’s list/table will contain 5-tuples• <source IP addr, source TCP/UDP port,
destination IP address, destination TCP/UDP port, protocol>
• Can specify wildcards, e.g. <128.92.0.3, *, 192.12.13.14, 80, TCP> could mean to let pass all TCP packets with a source addr 128.92.0.3, any source port, which are destined for 192.12.13.14 port 80.
Prof. Rick Han, University of Colorado at Boulder
Firewalls (3)• Sample policy #1: Filter-based firewalls can
reject all inbound packets with source IP’s not among addresses known to be reachable from that router interface• Called “ingress filtering”• Effective against IP spoofing• Thus, the interface from which a packet arrives is
as important as the IP header info
Prof. Rick Han, University of Colorado at Boulder
Firewalls (4)• Sample policy #2: Reject all inbound UDP
packets to block external video on corporate LAN• Won’t this filter all UDP-based DNS responses?
• Can limit to a few inbound ports from trusted DNS servers
• can also remember that you’re expecting a response from a particular DNS server.
• Can’t entirely eliminate spoofing of external addresses though
Prof. Rick Han, University of Colorado at Boulder
Firewalls (5)• Sample policy #3: Enable all outgoing TCP
connections but block all incoming TCP connections• Looks inside TCP packets and rejects all inbound
SYN attempts• Variation: look inside TCP packets and reject all
inbound packets with TCP ACK bit set to 0 – accomplishes same effect as rejecting inbound SYN’s• TCP ACK bit is set to 0 only for first segment
of a TCP connection, otherwise it is set to 1 for responses
• “Layer 4” switch
Prof. Rick Han, University of Colorado at Boulder
Firewalls (6)• FTP and firewalls:
• FTP’ing between an intranet client to an external server creates both an outbound control connection (port 21) and an inbound TCP data connection (port 20)• The inbound data connection gets blocked by
a firewall implementing sample policy #3• Solution: server supports PASV option,
chooses port > 1023, informs client of its port via the control channel, then the client initiates a TCP connection to server’s chosen port thru firewall
• Most Web browsers support the PASV option but not all FTP servers
Prof. Rick Han, University of Colorado at Boulder
Firewalls (7)• Sample policy #4: Reject all inbound
packets from a block of addresses• Some ISP’s have in the past rejected all packets
with IP source addresses from China because hackers often use insecure servers in China to launch DOS attacks
Prof. Rick Han, University of Colorado at Boulder
Gateways/Proxies• Packet-filtering firewalls are limited
• No notion of securing a “session”• Application-level gateways or proxies
• Permit session-level access control• To use an application-level protocol like
telnet, must authenticate to the gateway• Example: internal user wants to telnet to
external site• telnets to the gateway• gateway authenticates the user• If password/userid OK, then gateway
telnets to the outside world on user’s behalf
Prof. Rick Han, University of Colorado at Boulder
Gateways/Proxies (2)• Some limitations of application-level
gateways• One per application, e.g. ftp, http, smtp, etc.• Each application must explicitly be configured
to point towards gateway• Packet-filtering firewalls are transparent
• Performance penalty of relaying through gateway
Prof. Rick Han, University of Colorado at Boulder
Wireless Access & Firewalls
• 802.11b exposes your internal LAN• BS1 is a security risk (WEP problems now, fixed
in future?)
• So make sure wireless access is outside of the firewall• BS2 is safer placement, supplement with
another firewall (not shown)
FirewallCorporate LAN
Internet
BS1 BS2