1. Chapter 9. Key management
이 상 일

2. Key management? Key management ? distribution of cryptogtaph keys
Representing Identity  Ch.13
Authentication  Ch.11
Ch.9 : Propagate

3. NOTATION
XY : {Z}K
X send to Y
Encipherd message Z
Key K

4. 1. Session and Interchange Keys
Def 9.1
Session Key – cryptograpphic key associated with communication it self
Interchage Key – cryptographic key associated with principal to a communication
Comuncation <-> Principal to communcation

5. Session Key Specifically to exchange information with someone
Reduce eavesdrop, replay attack, forward search
Discard when the session end

6. Interchange key Associated with a principal
A can use the Key shares with B
To Convince B the sender is A
A can use it to all session

7. 9.2 Key Exchange To A to communicate secretly B
To using a shared cryptographic key
Criteria 1. to share cannot be transmitted in the clear 2. A and B decide to trust a third party 3. Protocals are public known

8. 9.2.1 Classical Cryptographic Key Exchange and Authentication
Simple protocol 1. Alice  Cathy: {request for session key to Bob}kalice 2. Cathy  Alice: {Ksesison }Kalice || {Ksession}Kbob 3. Alice  Bob: {Ksession}Kbob
Problem Bob cannot know to Whom
Attacker can exchange message intercept 3. Eve  Bob: {Ksession}Kbob

9. 9.2.1 Classical Cryptographic Key Exchange and Authentication
Needham – Schroeder protocol 1. Alice  Cathy : { Alice || Bob || rand1 } 2. Cathy  Alice : { Alice || Bob || rand1 || ksession || {Alice || ksession} kBob } kAlice 3. Alice  Bob : { Alice || ksession } kBob 4. Bob  Alice : { rand2 } ksession 5. Alice  Bob : { rand2 – 1 }ksession
Nonce – two random number(rand1, rand2)

10. 9.2.1 Classical Cryptographic Key Exchange and Authentication
If Eve got record
Replay Attack to Needham – Schroeder 1. Eve  Bob : { Alice || ksession } kBob 2. Bob  Alice : { rand3 } ksession [intercepted by Eve] 3. Eve  Bob : { rand3 – 1 }ksession

11. 9.2.1 Classical Cryptographic Key Exchange and Authentication
Needham – Schroeder protocol with timestamp 1. Alice  Cathy : { Alice || Bob || rand1 } 2. Cathy  Alice : { Alice || Bob || rand1 || ksession || {Alice || T || ksession} kBob } kAlice 3. Alice  Bob : { Alice || T || ksession } kBob 4. Bob  Alice : { rand2 } ksession 5. Alice Bob : { rand2 – 1 }ksession

12. 9.2.1 Classical Cryptographic Key Exchange and Authentication
Otway-Rees protocol 1. Alice  Bob : num || Alice || Bob || { rand1 || num || Alice || Bob }kAlice 2. Bob  Cathy : num || Alice || Bob || { rand1 || num || Alice || Bob }kAlice || {rand2 || num || Alice || Bob }kBob 3. Cathy  Bob : num || { rand1 || ksession }kAlice || { rand2 || ksession } kBob 4. Bob  Alice : num || { rand1 || ksession }kAlice

13. 9.2.2 Kerberos Needham – Schroeder protocol modified Denning and Sacco
Alice wants to use server S Authenticate herself to Kerberos system Obtain ticket to use S

14. 9.2.2 Kerberos
TAlice,Barnum = Barnum || {Alice || Alice address || valid time || kAlice,Barnum}kBarnum
TAlice,Barnum : ticket
kBarnum : key Barnum shares with the authentication server
valid time : the time interval during which the ticket is valid
AAlice,Barnum = {Alice || generation time || kt}kAlice,Barnum
AAlice,Barnum : Authenticator

15. 9.2.2 Kerberos - Alice want Guttenbergs file using
- authentication server is Cerberus
- ticket granting server is Barnum
1. Alice  Cerberus: Alice || Barnum 2. Cerberus  Alice : { kAlice,Barnum} kAlice || TAlice,Barnum 3. Alice  Barnum : Guttenberg || AAlice,Barnum || TAlice,Barnum 4. Barnum  Alice : Alice || {kAlice,Guttenberg} kAlice,Barnum || TAlice,Guttenberg 5. Alice  Guttenberg : AAlice,Guttenberg || TAlice,Guttenberg 6. Guttenberg  Alice : { t + 1} kAlice,Guttenberg

