Chapter 11 Security Protocols. Network Security Threats Security and Cryptography Network Security Protocols Cryptographic Algorithms

Chapter 11

Security Protocols

Network Security Threats

Security and Cryptography

Network Security Protocols

Chapter 11

Security Protocols

Network Security

z The combination of low-cost powerful computing

and high-performance networks is a two-edged sword:

z Many powerful new services and applications are enabled z But computer systems and networks become highly

susceptible to a wide variety of security threats

z Network security involves countermeasures to

protect computer systems from intruders

z Firewalls, security protocols, security practices z We will focus on security protocols

Threats, Security Requirements,

and Countermeasures

z Network Security Threats

z Eavesdropping, man-in-the-middle, client and server

imposters

z Denial of Service attacks

z Viruses, worms, and other malicious code

z Network Security Requirements

z Privacy, Integrity, Authentication, Non-Repudiation,

Availability

z Countermeasures

z Communication channel security z Border security

Security Requirements

Security threats motivate the following

requirements:

z

Privacy: information should be readable only by

intended recipient

z

Integrity: recipient can confirm that a message

has not been altered during transmission

z

Authentication: it is possible to verify that sender

or receiver is who he claims to be

z

Non-repudiation: sender cannot deny having

sent a given message.

Client Server Request Response re pla y

Eavesdropping

z Information transmitted over network can be observed

and recorded by eavesdroppers (using a packet sniffer)

z Information can be replayed in attempts to access

server

z Requirements: privacy, authentication,

Client Imposter

Server

Client Imposter

z

Imposters attempt to gain unauthorized

access to server

z Ex. bank account or database of personal records z For example, in IP spoofing imposter sends

packets with false source IP address

Attacker Server

Denial of Service Attack

z Attacker can flood a server with requests,

overloading the server resources

z Results in denial of service to legitimate clients

z Distributed denial of service attack on a server

involves coordinated attack from multiple (usually hijacked) computers

Client Server Imposter

Server Imposter

z

An imposter impersonates a legitimate server

to gain sensitive information from a client

z E.g. bank account number and associated user password

z

Requirements: privacy, authentication,

Client Man in _the Server middle

Man-in-the-Middle Attack

z An imposter manages to place itself as man in the

middle

z convincing the server that it is legitimate client

z convincing legitimate client that it is legitimate server z gathering sensitive information and possibly hijacking

session

Client Server Imposter

Malicious Code

z A client becomes infected with malicious code

z Opening attachments in email messages

z Executing code from bulletin boards or other sources

z Virus: code that, when executed, inserts itself in

other programs

z Worms: code that installs copies of itself in other

machines attached to a network

z Many variations of malicious code

Countermeasures

Secure communication channels

z Encryption

z Cryptographic

checksums and hashes

z Authentication

Countermeasures

Chapter 11

Security Protocols

Cryptography

z Encryption: transformation

of plaintext message into encrypted (and unreadable) message called ciphertext

z Decryption: recovery of

plaintext from ciphertext

z Cipher: algorithm for

encryption & decryption

z A secret key is required to

perform encryption & decryption

Substitution Ciphers

Substitution 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 a

z

Example:

z hvxfirgbÆ security

z

Substitution ciphers are easy to break

z Take histogram of frequency of occurrence of letters in a ciphertext message

Transposition Cipher

Transposition Cipher: Rearrange order of

letters/numerals in a message using a

particular rearrangement:

z

interchange character k with character k+1

z

Example:

z securityÆ esuciryt

z

Transposition Ciphers are easy to break

z Suppose plaintext and ciphertext are known

z Matching of letters in plaintext and ciphertext will reveal transposition mapping

E_K(.)

Key K Key K

Plaintext P Ciphertext C=EK(P) P

Encryption _Decryption

D_K(.)

Secret Key Cryptography

z Sender encrypts P by applying mapping E_K which

depends on secret key K: C = E_K(P)

z Receiver decrypts C by applying inverse mapping

What makes a good cipher?

z Algorithm should be easy to implement and deploy

on large scale

z Algorithm should be difficult to break: 1. Number of keys should be very large

z Attacker cannot try all possible keys

2. The secret key should be very hard to derive from

