Security Protocols CS 136 Computer Security Peter Reiher October 16, 2012 - PowerPoint PPT Presentation


Title: Security Protocols CS 136 Computer Security Peter Reiher October 16, 2012


1
Security ProtocolsCS 136Computer Security
Peter ReiherOctober 16, 2012
2
Outline
  • Designing secure protocols
  • Key exchange protocols
  • Common security problems in protocols

3
Basics of Security Protocols
  • Assume (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
  • Many of the concepts are important in many areas
    of computer/network security

4
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

5
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

6
Participants in Security Protocols

7
And the Bad Guys

And sometimes Alice or Bob might cheat
Who only listens passively
Who is actively malicious
8
Trusted Arbitrator

A disinterested third party trusted by all
legitimate participants
Arbitrators often simplify protocols, but add
overhead
9
Goals of Security Protocols
  • Each protocol is intended to achieve some very
    particular goal
  • Like setting up a key between two parties
  • Protocols may only be suitable for that
    particular purpose
  • Important secondary goal is minimalism
  • Fewest possible messages
  • Least possible data
  • Least possible encryption

10
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 theyve never communicated before

11
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?

12
Step One

Alice
Bob
Alice Requests Session Key for Bob
Who knows what at this point?
Trent
13
Step Two

Alice
Bob
EKA(KS), EKB(KS)
Who knows what at this point?
EKA(KS), EKB(KS)
Trent
KS
14
Step Three
KS
KS

Alice
Bob
EKA(KS), EKB(KS)
Who knows what at this point?
Trent
KS
15
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

16
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!

17
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

18
Applying the Man-in-the-Middle Attack

Alice
Bob
More precisely, what do they think they know?
Alice Requests Session Key for Mallory
Who knows what at this point?
Alice Requests Session Key for Bob
Trent
19
Trent Does His Job

Alice
Bob
EKA(KS), EKM(KS)
Trent
20
Alice Gets Ready to Talk to Bob
KS

Alice
Bob
KS
EKM(KS)
Mallory can now masquerade as Bob
EKM(KS)
Trent
21
Really Getting in the Middle

Alice
KS1
Bob
KS
EKM(KS1), EKB(KS1)
KS
EKB(KS1)
KS1
Mallory can also ask Trent for a key to talk to
Bob
Trent
22
Mallory Plays Man-in-the-Middle

Alice
KS1
Bob
KS
KS
Alices big secret
KS1
EKS(Alices big secret)
Bobs big secret
Alices big secret
EKS1(Alices big secret)
EKS1(Bobs big secret)
EKS(Alices big secret)
EKS1(Bobs big secret)
EKS(Bobs big secret)
EKS(Bobs big secret)
Alices big secret
Bobs big secret
Bobs big secret
23
Defeating the Man In the Middle
  • Problems
  • 1). Trent doesnt really know what hes supposed
    to do
  • 2). Alice doesnt 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)

24
Applying the First Fix
KB

Alice
Bob
Mallory cant read the request
EKA(Alice Requests Session Key for Bob)
And Mallory cant forge or alter Alices request
Trent
KB
25
But Theres 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?

26
Step One

Alice
EKA(Alice Requests Session Key for Bob)
Bob
EKA(Alice Requests Session Key for Bob)
Trent
27
Step Two

Alice
EKA(Alice Requests Session Key for Bob)
Bob
EKA(KS), EKB(KS)
EKA(KS), EKB(KS)
Trent
KS
28
Step Three
KS
KS

Alice
EKA(Alice Requests Session Key for Bob)
Bob
EKA(KS), EKB(KS)
EKA(KS), EKB(KS)
EKB(KS)
What can Mallory do with his saved messages?
Trent
KS
29
Mallory Waits for His Opportunity

EKA(Alice Requests Session Key for Bob)
EKA(KS), EKB(KS)
EKA(Alice Requests Session Key for Bob)
EKB(KS)
30
What Will Happen Next?
KS
KS

EKA(Alice Requests Session Key for Bob)
KS
EKA(KS), EKB(KS)
Whats so bad about that?
EKB(KS)
What if Mallory has cracked KS?
31
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 Alices message with his private key
  • Encrypt session with shared session key

32
Basic Key Exchange Using PK

KEA , KDA
KEB , KDB
Bob
Alice
EKDB(KS)
KS
KS
Bob verifies the message came from Alice
Bob extracts the key from the message
33
Man-in-the-Middle With Public Keys

KEA , KDA
KEM , KDM
KEB , KDB
Alice
Bob
Now Mallory can pose as Alice to Bob
34
And Bob Sends His Public Key

KEA , KDA
KEM , KDM
KEB , KDB
Alice
Bob
Now Mallory can pose as Bob to Alice
35
Alice Chooses a Session Key

