1 / 21

Case Study: Using PVS to Analyze Security Protocols

Case Study: Using PVS to Analyze Security Protocols. Kyle Taylor. Overview. Using PVS: Specify Communication Specify Encryption Specify Intruder Specify Protocol Analyze Results. What is PVS. General Prototype Verification System Inductive Theorem Prover

mieko
Download Presentation

Case Study: Using PVS to Analyze Security Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Case Study: Using PVS to Analyze Security Protocols Kyle Taylor

  2. Overview • Using PVS: • Specify Communication • Specify Encryption • Specify Intruder • Specify Protocol • Analyze Results

  3. What is PVS • General • Prototype Verification System • Inductive Theorem Prover • Augments classical higher-order logic with an advanced type system • Implemented in Common Lisp • Based upon 20 years of experience • Emacs Interface

  4. What is PVS Cont. • Intended for the formalization of requirements and high level design • Functional Specification Language • Haskell, Lisp, ML • PVS consists of • Specification language • Predefined theories • Proof Checker

  5. PVS Specification Language • Type checking is undecidable because of constrained types • Generates proof obligations for the theorem prover • Assumptions • Definitions • Axioms • Conjectures • Theorems • Lemmas

  6. PVS Proof Checker • Provides a collection of powerful primitive inference procedures • Propositional and quantified rules • Induction • Rewriting • Decision procedures for linear arithmatic • Requires Interactive proving • Contains automated proof strategies

  7. PVS and Security • PVS does not have built in security or communication primitives • The primitives need to be defined when a specification is developed • Luckily the definitions of the security primitives can be reused

  8. Communication and Encryption • Messages are defined as a function • Said(Sender: P, Receiver: P, Fields: F) • Fields are constructed by type coercion • Agent(Principle: P): F • Num(num: nat): F • Pkey(pkey: K): F • Con(field: F, field: F): F • Ped(pkey: K, field: F): F

  9. Communication and Encryption Cont • Encryption • Pub(principle: P): K • Priv(principle: P): K • Invkey(key: K): K • Axiom • Invkey(pub(A))=priv(A)

  10. Specifying Security • Parts(S) • All sub fields of a set S • Analz(S) • All sub fields of a set S that is accessible to an attacker • Synth(S) • The set of fields that is constructible for S • Secret() • Basic secrets • Initial() • Initial attacker knowledge

  11. Specifying a Protocol • Each protocol step is a function • The function accepts a Message and a Trace • The function returns a bool • The function constrains the Message and the Trace

  12. Specifying an Intruder • Done with a function • The function accepts a Message, a Trace, and a set of initial knowledge • The function returns a bool • Constructs messages from a set of initial knowledge and the set of derivable knowledge present in a trace • Constructed message is from the intruder

  13. ffgg Protocol • AB: A • BA: B, N1, N2 • AB: A, {N1, N2, M}PKB % {N1, X, Y}PKB • BA: N1, X, {X, Y, N1}PKB

  14. Ffgg Attack • AB: A • (A)B’: A % masquerade • B(A): N1, N2 • B’(A): N’1, N’2 • (B)A: N1, N’1 • AB: {N1, N’1, M}PKB • B(A):N1, N’1, {N’1, M, N1}PKB • (A)B’: {N’1, M, N1}PKB • B’(A): N’1, M, {M, N1, N’1}PKB

  15. ffgg Specification a1(E,H): bool= EXISTS (A, B): A /= B AND E = Said(A, B, Con(Num(1), Agent(A)))

  16. ffgg Specification Cont ffgg(Q: trace): RECURSIVE bool= CASES Q OF cons(E, H): ffgg(H) AND (Fake(E, H, initial) OR a1(E, H) OR b2(E, H) OR a3(E, H) OR b4(E, H)), null: TRUE ENDCASES MEASURE length

  17. ffgg Results • PVS derived a case enumerating a trace of the attack that the user would have to prove

  18. Discussion • Lessons Learned • Learning PVS is not trivial • Specification and prover are not intuitive • Theorem proving has the ability to be very useful • Security is tricky • Limitations • Amount of background required of the user • Amount of training time required • Ambiguity of specification

  19. Future Work • Develop a theorem prover that is specifically designed for Security protocols (Athena?) • Provide a less powerful specification language to increase simplicity • Provide better separation of modules

  20. Conclusion • 6 month estimate to learn PVS is very optimistic • One on one training with a PVS guru is a must • Limited use due to ambiguity of specifications

  21. References • Millen, “A Necessarily Parallel Attack”, FMSP ‘99, http://www.csl.sri.com/users/millen/capsl/ • Crow, Owre, Rushby, Shankar, Srivas, “A Tutorial Introduction to PVS” WIFT ’95, http://pvs.csl.sri.com/ • Butler, “An elementary tutorial on formal specification and verification using PVS”, http://pvs.csl.sri.com/ • Owre, Shankar, Rushby, “The PVS Specification Language”, http://pvs.csl.sri.com/ • Owre, Shankar, Rushby, “Users Guide for the PVS Specification and Verification System”, http://pvs.csl.sri.com/

More Related