Chapter 3

67
1 Chapter 3 Public-Key Cryptography and Message Authentication

description

Chapter 3. Public-Key Cryptography and Message Authentication. Recall :. In chapter 3 “Authentication” includes all three of these services. We need to defend against attacks such as:. ► bit flipping in stream cipher (my time-of-attack example). ► cut and paste attack with ECB. - PowerPoint PPT Presentation

Transcript of Chapter 3

Page 1: Chapter 3

1

Chapter 3

Public-Key Cryptography

and Message Authentication

Page 2: Chapter 3

2

1.4 Security Services * Authentication * Access Control * Data Confidentiality * Data Integrity * Non- repudiation * Availability Service \cs\security\stalling\secserv.wri

Recall:

In chapter 3 “Authentication”

includes all three of these services

Page 3: Chapter 3

3

We need to defend against attacks such as:

► bit flipping in stream cipher (my time-of-attack example)

► cut and paste attack with ECB

Page 4: Chapter 3

4

3.1 Approaches to Message Authentication

Authentication Using Conventional (Symmetric) Encryption

Assuming that only sender and receiver share a secret key, then successful decryption of a message proves that it is from the sender.

“If the message also includes error-detection and a sequence number, the receiver is assured that no alteration has been made and that the sequencing is proper.”

But what about the Christmas bonus cut-and-paste attack?

Circular reasoning!

Page 5: Chapter 3

5

Message Authentication without Message Encryption

We may want to be able to authenticate a message without encrypting it

Examples:

1. Public announcement, e.g. The system is going down in 5 minutes!

2. Receiver to busy to decrypt incoming messages.

3. Checking integrity of a computer program downloaded from a server.

Encryption and Authentication are separate;

Either or both may be needed

Page 6: Chapter 3

6

Message Authentication Code

A secret key is used to generate a small block of data, the MAC, which is appended to the message by the sender.

Knowing the secret key and the message, the receiver re-calculates the MAC and compares it to the appended

value.Sender calculates MACSecret

Recalculating the MAC is a “forward” calculation – fundamentally different from the “reverse” calculation in decryption.

Page 7: Chapter 3

7

Message Authentication Code – continued

If the appended code and the freshly-calculated code agree, then:

1. The receiver is assured that the message has not been altered. (Chapter 1 – data integrity – connectionless)

2. The receiver is assured that the message is from the alleged sender, since nobody else knows the secret key.

(Chapter 1 – participant authentication)

3. If the message includes a sequence number, the receiver is assured that there are no losses, duplications, or out-of-sequence elements.

(Chapter 1 – data integrity – connection-oriented)

Provided that suitable algorithms can be found to generate the Message Authentication Code!

4. The sender cannot deny having sent the message, since nobody else knows the secret

key. (Chapter 1 – nonrepudiation)

Page 8: Chapter 3

8

One-Way Hash Functions

Given a message, M, of arbitrary length a hash function produces a short, fixed-length block that is unique to M (“fingerprint”)

Figure 3.2 shows three ways to use hash functions in producing a MAC.

A hash function is a component of a MAC system.

It is not the complete system because a hash itself does not involve any secret information.

Page 9: Chapter 3

9

Figure 3.2(a) is essentially the same as figure 3.1:

Figure 3.2(b) is the same as 3.2(a), except using public-key encryption (defer until later).

Page 10: Chapter 3

10

One-Way Hash Functions – continued

Figures 3.2 (a) and (b) involve encryption, which is slow and expensive. Figure 3.2(c) is an alternative that avoids encryption:

This method is used in HMAC (see later)

Sometimes referred to as “keyed hash”

Pre-Shared secret Not transmitted

Page 11: Chapter 3

11

Recall from page 7:

2. In developing a particular security mechanism or algorithm, one must always consider potential attacks on those security features …

3. Because of point 2, the procedures used to provide particular services are often counterintuitive: It is not obvious from the statement of a particular requirement that such elaborate measures are needed. It is only when the various counter-measures are considered that the measures used make sense.

