• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Network Security
 

Network Security

on

  • 2,512 views

Presentation

Presentation

Statistics

Views

Total Views
2,512
Views on SlideShare
2,347
Embed Views
165

Actions

Likes
0
Downloads
139
Comments
0

3 Embeds 165

http://www.ustudy.in 144
http://ustudy.in 20
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Network Security Network Security Presentation Transcript

    • Note 11: Network Security
      • The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.
      • — The Art of War, Sun Tzu
      • Network Security Threats
      • Security and Cryptography
      • Network Security Protocols
      • Cryptographic Algorithms
      • What is information security?
        • Keeping information secure against stealing & changing & destroying & forging
        • Traditionally provided by physical (e.g., cabinets with locks) and administrative means (e.g., personal screening procedures)
      • Information security requirements have dramatically changed in the last several decades
        • Growing computer use requires automated tools to protect files and other stored information
        • Growing use of networks and communications links requires measures to protect data during transmission
      • Computer security
        • the generic name for the collection of tools designed to protect data and to thwart hackers
      • Network security
        • measures to protect data during their transmission
      • Internet security
        • measures to protect data during their transmission over a collection of interconnected networks
      • Note: boundaries among these definitions are blurred
      • Our focus is on Network Security (Internet & Wireless Network Security)
      • This consists of measures to deter, prevent, detect, and correct security violations that involve the transmission & storage of information
      • Network Security Threats
        • Eavesdropping, man-in-the-middle, client and server imposters
        • Denial of Service attacks
        • Viruses, worms, and other malicious code
      • Network Security Requirements
        • Privacy, Integrity, Authentication, Non-Repudiation, Availability
      • Countermeasures
        • Communication channel security
        • Border security
      • Information transmitted over network can be observed and recorded by eavesdroppers (using a packet sniffer)
      • Information can be replayed in attempts to access server
      Client Server Request Response replay
      • Imposters attempt to gain unauthorized access to server
        • Ex. bank account or database of personal records
        • For example, in IP spoofing imposter sends packets with false source IP address
      Client Imposter Server
      • Attacker can flood a server with requests, overloading the server resources
        • Results in denial of service to legitimate clients
      • Distributed denial of service attack on a server involves coordinated attack from multiple (usually hijacked) computers
      Attacker Server
      • An imposter impersonates a legitimate server to gain sensitive information from a client
        • E.g. bank account number and associated user password
      Client Server Imposter
      • An imposter manages to place itself as man in the middle
        • convincing the server that it is legitimate client
        • convincing legitimate client that it is legitimate server
        • gathering sensitive information and possibly hijacking session
      Client Server Man in the middle
      • A client becomes infected with malicious code
        • Opening attachments in email messages
        • Executing code from bulletin boards or other sources
      • Virus: code that, when executed, inserts itself in other programs
      • Worms: code that installs copies of itself in other machines attached to a network
      • Many variations of malicious code
      Client Server Imposter
      • Trojan horse
        • A program with an overt (documented or known) effect and a covert (undocumented or unexpected) effect
      • Virus
        • A set of instructions that inserts copies of itself into other programs
      • Worm
        • A program that replicates itself on other machines across a network
      • Bacteria/rabbit
        • A free-standing program that absorbs all of some class of resource
      • Trapdoor
        • An undocumented entry point in a program
      • Logic bomb
        • A program that performs an action when some external event occurs
      • Zombie
        • Malicious instructions on comprised machines used to launch attacks
      • Written by bad guys (except the trapdoor)
      • A virus can be installed in just about any program
        • Jump x
      • Original infection
        • Running a single infected program
      • The halting problem
        • It is impossible in general to tell what an arbitrary program will do by looking at it. -- Nobody looks.
      • Floppy or CD-R, CD-RW
      • Email
      • Resource sharing
      • Log into the other machine
      • Mobile programs
      • Program bugs
      • Buffer overflow
      • Operating System: resource access control
      • Virus Checker: instruction patterns, file lengths or digests
      • Software Patch: bug fixes
      • Intrusion Detection: host intrusion detection, network intrusion detection
      • Firewall: filter unwanted/unauthorized traffic
      • Don’t run software from suspicious sources
      • Frequently run virus checkers
      • Try to run programs in the most limited possible environments
      • Do frequent backups, and save old backups for a long time
      • Don’t boot off floppies
      • Security threats motivate the following requirements:
      • Privacy : information should be readable only by intended recipient
      • Integrity : recipient can confirm that a message has not been altered during transmission
      • Authentication : it is possible to verify that sender or receiver is who he claims to be
      • Non-repudiation : sender cannot deny having sent a given message.
      • Availability : information and services should be available whenever needed
      • Secure communication channels
      • Encryption
      • Cryptographic checksums and hashes
      • Authentication
      • Digital Signatures
      • Secure borders
      • Firewalls
      • Virus checking
      • Intrusion detection
      • Authentication
      • Access Control
    • Security and Cryptography
      • Encryption : transformation of plaintext message into encrypted (and unreadable) message called ciphertext
      • Decryption : recovery of plaintext from ciphertext
      • Cipher : algorithm for encryption & decryption
      • A key is required to perform encryption & decryption
      • Substitution Cipher: Map each letter or numeral into another letter or numeral:
        • a b c d e f g h i j k l m n o p q r s t u v w x y z
        • z y x w v u t s r q p o n m l k j i h g f e d c b a
      • Example:
        • hvxfirgb  security
      • Substitution ciphers are easy to break
        • Take histogram of frequency of occurrence of letters in a ciphertext message
        • Match to known frequencies of letters
      • Transposition Cipher: Rearrange order of letters/numerals in a message using a particular rearrangement:
        • interchange character k with character k+1
      • Example:
        • security  esuciryt
      • Transposition Ciphers are easy to break
        • Suppose plaintext and ciphertext are known; matching of letters in plaintext and ciphertext will reveal transposition mapping
        • Using anagram analysis: sliding pieces of ciphertext around, then looking for sections that look like anagrams of English words, and solving the anagrams
      • Sender encrypts P by applying mapping E K which depends on secret key K: C = E K (P)
      • Receiver decrypts C by applying inverse mapping D K which also depends on K: D K (E K (P)) = P
      E K (.) Key K Key K Plaintext P Ciphertext C=E K (P) P Encryption Decryption D K (.)
      • Algorithm should be easy to implement and deploy on large scale
      • Algorithm should be difficult to break:
      • Number of keys should be very large
        • Attacker cannot try all possible keys
      • The secret key should be very hard to derive from intercepted messages
        • Even if a large number of plaintext & corresponding cyphertexts are known to the attacker
      • Examples of secret key methods discussed later:
        • Data Encryption Standard (DES) and Triple DES
        • Advanced Encryption Standard (AES)
      • Privacy : secret key renders messages confidential
      • Integrity : alteration of the cyphertext will be detected, because the decrypted message will be gibberish
        • When privacy is not required, encryption of the entire message is overkill because much processing involved
        • We will see that cryptographic checksums provide integrity and require less processing
    • Sender (John) Receiver (Jane) E k (r) r E k (r´) r´ John to Jane, “let’s talk”
      • Send message identifying self
      • Send response with encrypted r
      • Can now authenticate receiver by issuing a challenge
      • Reply with challenge that contains random number r, nonce = n umber once
      • Apply secret key to decrypt message. If decrypted number is r then the transmitter is authenticated
      • Transmitter calculates a fixed number of bits (crypto checksum/hash) that depends on secret key K: H K (P)
      • Receiver recalculates hash from received message & compares to received hash
      Message Crypto Checksum Calculator CrytoChk Message K P P H K (P)
      • To be secure, it must be very difficult to find a message that generates a given hash
        • If not difficult, an attacker could produce a message and corresponding hash that would be accepted as valid
      • Suppose message is M bits long and hash is m bits long, and m << M
        • For each given hash value there are 2 M/m messages that give that hash
        • How long does it take to find a match?
        • Probability that a random message generates given hash is 2 - m since there are 2 m hashes
        • Mean # tries to find a given hash is: 2 m
      • M = 1000, m = 128
      • Number of possible messages: 2 1000
      • Number of possible hashes: 2 128
      • For each hash value there are 2 1000 /2 128 = 2 872 messages that generate the hash
      • A randomly selected message produces a desired hash value with probability 2 -128
      • If each attempt requires 1 microsecond, time to find matching message to a hash is:
        • 2 128 x1 microsecond = 2 25 years
      • Message Digest 5 (MD5)
        • Pad message to be multiple of 512 bits
        • Initialize 128 buffer to given value
        • Modify buffer content according to next 512 bits
        • Repeat until all blocks done
        • Buffer holds 128 bit hash
      • Keyed MD5
        • Pad message to be multiple of 512 bits
        • Attach and append secret key to padded message prior to performing hash function
        • Could also append/attach other information such as sender ID
      • Secure Hash Algorithm 1 (SHA-1)
        • Produce a 160-bit hash; more secure than MD5
        • Keyed version available
      • HMAC improves strength of a hash code
        • Pad secret key with zeros to length of 512 bits and X-OR with 64 repetitions of 00110110
        • Pad message to multiple of 512 bits
        • Calculate hash of padded key followed by padded message, 128 bits for MD5, 160 bits for SHA-1
        • Pad hash to 512 bits
        • Pad secret key with zeros to 512 bits and X-OR with 64 repetitions of 01011010
        • Calculate hash of padded key and padded hash
        • Result is final hash
      • Public key cryptography provides privacy using two different keys:
        • Public key K1 available to all for encrypting messages to a certain user: C = E K1 (P)
        • Private key K2 for user to decrypt messages: P = D K2 (E K1 (P))
      E K1 (.) Public key K 1 Private key K 2 Plaintext P Ciphertext C = E K1 (P) P Encryption Decryption D K2 (.)
      • E K1 and D K2 should be readily implementable
      • Inverse relationship should hold:
        • P = D K2 (E K1 (P)) and sometimes P = E K1 (D K2 (P))
      • K1 is a relatively small number of bits and K2 is usually a large number of bits
      • It is extremely difficult to decrypt E K1 (P) without K2
      • It should not be possible to deduce K2 from K1
      • Example: RSA public key cryptography
      • Named after Rivest, Shamir, and Adleman
      • Modular arithmetic & factorization of large numbers
        • Let n = pq , where p & q are two large numbers
          • n typically several hundred bits long, i.e. 512 bits
          • Plaintext must be shorter than n
        • Find e relatively prime to ( p – 1)( q – 1)
          • i.e. e has no common factors with ( p – 1)( q – 1)
          • Public key is { e , n }
        • Let d be multiplicative inverse of e
          • de = 1 modulo ( p – 1)( q – 1)
          • Private key is { d,n }
      • Fact: For P<n and n, p, q, d as above:
        • P de mod n = P mod n
      • Encryption:
        • C = P e mod n
        • Result is number less than n and is represented by same number of bits as key
      • Decryption:
        • C d mod n = P ed mod n = P mod n = P
      • Security stems from fact that it is very difficult to factor large numbers n , and with e to then determine d
      • Let p = 5, q = 11
        • n = pq = 55 and ( p – 1)( q – 1) = 40
      • Let e = 7, which is relatively prime to 40
        • 7d mod 40 = 1, gives d = 23
      • Public key is {7, 55}
      • Private key is {23, 55}
      • Encrypt “RSA”: R=18, S=19, A=1
        • C 1 = 18 7 mod 55 = 18 4+2+1 mod 55
        • = (18 mod 55) (18 2 mod 55) (18 4 mod 55) mod 55
        • = (18) (324 mod 55) (18 4 mod 55) mod 55
        • = (18) (49) (49 2 mod 55) mod 55 = (18)(49)(36) mod 55
        • = 31752 mod 55 = 17
        • C 2 = 19 7 mod 55 = 24
        • C 3 = 1 7 mod 55 = 1
      • Decrypt
        • 17 23 mod 55 = 17 16+4+2+1 mod 55 =18
        • 24 23 mod 55 = 19
        • 1 23 mod 55 = 1
      • Integrity:
        • Any one can send messages using public key, so integrity not assured directly
        • For integrity, transmitter:
          • encodes P with its private key K2 ΄ to obtain P ΄ = D K2 ΄ (P)
          • encodes P ΄ using receiver’s public key: C = E K1 (P ΄ )
        • Receiver:
          • decrypts C, D K2 (E K1 (P ΄ )) = P ΄
          • decrypts P ΄ using transmitters public key, E K1 ΄ (D K2΄ (P)) = P
          • Only the transmitter could have sent this message.
      • Transmitter identifies itself
      • Receiver sends a nonce encoded using the sender’s public key in a challenge message
      • Transmitter uses its private key to recover the nonce, and it returns the unencrypted nonce
      • Only the holder of the private key can find the nonce
      E K1 (r) r John to Jane, “let’s talk” Sender Receiver
      • Digital signatures provide nonrepudiation
        • User “signs” a message that cannot be repudiated
      • Digital signature obtained as follows:
        • Transmitter obtains a hash of the message
        • Transmitter encrypts the hash using its private key; result is the digital signature
        • Transmitter sends message and signature
      • To check the signature:
        • Receiver obtains hash of message
        • Receiver decrypts signature using sender’s public key
        • Receiver compares hash computed from message and hash obtained from signature
        • Procedure also ensures message integrity
      • Public key systems have more capabilities
        • Secret key: privacy, integrity, authentication
        • Public key: all of above + digital signature
      • Public key algorithms are more complex
        • Require more processing and hence much slower than secret key
      • Practice:
        • Use public key method during session setup to establish a session key
        • Use secret key cryptography during session using the session key
      • PGP developed by Phillip Zimmerman to provide secure email
        • http://www.philzimmermann.com/index.shtml
        • http://www.pgpi.org
      • Notorious for becoming publicly available for download over Internet in violation of US export restrictions
      • Uses public key cryptography to provide
        • Privacy, integrity, authentication, digital signature
      • De facto standard for email security
      • Also provides privacy and integrity for stored files
      • Every pair of users requires a separate shared secret key
        • N ( N – 1) keys for N users; Grows quickly with N
        • Similar to full-mesh connections for N users
      • Solution: Introduce Key Distribution Centers
        • Each users has shared key with the KDC
        • User A has shared key K KA with KDC
        • User B has shared key K KB with KDC
        • KDC provides shared key when A & B need to communicate
      • User A contacts the KDC to request a key for use with user B.
      • KDC:
        • Authenticates user A
        • Selects a key K AB and encrypts it to produce E KA (K AB ) and E KB (K AB ) .
      • KDC sends both versions of the encrypted key to A.
      • User A contacts user B and provides a ticket in the form of E KB (K AB )
      • Users A & B both have KAB
      KDC A B C D request E KA (K AB ), EKB(KAB) challenge response E KB (K AB )
      • Kerberos: authentication service for users to access servers over network
      • KDC has secret key with every user
      • At login, user supplies ID and password
        • KDC authenticates user & generates session key
        • Session key & ticket-granting ticket (TGT) is sent to user encrypted using shared secret key
      • To access a particular server, user sends request to KDC with server name and TGT
        • KDC decrypts TGT to recover session key & then returns ticket to client for desired server
      • In public key only one pair of keys per user
      • Key distribution problem: How to determine whether an advertised public key is not from an imposter?
      • Certification Authority (CA)
        • Issues digitally signed certificate that provides
          • User’s name & public key
          • Certificate serial #, expiration date
        • Certificates can be stored in publicly accessible directories
        • To communicate with B, a user contacts the CA to obtain the certificate for B
        • Users are configured to have the CA’s public key, which they use to verify the digital signature
      • Generate keys instead of distributing keys
      • Diffie-Hellman exchange to create a shared key
      • A & B pick p a large prime #, and generator g < p
        • A picks x and sends T = g x to B; B picks y and sends R = g y
        • Secret key is K = (g x ) y = (g y ) x which are calculated by A & B
      • Eavesdropper that obtains p, g, T, R cannot obtain x and y because x = logT and y = logR are extremely difficult to solve
      Transmitter A Receiver B T = g x R = g y K = R x mod p = g xy mod p K = T y mod p = g xy mod p
      • An intruder C can interpose itself between A & B
      • C establishes a shared key K 1 with A and a shared key K 2 with B
      • C can then intercept, decipher, and re-encrypt all communications
      • Need mutual authentication between A & B
      • Alternative: Community agrees on g & p; users publish their T, R, …
      Transmitter A Man in the middle C Receiver B T R' T' R K 1 = R´ x = g xy ´ K 1 = T y ´ = g xy ´ K 2 = R x ´ K 2 = T´ y = g x ´ y = g x ´ y
      • Diffie-Hellman exchange involves computation of powers of large numbers
        • Large number of multiplications implies heavy computational burden
        • Susceptible to denial-of-service attacks
    • Network Security Protocols
      • Computers A & B communicate across the Internet
      • Exposure to eavesdropping, imposters, DoS
      • Can encrypt some transmitted information
        • But IP headers need to be visible to routers & hence others
        • Eavesdropper can gather variety of usage information & deduce nature of interaction
        • Choice of which layer to apply security: IP, transport, or application layer
      A B Internet
      • Computers A and B have gateways interposed between their internal network and Internet
      • Gateway can be a firewall
        • Controls external access to internal network
        • Packet filtering according to various header fields
          • IP addresses, port numbers, ICMP types, fields within payload
      • Secure tunnels can be established between gateways
        • All internal information including headers can be encrypted
      A B Internet
      • Mobile host needs access to internal network
      • Gateway must provide user with access while barring intruders from accessing internal network
      • May also need to protect identity of mobile user
      • IP-address of mobile user changes
      Internet
      • Firewalls can operate at different layers
        • IP-layer filtering cannot operate on payload contents
      • Circuit-Level Gateways
        • Direct client-to-server TCP connections not allowed
        • Relays TCP segments between actual client & actual server
      • Application-Level Gateways or Proxies
        • Interposed between actual client and actual server
        • Performs authentication and determines what features are available to client
        • Monitors, filters & relays messages
      • Security Services can be provided at different layers of the protocol stack
      • Data Link Layer security
        • Point-to-point security between directly-connected devices, e.g. wireless LAN security
      • IP-Layer security
        • Security service between IP layers
        • e.g. IPsec
      • Transport Layer security
        • Security service between Transport Layers
        • E.g. Secure Sockets Layer & Transport Layer Security
    • .
      • IPsec defined in RFCs 2401, 2402, 2406
      • Provides authentication, integrity, confidentiality, and access control at the IP layer
      • Provides a key management protocol to provide automatic key distribution techniques.
      • Security service can be provided between a pair of communication nodes, where the node can be a host or a gateway (router or firewall).
      • Two protocols & two modes to provide traffic security:
        • Authentication Header and Encapsulating Security Payload
        • Transport mode or tunnel mode
      • A Security Association (SA) is a logical simplex connection between two network-layer entities
      • Two SA’s required for bidirectional secure communication
      • SA is specified by
        • A unique identifier
        • Security services to be used
        • Cryptographic algorithms to be used
        • How shared keys will be established
        • Other attributes such as lifetime
      • SA negotiated before security service begins
      • Integrity can be ascertained by sending a cryptographic checksum or hash of message
      • Authentication also provided if hash covers:
        • Shared secret key, sender’s identity & message
        • Fields that are changed while packet traverses Internet are set to zero in calculation of hash
      • To protect against replay attacks, message should carry a sequence number that is covered by the hash
        • Receiver accepts a packet only once
        • Receiver maintains a window of packets it accepts
      • Receiver recalculates hash and compares to hash in received packet
      • Inserted between regular header & payload
      • Packet header contains field indicating presence of authentication header
      • Authentication header includes:
        • Security association ID
        • Sequence number
        • Cryptographic hash
      Packet header Authentication header Packet payload Authenticated except for changeable fields
      • A tunnel can be created by encapsulating a packet within another packet
        • Inner packet header carries original source address
        • Entire contents of inner packet covered by hash
        • Outer packet header carries gateway’s address
      New header Authentication header Packet payload Authenticated except for changeable fields in new header Original header In tunnel mode Internet Tunnel
      • Privacy requires encryption of message
      • Encryption header identifies security association & sequence number
      • Encryption can cover payload + padding:
      • Authentication header can be used to detect alteration of any non-changeable fields & protect against replay attacks
      Packet + pad payload Packet header Encryption header Encrypted Encrypted Packet + pad payload New header Authentication header Encryption header
      • In tunnel mode, entire original packet is encrypted and unreadable to eavesdroppers
        • All original packet header fields are unreadable
        • Only gateway packet header is visible
      • It is also possible to use tunnel mode between trusted routers while traversing untrusted segments of the Internet
        • Trusted routers can decrypt inner packet & perform routing
      In tunnel mode New header Encryption header Original header Encrypted Packet payload
      • To setup security association, computers must:
        • Agree on security services that will be provided
        • Agree on cryptographic algorithms
        • Authenticate each other
        • Establish a shared secret key
      • Last two steps are difficult; possible approaches:
        • Manual set up of shared key between pair of users
        • Use Key Distribution Center
        • Contact a Certificate Authority
      • Internet Key Exchange (RFC 2409) for IPsec
        • Assumes parties have a name/identity for other party as well as a pre-established shared secret (secret key or private key)
    • Initiator Host Contains C i Proposes Security Association options Contains C i & C r Selects SA options Select random # C i : initiator’s cookie Check to see if C i already in use; If not, generate C r , responder’s cookie; Associate C r with initiator’s address Check C i & address against list; Associate (C i , C r ) with SA; record SA as “unauthenticated” Responder Host HDR, SA Cookie Request HDR, SA Cookie Response
    • Initiator Host T=g x mod p Nonce N i Initiate Diffie-Hellman exchange Check responder cookie, discard if not valid; If valid identify SA with (C i , C r ) & record as “unauthenticated” R=g y mod p Nonce N r Calculate K=(g y ) x mod p Calculate K=(g x ) y mod p Calculate secret string of bits SKEYID known only to initiator & responder Calculate secret string of bits SKEYID known only to initiator & responder Responder Host HDR, KE, N i Key Request HDR, KE, N r Key Response
    • Initiator Host Prepare signature based on SKEYID, T, R, C i , C r , the SA field, initiator ID SKEYID, T, R, C i , C r , SA, ID i Hash of info in HDR encrypted Authenticates initiator comparing decrypted hash to recalculated hash. If agree, SA declared authenticated. Prepares signature based on SKEYID, T, R, C i , C r , the SA field, responder ID r SKEYID, T, R, C i , C r , SA, ID r Hash of info in HDR Authenticate initiator. If successful, SA declared authenticated. Responder Host HDR, {ID i , Sig i } Signature Request HDR, {ID r , Sig r } Signature Request
      • SKEYID for authentication, based on:
        • Shared key that results from Diffie-Hellman
        • Pre-shared key
          • Pre-configured secret key
          • Private part of a public key pair
        • Nonces and/or cookies
      • Cookies
        • To counteract denial-of-service attacks
        • A user that wants to make a connection requests must first request a cookie
        • Connections requests are only accepted from users that have a valid cookie, and hence that must receive packets at the IP address from which they sent the request
      • Authentication header (AH) placed after headers that are examined at every hop
      • Presence of AH indicated by protocol value = 51 in IPv4 header
      • Authentication performed over all fields including IP header, except fields that change at every hop
      IPv4 Header AH Upper Layer (e.g., TCP or UDP)
      • Format used in IPv4 and IPv6
      • Next Header indicates next payload after AH
      • Length of Authentication data in multiples of 32 bits
      • SPI = unique ID for security association
      • Sequence number for anti-replay protection
      • Authentication data contains result of authentication computation
      Next Header Length Reserved Security Parameters Index 0 8 16 31 Sequence Number Authentication Data
      • ESP provides:
        • Integrity & authentication service
        • Privacy service by encryption of payload
      • Authentication data at end is optional
        • Placement at ends makes implementation simpler
      IPv4 Header ESP Upper Layer (e.g., TCP or UDP) HMAC
      • Authenticated coverage from SPI until next header field
      • Encrypted coverage from payload data field until next header
      • Protocol type = 50
      • Next header field is encrypted, so transport type not visible
      Security Parameters Index 0 16 24 31 Sequence Number Payload Data Padding Pad Length Next Header Authentication Data
      • SSL developed by Netscape Communications
        • Operates on top of TCP
        • Provides secure connections
          • HTTP, FTP, telnet, …
        • Electronic ordering & payment; e-mail
        • SSL 3.0 submitted to IETF for standardization
      • TLS standardized by IETF (RFC 2246)
        • Slight differences with SSL 3.0
      • TLS protocols operate at two layers
      • TLS Record Protocol operates on top of TCP
      • Protocols on top of TLS Record Protocol
        • TLS Handshake Protocol
        • TLS Change Cipher Specification Protocol
        • TLS Alert Protocol
      TCP TLS Record Protocol Handshake Protocol Change cipher spec Protocol Alert Protocol HTTP Protocol IP
      • TLS Record protocol provides
        • Privacy service through secret key encryption
          • Encryption algorithm is negotiated at session setup
          • Secret keys generated per connection using another protocol such as Handshake protocol
        • Reliability service through keyed message authentication code
          • Hash algorithm negotiated at session setup
          • Operates without hash only during session negotiation
      • TLS Handshake protocol used by client & server
        • Negotiate protocol version, encryption algorithm, key generation method
        • Can authenticate each other using public key algorithm
        • Client & server establish a shared secret
        • Multiple secure connections can be set up after session setup
      • Session specified by following parameters
        • Session Identifier : byte sequence selected by server
        • Peer Certificate : certificate of peer
        • Compression method : used prior to encryption
        • Cipher spec : encryption & message authentication code
        • Master Secret : 48-byte secret shared by client & server
        • Is resumable?: flag indicating if new connections can be initiated
    • Request connection Includes: Version #; Time & date; Session ID (if resuming); Ciphersuite (combinations of key exchange, encryption, MAC, compression) Send ServerHello if there is acceptable Ciphersuite combination; else, send failure alert & close connection. * Optional messages Server Certificate Server part of handshake done Server part of key exchange: Diffie-Hellman, g x; ; RSA, public key ServerHello includes: Version #; Random number; Session ID ; Ciphersuite & compression selections Compute shared key May contain public key New CipherSpec pending TLS Record protocol initially specifies no compression or encryption Client Server ClientHello ServerHello Certificate * ServerKeyExchange * ServerHelloDone
    • Client’s part of key agreement: Diffie-Hellman g y ; RSA, random #s Change Cipher protocol message notifies server that subsequent records protected under new CipherSpec & keys Server changes CipherSpec Hash using new CipherSpec; allows server to verify change in Cipherspec Compute shared key Verify CipherSpec Client Server ClientKeyExchange [ChangeCipherSpec] Finished
    • Notify client that subsequent records protected under new CipherSpec & keys Client changes CipherSpec Hash using new CipherSpec; Client verifies new CipherSpec
      • TLS Record protocol encapsulates application-layer messages
      • Privacy through secret key cryptography
      • Reliability through MAC
      • Fragmentation of application messages into blocks for compression/encryption
      • Decompression/Decryption/Verification/Reassembly
      Client Server Application Data [ChangeCipherSpec] Finished
    • Server requests certificate if client needs to be authenticated Client sends suitable certificate If server finds certificate unacceptable; server can send fatal failure alert message & close connection Client prepares digital signature based on messages sent using its private key Server verifies client has private key Client Server ClientHello ServerHello Certificate* ServerKeyExchange* CertificateRequest ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished Application Data [ChangeCipherSpec] Finished