Authenticity by Typing for Security Protocols - Lecture Slides | CMSC 838, Study notes of Computer Science

Download Authenticity by Typing for Security Protocols - Lecture Slides | CMSC 838 and more Study notes Computer Science in PDF only on Docsity! Authenticity by Typing for Security Protocols Presented for CMSC838z by Saurabh Srivastava Andrew D. Gordon Microsoft Research Alan Jeffrey DePaul University The way we (used to?) make protocols:  Specify the toplevel functional requirements:  data transfer --> ftp  distributed data transfer --> bittorrent (!!)  medium access --> 802.x  authentication --> Needham-Schroeder, Otway-Ree’s etc.  Specifications drawn up directly from functional requirements.  State machine diagrams as a side note.  Proof of correctness was ad hoc  Errors !  Security protocols are especially tricky. Jump to the last page…  Needham Schroeder ‘type-checked’:  Modified Needham Schroeder: $ java -jar ../../cryptyc.jar ns.cry Error, rooted at line 134: In end-statement: Can't guarantee that a correspondence has begun. Required correspondence: begun(providing session key kab to b for a) Available correspondences: None [poseidon]$ java -jar ../../cryptyc.jar ns-modified.cry Type checked OK! The overall view Top level specifications Spi-calculus representation Spi-calculus enriched with correspondence assertions Type annotations for keys, nonces and msgs Ok? Type checker Working code Automated? FSM? new! old Spi Calculus - by example A B{M}k Public channel = net out net {M}k; inp net ctext; new M; decrypt ctext is {M}k; repeat repeat new k; (A|B) Names and Msgs: • name: x • pair: (M,N) • empty: () • tagged union Processes: • out M N • inp M (x:T);P • P | Q • others… Safety and Robust safety  Safety:  P is safe <=> each end L has a corresponding begin L  Opponents: Arbitrary processes.  Untyped  Cannot assert events  Robust safety:  P is safe <=> (P|O) is safe for any arbitrary O. Note:  Might seen vacuous but in fact is not  Consider the opponent who does a replay attack: inp net msg; out net msg; out net msg; Example out net {M}k; inp net ctext; new M; decrypt ctext is {M}k; repeat repeat new k; (A|B) begin M; end M; • Allows us to correlate across processes • Opponent whichs breaks this: inp net ctext; out net ctext; out net ctext • Therefore safe but not robustly safe. A B{M}k • Solution: Add nonce! • Now robustly safe! • But need to check that: • Type system!!! B ends MEvent 2: A->B: {M,n}kMessage 2: B->A: nMessage 1: A begins MEvent 1: Outline - status check Top level specifications Spi-calculus representation Spi-calculus enriched with correspondence assertions Type annotations for keys, nonces and msgs Ok? Type checker Here An example  P = begin m; cast n is (n’:Nonce [end m]); out c n’  Q = inp c (x:Nonce [end m]); check n is x; end m  R = new (n:Un); (P|Q) typechecks?  Scenario:  n is a nonce that is somehow already shared between the processes. n:Un  c is a private channel (so can have type other than Ch(Un)) - so that we do not have to bother about encryption and decryption of the nonce  Specifically it has type Ch(Nonce [end m]) An example  Rules (informally):  If N:Un and P:ef cast N is (x:Nonce es);P: (es+ef)  If N:Un and and N’:Nonce es and Q:ef check N is N’;Q: ((ef - es) + [check N])  If P:ef new (N);P : (ef-[check N]) Brown: types Blue: Effects - end/check Green: Data Red: Processes  P = begin m; cast n is (n’:Nonce [end m]); out c n’  Q = inp c (x:Nonce [end m]); check n is x; end m  R = new (n:Un); (P|Q) [end m] [check n] [end m] [] P: [] Q: [check n] R: [check n]-[check n] = [] Post mortem analysis!  Notice what happened.  Cast:  The cast ‘encapsulated’ all the begins into the effect that nonce ‘carried’  Since a cast is the only way that a nonce type can be created => nonces will always carry effects to other processes  Check:  A check causes the reverse at the receiver process  In addition it adds to the effect multiset an effect which ensures that one and only one new matches the check. (single use of nonces) begin a; begin b; …. cast ___ es check ___ es …. end a; end b; Conceptually: Summary  Provides a way of validating the ‘model’ that will be implemented.  Uses correspondence assertions to verify `control flow’ (Lam and Woo)  Major contribution is the successful typing of nonce handshakes. Nonce handshakes allow processes to sync.  Forms the basis of verifying correctness of public key based protocols Criticism  Model does not handle timestamp based protocols. Although it does not seem hard to incorporate.  It is programming of the protocol! And that too with hard restrictions on the types.  Prone to error? - but probably less than manual spec.