CSCI 530, Spring 2010 Copyright © William C. Cheng T1CS530Key Management &DistributionBill Chenghttp://merlot.usc.edu/cs530-s10 CSCI 530, Spring 2010 Copyright © William C. Cheng T2Using Cryptographymust establish shared keyone side generates keyProvides foundation for security servicesBut can it bootstrap itself?transmits key to other sidebut how?straightforward plantouched upon one form of key exchange CSCI 530, Spring 2010 Copyright © William C. Cheng T3Two ProblemsPeer-to-peer key sharingProb 1: Known peer, insecure channelProb 2: Secure channel, unknown peer CSCI 530, Spring 2010 Copyright © William C. Cheng T4Man in the Middle of DHyou don’t really know you have a secure channelpublished public valuesDH provides key exchange, but no authenticationman-in-the-middleyou exchange a key with eavesdropper (man-in-the-middle),who exchanges key with the person you think are youtalking to directlyeavesdropper relays all messages, but observes orchanges them in transitsolutionsauthenticated DH (signed or encrypt DH value)encrypt the DH exchangesubsequently send has of DH value, with secret CSCI 530, Spring 2010 Copyright © William C. Cheng T5Security Through Obscurity?very simple permutationCaesar ciphersonly 25 different casesrelies strictly on no one knowing the methodkey exchange is really method exchange CSCI 530, Spring 2010 Copyright © William C. Cheng T6PasswordsReduces permutation space to key spaceBut key is more compact and perhaps more readilyexchanged out of bandCaesar cipher: one-letter "key"10-letter key for MSC reduces 26! (~4x1020) to 26P108-byte key for DES reduces 264! (~1010200) to 256 (~1017)in personby telephone (especially for public keys)Most security depends on some out of band bootstrapexceptions? are they really exceptions?DH provided key exchange, but not authenticationbut hard to remember 10-letter keyCSCI 530, Spring 2010 Copyright © William C. Cheng T7The German Enigma Machinenot as easily as widely regardedBroken first by Polish, then by Englishday keys plus scramblers (using subkeys)Weaknesses in key distribution"session keys" encrypted in duplicateEnigma did not use OFB/CFBRotor-basedABCDEABCDEplaintextciphertextrotors are wiredcodewheelsa rotor implementsa fixed mono-alphabetic substitutionpolyalphabetic substitution (with a long period) - theencipherment of each plaintext character causes variousrotors to move, like an odometer (but not exactly) CSCI 530, Spring 2010 Copyright © William C. Cheng T8Secret Key DistributionBill Chenghttp://merlot.usc.edu/cs530-s10 CSCI 530, Spring 2010 Copyright © William C. Cheng T9Peer-to-Peer Distributionhundreds of servers...Technically easyBut it doesn’t scaletimes thousands of users...yields ~ million keysbuilding up to the Needham-Schroeder approachCentralized key serverby hand!or have a day key{Kc,s}Kc is the credentials (contains session key) CSCI 530, Spring 2010 Copyright © William C. Cheng T10Needham and Schroeder - Basic Ideaencrypted twice, each with a different keyUser sends request to KDC: {s}KDC generates a random key: Kc,sNo keys ever traverse the net in the clear{Kc,s}Kc, {Kc,s}Ks{Kc,s}Ks is the ticketticket is opaque to the client, it is meant to be forwardedwith application request CSCI 530, Spring 2010 Copyright © William C. Cheng T11KDCKDCc sKcKs s CSCI 530, Spring 2010 Copyright © William C. Cheng T12KDC (Cont...)KDCc s{Kc,s}Kc{Kc,s}KsKcKs sCSCI 530, Spring 2010 Copyright © William C. Cheng T13KDC (Cont...)KDCc s{Kc,s}Kc{Kc,s}KsKcKs s {Kc,s}Ks{data}Kc,s CSCI 530, Spring 2010 Copyright © William C. Cheng T14Problem #1can now read all of user’s messages intended for serverHow does user know session key is encrypted for the server? And vice versa?Attacker intercepts initial request, and substitutes own namefor server CSCI 530, Spring 2010 Copyright © William C. Cheng T15Problem #1 (Cont...)KDCc sKcKs s AKa a CSCI 530, Spring 2010 Copyright © William C. Cheng T16Problem #1 (Cont...)KDCc s{Kc,a}Kc{Kc,a}KaKcKs s AKa a CSCI 530, Spring 2010 Copyright © William C. Cheng T17Problem #1 (Cont...)KDCc s{Kc,a}Kc{Kc,a}KaKcKs s {Kc,a}Ka{data}Kc,aAKa a CSCI 530, Spring 2010 Copyright © William C. Cheng T18Solution #1request looks like {c, s}Add names to ticket, credentialsBoth sides can verify intended target for key sharingThis is basic Needham-Schroeder{Kc,s, s}Kc and {Kc,s, c}Ks, respectivelyKDCc{Kc,a, a}Kc{Kc,a, c}KaKc c, s AKa aCSCI 530, Spring 2010 Copyright © William C. Cheng T19Problem #2can now read all traffic between user and serverHow can user and server know that session key is fresh?Attacker intercepts and records old KDC reply, then insertsthis in response to future requestsKDCc{Kc,s}Kc{Kc,s}KsKcA CSCI 530, Spring 2010 Copyright © William C. Cheng T20Problem #2 (Cont...)sKs s CSCI 530, Spring 2010 Copyright © William C. Cheng T21Problem #2 (Cont...)KDCcKcAsKscracking... CSCI 530, Spring 2010 Copyright © William C. Cheng T22Problem #2 (Cont...)KDCcKcAsKs2 months later...Kc,s cracked! CSCI 530, Spring 2010 Copyright © William C. Cheng T23Problem #2 (Cont...)KDCc{Kc,s}Kc{Kc,s}KsKcsKs s A{Kc,s}Kc{Kc,s}Ks s CSCI 530, Spring 2010 Copyright © William C. Cheng T24Problem #2 (Cont...)KDCc sKcKs{Kc,s}Ks{data}Kc,sACSCI 530, Spring 2010 Copyright © William C. Cheng T25Problem #2 (Cont...){Kc,s}Kc{Kc,s}Ks s KDCc sKcKs{Kc,s}Ks{data}Kc,sAeven if the attacker has not cracked Kc,s, simply replayingthe credentials can obtained more ciphertext {data}Kc,s tohelp it crack Kc,s CSCI 530, Spring 2010 Copyright © William C. Cheng T26Solution #2request looks like {c, s, n}Add nonces to ticket, credentials{Kc,s, s, n}Kc and {Kc,s, c, n}KsClient can now check that reply made in response to currentrequestKDCc{Kc,s, n’}Kc{Kc,s, n’}KsKc s, n AKa CSCI 530, Spring 2010 Copyright © William C. Cheng T27Problem #3attacker can spoof IP address and impersonate the clientUser now trusts credentialsBut can server trust user?How can server tell this isn’t a 3rd-party replay?Legitimate user makes electronic payment to attacker;attacker replays message to get paid multiple timesrequires no knowledge of session key CSCI 530, Spring 2010 Copyright © William C. Cheng T28Solution #3server generates second random nonceAdd challenge-responsesends to client, encrypted in session keyclient must decrypt, decrement, encryptEffective, but adds second round of messagesif the attacker does not know the session key, it cannotrespond CSCI 530, Spring 2010 Copyright © William
View Full Document
Unlocking...