KEA , KDA
KEM , KDM
KEB , KDB
KS
KS
Alice
Bob
KS
Bob and Alice are sharing a session key
Unfortunately, theyre also sharing it with
Mallory
36
Combined Key Distribution and Authentication
  • Usually the first requires the second
  • Not much good to be sure the key is a secret if
    you dont know who youre sharing it with
  • How can we achieve both goals?
  • In a single protocol
  • With relatively few messages

37
Needham-Schroeder Key Exchange
  • Uses symmetric cryptography
  • Requires a trusted authority
  • Who takes care of generating the new key
  • More complicated than some protocols weve seen

38
Needham-Schroeder, Step 1
KA
KB

RA
Alice
Bob
Trent
KA
KB
39
Whats 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 Alices random
    number generator not too important
  • Helps defend against replay attacks
  • This kind of random number is sometimes called a
    nonce

40
Needham-Schroeder, Step 2
KA
KB

RA
Alice
Bob
Trent
RA
KS
KA
KB
41
Needham-Schroeder, Step 3
KA
KB

KS
Alice
Bob
So were done, right?
KS
Wrong!
Trent
KA
KB
42
Needham-Schroeder, Step 4
KB
KA

KS
KS
Alice
Bob
RB
RB
Trent
KA
KB
43
Needham-Schroeder, Step 5
KB
KA

KS
KS
Alice
Bob
RB
RB
Now were done!
RB-1
Trent
KA
KB
44
Whats All This Extra Stuff For?
KA
KB

Alice
Bob
Can Mallory jump in later?
Trent
KS
KA
KB
45
Whats All This Extra Stuff For?
KA
KB

KS
Alice
Bob
Can Mallory jump in later?
What about those random numbers?
No, all later messages will use KS, which Mallory
doesnt know
Trent
KA
KB
46
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?
  • Lets try it without the random numbers

47
Mallory Waits For His Chance
KB
KA

Alice
Bob
Mallory
Trent
KA
KB
48
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

49
The Protocol Continues
KB
KA

KS
KS
Alice
Bob
Mallory steps aside for a bit
With no nonces, were done
Trent
KA
KB
50
So Whats 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 . . .

51
Mallory Steps Back Into the Picture
KB
KA

KS
KS
Alice
Bob
Mallory can replay Alice and Bobs old
conversation
Its using the current key, so Alice and Bob will
accept it
Trent
KA
KB
52
How Do the Random Numbers Help?
  • Alices random number assures her that the reply
    from Trent is fresh
  • But why does Bob need another random number?

53
Why Bob Also Needs a Random Number
KB
KA

KS
Alice
Bob
Lets say Alice doesnt want to talk to Bob
But Mallory wants Bob to think Alice wants to
talk
Trent
KA
KB
54
So What?
KB

KS
Bob
Mallory can now play back an old message from
Alice to Bob
And Bob will have no reason to be suspicious
Bobs random number exchange assures him that
Alice really wanted to talk
55
So, Everythings Fine, Right?
  • Not if any key KS ever gets divulged
  • Once KS is divulged, Mallory can forge Alices
    response to Bobs challenge
  • And convince Bob that hes talking to Alice when
    hes really talking to Mallory

56
Mallory Cracks an Old Key

KB
KS
RB
KS
Bob
RB - 1
Mallory compromises 10,000 computers belonging to
10,000 grandmothers to crack KS
Unfortunately, Mallory knows KS
So Mallory can answer Bobs challenge
57
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

58
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

59
Using Timestamps to Defeat Mallory
KB

KS
KS
Bob
TX
TX ltlt Tnow
EKB(KS,Alice,TX)
Tnow
Now Bob checks TX against his clock
So Bob, fearing replay, discards KS
And Mallorys attack is foiled
60
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

61
The Suppress-Replay Attack
  • Assume two participants in a security protocol
  • Using timestamps to avoid replay problems
  • If the senders clock is ahead of the receivers,
    attacker can intercept message
  • And replay later, when receivers clock still
    allows it

62
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

63
Is This Overkill?
  • Some of these attacks are pretty specialized
  • Requiring special access or information
  • Some can only achieve certain limited effects
  • Do we really care?

64
Why Should We Care?
  • Bad guys are very clever
  • Apparently irrelevant vulnerabilities give them
    room to show that
  • Changes in how you use protocols can make
    vulnerabilities more relevant
  • A protocol without a vulnerability is always
    better
  • Even if you currently dont care

65
Something to Bear in Mind
  • These vulnerabilities arent specific to just
    these protocols
  • They are common and pop up all over
  • Even in cases where you arent thinking about a
    protocol
  • Important to understand them at a high conceptual
    level
View by Category
About This Presentation
Title:

Security Protocols CS 136 Computer Security Peter Reiher October 16, 2012

