Chapter 11Security Protocols

Network Security ThreatsSecurity and CryptographyNetwork Security Protocols

Cryptographic Algorithms

Chapter 11Security Protocols

Network Security Threats

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

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

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

Client ServerRequest

Response

replay

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

Eavesdropping

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

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

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

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

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

Passive AttacksEavesdropping on transmissionsTo obtain informationRelease of message contents

Outsider learns content of transmissionTraffic analysis

By monitoring frequency and length of messages, even encrypted, nature of communication may be guessed

Difficult to detectCan be prevented

Active Attacks

MasqueradePretending to be a different entity

ReplayModification of messagesDenial of serviceEasy to detect

Detection may lead to deterrentHard to prevent

CountermeasuresSecure communication

channelsEncryptionCryptographic checksums and hashesAuthenticationDigital Signatures

CountermeasuresSecure borders

FirewallsVirus checkingIntrusion detectionAuthenticationAccess Control

Chapter 11Security Protocols

Security and Cryptography

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

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

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

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

Symmetric Encryption (Simplified)

Ingredients

Plain textEncryption algorithmSecret keyCipher textDecryption algorithm

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)

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

Location of Encryption Devices

Link Encryption

Each communication link equipped at both endsAll traffic secureHigh level of securityRequires lots of encryption devicesMessage must be decrypted at each switch to read address (virtual circuit number)Security vulnerable at switches

Particularly on public switched network

End to End EncryptionEncryption done at ends of systemData in encrypted form crosses network unalteredDestination shares key with source to decryptHost can only encrypt user data

Otherwise switching nodes could not read header or route packet

Traffic pattern not secureUse both link and end to end

Message Authentication

Protection against active attacksFalsification of dataEavesdropping

Message is authentic if it is genuine and comes from the alleged sourceAuthentication allows receiver to verify that message is authentic

Message has not alteredMessage is from authentic sourceMessage timeline

Authentication Using Encryption

Assumes sender and receiver are only entities that know keyMessage includes:

error detection code sequence numbertime stamp

Authentication Without Encryption

Authentication tag generated and appended to each messageMessage not encryptedUseful for:

Messages broadcast to multiple destinationsHave one destination responsible for authentication

One side heavily loadedEncryption adds to workloadCan authenticate random messages

Programs authenticated without encryption can be executed without decoding

Message Authentication Code

Generate authentication code based on shared key and messageCommon key shared between A and BIf only sender and receiver know key and code matches:

Receiver assured message has not alteredReceiver assured message is from alleged senderIf message has sequence number, receiver assured of proper sequence

Message Authentication Using Message Authentication Code

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

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)

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

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

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

One Way Hash Function

Accepts variable size message and produces fixed size tag (message digest)Advantages of authentication without encryption

Encryption is slowEncryption hardware expensiveEncryption hardware optimized to large dataAlgorithms covered by patentsAlgorithms subject to export controls (from USA)

Using One Way Hash

Secure Hash Functions

Hash function must have following properties:Can be applied to any size data blockProduce fixed length outputEasy to computeNot feasible to reverseNot feasible to find two message that give the same hash

SHA-1

Secure Hash Algorithm 1Input message less than 264 bits

Processed in 512 bit blocksOutput 160 bit digest

Message Digest GenerationUsing SHA-1

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

Public Key Encryption

Based on mathematical algorithmsAsymmetric

Use two separate keysIngredients

Plain textEncryption algorithmPublic and private keyCiphertextDecryption algorithm

Public Key Encryption -Encryption

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

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)

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.

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

Public Key Encryption –Authentication

Public Key Encryption -Operation

One key made publicUsed for encryption

Other kept privateUsed for decryption

Infeasible to determine decryption key given encryption key and algorithmEither key can be used for encryption, the other for decryption

Steps

User generates pair of keysUser places one key in public domainTo send a message to user, encrypt using public keyUser decrypts using private key

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

Digital Signature

Sender encrypts message with their private keyReceiver can decrypt using senders public keyThis authenticates sender, who is only person who has the matching keyDoes not give privacy of data

Decrypt key is public

Key ManagementGenerate a single pair of keys, one private and one public.Keep the private key secure and broadcast the public key to all and sundry.When Bob wishes to communicate with Alice, Bob can do the following:

Prepare a messageEncrypt that message using symmetric encryption with a one-time symmetric session key.Encrypt the session key using public-key encryption with Alice’s public key.Attach the encrypted session key to the message and send it to Alice.

How to verify that the “Alice’s” public key is valid?

Public Key Certificate Use

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

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

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

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)

challenge

response

EKB(KAB)

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

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

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

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, …

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

Chapter 11Security Protocols

Network Security Protocols

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

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

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

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

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

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

IPv4 and IPv6 Security

IPSecSecure branch office connectivity over InternetSecure remote access over InternetExtranet and intranet connectivityEnhanced electronic commerce security

IP Security (IPsec).

IPsec defined in RFCs 2401, 2402, 2406, 2408Provides 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

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

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

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

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

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

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

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)

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”

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

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.

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

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

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

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

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

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

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

The TSL Handshaking protocol, the Change Cipher Spec protocol, and the Alert protocol

The TSL Handshaking protocol, the Change Cipher Spec protocol, and the Alert protocol

Negotiate and instantiate the security parameters for the record layersAuthenticate the usersReport error conditions

The TSL Handshaking is used by a client and server to establish a session.

TLS Record Protocol

Use for the encapsulation of higher-level protocolsTLS Record protocol provides

Privacy service through secret key encryptionEncryption 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

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

The TLS handshake processStep 1:

The client and server exchange hello messages to negotiate algorithms, exchange random values, and initiate or resume the session

Step 2:The client and server exchange cryptographic parameters to allow them to agree on a pre-master secret.

Step 3:The client and server provide their record layer with the security parameters.

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

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

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

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

Secure Sockets LayerTransport Layer Security

Security servicesTransport Layer Security defined in RFC 2246SSL general-purpose service

Set of protocols that rely on TCPTwo implementation options

Part of underlying protocol suiteTransparent to applications

Embedded in specific packagesE.g. Netscape and Microsoft Explorer and most Web servers

Minor differences between SSLv3 and TLS

SSL ArchitectureSSL uses TCP to provide reliable end-to-end secure serviceSSL two layers of protocolsRecord Protocol provides basic security services to various higher-layer protocols

In particular, HTTP can operate on top of SSLThree higher-layer protocols

Handshake ProtocolChange Cipher Spec ProtocolAlert ProtocolUsed in management of SSL exchanges (see later)

SSL Protocol Stack

SSL Connection and SessionConnection

Transport that provides suitable type of servicePeer-to-peerTransientEvery connection associated with one session

SessionAssociation between client and serverCreated by Handshake ProtocolDefine set of cryptographic security parametersUsed to avoid negotiation of new security parameters for each connection

Maybe multiple secure connections between partiesMay be multiple simultaneous sessions between parties

Not used in practice

SSL Record ProtocolConfidentiality

Handshake Protocol defines shared secret keyUsed for symmetric encryption

Message IntegrityHandshake Protocol defines shared secret keyUsed to form message authentication code (MAC)

Each upper-layer message fragmented214 bytes (16384 bytes) or less

Compression optionally appliedCompute message authentication codeCompressed message plus MAC encrypted using symmetric encryptionPrepend header

SSL Record Protocol Operation

Record Protocol HeaderContent Type (8 bits)

change_cipher_spec, alert, handshake, and application_dataNo distinction between applications (e.g., HTTP)

Content of application data opaque to SSL

Major Version (8 bits) – SSL v3 is 3Minor Version (8 bits) - SSLv3 value is 0Compressed Length (16 bits)

Maximum 214 + 2048Record Protocol then transmits unit in TCP segmentReceived data are decrypted, verified, decompressed, and reassembled and then delivered

Change Cipher Spec Protocol

Uses Record ProtocolSingle message

Single byte value 1Cause pending state to be copied into current state

Updates cipher suite to be used on this connection

Alert ProtocolConvey SSL-related alerts to peer entityAlert messages compressed and encryptedTwo bytes

First byte warning(1) or fatal(2) If fatal, SSL immediately terminates connectionOther connections on session may continueNo new connections on session

Second byte indicates specific alertE.g. fatal alert is an incorrect MACE.g. nonfatal alert is close_notify message (no more messages)

Handshake Protocol

Most complex part of SSLAuthenticateNegotiate encryption and MAC algorithm and cryptographic keys to protect data sent in an SSL record.Used before any application data sent

