Transcript CSE331 22

CSE331:
Introduction to Networks
and Security
Lecture 22
Fall 2002
Announcements
• Project 3 is available on the web
– Get started early!
– It’s due 18 Nov.
• Class is cancelled next Wednesday (Nov. 6th)
• TA will cover projects 3&4 in class Friday,
Nov. 8
• Professor Gunter will be giving lectures on
Nov. 11th and 13th
CSE331 Fall 2002
2
Project 3
• Distributed Bank Simulation
– Java Network Programming
– Cryptix Libraries for cryptographic protocols
• Requirements
– Authentication Protocol
– Transaction Protocol
– Audit Logs
• Lab support on its way…
CSE331 Fall 2002
ATM
Client
ATM
Client
Bank
Server
3
Recap
• Cryptographic Hashes
• Digital Signatures
• Today:
– Protocols
– Authentication
CSE331 Fall 2002
4
Protocols: Where We’re Going
•
•
•
•
•
Overview
Entity Authentication
Key Establishment
SSL
Kerberos
CSE331 Fall 2002
5
General Definition of “Protocol”
• A protocol is a multi-party algorithm
– A sequence of steps that precisely specify the
actions required of the parties in order to achieve
a specified objective.
• Important that there are multiple participants
• Typically a situation of heterogeneous trust
– Alice may not trust Bart
– Bart may not trust the network
CSE331 Fall 2002
6
Characteristics of Protocols
• Every participant must know the protocol and
the steps in advance.
• Every participant must agree to follow the
protocol
• Big problem: How to deal with bad
participants?
– 3 basic kinds of protocols
CSE331 Fall 2002
7
Arbitrated Protocols
Tom
Alice
Bart
• Tom is an arbiter
– Disinterested in the outcome (doesn’t play favorites)
– Trusted by the participants
– Trusted 3rd party
CSE331 Fall 2002
8
Arbitrated Protocols (Continued)
• Real-world examples:
– Lawyers, Bankers, Notary Public
• Issues:
–
–
–
–
–
Finding a trusted 3rd party
Additional resources needed for the arbitrator
Delay (introduced by arbitration)
Arbitrator might become a bottleneck
Single point of vulnerability: attack the arbitrator!
CSE331 Fall 2002
9
Adjudicated Protocols
Alice
Evidence
Bart
Bart
acted
fairly.
Tom
Evidence
• Alice and Bard record an audit log
• Only in exceptional circumstances to they contact a
trusted 3rd party. (3rd party is not always needed.)
• Tom as the adjudicator can inspect the evidence and
determine whether the protocol was carried out fairly
CSE331 Fall 2002
10
Self-Enforcing Protocols
You’re
cheating,
Alice!
Alice
Bart
• No trusted 3rd party involved.
• Participants can determine whether other
parties cheat.
• Protocol is constructed so that there are no
possible disputes of the outcome.
CSE331 Fall 2002
11
Examples We’ve Seen
• Arbitrated Protocol
– Shared key digital signature algorithm
– Trusted 3rd party provided authenticity
• Adjudicated Protocol
– Public key digital signature algorithm
– Trusted 3rd party provided non-repudiation
CSE331 Fall 2002
12
Example: Shared-Key Authentication
Alice
Bart
KAB
KAB
• Assume Alice & Bart already share a key KAB.
– The key might have been decided upon in person
or obtained from a trusted 3rd party.
• Alice & Bart now want to communicate over a
network, but first wish to authenticate to each
other
CSE331 Fall 2002
13
Solution 1: Weak Authentication
Alice
Bart
KAB
KAB
KAB
• Alice sends Bart KAB.
– KAB acts as a password.
• The secret (key) is revealed to passive
observers.
• Only works one-way.
– Alice doesn’t know she’s talking to Bart.
CSE331 Fall 2002
14
Solution 2: Strong Authentication
Alice
I’m Alice
Bart
Challenge: Encrypt RB
Response: KAB{RB}
Challenge: Encrypt RA
KAB
Response: KAB{RA}
KAB
• Protocol doesn’t reveal the secret.
• Challenge/Response
– Bart requests proof that Alice knows the secret
– Alice requires proof from Bart
– RA and RB are randomly generated numbers
CSE331 Fall 2002
15
(Flawed) Optimized Version
Alice
Alice, RA
Bart
RB, KAB{RA}
KAB{RB}
KAB
KAB
• Why not send more information in each
message?
• This seems like a simple optimization.
• But, it’s broken… how?
CSE331 Fall 2002
16
Attack: Marvin can Masquerade as Alice
Alice, RA
RB, KAB{RA}
Bart
Alice, RB
R’B, KAB{RB}
KAB{RB}
KAB
• Marvin pretends to take the role of Alice in
two runs of the protocol.
– Tricks Bart into doing Alice’s part of the challenge!
– Interleaves two instances of the same protocol.
CSE331 Fall 2002
17
Lessons
• Protocol design is tricky and subtle
– “Optimizations” aren’t necessarily good
• Need to worry about:
– Multiple instances of the same protocol running in
parallel
– Intruders that play by the rules, mostly
• General principle:
– Don’t do anything more than necessary until
confidence is built.
– Initiator should prove identity before responder
takes action (like encryption)
CSE331 Fall 2002
18