View
212
Download
0
Tags:
Embed Size (px)
Citation preview
Security Protocols: They’re so NOT Security Protocols: They’re so NOT Easy!Easy!
Lecture MotivationLecture Motivation
In the last lecture we looked at some high-level descriptions of key distribution and agreement schemes.
These protocols cannot be used as they were stated.
In implementation of the actual protocol, there are many situations one should be careful of.
In this lecture, we will look at some common protocol failures that arise when trying to implement security protocols
We will then look at some specific examples of security protocols
Lecture OutlineLecture Outline
Some stories from the Dark Side…
Design Principles for building security protocols
Key tools for building robust security protocols– Naming
– Encryption
– Signing
– Timestamps and nonces
Examples as we go…– Wide-Mouthed Frog
– Denning-Sacco
– Woo-Lam
– Needham-Schroeder
We’ll end with a look at Kerberos
Tales from the Dark Side of Security…Tales from the Dark Side of Security…
Prepayment in Electricity Meter Systems: – Present a (purchased) digital token to a power meter.– Digital token would convey an ID so it could not be duplicated or
forged…– Problem was that the rate information was not protected
Bank Fraud:– A bank would allow customers to present a bank card which had a
PIN code encrypted and stored on the magnetic strip– Teller had a copy of the encryption key and could check the PINs.– Flaw in design: adversary could alter the account number on the
card to someone else’s, while using his own PIN number… he would check out ok… but the money would be drawn from someone else’s account!
– Flaw in design: PIN number was not connected to account #.
Tales from the Dark Side of Security, pg. 2Tales from the Dark Side of Security, pg. 2
Pay-Per-View TV Hacks:– Decoders are personalized with a smart card. Smart card cannot
decrypt bulk content, so the bulk decryption is done on the decoder.
– Many decoders have a microcontroller which passes messages between the cryptoprocessor and the smart card
– Attackers can go in and modify or replace the microcontroller, or can introduce a PC between the decoder and the card in order to manipulate messages exchanged.
– Kentucky Fried Chip hack: When a customer stops paying subscription, the
system sends a message to the decoder to disable the card.
The KFC hack replaced the microcontroller with a a version that would block this message.
It was able to do this because the system message was sent in the clear!
Caveat Cryptor: Designer Beware!Caveat Cryptor: Designer Beware!
The lesson learned from this last story is: The adversary can be very powerful and clever!
We must assume that the adversary has complete control over the network… – Be paranoid! Alice should not blindly trust what she is getting
from “Bob”! And vice-versa!– If we can build a system that we trust in this Seriously Caustic
environment, then we can trust it in more general (day-to-day) computing scenarios
So, who are the entities?– Alice and Bob may be users, or may be smart cards, or devices– Eve can be the compromised decoder, or the network, or a hacker– When needed, Trent will be a trusted third party server
Security is not easy…Security is not easy…
Building secure systems and protocols is not easy.
In general, its not an easy matter to prove that some protocol is indefinitely secure. – Denning-Sacco protocol took 12 years for a protocol failure to be
exposed
– Needham-Schroeder survived for 17 years before a man-in-the-middle attack was found
Attacks of today must always be considered when building systems– Attacks of tomorrow aren’t known yet…
– That’s the challenge!
What can we do?– Formal verification logics?
– Basic design guidelines?
Basic GuidelinesBasic Guidelines Needham has given several guidelines for building secure systems1. Be clear of security goals and assumptions
2. When using encryption, know why you are using it (secrecy? Authenticity? Binding? PRNG?) . Encryption is not security!
3. Be careful about temporal associations
4. Don’t assume the identity of a participant can be excluded from a message. Generally, it should be explicitly included in a message!
5. Have redundancy in your message!
6. Know the properties and weaknesses of the cryptographic protocols you are using.
7. Signatures do not imply that the signer knows what the message is that he is signing!
8. Don’t trust others to keep their secrets secret!
9. When responding to queries, be careful about encrypting, decrypting, or signing. You might be used as an oracle by an adversary!
10. Decryption is not the same as digital signatures- they have different purposes!
11. Distinguish between different runs of the protocol!
Other ConsiderationsOther Considerations
KISS (Keep It Simple Stupid) is often desirable from an engineering point of view…– Its generally BAD from a security point of view!
– Removing some data fields because they seem like they can be inferred (and thus shorten the message) can result in severe protocol failures!
Formal methods are helpful, but are at still at a young stage of development– For information on formal models, look Kailar’s logic in R.
Kailar, “Reasoning about accountability in protocols for electronic commerce,” 1995 IEEE Symposium on Security and Privacy
Why these rules? How to use them?Why these rules? How to use them?
The previous two slides gave guidelines, but not did not say why we should follow these guidelines.
We are going to look at several examples of protocols that, at first glance, looked OK… but flaws were uncovered later.
These examples will illustrate why we need to be careful, and why these rules are important.
In order to carry out these guidelines, we need some tools, so we will introduce various tools in the process to fix these protocols.
Wide-Mouthed Frog ProtocolWide-Mouthed Frog Protocol
The Wide-Mouthed Frog Protocol is one of the simplest symmetric key management protocols involving a trusted third party (Trent = T)
Alice chooses a session key to communicate with Bob and has Trent transfer it to Bob securely.
The parameter tA is a timestamp supplied by Alice, while tT is given by Trent. Bob will accept KAB as fresh if it arrives in a certain window of time.
The WMF protocol fails because Trent updates the timestamp
If Trent does not keep a list of all recent keys and timestamps, Eve can use Trent as an Oracle!
ABATK
ABBAK
K,ID,tE:BT
K,ID,tE:TA
BT
AT
Failure in the Wide-Mouthed Frog ProtocolFailure in the Wide-Mouthed Frog Protocol
Let’s see how Eve can make Trent act as an Oracle…
1. After seeing one exchange of the protocol, Eve could pretend to be Bob wanting to share a key with Alice
2. Eve would send Trent the replay
3. Trent would send back , where is a new timestamp. Alice would think this is an OK message since it came from Trent.
4. Eve could then pretend to be Alice and get
5. And so on…
Effect: The key KAB is kept indefinitely alive
To fix: You need to be explicitly clear about how you keep track of temporal succession (did you see this key before?)
ABATK K,ID,tEBT
'Tt ABB
'TK K,ID,tE
AT
ABA''TK K,ID,tE
BT
Denning-Sacco Public Key ExchangeDenning-Sacco Public Key Exchange
Distributing public keys is not as simple as announcing public keys… As we saw earlier, certificates help… but its not easy giving out certificates either!
In 1982, Denning and Sacco proposed one of the first public key protocols for distributing shared (symmetric) encryption keys using certificates
The protocol:
Here, we use the symbol to represent Alice’s private key.
First two messages gives Alice the certificates
The third message: Alice sends a key to be shared and a timestamp. The message is encrypted for secrecy and authenticity
ABAKK
BA
K,tEE,CB,CA:BA
CB,CA:AT
ID,ID:TA
1AB
1AK
Failure in Denning-SaccoFailure in Denning-Sacco
A big flaw was found in 1994 by Abadi in the Denning-Sacco protocol
The problem comes down to: In the last message, Bob should have a guarantee that this message was intended for him.
Although it looks like it does (it uses Kb), it does not.
Abadi realized that step 3, Bob can masquerade as Alice, and use this to fool Charles!
Here’s how:
1. Bob gets Charles’ certificate CC.
2. Bob creates a new message 3’ to send to Charles:
Now, Charles will think this message came from Alice and will use KAB as the key. Since Bob knows KAB, Bob can read Charles’ messages!
ABAKK K,tEE,CC,CA:CB 1AC
Failure in Denning-Sacco, pg. 2Failure in Denning-Sacco, pg. 2
What was wrong with Denning-Sacco?
The identities of who message 3 came from and was intended for was not clear.
Thus, the guideline: Names should be explicitly stated in the protocol messages!
A better choice for the third message would have been:
Important Caveat: Make certain you only use this format of the message only once between Alice, Bob, and Trent!– That is, make certain this message cannot be reused later in the protocol,
or in another protocol!
– It is possible to use one protocol against another!
ABABAKK K,t,ID,IDEE,CB,CA:CB 1AC
Woo-Lam Authentication ProtocolWoo-Lam Authentication Protocol
Woo and Lam presented an authentication protocol using symmetric cryptography in which Alice tries to prove her identity to Bob, yet she does not share a key with Bob but instead with Trent
The protocol:
The first step, Alice claims her identity. Step 2: Bob provides a nonce challenge. Step 3: Alice returns this
challenge encrypted using KAT. Step 4: Bob passes this to Trent for translation. Step 5: Trent translates
and returns the nonce. Bob verifies the nonce.
BK
BKAK
BK
B
A
NE:BT
NE,IDE:TB
NE:BA
N:AB
ID:BA
BT
ATBT
AT
Woo-Lam Protocol FailureWoo-Lam Protocol Failure
There is a protocol failure in Woo-Lam that comes from the fact that the connection between Bob-to-Trent’s message and Trent-to-Bob’s message is not strong enough
The only “connection” comes from the fact that message 4 and message 5 happen shortly one after another.
This weak association can be used in an attack where Eve impersonates Alice:
1. Eve tries to authenticate herself to Bob (or Bob’s computer) at about the same time as Alice.
2. Trent will respond to each at roughly the same time.
3. Eve intercepts both responses, and swaps them. Let us see how in a step-by-step description
Woo-Lam Protocol FailureWoo-Lam Protocol Failure
The step-by-step impersonation attack:
BK
''BK
BKEK
BKAK
BK
BK
'B
B
E
A
NE:BT
NE:BT
NE,IDE:TB
NE,IDE:TB
NE:BE
NE:BE
N:EB
N:AB
ID:BE
ID:BE
BT
BT
ETBT
ETBT
ET
ET
Step 1: Eve tells Bob that both Alice and Eve want to establish a connection
Step 2: Bob replies with two challenges. Eve gets one as usual, and intercepts the other!
Step 3: Eve responds to both challenges. Here, Eve can send anything for Alice, but she swaps Alice’s correct response for Eve’s response to send to Bob!
Step 4: Bob contacts Trent with two responses.
Step 5: Trent responds. One is junk. The other is the challenge meant for Alice. Bob gets back the challenge he issued to Alice and then thinks Alice is present (authenticated).
Some fixes to Woo-LamSome fixes to Woo-Lam
The problem was (again) that the last message was not tied to the identity of who it corresponded to.
One simple fix is to make message 5 include Alice’s identity:
So, Trent tells Bob who the response corresponds to. Then, Bob will be able to tell that message 5’ does not correspond to Eve’s nonce!
One problem is that Trent does not know what host that Alice is trying to log onto. Eve might get Alice to log onto Eve’s computer. Then Eve can start a logon in Alice’s name to Bob’s machine. Eve then gets Alice to answer Bob’s challenges to Eve…
The fix:
BAK N,IDE:BTBT
BAK
BBKKA
BBK
B
A
N,IDE:BT
N,IDEE,ID:TB
N,IDE:BA
N:AB
ID:BA
BT
ATBT
AT
Needham-SchroederNeedham-Schroeder
We now look at the Needham-Schroeder authenticated key exchange protocol
The protocol
1NE:BA
NE:AB
K,IDE:BA
K,IDE,K,NID,IDE:AT
N,ID,ID:TA
2K
2K
SAK
SAKS1BAK
1BA
S
S
B
BA
Step 1: Alice tells Trent what she is requestingStep 2: Trent gives Alice the session key and gives Alice a package to deliver to Bob.Step 3: Bob can get the session key, and the identity of who he is talking with (verified because it came from Trent).Step 4: Bob sends Alice a challengeStep 5: Alice answers challenge
An attack on Needham-SchroederAn attack on Needham-Schroeder
In 1981, Denning and Sacco showed if the session key is compromised, then Eve can make Bob think that he is communicating with Alice.
Assume the NS protocol took place, and that Eve has recorded the first 3 steps. Also, assume that Eve has obtained the session key.
The following steps subvert NS:
1NE:BE
NE:AB
K,IDE:BE
3K
3K
SAK
S
S
B
Step 1: Eve replays step 3 from NS as if she were Alice. Step 2: Bob gets this message and issues a challenge to Alice in the form of a new nonce. This challenge is intercepted by Eve.Step 3: Since Eve knows the session key, she can respond correctly to the challenge.
The basic problem: messages can be replayed once the session key is compromised!
Time, Time! Who’s got the Time?Time, Time! Who’s got the Time?
The clock plays an important role in many security protocols. – Time provides an ordering of events
– Time and timestamps help provide measures of freshness to protocols
Having reliable and synchronized clocks is an important challenge in building secure and trusted systems.– We can’t simply use the normal clock time… an enemy may manipulate
the clock, or the clock may fail
Setting the clock back:– Perhaps a user had access to some data in the past, but that access has
expired now. Setting the clock back might allow the user to access data for which his access privileges had expired.
– Expired certificates are fresh again…
– Automated tasks may be forced to repeat by repeatedly setting the clock back after the task is executed
Time, Time! Who’s got the Time? Pg. 2Time, Time! Who’s got the Time? Pg. 2
Stop the time:– An adversary may freeze the clock and thereby cause audit logs to
become ambiguous
– Actions, such as refreshes, no longer happen.
Setting the clock ahead:– Denial of service attacks are possible: Certificates automatically
expire!
– Many situations involve release of confidential information at a specified time in the future… moving the clock ahead forces the release of this information!
– In auction-based systems, if you can alter the auction-system clock forward, you can deny many rivals the opportunity to get last-bids in.
Time, Time! Who’s got the Time? Pg. 3Time, Time! Who’s got the Time? Pg. 3
Many of the fixes for Needham-Schroeder involve the use of timestamps (notably: Denning and Sacco have a timestamped version of NS, and Kerberos is a modification of NS).– Denning and Sacco point out that slow clocks allow for replay attacks
– Gong points out that fast clocks can be used to replay requests (If Alice has a fast clock, and Eve knows it, then Eve can reuse her request at the correct time).
Generally, protocols that rely on synchronized clocks must also be accompanied by protocols that access time servers.– These time protocols cannot rely on synchronized clocks and instead
must use nonces.
Reiter’s time protocol:
Time is accepted if response is quick.
ATK
AA
N,tE:AT
N,ID:TA
AT
KerberosKerberos
Kerberos is a real-world implementation of a symmetric cryptographic protocol that provides authentication and security during key exchange between users in a network.
It is, basically, a real-world implementation of Needham-Schroeder with some appropriate fixes.
Kerberos grew out of MIT’s Project Athena, whose purpose was to integrate a network of computer workstations and allow students to access files easily from anywhere on the network.
Kerberos is based upon a client-server model. Actors:
– Cliff: The Client, wants to use a service– Serge: The service server– Trent: A Trusted Authority (also called an Authentication Server)– Grant: Ticket Granting Server
There are two versions of Kerberos in use (Version 4 and Version 5). We will discuss the basics common to them both.
Overview of KerberosOverview of Kerberos
This slide borrowed from Stallings.
Trent
GrantCliff
Serge
Basic Kerberos StepsBasic Kerberos Steps
The basics of the protocol
1. Cliff to Trent: Request to Trent for help in authenticating with the Ticket Granting Server (Grant)
2. Trent to Cliff: Trent looks Cliff up. If Cliff is OK, Trent generates a session key KCG for use between Cliff and Grant. This is encrypted using KC. Trent also creates a Ticket Granting Ticket (TGT) that will allow Cliff to authenticate himself to Grant
1GrantCliff t,ID,ID
TGT,TTicket
K,t,AD,IDE,IDTGT
KET
CG2CliffCliffKGrant
CGK
G
C
Basic Kerberos Steps, pg. 2Basic Kerberos Steps, pg. 2
The basics of the protocol
3. Cliff to Grant: Using KCG, Cliff can now communicate with Grant. Cliff creates an authenticator message and sends AuthCG as well as TGT to Grant
4. Grant to Cliff: Grant gets AuthCG and TGT. Grant uses his secret key to recover Cliff’s name, etc. Grant uses KCG to decrypt AuthCG to verify authenticity of AuthCG. If the names match, and the timestamps are sufficiently close, then Cliff is valid. Grant creates a service ticket (encrypted with a key Grant shares with Serge). Grant sends ServTicket and encrypted KCS to Cliff
3CliffCliffKCG t,AD,IDEAuthCG
ServTicket,KE
K,ExpTime,t,AD,IDEServTicket
CSK
CS4CliffCliffK
CG
S
Basic Kerberos Steps, pg. 3Basic Kerberos Steps, pg. 3
The basics of the protocol
5. Cliff to Serge: Cliff now contacts Serge to use his services. He gets KCS, which he will use when communicating with Serge.
He creates an authenticator AuthCS.
Cliff sends Serge AuthCS and ServTicket.
Serge can decrypt ServTicket and get KCS.
Using KCS he can decrypt AuthCS and verify Cliff’s identity and the freshness of the authenticator.
6. Serge to Cliff: The service is provided and protected using KCS.
5CliffCliffKCS t,AD,IDEAuthCS
A few last remarks about KerberosA few last remarks about Kerberos
Lifetime of authenticators is a challenge– Too short and you will repeatedly have to enter your password– Too long and the security is weakened… there is a greater opportunity
for replay attacks.
The actual implementation details and exact protocol messages are more involved than was just described
There are differences between V.4 and V.5– Encryption modes (V.4 uses DES, and uses a mode of operation called
Propagating Block Chaining. PCBC is known to have a weakness to interchange attacks. V.5 uses CBC and allows you to specify encryption algorithm.)
– Double encryptions (message 2 and 4) are not necessary– V. 4 strictly is for IP based networks– Many other little differences…
Note: A paper is placed on website describing Kerberos V.4