Universally Composable Symbolic Analysis of Key-Exchange Protocols

1. Universally Composable Symbolic Analysis of Key-Exchange Protocols Jonathan Herzog (Joint work with Ran Canetti) 21 September 2004 The author's affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed by the author. If captured, MITRE will disavow any knowledge of your activities. Void where prohibited by law. No warrantee expressed or implied.

2. Introduction • This talk: symbolic (Dolev-Yao) analysis can guarantee concrete (Universally Composable) security • UC security: strongest known definition of security in computational model • Therefore: automated formal analysis as strong as strongest concrete, hand-crafted proof • Previous work: AR, MW, BPW, Gergi, others • Computational soundness for Dolev-Yao assumptions • Only relates proof-steps of formal analysis to proof-steps of computational analysis • Are the two models trying to prove the same goal?

3. Our Results • Same security goals? Yes and no. • Mutual authentication: Yes • DY-MA, UC-MA achieved by same protocols • UC analog to MW04 • Last mention of mutual authentication • All interesting details in KE case, anyway • Key-Exchange (KE): No • DY-KE is strictly weaker than UC-KE • Why? DY notion of secrecy weaker than UC notion • DY-KE and UC-KE equivalent, however, under “real-or-random” notion of secrecy

4. Universally composable security • Strongest known computational definition of security [C, BPW] • Definition phrased in terms of single execution • Implies secure even when composed with • Arbitrary peer protocols • Arbitrary sub-protocols • Arbitrary higher-level protocols • Currently requires “hand-crafted” proofs • Our goal: prove security in Dolev-Yao model instead • Show DY-KE equivalent to UC-KE

5. Analysis strategy Symbolic single- instance protocol Satisfies DY-KE Single-instance Setting Securely realizes UC-KE (UC crypto) UC theorem Simplify Ideal cryptography Security for multiple instances UC w/ joint state Concrete protocol UC-KE using actual crypto

6. Overview of talk • First half: overview of UC security • (Familiarity with Dolev-Yao model assumed) • Second half: • Relating Dolev-Yao and UC models • Key-exchange

7. P P A Computational protocols • Computational protocol: • Each message a bit-string • Each participant an efficient Turing machine • Take inputs, produce outputs • Adversary (also Turing machine) controls network • Two questions: • What is a protocol supposed to do? • What does it mean to do it securely?

8. Pretend each participant has secure channel to a trusted third party called the functionality “Dummy” participants send inputs to functionality Functionality calculates, sends appropriate output to each participant Functionality also provides channel to adversary P’ P’ F A The functionality

9. (start, P1, P2) (start, P2, P1) (Key, K) (Key, K) (finished, P1) (start, P1, P2) (start, P2, P1) (finished, P2) Example: KE functionality (P1, P2) (P2, P1) K

10. The functionality (cont.) • Definition of F specifies what information, options available to adversary • Adversary knows who starts protocol, • Chooses who receives keys • Assumption: we are willing to tolerate that leakage, those options, but no more • Adversary never learns key • Participants never get different keys • Intuition: no adversary should be able to tell real setting from functionality setting

11. P P A Formalizing intuition • In the “real” scenario, adversary sees potentially long series of messages

12. In the “ideal” scenario, adversary sees different set of messages (defined by description of F) Need to make functionality “look” like protocol This task performed by simulator P’ P’ F A Formalizing intuition (cont.)

13. Sits between functionality and simulator Translates functionality output into “protocol” Does not see F’s messages to participants! The simulator P’ P’ F S A

14. Protocol security • A protocol securely realizes functionality F if:  simulator S so that no adversary can distinguish between execution of  and execution of (F, S) • Note that simulator does not see “forbidden” information • Participant inputs, outputs from F to participants • Thus, simulator output is independent of forbidden info • If simulated protocol indistinguishable from real protocol, real protocol must also be (computationally) independent of forbidden information as well

15. Protocol  may be sub-protocol of higher-level protocol ’ Protocol ’ may leak info about P to adversary Worst case scenario: adversary learns from P’ entire output from P And can set inputs to P Higher-level protocols P P F S A

16. Higher-level protocols (cont.) • Is it meaningful to even talk about security when higher-level protocols reveal everything? • Answer: we have no control over higher-level protocol • Nevertheless, we will keep our end of the deal • Will remain indistinguishable from F regardless of what higher-level protocol (or adversary) does

17.  S s. t. these two situations indistinguishable to all adversaries: UC secure realization of F P P F P P S A A