intercepted messages

z Even if a large number of plaintext & corresponding

cyphertexts are known to the attacker

z Examples of secret key methods discussed later:

z Data Encryption Standard (DES) and Triple DES z Advanced Encryption Standard (AES)

Security using Secret Key

Cryptography

z

Privacy: secret key renders messages

confidential

z

Integrity: alteration of the cyphertext will be

detected, because the decrypted message

will be gibberish

z When privacy is not required, encryption of the entire message is overkill because much

processing involved

z 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”

Authentication using Secret Key

Cryptography

z Send message identifying self z Send response with

encrypted r

z Can now authenticate receiver

by issuing a challenge

z Reply with challenge that

contains random number r,

nonce = number once

z Apply secret key to decrypt

message. If decrypted number is r then the transmitter is

Cryptographic Checksums and

Hashes

z

Transmitter calculates a fixed number of bits

(crypto checksum/hash) that depends on

secret key

K: H

(P)

z

Receiver recalculates hash from received

message & compares to received hash

Message Crypto Checksum Calculator CrytoChk Message K P P H_K(P)

What makes a Good Hash?

z To be secure, it must be very difficult to find a

message that generates a given hash

z If not difficult, an attacker could produce a message and

corresponding hash that would be accepted as valid

z Suppose message is M bits long and hash is m bits

long, and m<<M

z For each given hash value there are 2M/m messages that

give that hash

z How long does it take to find a match?

z Probability that a random message generates given hash

is 2-msince there are 2m hashes

Example

z M = 1000, m = 128

z Number of possible messages: 21000 z Number of possible hashes: 2128

z For each hash value there are 21000/2128 = 2872

messages that generate the hash

z A randomly selected message produces a desired

hash value with probability 2-128

z If each attempt requires 1 microsecond, time to find

matching message to a hash is:

Some Hashing Algorithms

z Message Digest 5 (MD5)

z Pad message to be multiple of 512 bits z Initialize 128 buffer to given value

z Modify buffer content according to next 512 bits z Repeat until all blocks done

z _{Buffer holds 128 bit hash}

z Keyed MD5

z Pad message to be multiple of 512 bits

z Attach and append secret key to padded message prior to

performing hash function

z Could also append/attach other information such as sender ID

z Secure Hash Algorithm 1 (SHA-1)

z _{Produce a 160-bit hash; more secure than MD5} z Keyed version available

Hashed Message Authentication

Code Method

z

HMAC improves strength of a hash code

z Pad secret key with zeros to length of 512 bits and X-OR with 64 repetitions of 00110110

z Pad message to multiple of 512 bits

z Calculate hash of padded key followed by padded message, 128 bits for MD5, 160 bits for SHA-1

z Pad hash to 512 bits

z Pad secret key with zeros to 512 bits and X-OR with 64 repetitions of 01011010

z Calculate hash of padded key and padded hash z Result is final hash

E_K1(.)

Public key K1 Private key K2 Plaintext P Ciphertext C = E_K1(P) P

Encryption Decryption

D_K2(.)

Public Key Cryptography

z

Public key cryptography provides privacy

using two different keys:

z Public key K1 available to all for encrypting messages to a certain user: C = E_K1(P)

z Private key K2 for user to decrypt messages: P = D_K2(E_K1(P))

What makes a good public key

algorithm?

z E_K1 and D_K2 should be readily implementable z Inverse relationship should hold:

z P = D_K2(E_K1(P)) and sometimes P = E_K1(D_K2(P))

z K1 is a relatively small number of bits and K2 is

usually a large number of bits

z It is extremely difficult to decrypt E_K1(P) without K2 z It should not be possible to deduce K2 from K1

z Example: RSA public key cryptography (discussed

Integrity using Public Key

Cryptography

z

Integrity:

z Any one can send messages using public key, so integrity not assured directly

z For integrity, transmitter:

1. encodes P with its private key K2΄ to obtain P΄ = D_K2΄ P) 2. encodes P΄ using receiver’s public key: C = E_K1(P΄)

z Receiver:

1. decrypts C, D_K2(E_K1(P΄)) = P΄

2. decrypts P΄ using transmitters public key, E_K1΄(D_K2΄(P))

