chapter 11 security protocols
TRANSCRIPT
![Page 1: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/1.jpg)
Chapter 11Security Protocols
Network Security ThreatsSecurity and CryptographyNetwork Security Protocols
Cryptographic Algorithms
![Page 2: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/2.jpg)
Chapter 11Security Protocols
Network Security Threats
![Page 3: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/3.jpg)
Network SecurityThe combination of low-cost powerful computing and high-performance networks is a two-edged sword:
Many powerful new services and applications are enabled But computer systems and networks become highly susceptible to a wide variety of security threats
Network security involves countermeasures to protect computer systems from intruders
Firewalls, security protocols, security practicesWe will focus on security protocols
![Page 4: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/4.jpg)
Threats, Security Requirements, and Countermeasures
Network Security ThreatsEavesdropping, man-in-the-middle, client and server impostersDenial of Service attacksViruses, worms, and other malicious code
Network Security RequirementsPrivacy, Integrity, Authentication, Non-Repudiation, Availability
CountermeasuresCommunication channel security Border security
![Page 5: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/5.jpg)
Security RequirementsSecurity threats motivate the following
requirements:Privacy: information should be readable only by intended recipientIntegrity: recipient can confirm that a message has not been altered during transmissionAuthentication: it is possible to verify that sender or receiver is who he claims to beNon-repudiation: sender cannot deny having sent a given message.Availability: of information and services
![Page 6: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/6.jpg)
Client ServerRequest
Response
replay
Eavesdropping
Information transmitted over network can be observed and recorded by eavesdroppers (using a packet sniffer) Information can be replayed in attempts to access serverRequirements: privacy, authentication, non-repudiation
![Page 7: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/7.jpg)
Client Imposter
Server
Client Imposter
Imposters attempt to gain unauthorized access to server
Ex. bank account or database of personal recordsFor example, in IP spoofing imposter sends packets with false source IP address
Requirements: privacy, authentication
![Page 8: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/8.jpg)
Attacker Server
Denial of Service Attack
Attacker can flood a server with requests, overloading the server resources
Results in denial of service to legitimate clientsDistributed denial of service attack on a server involves coordinated attack from multiple (usually hijacked) computersRequirement: availability
![Page 9: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/9.jpg)
Client Server Imposter
Server Imposter
An imposter impersonates a legitimate server to gain sensitive information from a client
E.g. bank account number and associated user password
Requirements: privacy, authentication, non-repudiation
![Page 10: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/10.jpg)
Client ServerMan in
the middle
Man-in-the-Middle Attack
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 servergathering sensitive information and possibly hijacking session
Requirements: integrity, authentication
![Page 11: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/11.jpg)
Client Server Imposter
Malicious Code
A client becomes infected with malicious code Opening attachments in email messagesExecuting code from bulletin boards or other sources
Virus: code that, when executed, inserts itself in other programsWorms: code that installs copies of itself in other machines attached to a networkMany variations of malicious codeRequirements: privacy, integrity, availability
![Page 12: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/12.jpg)
CountermeasuresSecure communication
channelsEncryptionCryptographic checksums and hashesAuthenticationDigital Signatures
![Page 13: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/13.jpg)
CountermeasuresSecure borders
FirewallsVirus checkingIntrusion detectionAuthenticationAccess Control
![Page 14: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/14.jpg)
Chapter 11Security Protocols
Security and Cryptography
![Page 15: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/15.jpg)
CryptographyEncryption: transformation of plaintext message into encrypted (and unreadable) message called ciphertextDecryption: recovery of plaintext from ciphertextCipher: algorithm for encryption & decryptionA secret key is required to perform encryption & decryption
![Page 16: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/16.jpg)
Substitution CiphersSubstitution Cipher: Map each letter or
numeral into another letter of 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 aExample:
hvxfirgb securitySubstitution ciphers are easy to break
Take histogram of frequency of occurrence of letters in a ciphertext message Match to known frequencies of letters
![Page 17: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/17.jpg)
Transposition CipherTransposition Cipher: Rearrange order of
letters/numerals in a message using a particular rearrangement:
interchange character k with character k+1Example:
security esucirytTransposition Ciphers are easy to break
Suppose plaintext and ciphertext are knownMatching of letters in plaintext and ciphertext will reveal transposition mapping
![Page 18: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/18.jpg)
EK(.)
Key K Key K
Plaintext P Ciphertext C=EK(P) P
Encryption Decryption
DK(.)
Secret Key Cryptography
Sender encrypts P by applying mapping EK which depends on secret key K: C = EK(P)Receiver decrypts C by applying inverse mapping DK which also depends on K: DK(EK(P)) = P
![Page 19: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/19.jpg)
What makes a good cipher?Algorithm should be easy to implement and deploy on large scaleAlgorithm should be difficult to break:
1. Number of keys should be very largeAttacker cannot try all possible keys
2. 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 DESAdvanced Encryption Standard (AES)
![Page 20: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/20.jpg)
Security using Secret Key Cryptography
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 involvedWe will see that cryptographic checksums provide integrity and require less processing
![Page 21: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/21.jpg)
Sender (John)
Receiver (Jane)Ek(r)
r
Ek(r´)
r´
John to Jane, “let’s talk”
Authentication using Secret Key Cryptography
Send message identifying selfSend response with encrypted r Can now authenticate receiver by issuing a challenge
Reply with challenge that contains random number r, nonce = number onceApply secret key to decrypt message. If decrypted number is r then the transmitter is authenticated
![Page 22: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/22.jpg)
Cryptographic Checksums and Hashes
Transmitter calculates a fixed number of bits (crypto checksum/hash) that depends on secret key K: HK(P)Receiver recalculates hash from received message & compares to received hash
Message
CryptoChecksumCalculator
CrytoChk Message
K
P PHK(P)
![Page 23: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/23.jpg)
What makes a Good Hash?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 2M/m messages that give that hashHow long does it take to find a match?Probability that a random message generates given hash is 2-m since there are 2m hashesMean # tries to find given hash is: 2m
![Page 24: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/24.jpg)
ExampleM = 1000, m = 128Number of possible messages: 21000
Number of possible hashes: 2128
For each hash value there are 21000/2128 = 2872
messages that generate the hashA 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:2128x1 microsecond = 225 years
![Page 25: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/25.jpg)
Some Hashing AlgorithmsMessage Digest 5 (MD5)
Pad message to be multiple of 512 bitsInitialize 128 buffer to given valueModify buffer content according to next 512 bitsRepeat until all blocks done Buffer holds 128 bit hash
Keyed MD5Pad message to be multiple of 512 bitsAttach and append secret key to padded message prior to performing hash functionCould also append/attach other information such as sender ID
Secure Hash Algorithm 1 (SHA-1)Produce a 160-bit hash; more secure than MD5Keyed version available
![Page 26: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/26.jpg)
Hashed Message Authentication Code Method
HMAC improves strength of a hash codePad secret key with zeros to length of 512 bits and X-OR with 64 repetitions of 00110110 Pad message to multiple of 512 bitsCalculate hash of padded key followed by padded message, 128 bits for MD5, 160 bits for SHA-1Pad hash to 512 bitsPad secret key with zeros to 512 bits and X-OR with 64 repetitions of 01011010Calculate hash of padded key and padded hashResult is final hash
![Page 27: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/27.jpg)
EK1(.)
Public key K1 Private key K2
Plaintext P Ciphertext C = EK1(P) P
Encryption Decryption
DK2(.)
Public Key Cryptography
Public key cryptography provides privacyusing two different keys:
Public key K1 available to all for encrypting messages to a certain user: C = EK1(P)Private key K2 for user to decrypt messages: P = DK2(EK1(P))
![Page 28: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/28.jpg)
What makes a good public key algorithm?
EK1 and DK2 should be readily implementableInverse relationship should hold:
P = DK2(EK1(P)) and sometimes P = EK1(DK2(P))
K1 is a relatively small number of bits and K2 is usually a large number of bitsIt is extremely difficult to decrypt EK1(P) without K2
It should not be possible to deduce K2 from K1Example: RSA public key cryptography (discussed later)
![Page 29: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/29.jpg)
Integrity using Public Key Cryptography
Integrity:Any one can send messages using public key, so integrity not assured directlyFor integrity, transmitter:
1. encodes P with its private key K2΄ to obtain P΄ = DK2΄ P)2. encodes P΄ using receiver’s public key: C = EK1(P΄)Receiver:
1. decrypts C, DK2(EK1(P΄)) = P΄2. decrypts P΄ using transmitters public key, EK1΄(DK2΄(P))
= POnly the transmitter could have sent this message.
![Page 30: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/30.jpg)
Sender Receiver
EK1(r)
r
John to Jane, “let’s talk”
Authentication using Public Key Cryptography
Transmitter identifies itselfReceiver sends a nonce encoded using the sender’s public key in a challenge messageTransmitter uses its private key to recover the nonce, and it returns the unencrypted nonceOnly the holder of the private key can find the nonce
![Page 31: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/31.jpg)
Digital Signatures using Public Key Cryptography
Digital signatures provide nonrepudiationUser “signs” a message that cannot be repudiated
Digital signature obtained as follows:Transmitter obtains a hash of the messageTransmitter encrypts the hash using its private key; result is the digital signatureTransmitter sends message and signature
To check the signature:Receiver obtains hash of messageReceiver decrypts signature using sender’s public keyReceiver compares hash computed from message and hash obtained from signatureProcedure also ensures message integrity
![Page 32: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/32.jpg)
Secret Key vs. Public KeyPublic key systems have more capabilities
Secret key: privacy, integrity, authenticationPublic key: all of above + digital signature
Public key algorithms are more complexRequire more processing and hence much slower than secret key
Practice:Use public key method during session setup to establish a session keyUse secret key cryptography during session using the session key
![Page 33: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/33.jpg)
Example: Pretty Good Privacy (PGP)
PGP developed by Phillip Zimmerman to provide secure email
http://www.philzimmermann.com/index.shtmlhttp://www.pgpi.org
Notorious for becoming publicly available for download over Internet in violation of US export restrictionsUses public key cryptography to provide
Privacy, integrity, authentication, digital signatureDe facto standard for email securityAlso provides privacy and integrity for stored files
![Page 34: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/34.jpg)
Key Distribution in Secret Key Systems
Every pair of users requires a separate shared secret key
N(N – 1) keys for N users; Grows quickly with NSimilar to full-mesh connections for N users
Solution: Introduce Key Distribution CentersEach users has shared key with the KDCUser A has shared key KKA with KDCUser B has shared key KKB with KDCKDC provides shared key when A & B need to communicate
![Page 35: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/35.jpg)
KDC
A B
C D
Key Distribution CenterUser A contacts the KDC to request a key for use with user B.
KDC:
Authenticates user A
Selects a key KAB and encrypts it to produce EKA(KAB) and EKB(KAB).
KDC sends both versions of the encrypted key to A.
User A contacts user B and provides a ticket in the form of EKB(KAB)
Users A & B both have KAB
requestEKA(KAB), EKB(KAB)
challengeresponse
EKB(KAB)
![Page 36: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/36.jpg)
Example: KerberosKerberos: authentication service for users to access servers over networkKDC has secret key with every userAt login, user supplies ID and password
KDC authenticates user & generates session keySession 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
![Page 37: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/37.jpg)
Key Distribution in Public Key Systems
In public key only one pair of keys per userKey distribution problem: How to determine whether an advertised public key is not from an imposter?Certification Authority (CA)
Issues digitally signed certificate that providesUser’s name & public keyCertificate serial #, expiration date
Certificates can be stored in publicly accessible directoriesTo communicate with B, a user contacts the CA to obtain the certificate for BUsers are configured to have the CA’s public key, which they use to verify the digital signature
![Page 38: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/38.jpg)
Transmitter A
Receiver B
T = gx
R = gy
K = Rx mod p
= gxy mod p
K = Ty mod p
= gxy mod p
Key Generation: Diffie-HellmanExchange
Generate keys instead of distributing keysDiffie-Hellman exchange to create a shared keyA & B pick p a large prime #, and generator g < p
A picks x and sends T = gx to B; B picks y and sends R = gy
Secret key is K = (gx)y = (gy)x which are calculated by A & BEavesdropper that obtains p, g, T, R cannot obtain x and y because x = logT and y = logR are extremely difficult to solve
![Page 39: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/39.jpg)
Transmitter A
Man in the
middle C
Receiver B
T
R'
T'
R
K1 = R´x
= gxy´
K1 = T y´
= gxy´K2 = R x´ K2 = T´ y
= gx´ y = gx´ y
Man-in-the-Middle Attack
An intruder C can interpose itself between A & BC establishes a shared key K1 with A and a shared key K2with BC can then intercept, decipher, and re-encrypt all communicationsNeed mutual authentication between A & BAlternative: Community agrees on g & p; users publish their T, R, …
![Page 40: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/40.jpg)
Diffie-Hellman Complexity
Diffie-Hellman exchange involves computation of powers of large numbers
Large number of multiplications implies heavy computational burdenSusceptible to denial-of-service attacks
![Page 41: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/41.jpg)
Chapter 11Security Protocols
Network Security Protocols
![Page 42: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/42.jpg)
Direct Connections to Internet
Computers A & B communicate across the InternetExposure to eavesdropping, imposters, DoSCan encrypt some transmitted information
But IP headers need to be visible to routers & hence othersEavesdropper can gather variety of usage information & deduce nature of interactionChoice of which layer to apply security: IP, transport, or application layer
Internet
A B
![Page 43: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/43.jpg)
Gateway-to-Gateway
Computers A and B have gateways interposed between their internal network and InternetGateway can be a firewall
Controls external access to internal networkPacket filtering according to various header fields
IP addresses, port numbers, ICMP types, fields within payload
Secure tunnels can be established between gatewaysAll internal information including headers can be encrypted
Internet
A B
![Page 44: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/44.jpg)
Remote user to Gateway
Mobile host needs access to internal networkGateway must provide user with access while barring intruders from accessing internal networkMay also need to protect identity of mobile userIP-address of mobile user changes
Internet
![Page 45: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/45.jpg)
Firewall OptionsFirewalls can operate at different layers
IP-layer filtering cannot operate on payload contentsCircuit-Level Gateways
Direct client-to-server TCP connections not allowedRelays TCP segments between actual client & actual server
Application-Level Gateways or ProxiesInterposed between actual client and actual serverPerforms authentication and determines what features are available to clientMonitors, filters & relays messages
![Page 46: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/46.jpg)
Protocol Layer OptionsSecurity Services can be provided at different layers of the protocol stackData Link Layer security
Point-to-point security between directly-connected devices, e.g. wireless LAN security
IP-Layer securitySecurity service between IP-layer & Transport layerEnd-to-end security across an internet, e.g. IPsec
Transport Layer security Security service between Transport & Application LayersE.g. Secure Sockets Layer & Transport Layer Security
![Page 47: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/47.jpg)
Network Security ServicesIntegrity Service: information received from network has not been altered during transmissionAuthentication Service: the receiver can authenticate that information came from purported senderPrivacy Service: information is readable only by intended recipientIn applications that require network security, integrity & authentication essential; privacy not always justified
![Page 48: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/48.jpg)
IP Security (IPsec).
IPsec defined in RFCs 2401, 2402, 2406Provides authentication, integrity, confidentiality, and access control at the IP layerProvides 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 PayloadTransport mode or tunnel mode
![Page 49: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/49.jpg)
Security AssociationA Security Association (SA) is a logical simplex connection between two network-layer entitiesTwo SA’s required for bidirectional secure communicationSA is specified by
A unique identifierSecurity services to be usedCryptographic algorithms to be usedHow shared keys will be establishedOther attributes such as lifetime
SA negotiated before security service begins
![Page 50: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/50.jpg)
Integrity & Authentication ServiceIntegrity can be ascertained by sending a cryptographic checksum or hash of messageAuthentication also provided if hash covers:
Shared secret key, sender’s identity & messageFields 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 onceReceiver maintains a window of packets it accepts
Receiver recalculates hash and compares to hash in received packet
![Page 51: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/51.jpg)
Authentication Header
Inserted between regular header & payloadPacket header contains field indicating presence of authentication headerAuthentication header includes:
Security association IDSequence numberCryptographic hash
Packet header
Authentication header
Packet payload
Authenticated except for changeable fields
![Page 52: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/52.jpg)
Tunneling
A tunnel can be created by encapsulating a packet within another packet
Inner packet header carries original source addressEntire contents of inner packet covered by hashOuter 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
![Page 53: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/53.jpg)
Privacy ServicePrivacy requires encryption of messageEncryption header identifies security association & sequence numberEncryption can cover payload + padding:
Packet + pad payload
Packet header
Encryption header
Encrypted
Encrypted
Packet + pad payload
New header
Authentication header
Encryption header
Authentication header can be used to detect alteration of any non-changeable fields & protect against replay attacks
![Page 54: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/54.jpg)
In tunnel mode
New header
Encryption header
Original header
Encrypted
Packet payload
Privacy Service in Tunnel Mode
In tunnel mode, entire original packet is encrypted and unreadable to eavesdroppers
All original packet header fields are unreadableOnly 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
![Page 55: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/55.jpg)
Setting up a Security Association
To setup security association, computers must:Agree on security services that will be providedAgree on cryptographic algorithmsAuthenticate each otherEstablish a shared secret key
Last two steps are difficult; possible approaches:Manual set up of shared key between pair of usersUse Key Distribution CenterContact a Certificate Authority
Internet Key Exchange (RFC 2409) for IPsecAssumes parties have a name/identity for other party as well as a pre-established shared secret (secret key or private key)
![Page 56: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/56.jpg)
Internet Key Exchange (IKE)
Initiator Host Responder Host
HDR, SACookie Request
HDR, SACookie Response
Contains Ci
Proposes Security
Association options
Contains Ci & Cr
Selects SA options
Select random # Ci:initiator’s cookie
Check to see if Ci already in use; If not, generate Cr, responder’s cookie;Associate Cr with initiator’s address
Check Ci & address against list; Associate (Ci, Cr) with SA; record SA as “unauthenticated”
![Page 57: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/57.jpg)
Internet Key Exchange
Initiator Host Responder Host
HDR, KE, NiKey Request
HDR, KE, NrKey Response
T=gx mod p Nonce NiInitiate Diffie-Hellman exchange
Check responder cookie, discard if not valid; If valid identify SA with (Ci, Cr) & record as “unauthenticated”R=gy mod p Nonce Nr
Calculate K=(gy)x mod p Calculate K=(gx)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
![Page 58: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/58.jpg)
Internet Key ExchangeInitiator Host Responder Host
HDR, {IDi, Sigi}Signature Request
HDR, {IDr, Sigr}Signature Request
Prepare signature based on SKEYID, T, R, Ci, Cr, the SA field, initiator ID
SKEYID, T, R, Ci,
Cr, SA, IDiHash 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, Ci, Cr, the SA field, responder IDr
SKEYID, T, R, Ci, Cr, SA, IDr
Hash of info in HDR
Authenticate initiator. If successful, SA declared authenticated.
![Page 59: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/59.jpg)
SKEYID & CookiesSKEYID for authentication, based on:
Shared key that results from Diffie-HellmanPre-shared key
Pre-configured secret keyPrivate part of a public key pair
Nonces and/or cookiesCookies
To counteract denial-of-service attacksA user that wants to make a connection requests must first request a cookieConnections 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
![Page 60: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/60.jpg)
IPv4 Header AH Upper Layer (e.g., TCP or UDP)
IPsec Authentication Header
Authentication header (AH) placed after headers that are examined at every hopPresence of AH indicated by protocol value = 51 in IPv4 headerAuthentication performed over all fields including IP header, except fields that change at every hop
![Page 61: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/61.jpg)
Next Header Length Reserved
Security Parameters Index
0 8 16 31
Sequence Number
Authentication Data
Authentication Header Format
Format used in IPv4 and IPv6Next Header indicates next payload after AHLength of Authentication data in multiples of 32 bitsSPI = unique ID for security associationSequence number for anti-replay protectionAuthentication data contains result of authentication computation
![Page 62: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/62.jpg)
Encapsulating Security Payload
ESP provides:Integrity & authentication servicePrivacy service by encryption of payload
Authentication data at end is optionalPlacement at ends makes implementation simpler
IPv4 Header ESP Upper Layer (e.g., TCP or UDP) HMAC
![Page 63: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/63.jpg)
Security Parameters Index
0 16 24 31
Sequence Number
Payload Data
Padding
Pad Length Next Header
Authentication Data
ESP Header Format
Authenticated coverage from SPI until next header fieldEncrypted coverage from payload data field until next headerProtocol type = 50Next header field is encrypted, so transport type not visible
![Page 64: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/64.jpg)
Secure Sockets Layer (SSL)
SSL developed by Netscape CommunicationsOperates on top of TCPProvides secure connections
HTTP, FTP, telnet, …Electronic ordering & payment; e-mailSSL 3.0 submitted to IETF for standardization
TLS standardized by IETF (RFC 2246)Slight differences with SSL 3.0
![Page 65: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/65.jpg)
Transport Layer Security (TLS)
TLS protocols operate at two layersTLS Record Protocol operates on top of TCPProtocols on top of TLS Record Protocol
TLS Handshake ProtocolTLS Change Cipher Specification ProtocolTLS Alert Protocol
TCP
TLS Record Protocol
HandshakeProtocol
Change cipher spec Protocol
AlertProtocol
HTTPProtocol
IP
![Page 66: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/66.jpg)
TLS Record Protocol
TLS Record protocol providesPrivacy service through secret key encryption
Encryption algorithm is negotiated at session setupSecret keys generated per connection using another protocol such as Handshake protocol
Reliability service through keyed message authentication code
Hash algorithm negotiated at session setupOperates without hash only during session negotiation
![Page 67: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/67.jpg)
TLS Handshake ProtocolTLS Handshake protocol used by client & server
Negotiate protocol version, encryption algorithm, key generation methodCan authenticate each other using public key algorithmClient & server establish a shared secretMultiple secure connections can be set up after session setup
Session specified by following parametersSession Identifier: byte sequence selected by serverPeer Certificate: certificate of peerCompression method: used prior to encryptionCipher spec: encryption & message authentication codeMaster Secret: 48-byte secret shared by client & serverIs resumable?: flag indicating if new connections can be initiated
![Page 68: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/68.jpg)
Client Server
ClientHello
TLS Handshake Process
ServerHello
Certificate*
ServerKeyExchange*
ServerHelloDone
Request connectionIncludes:Version #; Time & date;Session ID (if resuming);Ciphersuite (combinationsof key exchange, encryption, MAC, compression)
Send ServerHello if there is acceptable Ciphersuitecombination; else, send failure alert & close connection.* Optional messages
Server Certificate
Server part of handshake done
Server part of key exchange:Diffie-Hellman, gx;; 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
![Page 69: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/69.jpg)
Client Server
ClientKeyExchange
[ChangeCipherSpec]
Finished
Client’s part of key agreement:Diffie-Hellman gy; 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
Handshake Protocol continued
Compute shared key
Verify CipherSpec
![Page 70: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/70.jpg)
Client Server
Application Data
Handshake Protocol completion
[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
![Page 71: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/71.jpg)
Client ServerClientHello
TLS Handshake with Client Authentication
ServerHelloCertificate*
ServerKeyExchange*
CertificateRequest
ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]Finished
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
![Page 72: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/72.jpg)
TLS 1.0 & SSL 3.0 Compatibility
TLS 1.0 allows backwards compatibility with SSL 3.0When TLS client sends ClientHello to SSL server:
Client sends TLS message with {3, 1} in version field to indicate it also supports SSL 3.0Server that supports SSL 3.0 will respond with SSL 3.0 ServerHello message
A TLS server that handles SSL 3.0 clientsAccepts SSL 3.0 ClientHello messages & responds with SSL 3.0 Server Hello message if client message contains {3,0} in version field indicating that it only supports SSL 3.0
![Page 73: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/73.jpg)
Client Hello Message
![Page 74: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/74.jpg)
ServerHello
![Page 75: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/75.jpg)
SSL Message Exchange
![Page 76: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/76.jpg)
Chapter 11Security Protocols
Cryptographic Algorithms
![Page 77: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/77.jpg)
Data Encryption Standard DES adopted by U.S. National Bureau of Standards in 1977
Most widely-used secret key systemEfficient hardware implementation
Encryption: Electronic Codebook (ECB) ModeMessage broken into 64-bit blocksEach 64-bit plaintext block encrypted separtely into 64-bit cyphertextOriginal version of DES uses a 56-bit key
Decryption: Encryption operations performed in reverse order
![Page 78: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/78.jpg)
Initial permutation
Iteration 1
Iteration 2
Iteration 16
32-bit swap
Inverse permutation
64-bit plaintext
64-bit ciphertext
48-bit Key 1
Generate 16 per-iteration keys
56-bit key
48-bit Key 2
48-bit Key 16
DES Algorithm
Initial permutation is independent of keyFinal permutation is inverse of initial permutationPenultimate step swaps 32-bits on left with 32-bits on the rightIntermediate 16 iterations apply a different key that is derived from the original 56-bit key
![Page 79: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/79.jpg)
DES Iteration64-bit block divided into Li –1 and Ri –1 halvesLeft output Li = Ri –1 Right output Ri = Li –1 XOR f(Ri –1, Ki)
bitwise XORf(.,.) as follows:
Ri –1 expanded to 48 bits using fixed re-ordering & duplication patternXORed with KiEach resulting group of 6-bits is mapped into 4-bit output according to substitution mapping
Li-1 Ri-1
L1 Ri
Li-1 f(Ri-1, K)
![Page 80: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/80.jpg)
Cipher Block Chaining
ECB mode encrypts 64-bit blocks independently
Attacker can use knowledge about pattern in message to attack encrypted sequence of blocks
Cipher Block Chaining (CBC) introduces dependency between consecutive blocks
Current plaintext block is XORed with preceding ciphertext blockFirst plaintext block XORed with an initialization vector that is transmitted to receiver in ciphertext
![Page 81: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/81.jpg)
Decrypt
P1
C1
IV
Decrypt
P2
C2
Decrypt
P3
C3(b) Decryption
…
Encrypt
P1
C1
Encrypt
P2
C2
Encrypt
P3
C3
IV
(a) Encryption
…
Cipher Block Chaining
![Page 82: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/82.jpg)
DES SecurityDES vulnerable to brute-force attack
56-bit key is too shortHas been broken in less than one day using a specially-designed computer
Triple-DES (3DES)Provides better securityUses two 56-bit keys
C = EK1(DK2(EK1(P)))P = DK1(EK2(DK1(P)))
Instead of “triple encryption”, use encryption-decryption-encryption
If K1 = K2, reduces to original DES
![Page 83: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/83.jpg)
Advanced Encryption Standard
AES selected in 2001 by U.S. NIST (National Institute of Standards & Technology)
Developed by Rijmen and DaemenSecret key systemEncryption of 128-bit blocks with keys of size 128, 192, or 256 bitsSoftware & efficient hardware implementation3.4x1038 keys vs. 7.2x1016 keys for 56-bit DES
AES is gradually replacing DES/3DESSee:
http://csrc.nist.gov/CryptoToolkit/aes/
![Page 84: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/84.jpg)
RSA Public Key AlgorithmNamed after Rivest, Shamir, and AdlemanModular arithmetic & factorization of large numbers
Let n = pq, where p & q are two large numbersn typically several hundred bits long, i.e. 512 bitsPlaintext 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 ede = 1 modulo (p – 1)(q – 1)Private key is {d,n}
![Page 85: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/85.jpg)
Encryption & DecryptionFact: For P<n and n, p, q, d as above:
Pde mod n = P mod nEncryption:
C = Pe mod n
Result is number less than n and is represented by same number of bits as key
Decryption:Cd mod n = Ped 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
![Page 86: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/86.jpg)
RSA Example
Let p = 5, q = 11n = pq = 55 and (p – 1)(q – 1) = 40
Let e = 7, which is relatively prime to 407d mod 40 = 1, gives d = 23
Public key is {7, 55}Private key is {23, 55}
![Page 87: Chapter 11 Security Protocols](https://reader030.vdocument.in/reader030/viewer/2022012813/61c45a10a108d8433e621c17/html5/thumbnails/87.jpg)
RSA Example continuedEncrypt “RSA”: R=18, S=19, A=1C1 = 187 mod 55 = 184+2+1 mod 55
= (18 mod 55) (182 mod 55) (184 mod 55) mod 55= (18) (324 mod 55) (184 mod 55) mod 55= (18) (49) (492 mod 55) mod 55 = (18)(49)(36) mod 55= 31752 mod 55 = 17
C2 = 197 mod 55 = 24C3 = 17 mod 55 = 1Decrypt 1723 mod 55 = 1716+4+2+1 mod 55 =182423 mod 55 = 19123 mod 55 = 1