Page 12: Chapter 3

12

3.2 Secure Hash Functions

Hash function requirements:

1. H can be applied to a block of data of any size.

2. H produces fixed-length output.

3. H(x) is relatively easy to compute for any x, making both hardware and software implementation practical.

4. For any given value h it is computationally infeasible to find x such that H(x) = h

Called “one-way” or “preimage resistant”

Page 13: Chapter 3

13

4. For any given value h it is computationally infeasible to find x such that H(x) = h

Encryption functions must be reversible; Hash functions must not be reversible!

Without the “one-way” property method (c) would not work

Page 14: Chapter 3

14

5. For any given block x, it is computationally infeasible to find y ≠ x with H(y) = H(x)

Without property #5 methods 3.2 (a) and (b) would not work

Called “second preimage resistant” or “weak collision resistant”

Page 15: Chapter 3

15

6. It is computationally infeasible to find any pair (x, y) such that H(x) = H(y)

3.2 Secure Hash Functions - continued

Called “(strong) collision-resistant”

This property is necessary to defend against the “birthday attack.”

Page 16: Chapter 3

16

Birthday Attack

Probability that two specific people have same birthday is 1/365

In a group of n people there are n*(n-1)/2 pairs

Probability that any two people have same birthday is n*(n-1)/(2 * 365)

What does n have to be for probability to be 0.5?

Approximating n*(n-1) as n2 we get

n2 = 2 * 365* 0.5 or n = √365 about 19

With 128-bit hash function, probability that two specific messages

have same hash value is 2-128

But probability that two messages exist with same hash value is 2-64

Page 17: Chapter 3

17

Security of Hash Functions

Clearly, it is desirable to use a hash function that has property 6, strong collision resistance.

Preimage-resistant (property 4): 2n/2

(yields to Birthday Attack)

Second preimage resistant (property 5): 2n/2

(yields to Birthday Attack)

A 160-bit hash code is now regarded as suspect!

Strong collision resistant (property 6): 2n

(resists Birthday Attack)

For a hash code of length n bits we expect the level of effort required to

break it by brute force to be 2n BUT

Page 18: Chapter 3

18

Simple Hash Functions

Ci = bi1 XOR bi2 XOR bi3 …. XOR bim

OK for accidental transmission errors, but useless for defense against Darth.

But XOR is commutative, so could permute blocks without changing C

Page 19: Chapter 3

19

SHA Secure Hash Function

Focus on SHA-512 - block size 1024 bits, hash code size 512 bits.

Page 20: Chapter 3

20

Step 1: Append padding bits. Step 2: Append original length

Page 21: Chapter 3

21

property of SHA-512 :

Every bit of hash code is a function of every bit of the input

Often referred to as the “compression

function”

Page 22: Chapter 3

22

Hashed Message Authentication Code (HMAC)

A hash function such as SHA-512 involves no secret information – hash must be combined with secret information to produce a message authentication code.

Figure 3.2

3.3 Message Authentication Codes

Page 23: Chapter 3

23

HMAC Design Objectives

1. To use, without modification, available hash functions.

2. To allow for easy replaceability of the embedded hash function in case more secure hash functions are found or required.

3. To preserve the original performance of the hash function without incurring significant degradation.

4. To use and handle keys in a simple way

5. To have a well-understood cryptographic analysis of the strength of the authentication mechanism based on reasonable

assumptions on the embedded hash function.

HMAC can be proven secure provided that the embedded hash function has some reasonable cryptographic strengths.

Page 24: Chapter 3

24

If the embedded hash function were ever discovered to be insecure, a replacement (more secure) hash function could be inserted into HMAC. Use of the original hash function before the discovery would not be invalidated.

This contrasts with the situation with encryption: if an encryption algorithm were “broken,” messages previously

encrypted with the algorithm could be decrypted.

Repeat:

HMAC Design Objectives

2. To allow for easy replaceability of the embedded hash function in case more secure hash functions are found or