= P

Sender Receiver

E_K1(r) r

John to Jane, “let’s talk”

Authentication using Public Key

Cryptography

z Transmitter identifies itself

z Receiver sends a nonce encoded using the sender’s

public key in a challenge message

z Transmitter uses its private key to recover the

nonce, and it returns the unencrypted nonce

Digital Signatures using Public

Key Cryptography

z Digital signatures provide nonrepudiation

z User “signs” a message that cannot be repudiated

z Digital signature obtained as follows:

z Transmitter obtains a hash of the message

z Transmitter encrypts the hash using its private key; result

is the digital signature

z Transmitter sends message and signature

z To check the signature:

z Receiver obtains hash of message

z Receiver decrypts signature using sender’s public key z Receiver compares hash computed from message and

hash obtained from signature

Secret Key vs. Public Key

z Public key systems have more capabilities

z Secret key: privacy, integrity, authentication z Public key: all of above + digital signature

z Public key algorithms are more complex

z Require more processing and hence much slower than

secret key

z Practice:

z Use public key method during session setup to establish a

session key

z Use secret key cryptography during session using the

Example: Pretty Good Privacy

(PGP)

z PGP developed by Phillip Zimmerman to provide

secure email

z http://www.philzimmermann.com/index.shtml z http://www.pgpi.org

z Notorious for becoming publicly available for

download over Internet in violation of US export restrictions

z Uses public key cryptography to provide

z Privacy, integrity, authentication, digital signature

z De facto standard for email security

Key Distribution in Secret Key

Systems

z

Every pair of users requires a separate

shared secret key

z N(N – 1) keys for N users; Grows quickly with N z Similar to full-mesh connections for N users

z

Solution: Introduce Key Distribution Centers

z Each users has shared key with the KDC z User A has shared key K_KA with KDC

z User B has shared key K_KB with KDC

z KDC provides shared key when A & B need to communicate

KDC

A B

C D

Key Distribution Center

z User A contacts the KDC to

request a key for use with user B. z KDC:

z Authenticates user A

z Selects a key K_AB and encrypts it to produce E_KA(K_AB) and E_KB(K_AB).

z KDC sends both versions of the encrypted key to A.

z User A contacts user B and provides a ticket in the form of E_KB(K_AB)

z Users A & B both have KAB

request

E_KA(K_AB), EKB(KAB) challenge

response

Example: Kerberos

z Kerberos: authentication service for users

to access servers over network

z KDC has secret key with every user

z _{At login, user supplies ID and password}

z KDC authenticates user & generates

session key

z Session key & ticket-granting ticket (TGT)

is sent to user encrypted using shared secret key

z _{To access a particular server, user sends}

request to KDC with server name and TGT

z KDC decrypts TGT to recover session key

& then returns ticket to client for desired server

Key Distribution in Public Key

Systems

z In public key only one pair of keys per user

z Key distribution problem: How to determine whether

an advertised public key is not from an imposter?

z Certification Authority (CA)

z Issues digitally signed certificate that provides

z User’s name & public key

z Certificate serial #, expiration date

z Certificates can be stored in publicly accessible directories z To communicate with B, a user contacts the CA to obtain

the certificate for B

z Users are configured to have the CA’s public key, which

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

Exchange

z Generate keys instead of distributing keys

z Diffie-Hellman exchange to create a shared key z A & B pick p a large prime #, and generator g < p

z A picks x and sends T = gx to B; B picks y and sends R = gy z _{Secret key is} K = (gx)y= (gy)x _{which are calculated by A & B}

z Eavesdropper that obtains p, g, T, R cannot obtain x and y

Transmitter A Man in the middle C Receiver B T R' T' R K₁ = R´x = gxy´ K₁ = Ty´ = gxy´ K₂ = R x´ K2 = T´ y = gx´y = gx´y

Man-in-the-Middle Attack

z An intruder C can interpose itself between A & B

z C establishes a shared key K₁ with A and a shared key K₂

with B

z C can then intercept, decipher, and re-encrypt all

communications

z Need mutual authentication between A & B

z Alternative: Community agrees on g & p; users publish their

Diffie-Hellman Complexity

z

