Chapter 8 Authentication, Data Integrity, Public Key Distribution, Firewalls - PowerPoint PPT Presentation

About This Presentation
Title:

Chapter 8 Authentication, Data Integrity, Public Key Distribution, Firewalls

Description:

Chapter 8 Authentication, Data Integrity, Public Key Distribution, Firewalls Professor Rick Han University of Colorado at Boulder rhan_at_cs.colorado.edu – PowerPoint PPT presentation

Number of Views:124
Avg rating:3.0/5.0
Slides: 42
Provided by: csColora
Category:

less

Transcript and Presenter's Notes

Title: Chapter 8 Authentication, Data Integrity, Public Key Distribution, Firewalls


1
Chapter 8Authentication, Data Integrity, Public
Key Distribution, Firewalls
  • Professor Rick Han
  • University of Colorado at Boulder
  • rhan_at_cs.colorado.edu

2
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
    him

Protocol ap1.0 Alice says I am Alice
Failure scenario??
  • Trudy says I am Alice

3
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, Alices IP address
  • IP spoofing is easy. Some routers dont
    forward if IP src addr doesnt match src LAN, but
    not all

4
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, Alices password
  • Telnet sents passwords in the clear

5
Authentication (4)
Protocol ap3.1 Alice says I am Alice and sends
her encrypted secret password to prove it.
I am Alice encrypt(password)
Failure scenario?
  • Trudy says I am Alice, Alices encrypted
    password
  • Replay or playback attack Trudy replays
    encrypted password without needing to know actual
    password

6
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 Bobs
    private key. This is Bobs digital signature.
  • Bob send both the message and his digital
    signature

7
Authentication via Digital Signatures (2)
  • Alice decrypts Bobs message using Bobs 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)

Bobs message
Compare
Bobs signature
Decrypt with Public Key
8
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

9
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 hasnt been tampered with (Data
    Integrity)
  • Caveat the hash function must be one-way to
    make these claims

10
Digital signature Signed message digest
  • Alice verifies signature and integrity of
    digitally signed message
  • Bob sends digitally signed message

11
Data Integrity via One-Way Hash Functions
  • The hash function H has the property that it is
    one-way
  • Given a message digest value MD, it is
    computationally infeasible to find a message y
    such that H(y)MD,
  • 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

12
Data Integrity via One-Way Hash Functions (2)
  • Example the TCP/IP checksum is a hash function
    that is not one-way
  • Ones complement 16-bit sum
  • 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
  • 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

13
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 ltm,c(m)gt
  • RC4 stream cipher used to encrypt packet
  • Send ciphertext RC4(key) XOR ltm,c(m)gt
  • Attacker creates a delta packet ltD,c(D)gt
  • Attacker XORs delta packet with ciphertext
  • RC4(key) XOR ltm,c(m)gt XOR ltD,c(D)gt
  • RC4(key) XOR ltm XOR D, c(m) XOR c(D)gt
  • RC4(key) XOR ltm, c(m XOR D)gt ? checksum
    is linear, not 1-way
  • RC4(key) XOR ltm, c(m)gt ? undetectable
    tampering of WEP

14
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

15
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
16
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 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
17
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.

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?
18
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 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

19
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 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

20
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
21
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.

22
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.

23
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

24
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

25
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

26
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

27
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)

28
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)

29
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

30
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

31
Chapter 8Firewalls
  • Professor Rick Han
  • University of Colorado at Boulder
  • rhan_at_cs.colorado.edu

32
Firewalls
  • Weve already seen two kinds of firewalls in
    action
  • NATs 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

33
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 firewalls list/table will contain 5-tuples
  • ltsource IP addr, source TCP/UDP port, destination
    IP address, destination TCP/UDP port, protocolgt
  • Can specify wildcards, e.g. lt128.92.0.3, ,
    192.12.13.14, 80, TCPgt 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.

34
Firewalls (3)
  • Sample policy 1 Filter-based firewalls can
    reject all inbound packets with source IPs 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

35
Firewalls (4)
  • Sample policy 2 Reject all inbound UDP packets
    to block external video on corporate LAN
  • Wont this filter all UDP-based DNS responses?
  • Can limit to a few inbound ports from trusted DNS
    servers
  • can also remember that youre expecting a
    response from a particular DNS server.
  • Cant entirely eliminate spoofing of external
    addresses though

36
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
    SYNs
  • 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

37
Firewalls (6)
  • FTP and firewalls
  • FTPing 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 gt 1023, informs client of its port via the
    control channel, then the client initiates a TCP
    connection to servers chosen port thru firewall
  • Most Web browsers support the PASV option but not
    all FTP servers

38
Firewalls (7)
  • Sample policy 4 Reject all inbound packets
    from a block of addresses
  • Some ISPs 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

39
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 users behalf

40
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

41
Wireless Access Firewalls
Corporate LAN
Firewall
Internet
BS1
BS2
  • 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)
Write a Comment
User Comments (0)
About PowerShow.com