lecture_7

lecture_7 - Security Protocols CS 136 Computer Security...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Security Protocols CS 136 Computer Security Peter Reiher January 26, 2010 CS 136, Winter 2010 Lecture 7 Page 1 Outline Designing secure protocols Basic protocols Key exchange Common security problems in protocols CS 136, Winter 2010 Lecture 7 Page 2 Basics of Security Protocols Work from the assumption (usually) that your encryption is sufficiently strong Given that, how do you design a message exchange to achieve a given result securely? Not nearly as easy as you probably think CS 136, Winter 2010 Lecture 7 Page 3 Security Protocols A series of steps involving two or more parties designed to accomplish a task with suitable security Sequence is important Cryptographic protocols use cryptography Different protocols assume different levels of trust between participants CS 136, Winter 2010 Lecture 7 Page 4 Types of Security Protocols Arbitrated protocols Involving a trusted third party Adjudicated protocols Trusted third party, after the fact Self-enforcing protocols No trusted third party CS 136, Winter 2010 Lecture 7 Page 5 Participants in Security Protocols Alice Bob CS 136, Winter 2010 Lecture 7 Page 6 And the Bad Guys Eve And sometimes Alice or Bob might cheat Mallory Who only listens passively CS 136, Winter 2010 Who is actively malicious Lecture 7 Page 7 Trusted Arbitrator Trent A disinterested third party trusted by all legitimate participants Arbitrators often simplify protocols, but add overhead CS 136, Winter 2010 Lecture 7 Page 8 Key Exchange Protocols Often we want a different encryption key for each communication session How do we get those keys to the participants? Securely Quickly Even if they've never communicated before CS 136, Winter 2010 Lecture 7 Page 9 Key Exchange With Symmetric Encryption and an Arbitrator Alice and Bob want to talk securely with a new key They both trust Trent Assume Alice & Bob each share a key with Trent How do Alice and Bob get a shared key? CS 136, Winter 2010 Lecture 7 Page 10 Step One KA Alice Alice Requests Session Key for Bob CS 136, Winter 2010 KB Bob Who knows what at this point? KA Trent KB Lecture 7 Page 11 Step Two KA Alice EKA(KS), EKB(KS) EKA(KS), EKB(KS) KA CS 136, Winter 2010 KB Bob Who knows what at this point? Trent KS KB Lecture 7 Page 12 Step Three KS Alice EKA(KS), EKB(KS) KA EKB(KS) KB Bob Who knows what at this point? KA CS 136, Winter 2010 KS Trent KS KB Lecture 7 Page 13 What Has the Protocol Achieved? Alice and Bob both have a new session key The session key was transmitted using keys known only to Alice and Bob Both Alice and Bob know that Trent participated But there are vulnerabilities CS 136, Winter 2010 Lecture 7 Page 14 Problems With the Protocol What if the initial request was grabbed by Mallory? Could he do something bad that ends up causing us problems? Yes! CS 136, Winter 2010 Lecture 7 Page 15 The Man-in-the-Middle Attack A class of attacks where an active attacker interposes himself secretly in a protocol Allowing alteration of the effects of the protocol Without necessarily attacking the encryption CS 136, Winter 2010 Lecture 7 Page 16 Applying the Man-in-the-Middle Attack KA Alice Alice Alice Requests Requests Session Session Key for Key for Mallory Bob CS 136, Winter 2010 KM Mallory KB Bob More precisely, Who knows what do they think what at this they know? point? KB Lecture 7 Page 17 KA Trent KM Trent Does His Job KA Alice EKA(KS), EKM(KS) KM Mallory KB Bob KA CS 136, Winter 2010 Trent KM KB Lecture 7 Page 18 Alice Gets Ready to Talk to Bob EKM(KS) KA Alice KS EKM(KS) KS KM KB Bob Mallory EKM(KS) Mallory can now masquerade as Bob Trent KM KB Lecture 7 Page 19 KA CS 136, Winter 2010 Really Getting in the Middle KA Alice KM KB Bob KS1 EKB(KS1) EKM(KS1), Mallory KS KS KS1 EKB(KS1) Mallory can also ask Trent for a key to talk to Trent KA KB Bob KM CS 136, Winter 2010 Lecture 7 Page 20 Mallory Plays Man-in-theMiddle Mallory KS Alice's big secret KS KS1 EKS(Alice's big secret) Bob's big secret Alice's big secret EKS1(Alice's big secret) EKS(Alice's big secret) EKS1(Bob's big secret()Bob's big secret) EKS1 EKS(Bob's big secret) EKS(Bob's big secret) Alice's big secret Bob's big secret CS 136, Winter 2010 Alice Bob KS1 Bob's big secret Lecture 7 Page 21 Defeating the Man In the Middle Problems: 1). Trent doesn't really know what he's supposed to do 2). Alice doesn't verify he did the right thing Minor changes can fix that 1). Encrypt request with KA 2). Include identity of other participant in response - EKA(KS, Bob) CS 136, Winter 2010 Lecture 7 Page 22 Applying the First Fix KB KA Alice EKA(Alice Requests Session Key for Bob) CS 136, Winter 2010 KM Mallory Bob Mallory can't read the request And Mallory can't forge or alter Alice's request KA Trent KB KM Lecture 7 Page 23 But There's Another Problem A replay attack Replay attacks occur when Mallory copies down a bunch of protocol messages And then plays them again In some cases, this can wreak havoc Why does it here? CS 136, Winter 2010 Lecture 7 Page 24 Step One KA Alice Alice Requests Session Key for Bob CS 136, Winter 2010 Alice Requests Session Key for Bob KB Bob Mallory KA Trent KB Lecture 7 Page 25 Step Two KA Alice EKA(KS), EKB(KS) Alice Requests Session Key for Bob KB EKA(KS), EKB(KS) Bob Mallory KA CS 136, Winter 2010 Trent KS KB Lecture 7 Page 26 Step Three KS Alice EKA(KS), EKB(KS) KA EKB(KS) Alice Requests Session Key for Bob KB EKA(KS), EKB(KS) EKB(KS) KS Bob Mallory KA CS 136, Winter 2010 Trent KS What can Mallory do with his saved messages? KB Lecture 7 Page 27 Mallory Waits for His Opportunity KA Alice Requests Session Key for Bob CS 136, Winter 2010 EKA(KS), EKB(KS) Alice Requests Session Key for Bob KB EKA(KS), EKB(KS) EKB(KS) Mallory KA KB Lecture 7 Page 28 What Will Happen Next? KS KA What's so bad about that? EKB(KS) Alice Requests Session Key for Bob KB EKA(KS), EKB(KS) EKB(KS) KS KS Mallory What if Mallory has cracked KS? KB Lecture 7 Page 29 KA CS 136, Winter 2010 Key Exchange With Public Key Cryptography With no trusted arbitrator Alice sends Bob her public key Bob sends Alice his public key Alice generates a session key and sends it to Bob encrypted with his public key, signed with her private key Bob decrypts Alice's message with his private key Encrypt session with shared session key CS 136, Winter 2010 Lecture 7 Page 30 Basic Key Exchange Using PK KEA , KDA Alice's PK is KDA Bob's PK is KDB EKEA(EKDB(KS)) KEB , KDB Alice KS Bob EKDB(KS) KS Bob verifies the message came from Alice Bob extracts the key from the message CS 136, Winter 2010 Lecture 7 Page 31 Man-in-the-Middle With Public Keys KEA , KDA KEM , KDM KEB , KDB Alice's PK is KDA Alice's PK is KDM Alice Mallory Bob Now Mallory can pose as Alice to Bob CS 136, Winter 2010 Lecture 7 Page 32 And Bob Sends His Public Key KEA , KDA KEM , KDM Bob's PK is KDB KEB , KDB Bob's PK is KDM Alice Mallory Bob Now Mallory can pose as Bob to Alice CS 136, Winter 2010 Lecture 7 Page 33 Alice Chooses a Session Key KEA , KDA EKEA (EKDM(KS)) KS KEM , KDM KEB , KDB EKEM (EKDB(KS)) KS KS Alice Bob Mallory Bob and Alice are sharing a session key Unfortunately, they're also sharing it with Mallory CS 136, Winter 2010 Lecture 7 Page 34 Combined Key Distribution and Authentication Usually the first requires the second Not much good to be sure the key is a secret if you don't know who you're sharing it with How can we achieve both goals? In a single protocol With relatively few messages CS 136, Winter 2010 Lecture 7 Page 35 Needham-Schroeder Key Exchange Uses symmetric cryptography Requires a trusted authority Who takes care of generating the new key More complicated than some protocols we've seen CS 136, Winter 2010 Lecture 7 Page 36 Needham-Schroeder, Step 1 KA RA Alice Bob K Alice,Bob,RA Trent KA K CS 136, Winter 2010 Lecture 7 Page 37 What's the Point of RA? RA is random number chosen by Alice for this invocation of the protocol Not used as a key, so quality of Alice's random number generator not too important Helps defend against replay attacks This kind of random number is sometimes called a nonce CS 136, Winter 2010 Lecture 7 Page 38 Needham-Schroeder, Step 2 KA RA Alice Including RA prevents replay Including Bob prevents attacker from replacing Bob's identity K Bob EKA(RA,Bob,KS, What's all this stuff for? CS 136, Winter 2010 RA K S Trent KA K Including the encrypted message for Bob ensures Bob's message can't be replaced Lecture 7 Page 39 Needham-Schroeder, Step 3 KA K Alice S EKB(K ,Alice) So we're done, right? Wrong! Bob K S K Trent KA K CS 136, Winter 2010 Lecture 7 Page 40 Needham-Schroeder, Step 4 KA K Alice RB S B EKS(R ) K S K Bob RB Trent KA K CS 136, Winter 2010 Lecture 7 Page 41 Needham-Schroeder, Step 5 KA K Alice RB S B EKS(R -1) Now we're done! K S K Bob RB RB-1 Trent KA K CS 136, Winter 2010 Lecture 7 Page 42 What's All This Extra Stuff For? KA Alice Alice knows she's talking to Bob K Bob Trent said she was Can Mallory jump in later? No, only Bob could read the key package Trent created EKA(RA,Bob,KS, S CS 136, Winter 2010 K Trent KA K Lecture 7 Page 43 What's All This Extra Stuff For? KA S EKB(K ,Alice) K Alice Bobrs? K mbe m nu Can Mallory Trent saidrhe was ando hose Bob knows jump in later?out t t ab a he's talking hall later W No, to Alice messages will use KS, which Mallory Trent KA K doesn't know CS 136, Winter 2010 Lecture 7 Page 44 Mallory Causes Problems Alice and Bob do something Mallory likes Mallory watches the messages they send to do so Mallory wants to make them do it again Can Mallory replay the conversation? Let's try it without the random numbers CS 136, Winter 2010 Lecture 7 Page 45 Mallory Waits For His Chance KA Alice EKA(Bob,KS, EKB(K ,Alice) K Mallory Bob Alice,Bob Trent KA K CS 136, Winter 2010 Lecture 7 Page 46 What Will Alice Do Now? The message could only have been created by Trent It properly indicates she wants to talk to Bob It contains a perfectly plausible key Alice will probably go ahead with the protocol CS 136, Winter 2010 Lecture 7 Page 47 The Protocol Continues KA K Alice Mallory steps aside for a bit Trent KA K CS 136, Winter 2010 EKB(K ,Alice) Mallory Bob K S S K With no random keys, we're done Lecture 7 Page 48 So What's the Problem Alice and Bob agree KS is their key They both know the key Trent definitely created the key for them Nobody else has the key But . . . CS 136, Winter 2010 Lecture 7 Page 49 Mallory Steps Back Into the Picture KA S EKS(Old message 2) EKS(Old message 1) K Bob S K Alice Mallory can replay Alice and Bob's old conversation CS 136, Winter 2010 Mallory K Trent KA K It's using the current key, so Alice and Bob will accept it Lecture 7 Page 50 How Do the Random Numbers Help? Alice's random number assures her that the reply from Trent is fresh But why does Bob need another random number? CS 136, Winter 2010 Lecture 7 Page 51 KA Why Bob Also Needs a Random Number EKB(K ,Alice) K Alice Let's say Alice doesn't want to talk to Bob Mallory Bob S K Trent KA K CS 136, Winter 2010 But Mallory wants Bob to think Alice wants to talk Lecture 7 Page 52 So What? EKS(Old message 1) K S Bob Mallory K Mallory can now play back an old message from Alice to Bob And Bob will have no reason to be suspicious Bob's random number exchange assures him that Alice really wanted to talk CS 136, Winter 2010 Lecture 7 Page 53 So, Everything's Fine, Right? Not if any key KS ever gets divulged Once KS is divulged, Mallory can forge Alice's response to Bob's challenge And convince Bob that he's talking to Alice when he's really talking to Mallory CS 136, Winter 2010 Lecture 7 Page 54 Mallory Cracks an Old Key B S EKS B,Alice) EKB(K(R ) EKS(R - 1) K Bob S RB - 1 Mallory enlists 10,000 computers belonging to 10,000 grandmothers to crack KS Unfortunately, Mallory knows KS So Mallory can answer Bob's challenge CS 136, Winter 2010 Lecture 7 Page 55 K Mallory K RB Timestamps in Security Protocols One method of handling this kind of problem is timestamps Proper use of timestamps can limit the time during which an exposed key is dangerous But timestamps have their own problems CS 136, Winter 2010 Lecture 7 Page 56 Using Timestamps in the Needham-Schroeder Protocol The trusted authority includes timestamps in his encrypted messages to Alice and Bob Based on a global clock When Alice or Bob decrypts, if the timestamp is too old, abort the protocol CS 136, Winter 2010 Lecture 7 Page 57 Using Timestamps to Defeat Mallory S EKB(K ,Alice,T ) K S K Mallory TX << Tnow Bob K TX EKB(K ,Alice,T ) Tnow Now Bob checks TX against his clock So Bob, fearing replay, discards KS And Mallory's attack is foiled CS 136, Winter 2010 Lecture 7 Page 58 Problems With Using Timestamps They require a globally synchronized set of clocks Hard to obtain, often Attacks on clocks become important They leave a window of vulnerability Lecture 7 Page 59 CS 136, Winter 2010 The Suppress-Replay Attack Assume two participants in a security protocol Using timestamps to avoid replay problems If the sender's clock is ahead of the receiver's, attacker can intercept message And replay later, when receiver's clock still allows it Lecture 7 Page 60 CS 136, Winter 2010 Handling Clock Problems 1). Rely on clocks that are fairly synchronized and hard to tamper Perhaps GPS signals 2). Make all comparisons against the same clock So no two clocks need to be synchronized CS 136, Winter 2010 Lecture 7 Page 61 What Else Can You Do With Security Protocols? Secret sharing Fair coin flips and other games Simultaneous contract signing Secure elections Lots of other neat stuff Lecture 7 Page 62 CS 136, Winter 2010 ...
View Full Document

This note was uploaded on 02/08/2010 for the course ENGR 111 taught by Professor King during the Spring '09 term at UCLA.

Ask a homework question - tutors are online