Diffie-Hellman exchange involves

computation of powers of large numbers

z Large number of multiplications implies heavy computational burden

Chapter 11

Security Protocols

Direct Connections to Internet

z Computers A & B communicate across the Internet z Exposure to eavesdropping, imposters, DoS

z Can encrypt some transmitted information

z But IP headers need to be visible to routers & hence others

z Eavesdropper can gather variety of usage information & deduce

nature of interaction

z Choice of which layer to apply security: IP, transport, or

application layer

Internet

Gateway-to-Gateway

z Computers A and B have gateways interposed between their

internal network and Internet

z Gateway can be a firewall

z _{Controls external access to internal network}

z _{Packet filtering according to various header fields}

z IP addresses, port numbers, ICMP types, fields within payload

z Secure tunnels can be established between gateways

z All internal information including headers can be encrypted

Internet

Remote user to Gateway

z Mobile host needs access to internal network z Gateway must provide user with access while

barring intruders from accessing internal network

z May also need to protect identity of mobile user z IP-address of mobile user changes

Firewall Options

z Firewalls can operate at different layers

z IP-layer filtering cannot operate on payload contents

z Circuit-Level Gateways

z Direct client-to-server TCP connections not allowed z Relays TCP segments between actual client & actual

server

z Application-Level Gateways or Proxies

z Interposed between actual client and actual server

z Performs authentication and determines what features are

available to client

Protocol Layer Options

z Security Services can be provided at different layers of

the protocol stack

z Data Link Layer security

z Point-to-point security between directly-connected devices,

e.g. wireless LAN security

z IP-Layer security

z Security service between IP-layer & Transport layer z End-to-end security across an internet, e.g. IPsec

z Transport Layer security

z Security service between Transport & Application Layers z E.g. Secure Sockets Layer & Transport Layer Security

Network Security Services

z

Integrity Service: information received from

network has not been altered during

transmission

z

Authentication Service: the receiver can

authenticate that information came from

purported sender

z

Privacy Service: information is readable only by

intended recipient

z

In applications that require network security,

integrity & authentication essential; privacy not

always justified

IP Security (IPsec)

.

z IPsec defined in RFCs 2401, 2402, 2406

z Provides authentication, integrity, confidentiality, and

access control at the IP layer

z Provides a key management protocol to provide

automatic key distribution techniques.

z Security service can be provided between a pair of

communication nodes, where the node can be a host or a gateway (router or firewall).

z Two protocols & two modes to provide traffic security:

z Authentication Header and Encapsulating Security Payload z Transport mode or tunnel mode

Security Association

z A Security Association (SA) is a logical simplex

connection between two network-layer entities

z Two SA’s required for bidirectional secure

communication

z SA is specified by

z A unique identifier

z Security services to be used

z Cryptographic algorithms to be used z How shared keys will be established z Other attributes such as lifetime

Integrity & Authentication Service

z Integrity can be ascertained by sending a

cryptographic checksum or hash of message

z Authentication also provided if hash covers:

z Shared secret key, sender’s identity & message

z Fields that are changed while packet traverses Internet are

set to zero in calculation of hash

z To protect against replay attacks, message should

carry a sequence number that is covered by the hash

z Receiver accepts a packet only once

z Receiver maintains a window of packets it accepts

z Receiver recalculates hash and compares to hash in

Authentication Header

z

Inserted between regular header & payload

z

Packet header contains field indicating

presence of authentication header

z

Authentication header includes:

z Security association ID z Sequence number z Cryptographic hash Packet header Authentication header Packet payload

Tunneling

z A tunnel can be created by encapsulating a packet

within another packet

z Inner packet header carries original source address z Entire contents of inner packet covered by hash

z 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 Service

z Privacy requires encryption of message

z Encryption header identifies security association &

sequence number

z Encryption can cover payload + padding:

Packet + pad payload Packet header Encryption header Encrypted Encrypted Packet + pad payload New header Authentication header Encryption header

z Authentication header can be used to detect alteration of

In tunnel mode New header Encryption header Original header Encrypted Packet payload

Privacy Service in Tunnel Mode

z In tunnel mode, entire original packet is encrypted

and unreadable to eavesdroppers

