Distributed Systems Security. Authentication Principles - 2. Prof. Steve Wilbur

(1)

MSc in Data Communications Networks and Distributed Systems, UCL

D

^CN^DS

Z08

Distributed Systems Security Authentication Principles - 2

Prof. Steve Wilbur [email protected]

D

^CN^DS

Z08

Lecture Objectives

u Examine classic authentication protocols based on PKC and identify weaknesses

u Examine classic ways of dealing with key

distribution

(2)

D

^CN^DS

Z08

3 - 3

Basic Protocol Map

u We will use the following map to keep our bearings as we explore the various protocols

Public Key (PKC) Shared Key

(SKC)

Two-way PKC One-way PKC Public Key Distribution

Two-way SKC One-way SKC Shared Key Distribution

Two-way Authentication

One-way Authentication

Key Distribution

D

^CN^DS

Z08

Notation

A, B U, V, W E S

IDx KRx KUx Ks {Data}K

Principals - “good guys” e.g.. Alice, Bob Domains - “organisations” e.g.. UCL, IBM Eavesdropper - “bad guys”, e.g.. Eve Security server/service

Identity (name) of “x”

pRivate (secret) key of “x”

pUblic key of “x”

Conventional (SKC) “Session” key Data encrypted with key K

(3)

D

^CN^DS

Z08

3 - 5

Two-way PKC Authentication

u Assume A, B already have their own private keys, KRa and KRb (do not know each other’s key) u The trusted third party, S knows public keys KUa

and KUb of A and B

u This information is public so why does S need to be trusted?

u Protocol needed to mutually authenticate A and B

D

^CN^DS

Z08

Needham & Schroeder

Two-Way PKC Authentication

KRa, KRb are Private Keys KUa, KUb are the Public Keys

Authentication Server - S

Server - B Client - A

1 2

3 6 7

KUa KUb

KRb KRa

KUb KUa

4 5

KRs

KUs KUs

(4)

D

^CN^DS

Z08

3 - 7

Needham & Schroeder

Two-Way PKC Authentication - 2

u Appears more complex: more keys, more messages

u Red keys are private and purple keys are public keys - distributed before protocol begins

u Orange keys are distributed by protocol

u Protocol principle is actually simpler than for SKC u Not all steps needed after first use

D

^CN^DS

Z08

Needham & Schroeder PKC Protocol

u A, B are parties involved u S is Authentication Server u KUa, KUb, KUs are Public

keys of A, B, S

u KRa, KRb, KRs are Private Keys of A, B, S

u I is “nonce” used once only u {x}k means “x encrypted by

key k”

u Caching of Public Keys can reduce number of steps

Authentication with Public Keys 1. A->S: IDa, IDb 2. S->A: {KUb, IDb}KRs 3. A->B: {Ia, IDa}KUb 4. B->S: IDb, IDa 5. S->B: {KUa, IDa}KRs 6. B->A: {Ia, Ib}KUa 7. A->B: {Ib}KUb Data Phase

x. A->B: {{Mab}KRa }KUb y. B->A: {{Mba}KRb }KUa S

B A

(5)

D

^CN^DS

Z08

3 - 9

Needham & Schroeder PKC Protocol - 2

u Note token at step 2 contains identity of B and its public key encrypted by S

u But this is not a secret, so why is it encrypted?

u This is embryo form of a Public Key Certificate

o Provides information vouched for by S

o Securely distributed - encrypted with S’s private key o KUb and B’s identity bound by encryption process o Could send in clear with accompanying digital

signature instead

D

^CN^DS

Z08

Needham & Schroeder PKC Protocol - 3

u Steps 3, 6 and 7 establish “live-ness” of A and B by showing they can use their private key to encrypt and value chosen by the other party

u One case of a challenge-response protocol

u Encryption of messages using:

o sender’s private key for authentication(anyone can decrypt it) and,

o recipient’s public key for secrecy(only recipient can decrypt it)

u But, use of PKC for message exchange is slow...

(6)

D

^CN^DS

Z08

3 - 11

Denning

Hybrid Protocol

Authentication with Public Key Cryptography 1. A->S: IDa, IDb

2. S->A: CERTa, CERTb

3. A->B: CERTa, CERTb, {{Ks, T}KRa }KUb

CERTa = {IDa, KUa, Ta}KRs CERTb = {KUb, IDb, Tb}KRs Data Phase with SKC x. A->B: {Mab} Ks y. B->A: {Mba} Ks u Timestamp in certificates

provides validity period u Timestamp in message 3

for Ks distribution protects against replay of session key

u Session key chosen by A u BUT, usual problems

with clock synchronisation

S B A

D

^CN^DS

Z08

Woo and Lam Hybrid Protocol

2. S->A:{KUb, IDb}KRs 3. A->B: {Na, IDa}KUb 4. B->S: IDb, IDa, {Na}KUs

5. S->B:{IDa, KUa}KRs, {{Na, Ks, IDb}KRs }KUb 6. B->A: {{Na, Ks, IDb}KRs, Nb}KUa

