Lecture 11 Protocols (Continued) Chapters 9 and 11 in KPS 1 Key - - PDF document

▶
lecture 11
SMART_READER_LITE
LIVE PREVIEW

Lecture 11 Protocols (Continued) Chapters 9 and 11 in KPS 1 Key - - PDF document

Feb 29, 2024 307 likes •455 views

Lecture 11 Protocols (Continued) Chapters 9 and 11 in KPS 1 Key Distribution Center (KDC) or Trusted Third Party (TTP) K(X) = Encryption of X with key K KDC generates fresh K Alice Bob obtains K and Obtains knows to use as a K Msg3: K B

slide-1
SLIDE 1

1

Lecture 11

1

Protocols (Continued)

Chapters 9 and 11 in KPS

Key Distribution Center (KDC) or Trusted Third Party (TTP)

2

  • Alice and Bob communicate using K as a short-term (session) key for encryption and/or data integrity
  • Note:
  • Msg2 is not tied to Msg1
  • Msg1 is possibly old
  • Msg2 is possibly old and so is Msg3
  • Bob and Alice don’t authenticate each other!

Alice Obtains K

Bob obtains K and knows to use as a key for communicating with Alice

KDC generates fresh K

Msg3: KB(A,K)

K(X) = Encryption of X with key K

slide-2
SLIDE 2

2

3

KDC A B (1) Request, B, N1 (2) EKa[ Ks, Request, N1, EKb(Ks,A) ] (3) EKb[Ks, A] (4) EKs[A, N2] (5) EKs[f(N2)]

Notes:

  • Msg2 is tied to Msg1
  • Msg2 is fresh/new
  • Msg3 is possibly old *
  • Msg1 is possibly old (KDC doesn’t authenticate Alice)
  • Bob authenticates Alice
  • Bob authenticates KDC
  • Alice DOES NOT authenticate Bob

A Typical Key Distribution Scenario

EK[X] = Encryption of X with K

Public Key Distribution

General schemes:

  • Public announcement (e.g., in a newsgroup
  • r email message)
  • Can be forged
  • Publicly available directory
  • Can be tampered with
  • Public-key certificates (PKCs) issued by

trusted off-line Certification Authorities (CAs)

4

slide-3
SLIDE 3

3

Certification Authorities

  • Certification authority (CA): trusted, highly secure (physically and

electronically) component

  • Issues public key certificates; each binds a public key to a specific entity
  • Each entity (user, host, etc.) registers its public key with CA.
  • Bob provides “proof of identity” to CA.
  • CA creates public key certificate binding Bob’s ID/name to this public key.
  • Certificate containing Bob’s public key is signed by CA:

CA says: “this is Bob’s public key”

5

Bob’s public key

PK

B Bob’s identifying information

digital signature

CA private key

SK

CA

PK

B

certificate for Bob’s public key, signed by CA

  • When Alice wants to get Bob’s public key:
  • Get Bob’s certificate (from Bob or elsewhere)
  • Using CA’s public key verify the signature on Bob’s certificate
  • Check for expiration
  • Check for revocation (we’ll talk about this later)
  • Extract Bob’s public key

6

Bob’s Public Key

PK

B

digital signature CA Public Key

PK CA PKB

Certification Authority

slide-4
SLIDE 4

4

7

  • Serial number (unique to issuer)
  • Info about certificate owner, including algorithm and

key value itself (not shown)

  • info about

certificate issuer

  • valid dates
  • digital

signature by issuer

A Certificate Contains

8

A Sample Certificate (1/2)

slide-5
SLIDE 5

5

9

A Sample Certificate (2/2)

Back to Protocols

10

slide-6
SLIDE 6

6

11

Alice Bob

1 2 3 4 5

  • 1. A  T: A, B, NA
  • 2. T  A: {NA, B, K, {K, A}KB }KA
  • 3. A  B: {K, A}KB
  • 4. B  A: {NB}K
  • 5. A  B: {NB-1}K

B KDC

Needham-Schroeder Protocol (1978): First Distributed Security Protocol

{X}K = Encryption of X with key K

Security?

Denning-Sacco Attack: suppose Eve recorded an old protocol session for which she somehow knows the session key K‘: 1. A  T: A, B, NA 2. T  A: {NA, B, K’, {K’, A}KB}K A 3. A  B: {K’, A}KB

  • At a later time:

1. E  B: {K’, A}KB 2. B  E: {NB}K’ 3. E  B: {NB-1}K’

12

slide-7
SLIDE 7

7

Fixing the Attack

  • Bob has no guarantees about freshness of the message in

step 3.

  • Eve exploits this to impersonate Alice to Bob - old session

keys are useful.

  • Can be fixed by adding timestamps:
  • Limits usefulness of old session keys
  • Eve’s attack becomes:

3: E  B: {K’, T’, A}KB attack is now thwarted because T’ is stale

13

PK-based Needham-Schroeder Protocol

14

