CSE 331 Introduction to Networks and Security Lecture

CSE 331: 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. 6 th) • TA will cover projects 3&4 in class Friday, Nov. 8 • Professor Gunter will be giving lectures on Nov. 11 th and 13 th CSE 331 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… CSE 331 Fall 2002 ATM Client Bank Server 3

Recap • Cryptographic Hashes • Digital Signatures • Today: – Protocols – Authentication CSE 331 Fall 2002 4

Protocols: Where We’re Going • • • Overview Entity Authentication Key Establishment SSL Kerberos CSE 331 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 CSE 331 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 CSE 331 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 3 rd party CSE 331 Fall 2002 8

Arbitrated Protocols (Continued) • Real-world examples: – Lawyers, Bankers, Notary Public • Issues: – – – Finding a trusted 3 rd party Additional resources needed for the arbitrator Delay (introduced by arbitration) Arbitrator might become a bottleneck Single point of vulnerability: attack the arbitrator! CSE 331 Fall 2002 9

Adjudicated Protocols Alice Evidence Bart acted fairly. Tom Evidence • Alice and Bard record an audit log • Only in exceptional circumstances to they contact a trusted 3 rd party. (3 rd party is not always needed. ) • Tom as the adjudicator can inspect the evidence and determine whether the protocol was carried out fairly CSE 331 Fall 2002 10

Self-Enforcing Protocols You’re cheating, Alice! Alice Bart • No trusted 3 rd party involved. • Participants can determine whether other parties cheat. • Protocol is constructed so that there are no possible disputes of the outcome. CSE 331 Fall 2002 11

Examples We’ve Seen • Arbitrated Protocol – Shared key digital signature algorithm – Trusted 3 rd party provided authenticity • Adjudicated Protocol – Public key digital signature algorithm – Trusted 3 rd party provided non-repudiation CSE 331 Fall 2002 12

Example: Shared-Key Authentication Alice Bart KAB • Assume Alice & Bart already share a key KAB. – The key might have been decided upon in person or obtained from a trusted 3 rd party. • Alice & Bart now want to communicate over a network, but first wish to authenticate to each other CSE 331 Fall 2002 13

Solution 1: Weak Authentication Alice Bart 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. CSE 331 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 CSE 331 Fall 2002 15

(Flawed) Optimized Version Alice, RA Bart RB, KAB{RA} KAB{RB} KAB • Why not send more information in each message? • This seems like a simple optimization. • But, it’s broken… how? CSE 331 Fall 2002 16

Attack: Marvin can Masquerade as Alice, RA RB, KAB{RA} Bart Alice, RB R’B, 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. CSE 331 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) CSE 331 Fall 2002 18