05_KeyManagement

7/30/2019 05_KeyManagement

1/53

Slide #9-1

Chapter 5: Qun l kha

Kha phin v kha trao i

Trao i kha

H tng kha m ha

Lu tr v thu hi kha

Ch k s


2/53

Slide #9-2

K php

XY: {Z|| W} kX,YXgi cho Ybn tin c to bng cch ghpZv W

sau m ha bi kha kX,Y, l kha chia s giaXv Y AT: {Z} kA || { W} kA,T

Agi cho Tmt bn tin bao gmZc m ha bngkha kA, l kha caA, v Wc m ha bng kha

kA,T, kha chia s giaA v T r1, r2nonces (cc s ngu nhin khng lp li)


3/53

Slide #9-3

Kha phin v kha trao i

Alice mun gi mt bn tin m cho Bob Assume public key encryption Alice generates a random cryptographic key k

sand uses

it to encipherm

To be used for this message only Called asession key

She enciphers ks with Bob;s public key kB

kB enciphers all session keys Alice uses to communicate withBob

Called an interchange key

Alice sends { m } ks{ ks} kB


4/53

Slide #9-4

Li ch ca kha phin

Hn ch lng d liu c m ha bng 1 kha Standard practice, to decrease the amount of traffic an

attacker can obtain

Ngn chn mt s tn cng Example: Alice will send Bob message that is either

BUY or SELL. Eve computes possible ciphertexts{ BUY } kBand { SELL } kB. Eve intercepts

enciphered message, compares, and gets plaintext atonce


5/53

Slide #9-5

Cc gii thut trao i kha

Mc tiu: Alice, Bob c c kha chung Key cannot be sent in clear

Attacker can listen in Key can be sent enciphered, or derived from exchanged dataplus data not known to an eavesdropper

Alice, Bob may trust third party

All cryptosystems, protocols publicly known Only secret data is the keys, ancillary information known only

to Alice and Bob needed to derive keys

Anything transmitted is assumed known to attacker


6/53

Slide #9-6

Phng php truyn thng

Vn khi u: how do Alice, Bob begin? Alice cant send it to Bob in the clear!

Gi s c bn th 3 tin cy, CathyAlice and Cathy share secret key kA

Bob and Cathy share secret key kB

S dng cc kha ny trao i khachung ks


7/53

Slide #9-7

Simple Protocol

Alice Cathy{ request for session key to Bob } kA

Alice Cathy{ ks } kA || { ks } kB

Alice Bob{ ks } kB


8/53

Slide #9-8

Vn

Lm th no Bob bit l ang ni chuynvi Alice?

Replay attack: Eve records message from Aliceto Bob, later replays it; Bob may think hestalking to Alice, but he isnt

Session key reuse: Eve replays message fromAlice to Bob, so Bob re-uses session key

Phi cung cp chc nng xc thc chngli tn cng gi lp


9/53

Slide #9-9

Needham-Schroeder

Alice CathyAlice || Bob || r1

Alice Cathy{ Alice || Bob || r1 || ks || { Alice || ks } kB } kA

Alice Bob{ Alice || ks } kB

Alice Bob{ r2 } ks

Alice Bob{ r21 } ks


10/53

Slide #9-10

Phn tch: Alice talking to Bob

Bn tin th 2 Enciphered using key only she, Cathy knows

So Cathy enciphered it Response to first message

As r1 in it matches r1 in first message

Bn tin th 3

Alice knows only Bob can read it As only Bob can derive session key from message

Any messages enciphered with that key are from Bob


11/53

Slide #9-11

Phn tch: Bob talking to Alice

Bn tin th 3 Enciphered using key only he, Cathy know

So Cathy enciphered itNames Alice, session key

Cathy provided session key, says Alice is other party

Bn tin th 4

Uses session key to determine if it is replay from Eve If not, Alice will respond correctly in fifth message

If so, Eve cant decipherr2and so cant respond, or respondsincorrectly


12/53

Slide #9-12

Ci tin ca Denning-Sacco

Gi thit: Tt c kha u b mt

Tnh hung: Gi s Eve c th ly kha phin.

nh hng ti giao thc trao i kha? In what follows, Eve knows ks

Eve Bob{ Alice || ks } kB

Eve Bob{ r2 } ks

Eve Bob{ r21 } ks


13/53

Slide #9-13

Gii php

Trong giao thc trn, Eve gi mo Alice Vn : Gi lp trong bn tin th 3

First in previous slide Gii php: S dng trng thi gian T phthin gi lp

im yu: N ng h khng ng b c th t

chi bn tin hp l hoc chp nhp gi tin lp Parties with either slow or fast clocks vulnerable toreplay

