Cryptography ProtocolsApplications for protocolsProtocolIllustrate protocol notationSlide 5Key DistributionBack to key distributionSlide 8Get Public Key from Key AuthoritySlide 10Slide 11Slide 12Get Session Key from Key AuthoritySlide 14Create a secret shared session keySlide 16Needham Schroeder protocol Use a trusted third partyNeedham Schroeder protocolSlide 19Slide 20Why do we need steps 4 & 5Still a problem …...Denning’s solution - add timestampsControlling timingDigital SignatureDigital signatureDistribution protocol -- using certificatesSlide 28Key distribution with certificatesSlide 30BackupsAvoids the suppress-replay attacksCryptography ProtocolsAnita JonesCS451 Information Security Copyright(C) Anita JonesSeptember, 2006 Applications for protocolsKey distributionConfidentialitySign message with digital signatureAuthenticationNon-repudiation…..September, 2006 Protocolprotocol – an agreed upon sequence of actions to accomplish some taskNumbered sequence of message transmissionsExchanged by 2 or more partiesNamed, but NOT guaranteed to be who they say they areExample format1 A B: <message1>2 B A: <message2>……..September, 2006 Illustrate protocol notation1 A->KDC: IDA, IDB, ‘need Certificate’ 2 KDC->A: EKa [‘need Certificate’, IDB, CAB] 3 . . .4 . . .5 . . .Objective: distribute digital certificate for B …………..Sequence (strict sequence) of numbered stepsA -> B denotes that A sends message to BMessage follows the colonSeptember, 2006 Notation for KeysShared secret session key – KsA’s public or private key – KaB’s public or private key – KbEKa[M] – encrypt with A’s keyDKa[M] – A “decrypts” with its keySince “E” and “D” are the same, I use E, almost always.Public and private keys – obvious in context.Key DistributionDistribute public keys Distribute secret (session) keysSeptember, 2006 Back to key distributioneach user generates public/private keysdistributes via:individual gives out his public key, e.g. append key to email automaticallyinsert into public directory (maintained by reputable party) readable by allpublic key authority that requires a request before returning public key (or certificate)September, 2006 Key distribution via KDCVersion 1 situation: A wants to talk to BA & B need the public key of the otherA & B trust the key distribution center KDCUsers want to be assured that the key came from KDC (authentication)September, 2006 Get Public Key from Key Authority… KDC (Key Distribution Center) knows public key for A,B Everyone knows KDC’s public key1 A->KDC: “need key”, IDB2 KDC->A: EKR-KDC [KUB ,“need key”, IDB]3 B->KDC: “need key”, IDA4 KDC->B: EKR-KDC [KUA ,“need key”, IDA]Authentication: A,B know that keys came from KDCSeptember, 2006 Key distribution via KDCVersion 2 situation: A wants to talk to BA & B need the public key of the otherA & B trust the key distribution center KDCA already shares a secret key with KDC, Ka B already shares a secret key with KDC, KbSeptember, 2006 Get Public Key from Key Authority… Exchanges use a shared (secret) key1 A->KDC: EKa[“need key”, IDB]2 KDC->A: EKa [KUB ,“need key”, IDB]3 B->KDC: EKb[“need key”, IDA]4 KDC->B: EKb[KUA ,“need key”, IDA]September, 2006 Secret Session Key from KDCVersion 3 situation: A wants to talk to B (a session)A & B need a secret key -- sharedA & B trust KDC to create that session keyProtocol:A asks for session key (to talk to B)KDC creates the key and sends it to AKDC sends the same key to BB receives a key from KDC, associated with A’s name, so B knows that A wants a session with BSeptember, 2006 Get Session Key from Key Authority… KDC (Key Distribution Center) knows public keys of A,B Everyone knows KDC’s public key1 A->KDC: EKR-a[“key”, IDB]2 KDC->A: EKU-a[EKR-KDC [KS ,“key”, IDB]]3 KDC->B: EKU-b[EKR-KDC [KS ,“key”, IDA]]One key “authenticates”; other key keeps the session key confidentialSeptember, 2006 A&B Generate their own Secret Session KeyVersion 4 situation: A wants to talk to B (a session)They want to use a shared, secret session key… for efficiencyA & B already know each other’s public keysThey talk directly – no KDC involvementSeptember, 2006 Create a secret shared session key… given a public key mechanism, users can directly exchange a secret session key1 A->B: EKU-B [IDA, “start session 88”] …A says “I want to talk”2 B->A: EKU-A[Ks, “session 88”] …ok A, here’s our session keyB creates KS, the shared session keySeptember, 2006 Introducing the notion of a NONCENonce word is invented or used just for a particular occasion used in security protocols to ensure “sequence” of a set of messagesensure “freshness” of a messagecan be a time stamp, a random number or a counter valueshould be difficult to guesscreators must remember their noncesSeptember, 2006 Needham Schroeder protocolUse a trusted third partyKDC - key distribution center is trustedeach user shares secret key with KDCKDC generates keys to be used for a sessionKDC distributes those session keysSession uses secret key, not public/private keySeptember, 2006 Needham Schroeder protocol1 A->KDC: A asks for secret key for A & B2 KDC->A: here is key & envelope for B 3 A->B: A sends the envelope (key inside)4 B->A: I got particular key k5 A->B: I saw that you received key kObjective: distribute session key securely to A and BSeptember, 2006 Needham Schroeder protocol1 A->KDC: IDA, IDB, N1 2 KDC->A: EKa [Ks, IDB, N1, EKb [Ks, IDA ]] 3 A->B: EKb[Ks, IDA]4 B->A: EKs[ N2 ]5 A->B: EKs[ f(N2) ]Objective: distribute session key securely to A and BSeptember, 2006 Issuesstep 1 was not encrypted? Any problem?alternative values of the nonce, f(nonce)could any intervention in the sequence allow a masquerade?replay of step 2KDC sent message to A, but who “authenticated” B to A?September, 2006 Why do we need steps 4 & 5Stop replay attack where adversary captures message in step 3 and replays it, in order to disrupt operations at BSeptember, 2006 Still a problem …...Assume that adversary X compromised an old session key.OK, not likely but …Z impersonates
View Full Document