Description:

Security Protocols CS 136 Computer Security Peter Reiher October 16, 2012 – PowerPoint PPT presentation

Number of Views:100
Avg rating:3.0/5.0
Slides: 66
Provided by: PeterR230
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Security Protocols CS 136 Computer Security Peter Reiher October 16, 2012


1
Security ProtocolsCS 136Computer Security
Peter ReiherOctober 16, 2012
2
Outline
  • Designing secure protocols
  • Key exchange protocols
  • Common security problems in protocols

3
Basics of Security Protocols
  • Assume (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
  • Many of the concepts are important in many areas
    of computer/network security

4
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

5
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

6
Participants in Security Protocols

7
And the Bad Guys

And sometimes Alice or Bob might cheat
Who only listens passively
Who is actively malicious
8
Trusted Arbitrator

A disinterested third party trusted by all
legitimate participants
Arbitrators often simplify protocols, but add
overhead
9
Goals of Security Protocols
  • Each protocol is intended to achieve some very
    particular goal
  • Like setting up a key between two parties
  • Protocols may only be suitable for that
    particular purpose
  • Important secondary goal is minimalism
  • Fewest possible messages
  • Least possible data
  • Least possible encryption

10
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 theyve never communicated before

11
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?

12
Step One

Alice
Bob
Alice Requests Session Key for Bob
Who knows what at this point?
Trent
13
Step Two

Alice
Bob
EKA(KS), EKB(KS)
Who knows what at this point?
EKA(KS), EKB(KS)
Trent
KS
14
Step Three
KS
KS

Alice
Bob
EKA(KS), EKB(KS)
Who knows what at this point?
Trent
KS
15
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

16
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!

17
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

18
Applying the Man-in-the-Middle Attack

Alice
Bob
More precisely, what do they think they know?
Alice Requests Session Key for Mallory
Who knows what at this point?
Alice Requests Session Key for Bob
Trent
19
Trent Does His Job

Alice
Bob
EKA(KS), EKM(KS)
Trent
20
Alice Gets Ready to Talk to Bob
KS

Alice
Bob
KS
EKM(KS)
Mallory can now masquerade as Bob
EKM(KS)
Trent
21
Really Getting in the Middle

Alice
KS1
Bob
KS
EKM(KS1), EKB(KS1)
KS
EKB(KS1)
KS1
Mallory can also ask Trent for a key to talk to
Bob
Trent
22
Mallory Plays Man-in-the-Middle

Alice
KS1
Bob
KS
KS
Alices big secret
KS1
EKS(Alices big secret)
Bobs big secret
Alices big secret
EKS1(Alices big secret)
EKS1(Bobs big secret)
EKS(Alices big secret)
EKS1(Bobs big secret)
EKS(Bobs big secret)
EKS(Bobs big secret)
Alices big secret
Bobs big secret
Bobs big secret
23
Defeating the Man In the Middle
  • Problems
  • 1). Trent doesnt really know what hes supposed
    to do
  • 2). Alice doesnt 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)

24
Applying the First Fix
KB

Alice
Bob
Mallory cant read the request
EKA(Alice Requests Session Key for Bob)
And Mallory cant forge or alter Alices request
Trent
KB
25
But Theres 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?

26
Step One

Alice
EKA(Alice Requests Session Key for Bob)
Bob
EKA(Alice Requests Session Key for Bob)
Trent
27
Step Two

Alice
EKA(Alice Requests Session Key for Bob)
Bob
EKA(KS), EKB(KS)
EKA(KS), EKB(KS)
Trent
KS
28
Step Three
KS
KS

Alice
EKA(Alice Requests Session Key for Bob)
Bob
EKA(KS), EKB(KS)
EKA(KS), EKB(KS)
EKB(KS)
What can Mallory do with his saved messages?
Trent
KS
29
Mallory Waits for His Opportunity

EKA(Alice Requests Session Key for Bob)
EKA(KS), EKB(KS)
EKA(Alice Requests Session Key for Bob)
EKB(KS)
30
What Will Happen Next?
KS
KS

EKA(Alice Requests Session Key for Bob)
KS
EKA(KS), EKB(KS)
Whats so bad about that?
EKB(KS)
What if Mallory has cracked KS?
31
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 Alices message with his private key
  • Encrypt session with shared session key

32
Basic Key Exchange Using PK

KEA , KDA
KEB , KDB
Bob
Alice
EKDB(KS)
KS
KS
Bob verifies the message came from Alice
Bob extracts the key from the message
33
Man-in-the-Middle With Public Keys

KEA , KDA
KEM , KDM
KEB , KDB
Alice
Bob
Now Mallory can pose as Alice to Bob
34
And Bob Sends His Public Key