z All original packet header fields are unreadable z Only gateway packet header is visible

z It is also possible to use tunnel mode between

trusted routers while traversing untrusted segments of the Internet

Setting up a Security Association

z To setup security association, computers must:

z Agree on security services that will be provided z Agree on cryptographic algorithms

z Authenticate each other

z Establish a shared secret key

z Last two steps are difficult; possible approaches:

z Manual set up of shared key between pair of users z Use Key Distribution Center

z Contact a Certificate Authority

z Internet Key Exchange (RFC 2409) for IPsec

z Assumes 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, SA Cookie Request HDR, SA Cookie Response 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”

Internet Key Exchange

Initiator Host Responder Host

HDR, KE, N_i Key Request HDR, KE, N_r Key Response T=gx _{mod p} Nonce Ni Initiate Diffie-Hellman exchange

Check responder cookie, discard if not valid; If valid identify SA with (C_i, C_r) & record as “unauthenticated” R=gy _{mod p} Nonce N_r

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 Exchange

Initiator Host Responder Host

HDR, {ID_i, Sig_i} Signature Request HDR, {ID_r, Sig_r} Signature Request 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.

SKEYID & Cookies

z SKEYID for authentication, based on:

z Shared key that results from Diffie-Hellman z Pre-shared key

z Pre-configured secret key

z Private part of a public key pair

z Nonces and/or cookies

z Cookies

z To counteract denial-of-service attacks

z A user that wants to make a connection requests must first

request a cookie

z 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

IPv4 Header AH Upper Layer (e.g., TCP or UDP)

IPsec Authentication Header

z Authentication header (AH) placed after headers

that are examined at every hop

z Presence of AH indicated by protocol value = 51 in

IPv4 header

z Authentication performed over all fields including IP

Next Header Length Reserved Security Parameters Index

0 8 16 31

Sequence Number Authentication Data

Authentication Header Format

z Format used in IPv4 and IPv6

z Next Header indicates next payload after AH

z Length of Authentication data in multiples of 32 bits z SPI = unique ID for security association

z Sequence number for anti-replay protection

z Authentication data contains result of authentication

Encapsulating Security Payload

z

ESP provides:

z Integrity & authentication service

z Privacy service by encryption of payload

z

Authentication data at end is optional

z Placement at ends makes implementation simpler

Security Parameters Index

0 16 24 31 Sequence Number

Payload Data Padding

Pad Length Next Header Authentication Data

ESP Header Format

z Authenticated coverage from SPI until next header field

z Encrypted coverage from payload data field until next header z Protocol type = 50

Secure Sockets Layer (SSL)

z

SSL developed by Netscape Communications

z Operates on top of TCP

z Provides secure connections

z HTTP, FTP, telnet, …

z Electronic ordering & payment; e-mail

z SSL 3.0 submitted to IETF for standardization

z

TLS standardized by IETF (RFC 2246)

Transport Layer Security (TLS)

z TLS protocols operate at two layers

z TLS Record Protocol operates on top of TCP z Protocols on top of TLS Record Protocol

z TLS Handshake Protocol

z TLS Change Cipher Specification Protocol z TLS Alert Protocol TCP TLS Record Protocol Handshake Protocol Change cipher spec Protocol Alert Protocol HTTP Protocol IP

TLS Record Protocol

z

TLS Record protocol provides

z Privacy service through secret key encryption

z Encryption algorithm is negotiated at session setup z Secret keys generated per connection using another

protocol such as Handshake protocol

z Reliability service through keyed message authentication code

z Hash algorithm negotiated at session setup

TLS Handshake Protocol

z TLS Handshake protocol used by client & server

z Negotiate protocol version, encryption algorithm, key

generation method

z Can authenticate each other using public key algorithm z Client & server establish a shared secret

z Multiple secure connections can be set up after session

setup

z Session specified by following parameters

z Session Identifier: byte sequence selected by server z Peer Certificate: certificate of peer

z Compression method: used prior to encryption

z Cipher spec: encryption & message authentication code z Master Secret: 48-byte secret shared by client & server z Is resumable?: flag indicating if new connections can be

Client Server ClientHello

TLS Handshake Process

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

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 Server

ClientHello