required.

This assumes that whoever discovered the insecurity didn’t exploit it privately!

Page 25: Chapter 3

25

The HMAC Algorithm

First part of key padded

to b bitsPadded Message

Second part of key padded to

b bits

SHA-512

Result of inner hash is

“message” for outer hash

SHA-512

Final result

HMAC adds three executions of the basic hash function – should not add significant time

for long messages.

Page 26: Chapter 3

26

MACs Based on Block Ciphers

Cipher-Based Message Authentication Code

We adopted the philosophy that encryption and authentication have separate objectives and techniques. Why merge them here?

Quote from NIST publication 800-38B:

CMAC may be appropriate for information systems in which an approved block cipher is more readily available than an approved hash function.

This does not seem to be a compelling reason to study this.

On the other hand, Stallings (p77) states that “systems that simultaneously protect confidentiality and authenticity (integrity) of communications” may have advantages (and may be mandated in federal systems).

Because of the limited time we have available, we will omit this section.

Page 27: Chapter 3

27

3.4 Public-Key Cryptography Principles

Public-Key Encryption Structure

► first publicly proposed by Diffie and Hellman in 1976

(but known to British cryptographers in WWII)

► first truly revolutionary advance in encryption

in literally thousands of years

► public-key algorithms based on mathematical functions

► public-key cryptography is asymmetric, involving use of two separate keys, one made public and the other kept private.

Page 28: Chapter 3

28

Page 29: Chapter 3

29

Common misconceptions about public-key cryptography

► public-key cryptography more secure than symmetric (conventional) cryptography

For same key length public-key is less secure

1024-bit asymmetric keys are about as secure as 80-bit symmetric keys.

Page 30: Chapter 3

30

Common misconceptions about public-key cryptography - continued

► public-key cryptography is a general-purpose technique that has made symmetric (conventional) cryptography obsolete

► key distribution is trivial when using public-key encryption, compared to cumbersome key distribution centers in symmetric encryption

public-key is about 1,000 times slower than symmetric, so will not replace symmetric for bulk encryption

public-key distribution usually involves a central agent

Page 31: Chapter 3

31

Recall from section 2.1:

“A symmetric encryption scheme has five ingredients”

Section 3.4: A public-key encryption scheme has six ingredients:

► plaintext

► encryption algorithm

► public and private key

► ciphertext

► decryption algorithm

Page 32: Chapter 3

32

► public and private key:

The public key of the pair is made public for others to use;

The private key is known only to its owner.

One key of the pair is used for encryption, the other for decryption

Terminology: although the private key is kept secret, we refer to it as “private” so as not to confuse with the “secret key” of symmetric encryption.

Page 33: Chapter 3

33

“Essential steps” for confidentiality:

1. Each user generates a pair of keys

Figure 3.9 (a)

Bob Alice

2. Each user places one of the keys in a public register or other

accessible file3. If Bob wishes to send a private message to Alice, he obtains her public key and encrypts the message with it.

4. Alice decrypts the message with her private key.

Page 34: Chapter 3

34

Figure 3.9

Bob obtained these from public register or other accessible

file

We do not send long messages this way!

No authentication of Bob! Everybody knows Alice’s public key!

Page 35: Chapter 3

35

Applications for Public-Key Cryptosystems

► encryption/decryption – but not used for long messages,

► digital signatures – we will study in section 3.6

► key exchange – we will study in section 4.3

Page 36: Chapter 3

36

Requirements for Encryption using Public-Key Cryptography

1. It is computationally easy for party B to generate a key pair PUB, PRB

2. It is computationally easy for a sender A, knowing PUB

to encrypt a (short) message to send to B

3. It is computationally easy for B to decrypt the message

using his/her private key

4. It is computationally infeasible for an opponent, knowing PUB

to determine the private key PRB

5. It is computationally infeasible for an opponent, knowing PUB and

the ciphertext, to recover the plaintext

6. (useful, not required) Either of the two related keys

can be used for encryption, the other for decryption