Resetting clock does noteliminate vulnerability


14/53

Slide #9-14

Needham-Schroeder with

Denning-Sacco ModificationAlice Cathy

Alice || Bob || r1

Alice Cathy{ Alice || Bob || r1 || ks || { Alice || T|| ks } kB } kA

Alice Bob{ Alice || T|| ks } kB

Alice Bob{ r2 } ks

Alice Bob{ r21 } ks


15/53

Slide #9-15

Giao thc Otway-Rees

Khc phc vn That is, Eve replaying the third message in the

protocol

Khng dng trng thi gianNot vulnerable to the problems that Denning-

Sacco modification has S dng s nguyn n kt hp tt c cc

bn tin trong mt trao i c th


16/53

Slide #9-16

The Protocol

Alice Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA

Cathy Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA ||{ r2 || n || Alice || Bob } kB

Cathy Bobn || { r1 || ks } kA || { r2 || ks } kB

Alice Bobn || { r1 || ks } kA


17/53

Slide #9-17

Phn tch: Alice talking to Bob

Bn tin th 4Ifn matches first message, Alice knows it is

part of this protocol exchangeCathy generated ks because only she, Alice

know kA

Enciphered part belongs to exchange as r1matches r1 in encrypted part of first message


18/53

Slide #9-18

Phn tch: Bob talking to Alice

Bn tin th 3Ifn matches second message, Bob knows it is

part of this protocol exchangeCathy generated ks because only she, Bob know

kB

Enciphered part belongs to exchange as r2matches r2 in encrypted part of second message


19/53

Slide #9-19

Tn cng gi lp

Eve c kha c ks, v bn tin trong bc 3 n || { r1 || ks } kA || { r2 || ks } kB

Eve gi cho Alice Alice has no ongoing key exchange with Bob: n

matches nothing, so is rejected

Alice has ongoing key exchange with Bob: n does not

match, so is again rejected If replay is for the current key exchange, andEve sent the

relevant part before Bob did, Eve could simply listen to traffic;

no replay involved


20/53

Slide #9-20

Kerberos

H thng xc thc Based on Needham-Schroeder with Denning-Sacco

modification Central server plays role of trusted third party(Cathy)

Th

Issuer vouches for identity of requester of service Th xc thc

Identifies sender


21/53

Slide #9-21

tng

Useruxc thc ti Kerberos server Obtains ticket Tu,TGSfor ticket granting service (TGS)

Userumun s dng dch vs: User sends authenticatorAu, ticket Tu,TGSto TGS asking

for ticket for service

TGS sends ticket Tu,s to user

User sendsAu, Tu,s to server as request to uses

Details follow


22/53

Slide #9-22

Th

Giy xc nhn cho bit ngi cp th nhn dinngi yu cu th

V d v th c cp cho u dng dch vsTu,s =s || { u || us address || valid time || ku,s } ks

where:

ku,s is session key for user and service

Valid time is interval for which ticket valid

us address may be IP address or something else Note: more fields, but not relevant here


23/53

Slide #9-23

Th xc thc

Giy xc nhn cha nhn din ca ngi gi th Used to confirm sender is entity to which ticket was

issued

Example: authenticator useru generates forservices

Au,s = { u || generation time || kt} ku,s

where:

ktis alternate session key Generation time is when authenticator generated

Note: more fields, not relevant here


24/53

Slide #9-24

Protocol

user Cathyuser|| TGS

Cathy user{ ku,TGS} ku || Tu,TGS

user TGSservice ||Au,TGS || Tu,TGS

user TGSuser|| { ku,s } ku,TGS || Tu,s

user serviceAu,s || Tu,s

user service{ t+ 1 } ku,s


25/53

Slide #9-25

Phn tch

Hai bc u ly th ngi dng s dngTGS

Useru can obtain session key only ifu knowskey shared with Cathy

Bn bc tip theo chi ra cch uly v sdng th cho dch vsServices validates request by checking sender

(usingAu,s) is same as entity ticket issued to

Step 6 optional; used when u requestsconfirmation


26/53

Slide #9-26

Vn

Da vo ng h c ng bIf not synchronized and old tickets,

authenticators not cached, replay is possible

Th c mt s trng c nhDictionary attacks possible

Kerberos 4 session keys weak (had much lessthan 56 bits of randomness); researchers at

Purdue found them from tickets in minutes


27/53

Slide #9-27

Public Key Key Exchange

Kha trao i c cng khai eA, eBAlice and Bobs public keys known to all

dA, dBAlice and Bobs private keys known only toowner

Simple protocol ks is desired session key

Alice Bob{ ks } eB


28/53