7. A->B: {Nb} Ks Data Phase with SKC x. A->B: {Mab} Ks y. B->A: {Mba} Ks u Certificates (red) do

not have validity - but could have u Token (purple)

contains session key and info for mutual authentication u This binding assures

A that Ks is fresh u Session key chosen

by S

S B A

(7)

D

^CN^DS

Z08

3 - 13

Woo and Lam

Hybrid Revised Protocol

2. S->A: {KUb, IDb}KRs 3. A->B: {Na, IDa}KUb 4. B->S: IDb, IDa, {Na}KUs

5. S->B: {IDa, KUa}KRs, {{Na, Ks, IDa, IDb}KRs }KUb 6. B->A: {{Na, Ks, IDa, IDb}KRs, Nb}KUa

7. A->B: {Nb} Ks Data Phase with SKC x. A->B: {Mab} Ks y. B->A: {Mba} Ks u Weakness in that

Na may only be unique among A’s nonces

u So IDa, Na uniquely identifies session request u Note: many

published protocols have been revised after careful analysis!!

S B A

D

^CN^DS

Z08

Public Key Distribution

u In principle we can distribute public keys by:

o Public announcement o Publicly available directory o Public-key authority o Public-key certificates

u Public Announcement

o Distribution of public key alone means that recipient is responsible for labeling it with owner’s identity

o Precarious - label may come “unglued”

o Rogue may substitute their own PK allowing them to intercept/fake messages and denies service to legitimate party

(8)

D

^CN^DS

Z08

3 - 15

Public Key Distribution - 2

u Publicly Available Directory

o Rely on OS file protection to bind owner’s identity and Public Key

o Allow owners update access o All other users read only access

o Most file system security can be cracked

u Public Key Authority

o Similar to Authentication Server (S) in N&S protocols o For volume use S would be bottleneck

o So need approach which has many more distribution points, yet still retains proof of authenticity

D

^CN^DS

Z08

Public Key Certificates

u Bind owner’s identity to their public key under specified issuing authority

u Can be freely distributed

u Tampering will be detected, ∴ route taken for delivery is very unlikely to weaken trust in the certificate per se

u Can be distributed by anyone, e.g. certificates that might be needed by the recipient can be sent with message

o Recipient can check their validity, or

o Recipient can get “fresh” ones from its favourite Certificate Distribution Centre

(9)

D

^CN^DS

Z08

3 - 17

Public Key Certificates

u In practice: need additional information such as:

o Validity period

o Encryption algorithm identifier

o Mode of use of algorithm, e.g.. key length o etc.

u Certificates have to be revoked if:

o Private key compromised

o Key details change, e.g.. owner leaves company

u These and other practical issues covered later

D

^CN^DS

Z08

Certificate Life-Cycle

Certificate contents in plain text Issuer

User

Hash Alg ID Enc

Alg ID Signature

Hash Encrypt KRs

Hash Decrypt KUs

Hu Hs

Hs

If Hu = Hs then the Certificate has not been tampered with

Similar technique can be used for ensuring integrity of any plaintext message

(10)

D

^CN^DS

Z08

3 - 19

PKC Authentication Multiple Domains

u Consider A and B in different domains U and V

u ∴ A’s PK distributed via certificate issued by U and B’s by V

u How does A get B’s PK and vice versa?

u Trust relationships:

o U and V trust each other - Cross-Certification

o U and V trust a third party W - Super-Domain

V U

W

U V

A B

D

^CN^DS

Z08

Certification Paths

u Let us first take simplest case where A and B are in same domain U

u Cu(A) = Certificate for A issued by U

= {IDa, KUa}KRu

u Cu(B) = Certificate for B issued by U

= {IDb, KUb}KRu u For communication between A and B:

A has: Cu(A) B has: Cu(B)

Cu(B) Cu(A)

Pu Pu

u Using Pu, A and B can both validate other party’s certificate ie. verify that U issued the certificate and that U believes that KUx is the public key of IDx

u ∴ A and B can believe that KUx is the public key of IDx

(11)

D

^CN^DS

Z08

3 - 21

Certification Paths - 2

u If A in domain U then Cu(A) issued by U u If B in domain V then Cv(B) issued by V

u Cross Certification:

o U issues Cu(V) = {IDv, KUv}KRu o V issues Cv(U) = {IDu, KUu}KRv

u Super Domain:

o W issues Cw(U) = {IDu, KUu}KRw o W issues Cw(V) = {IDv, KUv}KRw

V U

W

U V

A B

D

^CN^DS

Z08

Certification Paths - 3

u Both use same approach for finding target PK so let us just consider Cross Certification case

u A might send to B o Message, Cu(A), Cv(U)

o These are certificates and are public - so Cv is not just available to entities within domain V

u B has Pv

u ∴ B can extract Public Key of U (strictly believe that KUu is the public key of IDu)

u B can then can extract Public Key of A using KUu from Cu(A) (strictly believe that KUa is the public key of IDa) u Chain can be longer, e.g.

Message, Cx1(A), Cx2(x1), Cx3(x2), .... Cxn(Xn-1) where B is in domain Xn and possesses Pxn