Page 37: Chapter 3

37

3.5 Public-Key Cryptography Algorithms

The RSA Algorithm

Developed in 1977 by Rivest, Shamir, and Adleman at MIT.

For plaintext block M, the ciphertext block C is obtained by:

C = Me mod nThe plaintext is recovered by:

M = Cd mod n = (Me mod n)d mod n = Med mod n

RSA is a block cipher in which the plaintext and ciphertext are

represented by integers between 0 and n – 1 for some n (”modulus”)

If both sender and receiver know n and e but only the receiver knows d, the receiver’s public key is { e, n } and private key is { d, n }

e could be called the “encryption exponent ”

Page 38: Chapter 3

38

3.4 Public-Key Cryptography Algorithms - continued

From previous slide:

For plaintext block M, the ciphertext block C is obtained by:

C = Me mod n

The plaintext is recovered by:

M = Cd mod n = Med mod n

1. For this to work, it must be possible to find n, e, and d such that

Med mod n = M for all M < n

2. It must be relatively easy to calculate Me and Cd for all M < n

3. It must be infeasible to compute d, given e and n

Page 39: Chapter 3

39

1 – 3. Select p = 17, q = 11 so n = 187 and φ(n) = 160

4. Choose e such that it is relatively prime to 160 and less than 160

Divisors of 160? yes 1, 2, 4, 5, 8, 10 …

no: 3 6, 7 9 11, 12, 13 ….

Choose e = 7

Page 40: Chapter 3

40

1 – 3. Select p = 17, q = 11 so n = 187 and φ(n) = 160

4. e = 7

5. Determine d such that de mod 160 = 1

Public key is { 7, 187 } Private key is { 23, 187 }

7d = 1, 161, 321, 481 …..

7 * 23 = 161

Page 41: Chapter 3

41

Page 42: Chapter 3

42

Encryption: evaluate 887 mod 187

Decryption: evaluate 1123 mod 187

Factorize the big number and

use properties of modular arithmetic (page 402)

1123 is a big number and hard to handle by simple programming!

Page 43: Chapter 3

43

Page 44: Chapter 3

44

Page 45: Chapter 3

45

leftrsasigkey=0sAQOc8zS+aKhfo46XdLSBzFLDOadFDitIUXfL3bP9v7aWH5seCtYrDV7bfAnzHmYqJ6yClH8cJEEYUvdVtO3/2H2dGLeigTD1XuKQzxr+FeF+bV66W6s+06+WdVEZfu7k0gWVFH+TjAUkXDZV8+cVU94m7KHVjAyx45GPN4/YOoMgN3t1QCdSGytlulyc42oosrWow+8dv3+oxVgwHUsHRF1aUoT7RcOZ+9m9V6UsIZXK5coXOJAN6f2T690dUBMcZvCYiBmi6RJAZ1DZncrQFxOtFft75qC0VJvUufcMtLYQ6dMhcQFkO58efN2tXAtC+EuzGUSVh2ftm/hf7S0qsjW+aZXQWiCy9NH3V7HhZVF2KzTH

# The exponent of the RSA public key is forced to the value 3