Slide #9-28

Vn v gii php

D b tn cng gi mo hoc gi lp Because eB known to anyone, Bob has no assurance that

Alice sent message

Simple fix uses Alices private key ks is desired session key

Alice Bob{ { ks } dA } eB


29/53

Slide #9-29

Notes

C th km theo bn tin m ha bng kha ks

Gi s Bob c kha cng khai ca Alice v ngc

li If not, each must get it from public server

If keys not bound to identity of owner, attacker Eve canlaunch a man-in-the-middle attack (next slide; Cathy is

public server providing public keys) Solution to this (binding identity to keys) discussed later as

public key infrastructure (PKI)


30/53

Slide #9-30

Man-in-the-Middle Attack

Alice Cathysend Bobs public key

Eve Cathysend Bobs public key

Eve CathyeB

AliceeE

Eve

Alice Bob{ k

s} e

E

Eve Bob{ ks } eB

Eve intercepts request

Eve intercepts message


31/53

Slide #9-31

Cryptographic Key Infrastructure

Mc tiu: Gn cc thc th vi kha

Truyn thng: Khng kh thi v cc kha c chia s

Use protocols to agree on a shared key (see earlier) Public key: Gn thc th vi kha cng khai

Crucial as people will use key to communicate withprincipal whose identity is bound to key

Erroneous binding means no secrecy betweenprincipals

Assume principal identified by an acceptable name


32/53

Slide #9-32

Certificates: Chng ch

To mt th (bn tin) c cha:Identity of principal (here, Alice)

Corresponding public keyTimestamp (when issued)

Other information (perhaps identity of signer)

signed by trusted authority (here, Cathy)

CA = { eA || Alice || T} dC


33/53

Slide #9-33

Use

Bob nhn chng ch ca Alice If he knows Cathys public key, he can decipher the

certificate

When was certificate issued? Is the principal Alice?

Now Bob has Alices public key

Vn : Bob cn kha cng khai ca Cathy xc

minh chng ch (certificate) Problem pushed up a level Two approaches: Merkles tree, signature chains


34/53

Slide #9-34

Certificate Signature Chains

To chng chGenerate hash of certificate

Encipher hash with issuers private key Xc minh

Obtain issuers public keyDecipher enciphered hashRecompute hash from certificate and compare

Vn : Ly c kha cng khai ca ngicp


35/53

Slide #9-35

X.509 Chains

Some certificate components in X.509v3: Version

Serial number Signature algorithm identifier: hash algorithm

Issuers name; uniquely identifies issuer

Interval of validity

Subjects name; uniquely identifies subject Subjects public key

Signature: enciphered hash


36/53

Slide #9-36

Xc minh chng ch X.509

Ly kha cng khai ca ngi cp The one for the particular signature algorithm

Gii m ch k Gives hash of certificate

Tnh li m bm t chng ch v so snh If they differ, theres a problem

Kim tra thi gian This confirms that certificate is current


37/53

Slide #9-37

Issuers: Ngi cp

Certification Authority (CA): n v phthnh chng ch

Multiple issuers pose validation problem Alices CA is Cathy; Bobs CA is Don; how

can Alice validate Bobs certificate?

Have Cathy and Don cross-certify Each issues certificate for the other


38/53

Slide #9-38

Xc minh v Xc nhn cho

Certificates: Cathy Dan


39/53

Slide #9-39

PGP Chains

Chng ch OpenPGP c cu trc dng cc gi tin One public key packet Zero or more signature packets

Gi tin kha cng khai: Version (3 or 4; 3 compatible with all versions of PGP,

4 not compatible with older versions of PGP)

Creation time Validity period (not present in version 3) Public key algorithm, associated parameters Public key


40/53

Slide #9-40

Gi tin ch k OpenPGP

Version 3 signature packet Version (3) Signature type (level of trust) Creation time (when next fields hashed) Signers key identifier (identifies key to encipher hash) Public key algorithm (used to encipher hash) Hash algorithm Part of signed hash (used for quick check) Signature (enciphered hash)

Version 4 packet more complex


41/53

Slide #9-41

Signing

Mt chng ch c th c nhiu ch k

Thuc tnh tin cy c a vo mi ch k

Range from untrusted to ultimate trust Signer defines meaning of trust level (no standards!)

Version 4: Kha c k bi chnh ch th Called self-signing


42/53

Slide #9-42

Xc minh chng ch

Alice needs to validateBobs OpenPGP cert Does not know Fred,

Giselle, or Ellen

Alice gets Giselles cert Knows Henry slightly, but

his signature is at casuallevel of trust