Handshake Protocol –Phase 1 Initiate A Logical Connection

VersionHighest SSL version understood by client

Random Client-generated random structure32-bit timestamp and 28 bytes from secure random number generatorUsed during key exchange to prevent replay attacks

Session IDVariable-length Nonzero indicates client wishes to update existing connection or create new connection on sessionZero indicates client wishes to establish new connection on new session

CipherSuiteList of cryptographic algorithms supported by clientEach element defines key exchange algorithm and CipherSpec

Compression MethodCompression methods client supports

Handshake Protocol – Phase 2, 3

Client waits for server_hello messageSame parameters as client_hello

Phase 2 depends on underlying public-keyed encryption schemeFinal message in Phase 2 is server_done

RequiredPhase 3

Upon receipt of server_done, client verifies certificate if required and check server_hello parametersClient sends messages to server, depending on underlying public-key scheme

Handshake Protocol –Phase 4

Completes setting upClient sends change_cipher_specCopies pending CipherSpec into current CipherSpec

Not considered part of Handshake ProtocolSent using Change Cipher Spec Protocol

Client sends finished message under new algorithms, keys, and secretsFinished message verifies key exchange and authentication successfulServer sends own change_cipher_spec messageTransfers pending to current CipherSpecSends its finished messageHandshake complete

Handshake Protocol Action

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

Client Hello Message

Server Hello

SSL Message Exchange

Chapter 11Security Protocols

Cryptographic Algorithms

Algorithms

Block cipherProcess plain text in fixed block sizes producing block of cipher text of equal sizeData encryption standard (DES)Triple DES (TDES)Advanced Encryption Standard

Data Encryption Standard

US standard64 bit plain text blocks56 bit keyBroken in 1998 by Electronic Frontier Foundation

Special purpose machineLess than three daysDES now worthless

Triple DEA

ANSI X9.17 (1985)Incorporated in DEA standard 1999Uses 3 keys and 3 executions of DEA algorithmEffective key length 112 or 168 bitSlowBlock size (64 bit) too small

Advanced Encryption Standard

National Institute of Standards and Technology (NIST) in 1997 issued call for Advanced Encryption Standard (AES)

Security strength equal to or better than 3DESImproved efficiencySymmetric block cipherBlock length 128 bitsKey lengths 128, 192, and 256 bitsEvaluation include security, computational efficiency, memory requirements, hardware and software suitability, and flexibility2001, AES issued as federal information processing standard (FIPS 197)

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

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

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, Ki)

Cipher Block Chaining

Electronic Codebook (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

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

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

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/

AES DescriptionAssume key length 128 bitsInput is single 128-bit block

Depicted as square matrix of bytesBlock copied into State array

Modified at each stageAfter final stage, State copied to output matrix

128-bit key depicted as square matrix of bytesExpanded into array of key schedule wordsEach four bytesTotal key schedule 44 words for 128-bit key

Byte ordering by columnFirst four bytes of 128-bit plaintext input occupy first column of in matrixFirst four bytes of expanded key occupy first column of w matrix

AES Encryption and Decryption

AES Comments (1)Key expanded into array of forty-four 32-bit words, w[i]

Four distinct words (128 bits) serve as round key for each round

Four different stagesOne permutation and three substitution

Substitute bytes uses S-box table to perform byte-by-byte substitution of blockShift rows is permutation that performed row by rowMix columns is substitution that alters each byte in column as function of all of bytes in columnAdd round key is bitwise XOR of current block with portion of expanded key

Simple structureFor both encryption and decryption, cipher begins with Add Round Key stageFollowed by nine rounds,

Each includes all four stagesFollowed by tenth round of three stages

AES Encryption Round

AES Comments (2)Only Add Round Key stage uses key

Begin and ends with Add Round Key stageAny other stage at beginning or end, reversible without key

Adds no securityAdd Round Key stage by itself not formidable

Other three stages scramble bitsBy themselves provide no security because no key

Each stage easily reversibleDecryption uses expanded key in reverse order

Not identical to encryption algorithmEasy to verify that decryption does recover plaintextFinal round of encryption and decryption consists of only three stages

To make the cipher reversible

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}

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

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}

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

RSA Algorithm

RSA Example