An actual RSA key (from lab session #2):

This modulus is 2238 bits long

Page 46: Chapter 3

46

Two possible approaches to defeating the RSA algorithm:

► brute force (try all possible keys)

– for key-length (say) 1024 bits, this is infeasible

► try to factor n into p x q

- most efforts do this, but with n (say) 300 decimal digits, it’s hard!

Page 47: Chapter 3

47

RSA Challenges:

Page 48: Chapter 3

48

Page 49: Chapter 3

49

The factoring research team of F. Bahr, M. Boehm, J. Franke, T. Kleinjung continued its productivity with a successful factorization of the challenge number RSA-640, reported on November 2, 2005. The factors are:

1634733645809253848443133883865090859841783670033092312181110852389333100104508151212118167511579

and

1900871281664822113126851573935413975471896789968 515493666638539088027103802104498957191261465571

The effort took approximately 30 2.2GHz-Opteron-CPU years according to the submitters, over five months of calendar time. They earned a prize of $20,000.

RSA 640:

If modulus, n, is the 193-digit number:

310 7418240490 0437213507 5003588856 7930037346 0228427275 4572016194 8823206440 5180815045 5634682967 1723286782 4379162728 3803341547 1073108501 9195485290 0733772482 2783525742 3864540146 9173660247 7652346609

What are p and q?

Page 50: Chapter 3

50

Diffie-Hellman Key Exchange

“The purpose of the algorithm is to enable two users to exchange a secret key securely that can then be used for subsequent [symmetric] encryption of messages. The algorithm itself is limited to the exchange of the keys.”

(however, an extension of D-H, known as El Gamal can be used for encryption)

“The Diffie-Hellman algorithm depends for its effectiveness on the difficulty of computing discrete logarithms.”

Page 51: Chapter 3

51

modulus

generator

Page 52: Chapter 3

52

Page 53: Chapter 3

53

Figure 3.13

Global public parameters q and α established in advance

Page 54: Chapter 3

54

Required to prove: the two computations of K give the same value

Page 55: Chapter 3

55

Required to prove: the two computations of K give the same value

Page 56: Chapter 3

56

Trivial example of Diffie-Hellman – problem 3.21

Page 57: Chapter 3

57

Problem 3.21(a): If A has public key YA = 9. what is A’s private key XA?

Recall YA = αXA mod q

Want 9 = 2XA mod 11

Problem 3.21(b): If B has public key YB = 3, what is shared key K ?

Recall K = (YB)XA mod q

= 36 mod 11 = 729 mod 11 = 3

Because of the difficulty of computing discrete logarithms, an

attacker knowing α, q, YA and YB cannot easily compute K

From previous slide: 64 mod 11 = 9 so XA = 6

Page 58: Chapter 3

58

3192-bit Diffie-Hellman public key

(from lab session #4)

Page 59: Chapter 3

59

Key Exchange Protocols – ways of using Diffie-Hellman

► “simple protocol” – figure 3.13

► using a central repository of public D-H keys (next slide).

Page 60: Chapter 3

60

In this implementation, both private and

public DH keys are semi-permanent

Page 61: Chapter 3

61

Man-in-the-Middle Attack

Alice Bob

Problem: the “simple protocol” does not authenticate the participants.

We’ll return to this problem in chapter 8

Page 62: Chapter 3

62

Other Public-Key Cryptography Algorithms

► Digital Signature Standard - use in lab session #1

► Elliptic-Curve Cryptography – know it exists

(increasing importance)

Page 63: Chapter 3

63

3.6 Digital Signatures

Bob wants to send a message to Alice; it’s not confidential, but he wants her to be sure that it is from him (authentication).

Here, the entire message serves as a digital signature; Bob would normally encrypt just a hash of the message

and append it (next slide).

Bob Alice

Fig 3.9(b)

Page 64: Chapter 3

64

Figure 3.2

Figure 3.2(b) was a better representation of “digital signatures”:

Alice Bob

Caution! Alice and Bob swapped from previous slide!

Page 65: Chapter 3

65

► Since only Alice knows her private key, if Bob can decode and verify the signature with her public key, the message must have come from Alice

(giving authentication and non-repudiation).

► Without Alice’s private key, Darth cannot substitute a different message and produce a correctly-encrypted hash

(giving message integrity).

Benefits of the Digital Signature

Page 66: Chapter 3

66

► The signature (encrypted hash of the message) can be detached from the message itself. Because the hash refers uniquely to the particular message, Darth cannot claim that

the detached signature belongs to a different message (useful when several people in different countries must sign).

Benefits of the Digital Signature

But this does not provide message confidentiality!

Page 67: Chapter 3

67

End of Chapter 3

At this point in the course we have covered all the basic techniques needed to provide

confidentiality and authentication services. In the rest of the course we examine specific

implementations for use in various situations.