16. 9.2.3 Public Key Cryptographic Exchange and Authentication
Alice  Bob : { ksession } eBob
eBob is Bob’s public key

17. 9.2.3 Public Key Cryptographic Exchange and Authentication
Problem : who the message comes from 1. Alice  Peter : { send me Bob's public key } [ intercepted by Eve ] 2. Eve  Peter : { send me Bob's public key } 3. Peter  Eve : eBob 4. Eve  Alice : eEve 5. Alice  Bob : { ksession } eEve [ intercepted by Eve ] 6. Eve  Bob : { ksession } eBob
Alice  Bob : Alice || { { ksession } dAlice } eBob

18. 9.3 Cryptographic Key Infrastructures
A certificate is a token that bind an identity to a cryptographic key
Certificate structure Calice = {ealice || Alice || T}dCathy

19. 9.3.1 Certificate Signature Chains
X.509 : Directory Authentication Framework
Components 1. Version – each version 2. Serial Number – unique certificate 3. Signature algorithm identifier – identify algorithm, parameters, used to sign certificate 4. Issuer’s Distinguished Name– unique issuer’s name 5. Validity Interval – valid time 6. Subject’s Distinguished Name – uniquely identify subject

20. 9.3.1 Certificate Signature Chains
Components 7. Subject’s public key information – identify the algorithm, parameters, subject’s public key 8. Issuer’s unique idenfier (ver 2,3 only) 9. Subject’s unique idenfier (ver 2,3 only) 10. Extensions – (version 3 only) extensions in the a 11. Sugnature – algorithm and parameters used to sign the certificate

21. 9.3.1 Certificate Signature Chains
A certification authority(CA) is an entity that issues certificates
X<<Y>> : certificate that X generated for the subject Y
Signature chain : Cathy<<Dan>>Dan<<Bob>>

22. 9.3.1 Certificate Signature Chains
PGP Certificate Signature Chain
OpenPGP public key structure 1. Version 2. Time of creation 3. Validity period 4. public key algorithm and parameters 5. public key

23. 9.3.1 Certificate Signature Chains
OpenPGP ver.3 1. Version 3 2. Signature type 3. Creation time 4. Key identifier of the signer 5. Public key algorithm 6. Hash algorithm 7. Part of signed hash value 8. Signature
Ver.4 is more complex

24. 9.3.1 Certificate Signature Chains
Difference of X.509 and PGP
PGP’s single key may have multiple signature
PGP have a notion of trust – single key may have different levels of trust

25. 9.4 Storing and Revoking keys
Secret keys (for classical cryptosystems) and private keys (for public key cryptosystems) must protected
Expiration date keys must revoke

26. 9.4.1 Key storage
Attacker can get key on a multiuser system or network system
Solution – enciphering Key
Feasible Solution – Physical device
More physical device

27. 9.4.2 Key Revocation Expiration date  compromise, change
It must be revoked
1. To ensure that the revocation is correct
2. to ensure timeliness of the revocation throughout the infrastructure
A certificate revocation list is a list of certificates that are no longer valid

28. 9.5 Digital Signature
Digital Signature : Construct that authenticates both the origin and contents of a message in a manner that is provable to a disinterested third party
Classical Signature – Private Key Public Key Signature – Public Key

29. 9.5.1 Classical Signature
Cathy is third party, and have KAlice & KBob 1. Alice  Bob : {m} KAlice 2. Bob  Cathy : {m} KAlice 3. Cathy  Bob : {m} KBob

30. 9.5.2 Public Key Signatures
It use Public Key
Ex) Based on RSA system

31. 9.5.2 Public Key Signatures Alice knows Sign m1 and m2
F(05) 05^17mod77 = 3
R(17) 17^17mod77 = 19
5*17mod77 = 8
3*19mod77 = 57
So I(08) = 57

32. 9.5.2 Public Key Signatures (06^53mod77)^11mod95=63
Bob want the contract to be N(13)
13^r mod77 = 6 then r = 59
rebobmodnbob = 59*53mod60 = 7
Replace public key (7,77)
Reset private key 43
Then, (63^59mod95)^43mod77 = 13