KEA , KDA
KEM , KDM
KEB , KDB
Alice
Bob
Now Mallory can pose as Bob to Alice
35
Alice Chooses a Session Key

KEA , KDA
KEM , KDM
KEB , KDB
KS
KS
Alice
Bob
KS
Bob and Alice are sharing a session key
Unfortunately, theyre also sharing it with
Mallory
36
Combined Key Distribution and Authentication
  • Usually the first requires the second
  • Not much good to be sure the key is a secret if
    you dont know who youre sharing it with
  • How can we achieve both goals?
  • In a single protocol
  • With relatively few messages

37
Needham-Schroeder Key Exchange
  • Uses symmetric cryptography
  • Requires a trusted authority
  • Who takes care of generating the new key
  • More complicated than some protocols weve seen

38
Needham-Schroeder, Step 1
KA
KB

RA
Alice
Bob
Trent
KA
KB
39
Whats 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 Alices random
    number generator not too important
  • Helps defend against replay attacks
  • This kind of random number is sometimes called a
    nonce

40
Needham-Schroeder, Step 2
KA
KB

RA
Alice
Bob
Trent
RA
KS
KA
KB
41
Needham-Schroeder, Step 3
KA
KB

KS
Alice
Bob
So were done, right?
KS
Wrong!
Trent
KA
KB
42
Needham-Schroeder, Step 4
KB
KA

KS
KS
Alice
Bob
RB
RB
Trent
KA
KB
43
Needham-Schroeder, Step 5
KB
KA

KS
KS
Alice
Bob
RB
RB
Now were done!
RB-1
Trent
KA
KB
44
Whats All This Extra Stuff For?
KA
KB

Alice
Bob
Can Mallory jump in later?
Trent
KS
KA
KB
45
Whats All This Extra Stuff For?
KA
KB

KS
Alice
Bob
Can Mallory jump in later?
What about those random numbers?
No, all later messages will use KS, which Mallory
doesnt know
Trent
KA
KB
46
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?
  • Lets try it without the random numbers

47
Mallory Waits For His Chance
KB
KA

Alice
Bob
Mallory
Trent
KA
KB
48
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

49
The Protocol Continues
KB
KA

KS
KS
Alice
Bob
Mallory steps aside for a bit
With no nonces, were done
Trent
KA
KB
50
So Whats 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 . . .

51
Mallory Steps Back Into the Picture
KB
KA

KS
KS
Alice
Bob
Mallory can replay Alice and Bobs old
conversation
Its using the current key, so Alice and Bob will
accept it
Trent
KA
KB
52
How Do the Random Numbers Help?
  • Alices random number assures her that the reply
    from Trent is fresh
  • But why does Bob need another random number?

53
Why Bob Also Needs a Random Number
KB
KA

KS
Alice
Bob
Lets say Alice doesnt want to talk to Bob
But Mallory wants Bob to think Alice wants to
talk
Trent
KA
KB
54
So What?
KB

KS
Bob
Mallory can now play back an old message from
Alice to Bob
And Bob will have no reason to be suspicious
Bobs random number exchange assures him that
Alice really wanted to talk
55
So, Everythings Fine, Right?
  • Not if any key KS ever gets divulged
  • Once KS is divulged, Mallory can forge Alices
    response to Bobs challenge
  • And convince Bob that hes talking to Alice when
    hes really talking to Mallory

56
Mallory Cracks an Old Key

KB
KS
RB
KS
Bob
RB - 1
Mallory compromises 10,000 computers belonging to
10,000 grandmothers to crack KS
Unfortunately, Mallory knows KS
So Mallory can answer Bobs challenge
57
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

58
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

59
Using Timestamps to Defeat Mallory
KB

KS
KS
Bob
TX
TX ltlt Tnow
EKB(KS,Alice,TX)
Tnow
Now Bob checks TX against his clock
So Bob, fearing replay, discards KS
And Mallorys attack is foiled
60
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

61
The Suppress-Replay Attack
  • Assume two participants in a security protocol
  • Using timestamps to avoid replay problems
  • If the senders clock is ahead of the receivers,
    attacker can intercept message
  • And replay later, when receivers clock still
    allows it

62
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

63
Is This Overkill?
  • Some of these attacks are pretty specialized
  • Requiring special access or information
  • Some can only achieve certain limited effects
  • Do we really care?

64
Why Should We Care?
  • Bad guys are very clever
  • Apparently irrelevant vulnerabilities give them
    room to show that
  • Changes in how you use protocols can make
    vulnerabilities more relevant
  • A protocol without a vulnerability is always
    better
  • Even if you currently dont care

65
Something to Bear in Mind
  • These vulnerabilities arent specific to just
    these protocols
  • They are common and pop up all over
  • Even in cases where you arent thinking about a
    protocol
  • Important to understand them at a high conceptual
    level
About PowerShow.com