Alice gets Ellens cert Knows Jack, so uses hiscert to validate Ellens, thenhers to validate Bobs Bob

Fred

Giselle

Ellen

Irene

Henry

Jack

Arrows show signatures

Self signatures not shown


43/53

Slide #9-43

Lu tr kha

Trong cc h thng a ngi dng hoc mitrng mng: K tn cng c th vt qua h

thng iu khin truy cp Encipher file containing key Attacker can monitor keystrokes to decipher files

Key will be resident in memory that attacker may be able toread

Use physical devices like smart card Key never enters system

Card can be stolen, so have 2 devices combine bits to makesingle key


44/53

Slide #9-44

Thu hi kha

Chng ch khng cn hp l trc khi ht hn Usually due to compromised key May be due to change in circumstance (e.g., someone

leaving company)

Vn : Entity revoking certificate authorized to do so Revocation information circulates to everyone fast

enough Network delays, infrastructure problems may delay

information


45/53

Slide #9-45

CRLs

Certificate revocation listCRL: Danh schnhng chng ch b thu hi

X.509: Ch c ngi pht hnh chng ch c thuhi Added to CRL

PGP: Ngi k c thu hi ch k, ngi s huc th thu hi c chng ch, hoc cho php ngikhc thu hi Revocation message placed in PGP packet and signed Flag marks it as revocation message


46/53

Slide #9-46

Ch k s

Mt cu trc dng xc thc ngun gc v nidung ca bn tin v c th chng minh s xc thc vi 1 bn th 3 khch quan.

Ngi gi khng th t chi gi bn tin (dchv khng th chi ci) Limited to technicalproofs

Inability to deny ones cryptographic key was used to sign

One could claim the cryptographic key was stolen orcompromised

Legal proofs, etc., probably required; not dealt with here


47/53

Slide #9-47

Sai lm thng gp

Thng thng: Alice, Bob share key kAlice sends m || { m } kto Bob

y l ch k s?WRONG

khng phi l ch k s L do? Bn th 3 khng th xc nh l Alice

hay Bob to bn tin trn


48/53

Slide #9-48

Ch k s truyn thng

Cn c bn th 3 tin cy Alice, Bob each share keys with trusted party Cathy

gii quyt tranh chp, ngi gii quyt ly { m } kAlice,

{ m } kBob, v yu cu Cathy gii m; nu 2 bn tin khp,th tng ng hp ng 2 bn k

Alice Bob

Cathy Bob

Cathy Bob

{ m }kAlice

{ m }kAlice

{ m }kBob


49/53

Slide #9-49

Ch k s kha cng khai

Kha ca Alice: dAlice, eAlice

Alice gi cho Bobm || { m } dAlice

Khi c tranh chp, ngi gii quyt tnh:{ { m } dAlice } eAlice

Nu kt qu l m, Alice k bn tin Shes the only one who knows dAlice!


50/53

Slide #9-50

Ch k s RSA

Dng kha ring m ha bn tinProtocol for use is critical

Cc im chnh:Never sign random documents, and when

signing, always sign hash and never document

Mathematical properties can be turned against signerSign message first, then encipher

Changing public keys causes forgery


51/53

Slide #9-51

Attack #1

Tnh hung Alice, Bob k H nA = 95, eA = 59, dA = 11 nB = 77, eB = 53, dB = 17

26 H, c s t 00 n 25 Alice has Bob sign 05 and 17:

c = mdB mod nB = 0517 mod 77 = 3 c = mdB mod nB = 1717 mod 77 = 19

Alice computes 0517 mod 77 = 08; correspondingsignature is 0319 mod 77 = 57; claims Bob signed 08

Judge computes ceB mod nB= 5753 mod 77 = 08 Signature validated; Bob is toast


52/53

Slide #9-52

Attack #2: Bobs Revenge

Bob, Alice ng k H 06 Alice m ha, sau k:

(meB mod 77)dA mod nA

= (0653 mod 77)11 mod 95 = 63

Bob thay i kha cng khai Computes rsuch that 13rmod 77 = 6; say, r= 59 Computes reB mod (nB) = 5953 mod 60 = 7

Replace public key eB with 7, private key dB = 43 Bob tuyn b H l13. Tnh: (6359 mod 95)43 mod 77 = 13 Verified; now Alice is toast


53/53

Slide #9 53

Key Points

Key management critical to effective use ofcryptosystems

Different levels of keys (session vs. interchange)

Keys need infrastructure to identify holders, allowrevoking

Key escrowing complicates infrastructure

Digital signatures provide integrity of origin andcontent

Much easier with public key cryptosystems than withclassical cryptosystems

05_KeyManagement

Documents

Transcript of 05_KeyManagement