TTP A B

  • 3. [Na, A]PKb
  • 6. [Na, Nb]PKa
  • 7. [Nb]PKb
  • CERTB = Message 2, CERTA = Message 5
  • PKA: Alice’s public key, PKB: Bob’s public key
  • SKT: TTP’s secret (private) key used for signing
  • Everyone knows TTP’s public key PKT

KDC

Alice Bob

[X]K = Encryption of X with key K

slide-8
SLIDE 8

8

Another Attack

  • 1, 2, 4, 5: Delivery of public key
  • Does not guarantee freshness of the public key

How to solve it?

  • Timestamp in messages 2 and 5 or challenges in messages 1&2 and 4&5
  • Public Key Certificate: assign expiration time/data to each certificate (messages 2

and 5)

15

PK-based Denning-Sacco Attack

16

TTP

A B

  • 3. CertA,CertB, [ {KAB,TA}SKA ] PKB
  • 1. A, B
  • 2. CertA, CertB
  • 4. Secure communication with KAB

3’. CertA,CertC, [ {KAB,TA}SKA] PKC 4’. Secure communication with KAB

B

Bob impersonates Alice

C

Thinks she is talking to A

Alice Bob

B

Bob

B

TTP

KDC

CertA={PKA,A}SKT CertB={PKB,B}SKT CertC={PKC,C}SKT

slide-9
SLIDE 9

9

Lowe’s Attack (Impersonation by Interleaving)

17

Original

  • 3. A  B: [Na, A]PKb
  • 6. B  A: [Na, Nb]PKa
  • 7. A  B: [Nb]PKb

Attack: E impersonates A 1.3. A  E: [Na, A]PKe 2.3. E  B: [Na, A]PKb 2.6. B  E: [Na,Nb]PKa 1.6. E  A: [Na,Nb]PKa 1.7. A  E: [Nb]PKe 2.7. E  B: [Nb]PKb Fix

  • 3. A  B: [Na, A]PKb
  • 6. B  A: [B, Na, Nb]PKa
  • 7. A  B: [Nb]PKb

Fixed PK-based Needham-Schroeder Protocol

18

TTP A B

  • 3. [Na, A]PKb
  • 6. [B, Na, Nb]PKa
  • 7. [Nb]PKb

KDC

Alice Bob

slide-10
SLIDE 10

10

Reflection Attack and a Fix

  • Original Protocol

1. A  B : rA 2. B  A : { rA, rB } K 3. A  B : rB

  • Attack

1. A  E : rA 2. E  A : rA : Starting a new session 3. A  E : { rA, rA’ } K : Reply to (2) 4. E  A : { rA, rA’ } K : Reply to (1) 5. A  E : rA’ Solutions?

  • Use 2 different uni-directional keys k” (AB) and k’ (BA)
  • Remove symmetry (direction, msg identifiers)

19

Interleaving Attacks

  • Protocol for Mutual Authentication

1. A  B : A, rA, 2. B  A : rB, { rB, rA, A } SKB 3. A  B : rA’, { rA’, rB, B } SKA

  • Attack

1. E  B : A, rA 2. B  E : rB, { rB, rA, A } SKB 3. E  A : B, rB 4. A  E : rA’, { rA’, rB, B } SKA 5. E  B : rA’, { rA’, rB, B } SKA

  • Attack due to symmetric messages (2), (3)

20

slide-11
SLIDE 11

11

Lessons learned?

  • Designing secure protocols is hard. There are many

documented failures in the literature.

  • Good protocols are already standardized (e.g., ISO

9798, X.509, …) – use them!

  • In other words, don’t invent your own!
  • The problem of verifying (proving) protocol security

gets much harder as protocols get more complex: more parties, messages and rounds.

21

If interested to learn further, read this paper:

“Programming Satan’s Computer” by R. Anderson and R. Needham available at: http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf

22

slide-12
SLIDE 12

12

Secure Protocol Examples

23

Authenticated Public-Key-based Key Exchange (Station-to-Station or STS Protocol)

24

p a y

v a

mod =

Choose random v

Bob a b bob w b

y y SIG p a y } , { mod = =

Choose random w, Compute

p y K

w a ba

mod ) ( =

Compute

( ) mod { , }

v ab b alice alice a b

K y p SIG y y = =

bob b bob

SIG y CERT , ,

alice alice SIG

CERT ,

slide-13
SLIDE 13

13

x.509 Authentication & Key Distribution Protocols

A B

SK PK ab a a a

K

  • ther

B r t } ] [ , , , , , 1 {

25

A B

SK PK ab a a a

K

  • ther

B r t } ] [ , , , , , 2 {

B A

SK PK ba b a b b

K

  • ther

r A r t } ] [ , , , , , , 2 {

A B

SK PK ab a a a

K

  • ther

B r t } ] [ , , , , , 3 {

B A

SK PK ba b a b b

K

  • ther

r A r t } ] [ , , , , , , 3 {

A

SK b

r } , 3 {

One-msg AB Two-msg AB Three-msg AB