TLS Handshake with Client

Authentication

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

TLS 1.0 & SSL 3.0 Compatibility

z TLS 1.0 allows backwards compatibility with SSL 3.0 z When TLS client sends ClientHello to SSL server:

z Client sends TLS message with {3, 1} in version field to

indicate it also supports SSL 3.0

z Server that supports SSL 3.0 will respond with SSL 3.0

ServerHello message

z A TLS server that handles SSL 3.0 clients

z Accepts 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

Chapter 11

Security Protocols

Data Encryption Standard

z DES adopted by U.S. National Bureau of Standards

in 1977

z Most widely-used secret key system z Efficient hardware implementation

z Encryption: Electronic Codebook (ECB) Mode

z Message broken into 64-bit blocks

z Each 64-bit plaintext block encrypted separtely into 64-bit

cyphertext

z Original version of DES uses a 56-bit key

z Decryption: Encryption operations performed in

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

z Penultimate step swaps

32-bits on left with 32-bits on the right

z Intermediate 16 iterations

apply a different key that is derived from the original 56-bit key

DES Iteration

z 64-bit block divided into L_{i –1}

and R_{i –1} halves z Left output L_i = R_{i –1} z Right output R_i = L_{i –1} XOR f(R_{i –1}, K_i) z bitwise XOR z f(.,.) as follows: z R_{i –1} expanded to 48 bits

using fixed re-ordering & duplication pattern

z _{XORed with} K_i

z _{Each resulting group of}

6-bits is mapped into 4-bit output according to

substitution mapping

L_i-1 R_i-1

L₁ R_i

Cipher Block Chaining

z

ECB mode encrypts 64-bit blocks

independently

z Attacker can use knowledge about pattern in

message to attack encrypted sequence of blocks

z

Cipher Block Chaining (CBC) introduces

dependency between consecutive blocks

z Current plaintext block is XORed with preceding ciphertext block

z First 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 …

DES Security

z DES vulnerable to brute-force attack

z 56-bit key is too short

z Has been broken in less than one day using a

specially-designed computer

z Triple-DES (3DES)

z Provides better security z Uses two 56-bit keys

C = E_K1(D_K2(E_K1(P)))

P = D_K1(E_K2(D_K1(P)))

z Instead of “triple encryption”, use

encryption-decryption-encryption

Advanced Encryption Standard

z AES selected in 2001 by U.S. NIST (National

Institute of Standards & Technology)

z Developed by Rijmen and Daemen z Secret key system

z Encryption of 128-bit blocks with keys of size 128, 192, or

256 bits

z Software & efficient hardware implementation z 3.4x1038 keys vs. 7.2x1016 keys for 56-bit DES

z AES is gradually replacing DES/3DES

z See:

RSA Public Key Algorithm

z

Named after Rivest, Shamir, and Adleman

z

Modular arithmetic & factorization of large

numbers

z Let n = pq, where p & q are two large numbers

z n typically several hundred bits long, i.e. 512 bits z Plaintext must be shorter than n

z Find e relatively prime to (p – 1)(q – 1)

z i.e. e has no common factors with (p – 1)(q – 1)

z Public key is {e,n}

z Let d be multiplicative inverse of e

z de = 1 modulo (p – 1)(q – 1)

Encryption & Decryption

z Fact: For P<n and n, p, q, d as above:

Pde _{mod n = P mod n}

z Encryption:

C = Pe _{mod n}

z Result is number less than n and is represented by same

number of bits as key

z Decryption:

Cd _{mod n = P}ed _{mod n = P mod n = P}

z Security stems from fact that it is very difficult to factor

RSA Example

z

Let

p = 5, q = 11

z n = pq = 55 and (p – 1)(q – 1) = 40

z

Let

e = 7, which is relatively prime to 40

z 7d mod 40 = 1, gives d = 23

z

Public key is {7, 55}

RSA Example continued

z Encrypt “RSA”: R=18, S=19, A=1

C₁ = 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 C₂ = 197 mod 55 = 24 C₃ = 17 mod 55 = 1 z Decrypt 1723 mod 55 = 1716+4+2+1 mod 55 =18 2423 mod 55 = 19 123 mod 55 = 1