18. Key exchange • Standard symbolic definition: • Key Agreement: IfP1outputs(Finished K)and P2 outputs(Finished K’)then K = K’. • Traditional Dolev-Yao secrecy: If either participant outputs(Finished K), then adversary can never learnK • Not strong enough! • Protocols exists that satisfy above, but not UC secure • Example: Needham-Schroeder-Lowe

19. {A Na}KB {K}KB A B {B Na K}KA Needham-Schroeder-Lowe • Suppose K=Nb is used as secret key • Secret, under traditional definition • K output by A before B receives third message • Goal of adversary: distinguish • Real - K used in protocol • Ideal - K independent of simulated protocol

20. Distinguisher for NSL • Test: Flip coin • Heads: send {K}KB(real value) to B • Tails: make random key K’, send {K’}KB to B • Adversary knows B’s “correct” response from B • B will give correct response in real setting • Simulator in ideal setting won’t know what to do • Can’t tell K’ from K • Both random values to simulator • Will be wrong with probability .5 • No simulator can fool this adversary

21. Real-or-random (1/3) • Need: real-or-random property for session keys: • Let be a protocol • Let r be , except that when a participant finishes, it outputs real key Kr • Let f be , except that when a participant finishes, it outputs random key Kf • Want: adversary can’t distinguish two protocols

22. Real-or-random (2/3) • Let S be a strategy • Sequence of deductions and transmissions • Attempt 1: For any strategy, Trace(S, r) = Traces(S, f) • Problem: Kf not in any traces of r • Attempt 2: Trace(S,r) = Rename(Trace(S,f),KfKr) • Sufficient for “if,” too strong for “only if” • Two different traces may ‘appear’ the same to adversary

23. Real-or-random (3/3) • Observable part of trace: Abadi-Rogaway pattern • Undecipherable encryptions replaced by “blob” • Example: t = {N1, N2}K1, {N2}K2, K1-1 Pattern(t) = {N1, N2}K1, K2, K1-1 • Final condition: for any strategy: Pattern(Trace(S,r)) = Pattern(Rename(Trace(S, f),KfKr)))

24. Main results • Theorem: let  be a concrete protocol. Then  securely realizes FKE iff  satisfies • Key agreement • Traditional Dolev-Yao secrecy of session key • Real-or-random

25. Future work • How to prove Dolev-Yao real-or-random? • Possibly related to Blanchet’s “super secrecy” • Simpler form? • Similar results for protocols using symmetric encryption, signatures, Diffie-Hellman?

26. Backup-slides

27. (start, P1, P2) (start, P2, P1) (finished, P1, P2) (finished, P1, P2) (finished, P1, P2) (finished, P2, P1) (start, P1, P2) (start, P2, P1) Example: MA functionality (P1, P2) (P2, P1)

28. Mutual Authentication • Dolev-Yao mutual authentication (DY-MA): Adversary cannot make party P1 (locally) output (finished P1 P2) before P2 outputs (starting P1 P2) and vice-versa • UC: FMA only sends (success P1 P2) to participants after both submit (start P1 P2) • Theorem: let  be a simple protocol. Then  achieves DY-MA iff  securely realizes FMA • (Note: UC analog to MW04)

29. “Simple” protocols • Recall goal: equate DY and UC security • Need protocols to be meaningful in both models • Efficient implementations (needed by UC) • Messages with DY-like parse trees • Consider programs from a “programming language” • Equality testing, branching • Standard DY adversary actions • Uses UC-secure asymmetric encryption • Will probably be replaced by CPPL

30. (P1 P2) (P2 P1) (P1 P2) (P2 P1) Key P1 Key P2 Key k Key k Key P2 UC Key-Exchange Functionality FKE (P1 P2) A P1 k  {0,1}n (P2 P1) P2

31. Mapping lemma • Let  be a simple protocol • Every concrete execution of protocol  (with any concrete adversary) has valid Dolev-Yao interpretation • Lemma: such interpretations could almost always be generated by Dolev-Yao adversary in purely Dolev-Yao setting • Similar result to MW04 • Cor: To prove that simple protocol  securely realizes F, need only show that it achieves Dolev-Yao goal G • If F and G are equivalent over traces • Note: traces now includes input/output

32. P’ P’ P P F A A Protocol security • Intuition: A protocol securely realizes a functionality F if running  is “just like” using F =

33. Implications of definition • Purpose of protocol: jointly calculate the outputs specified by description of F • Security: No one learns more from  than would be revealed by F • However: definition (in particular) requires that no adversary can distinguish the two situations • Can this definition be realized?