slides

261 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
261
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • So, consider these two millionaires that made it on the internet and are sitting in the pleasant afternoon sun
  • on some south-pacific island.
  • And, as the afternoon rolls by,
  • the conversation turns to the inevitable topic of who lost more money on the stock market…
  • Indeed, they are dying to know who lost more,
  • But they do not want to reveal to each other their how much they actually lost.
  • so they are kind of stuck.
  • So, is there a way for the two millionaires to jointly find out who lost more, without revealing additional information to each other? That is, is there a protocol for two parties, where each party has a private input, and the only thing any of them learns is Which input is larger?
  • This is of course the famous “millionaires problem” suggested by Yao in 82. it is only one example for a very rich collection of problems, which we call “cryptographic protocol problems”.
  • The universal composition theorem states that the composed protocol, rho^pi, emulates the original protocol rho (with ideal access to F). That is, for any adversary A that interacts with rho^pi there exists an adversary A’, that interacts with rho with ideal access to F, Such that no environment can tell the difference between the two interactions. An immediate corollary is that if rho^F securely realizes some ideal functionality, G, then so does the composed protocol, rho^pi.
  • slides

    1. 1. Security and Composition of Cryptographic Protocols CQIS'05 Tutorial Ran Canetti IBM Research
    2. 3. Nice sun…
    3. 4. yeah...
    4. 5. You know, I lost more than you in the stock market.
    5. 6. No way. How much did you lose?
    6. 7. I won’t tell you... How much did you lose?
    7. 8. You tell first!
    8. 9. No, you tell first!
    9. 10. No, you tell first!
    10. 11. I lost X $ is X>Y? I lost Y $
    11. 12. I lost X $ is X>Y? I lost Y $ The millionaires problem [Yao82]
    12. 13. Cryptographic protocol problems <ul><li>Two (or more) parties want to perform some joint computation, while guaranteeing: </li></ul><ul><li>Correctness of outputs </li></ul><ul><li>Privacy of local data </li></ul><ul><li>Against “adversarial behavior” </li></ul>
    13. 14. Cryptographic protocol problems: Two-party tasks <ul><li>Coin tossing [Blum 82] </li></ul><ul><li>Generate a common uniformly distributed bit (or string). </li></ul><ul><li>Zero-Knowledge [Goldwasser-Micali-Rackoff 85] </li></ul><ul><li>P proves to V that x L “without revealing extra info”. </li></ul><ul><li>Commitment [Blum 82] </li></ul><ul><li>Two stage process: </li></ul><ul><li>- C gives x to V “in an envelope” </li></ul><ul><li>(i.e., x is fixed but remains unknown to V). </li></ul><ul><li>- C enables V to “open the envelope” (i.e., retrieve x). </li></ul><ul><li>Oblivious Transfer [Rabin 81] </li></ul><ul><li>... </li></ul>
    14. 15. Cryptographic protocol problems: Secure Communication <ul><li>Key-exchange: [Diffie-Hellman76] </li></ul><ul><li>Parties A,B agree on a key that remains secret to eavesdroppers. </li></ul><ul><li>Secure channels: </li></ul><ul><li>Parties exchange secret and authenticated messages. </li></ul><ul><li>(Here the adversary is an “external entity”) </li></ul><ul><li>Very prevalent in practice ( SSL,TLS,IPSEC,SSH,PGP,…) </li></ul>
    15. 16. Cryptographic protocol problems: Multiparty tasks and applications <ul><li>Voting </li></ul><ul><li>“ E-commerce”: </li></ul><ul><ul><li>On-line Auctions </li></ul></ul><ul><ul><li>On-line trading and financial markets </li></ul></ul><ul><ul><li>On-line shopping </li></ul></ul><ul><li>Secure distributed storage </li></ul><ul><li>Privacy-preserving Database operations: </li></ul><ul><ul><li>Private information retrieval </li></ul></ul><ul><ul><li>Privacy preserving database pooling </li></ul></ul><ul><li>Secure peer-to-peer networks </li></ul><ul><li>… </li></ul><ul><li>Generalc function evaluation and “interactive games” </li></ul>
    16. 17. Cryptographic protocols: main research efforts in past 20+ years <ul><li>General feasibility results [Yao86, Goldreich-Micali-Wigderson87, BenOr-Goldwasser-Wigderson88,…] </li></ul><ul><li>More efficient protocols </li></ul><ul><li>Implementing and incorporating in security systems </li></ul><ul><li>New functionality and applications </li></ul><ul><li>Formalize the security properties required from protocols, and rigorously prove security of protocols </li></ul>
    17. 18. What does it mean that a protocol is “secure”? <ul><li>Rigorously capturing the intuitive notion of security is a notoriously tricky business… </li></ul><ul><li>A main stumbling point: Definitions of security are very sensitive to the execution environment. </li></ul>
    18. 19. In this tutorial: <ul><li>Review a basic and general definition of security, see examples. </li></ul><ul><li>Discuss and motivate secure protocol composition. </li></ul><ul><li>Show that the basic definition guarantees security under non-concurrent composition, but not under concurrent composition. </li></ul><ul><li>Sketch a definition that preserves security under general, concurrent secure composition (Universal Composition), review basic feasibility results. </li></ul><ul><li>Explore connections to “formal analysis” of protocols (the “Dolev-Yao model”). </li></ul>
    19. 20. The general definitional approach [Goldreich-Micali-Wigderson87] <ul><li>‘ A protocol is secure for some task if it “emulates” an “ideal process” where the parties hand their inputs to a “trusted party”, who locally computes the desired outputs and hands them back to the parties.’ </li></ul>
    20. 21. Attractive properties of the “trusted party approach”: <ul><li>Intuitive, elegant... </li></ul><ul><li>Expressive: Can capture correctness, privacy, influence, collusion, ... </li></ul><ul><li>General: Can be used to capture many tasks </li></ul><ul><li>Amenable to composition </li></ul><ul><li>A natural extension of Zero-Kenowledge </li></ul><ul><li>But, how to formalize? </li></ul>
    21. 22. A basic formalization (based on [Goldwasser-Levin90,Micali-Rogaway91,Beaver91,C95,C00]) <ul><li>Formalize the process of protocol execution in presence of an adversary </li></ul><ul><li>Formalize the “ideal process” for realizing the functionality </li></ul><ul><li>Formalize the notion of “a protocol emulates the ideal process for a functionality.” </li></ul>
    22. 23. <ul><li>The model for protocol execution : </li></ul>P 1 P 3 P 4 P 2 A <ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary A, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    23. 24. <ul><li>The model for protocol execution : </li></ul>P 1 P 3 P 4 P 2 A <ul><li>The parties and the adversary </li></ul><ul><li>get external input. </li></ul><ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary A, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    24. 25. <ul><li>The model for protocol execution : </li></ul><ul><li>The parties and the adversary </li></ul><ul><li>get external input. </li></ul><ul><li>The parties and adversary interact </li></ul><ul><li>(parties running the protocol, </li></ul><ul><li>A interferes according to the model.) </li></ul>P 1 P 3 P 4 P 2 A <ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary A, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    25. 26. <ul><li>The model for protocol execution : </li></ul><ul><li>The parties and the adversary </li></ul><ul><li>get external input. </li></ul><ul><li>The parties and adversary interact </li></ul><ul><li>(parties running the protocol, </li></ul><ul><li>A interferes according to the model.) </li></ul><ul><li>The parites and the adversary generate their local outputs. </li></ul>P 1 P 3 P 4 P 2 A <ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary A, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    26. 27. <ul><li>The ideal process: </li></ul>P 1 P 3 P 4 P 2 S <ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary S, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    27. 28. <ul><li>The ideal process: </li></ul>P 1 P 3 P 4 P 2 S <ul><li>The parties and the adversary </li></ul><ul><li>get external input. </li></ul><ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary S, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    28. 29. <ul><li>The ideal process: </li></ul>P 1 P 3 P 4 P 2 F S <ul><li>The parties and the adversary </li></ul><ul><li>get external input. </li></ul><ul><li>The parties and adversary hand </li></ul><ul><li>Their inputs to a “trusted party”. </li></ul><ul><li>The trusted party locally evaluates </li></ul><ul><li>The function and hands each party </li></ul><ul><li>Its prescribed output. </li></ul><ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary S, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    29. 30. <ul><li>The ideal process: </li></ul>P 1 P 3 P 4 P 2 F S <ul><li>The parties and the adversary </li></ul><ul><li>get external input. </li></ul><ul><li>The parties and adversary hand </li></ul><ul><li>Their inputs to a “trusted party”. </li></ul><ul><li>The trusted party locally evaluates </li></ul><ul><li>The function and hands each party </li></ul><ul><li>Its prescribed output. </li></ul><ul><li>The parties and adversary generate </li></ul><ul><li>their local outputs. </li></ul><ul><li>Participants: </li></ul><ul><li>Parties P 1 …P n </li></ul><ul><li>Adversary S, controlling </li></ul><ul><li>the corrupted parties. </li></ul>
    30. 31. <ul><li>Emulating the ideal process: </li></ul>Z Z Z Z Ideal process: Protocol execution: P 1 P 3 P 4 P 2 A P 1 P 3 P 4 P 2 F S
    31. 32. <ul><li>2. Say that a protocol emulates the ideal process for evaluating F if for any adversary A there exists an adversary S such that no “external environment” Z can tell between: </li></ul><ul><li>A run of protocol . </li></ul><ul><li>An “ideal execution” where the parties interact with F. </li></ul><ul><li>In this case, we say that securely realizes functionality F. </li></ul>Definition of security
    32. 33. <ul><li>Correctness : In the ideal process the parties get the “correct” outputs, based on the inputs of all parties. Consequently, the same must happen in the protocol execution (or else Z will tell the difference). </li></ul><ul><li>Secrecy: In the ideal process the adversary learns nothing other than the outputs of bad parties. Consequently, the same must happen in the protocol execution. </li></ul><ul><li>“ Input independence:” The bad parties cannot choose their inputs based on the inputs of the honest parties. </li></ul><ul><li>… </li></ul>Implications of the definition
    33. 34. Example: The millionaires functionality <ul><li>Receive (x) from party A </li></ul><ul><li>Receive (y) from party B </li></ul><ul><li>Set b=x>y. Send (b) to A and B, and halt. </li></ul>
    34. 35. Example: The coin tossing functionality <ul><li>Receive “start” from A </li></ul><ul><li>Receive “start” from B </li></ul><ul><li>Choose s  R {0,1} k , send s to A and B, and halt. </li></ul><ul><li>Note: </li></ul><ul><li>Both parties are assured that s is chosen uniformly and is not biased. </li></ul>
    35. 36. Example: The ZK functionality,F ZK (for relation R) <ul><li>Receive (x,w) from P </li></ul><ul><li>Receive (x) from V </li></ul><ul><li>Send (R(x,w)) to V and halt. </li></ul><ul><li>Note: </li></ul><ul><li>V is assured that it accepts only if R(x,w)=1 (soundness) </li></ul><ul><li>P is assured that V learns nothing but R(x,w) (Zero-Knowledge) </li></ul>
    36. 37. Equivalence with other formulations <ul><li>Traditionally ZK was defined a bit differently. </li></ul><ul><li>But can see that the two formalizations are essentially equivalent: </li></ul><ul><li>A protocol securely realizes F ZK if and only if it is a ZK proof of knowledge. </li></ul><ul><li>(Here both soundness and ZKness are computational.) </li></ul>
    37. 38. <ul><li>[Y86]: Can realize any two-party functionality for honest-but-curious parties. </li></ul><ul><li>[GMW87]: Can realize any ideal functionality </li></ul><ul><ul><li>with any number of faults (without guaranteed termination) </li></ul></ul><ul><ul><li>With up to n/2 faults (with guaranteed termination) </li></ul></ul><ul><li>[Ben-Or,Goldwasser,Wigderson88]: Assuming secure channels, can do </li></ul><ul><ul><li>Unconditional security with n/3 faults </li></ul></ul><ul><ul><li>Adaptive security </li></ul></ul><ul><li>Many improvements and extensions [RB89,CFGN95,GRR97,…] </li></ul>General feasibility results
    38. 39. <ul><li>Represent the code of the trusted party as a circuit. </li></ul><ul><li>Evaluate the circuit gate by gate in a secure way against honest-but-curious faults. </li></ul><ul><li>“ Compile” the protocol to obtain resilience to malicious faults: </li></ul><ul><ul><li>[GMW87]: Use general ZK proofs </li></ul></ul><ul><ul><li>[BGW88]: Use special-purpose algebraic proofs </li></ul></ul>The basic technique
    39. 40. <ul><li>The definition of security considers only a single protocol execution, in isolation. </li></ul><ul><li>What about security when a protocol is running in conjunction with other protocols? </li></ul><ul><ul><li>Other instances of the same protocol? </li></ul></ul><ul><ul><li>Other protocols? </li></ul></ul><ul><ul><li>Instances running sequentially? </li></ul></ul><ul><ul><li>Instances running concurrently? </li></ul></ul>Is security preserved under protocol composition?
    40. 41. <ul><li>Modular design and analysis of protocols: </li></ul><ul><ul><li>Break down a complex task into simpler sub-tasks. </li></ul></ul><ul><ul><li>Design and analyze a protocol for each of the sub-tasks (as stand-alone). </li></ul></ul><ul><ul><li>Compose the protocols to obtain a protocol for the original task. </li></ul></ul><ul><ul><li>Deduce the security of the composite protocol. </li></ul></ul><ul><li>Security in unknown environments: </li></ul><ul><ul><li>Guarantee security when the protocol is running alongside other (potentially unknown) protocols. </li></ul></ul>Two benefits of security-preserving composition of protocols
    41. 42. Non-concurrent modular composition (Originates with [Micali-Rogaway91] ) <ul><li>Start with: </li></ul><ul><li>Protocol F that uses ideal calls to F </li></ul><ul><li>Protocol that securely realizes F </li></ul><ul><li>Construct the composed protocol : </li></ul><ul><li>Each call to F is replaced with an invocation of . </li></ul><ul><li>Each value returned from is treated as coming from F. </li></ul>
    42. 43. The composition operation (single call to F) F 
    43. 44. The composition operation (single call to F)  F
    44. 45. The non-concurrent composition theorem: [C. 00] <ul><li>If in no two protocol copies are running concurrently, then Protocol “emulates” protocol F . </li></ul><ul><li>(That is, for any adversary A there exists an adversary A` such that no Z can tell whether it is interacting with ( , A) or with ( F ,A`).) </li></ul><ul><li>Corollary: If F securely realizes functionality G then so does . </li></ul>(A similar composition theorem was proven in [Micali-Rogaway91] With respect to their notion.)
    45. 46. <ul><li>The basic notion of security does not preserve security. </li></ul><ul><ul><li>Example 1 : Running as few as two copies of ZK protocols in parallel does not necessarily preserve ZK [Goldreich-Krawczyk88]. </li></ul></ul><ul><li>(Still, there exist protocols that remain ZK under parallel composition [Feige-Shamir90,Goldreich02] .) </li></ul><ul><li>Need a notion that guarantees security for parallel composition </li></ul>What about concurrent composition? V P V x x
    46. 47. Example 2: Zero-Knowledge under concurrent composition [Feige90, Dwork-Naor-Sahai98] <ul><li>What if a ZK protocol is executed many times concurrently (“concurrent ZK”)? </li></ul><ul><li>Hard to achieve: </li></ul><ul><ul><li>Best known: O(log n) rounds [Richardson-Kilian99,...,Prabhakaran-Rosen-Sahai02] </li></ul></ul><ul><ul><li>Lower bound of (log n) rounds (for black-box simulation) [C-Kilian-Petrank-Rosen01] </li></ul></ul><ul><ul><li> </li></ul></ul>P V V V V … <ul><li>Need yet another notion of ZK, </li></ul><ul><li>to deal with this type of concurrent </li></ul><ul><li>composition. </li></ul>
    47. 48. Example 3: Malleability of Zero-Knowledge [Dolev-Dwork-Naor91] <ul><li>What if the verifier can use the interaction to prove a “related theorem” to a third party? </li></ul><ul><ul><li> </li></ul></ul>w, R(x,w)=1 P V P’ V’ X+1 <ul><li>None of the previous notions prevents this attack. </li></ul><ul><li>There exist protocols that prevent the attack [DDN91] . </li></ul><ul><li>Need yet another notion of ZK, that guarantees “non-malleability”. </li></ul>x
    48. 49. Example 4: Malleability of commitment [Dolev-Dwork-Naor91] <ul><li>The stand-alone notion does not guarantee “independence” among committed values. </li></ul><ul><li>Example: A simple auction protocol. </li></ul>Phase 1: Each bidder publishes a commitment to its bid. Phase 2: Bidders open their commitments.
    49. 50. <ul><li>The stand-alone notion does not guarantee “independence” among committed values. </li></ul><ul><li>Example: A simple auction protocol. </li></ul>Example 4: Malleability of commitment [Dolev-Dwork-Naor91] Phase 1: Each bidder publishes a commitment to its bid. P1 P2 A C=Com(v) C’ Phase 2: Bidders open their commitments. P1 P2 A v v+1
    50. 51. What about an arbitrary multi-execution environment? <ul><li>All the above concerns exist, and more. </li></ul><ul><li>In addition: potential bad interactions with other (unknown) protocols… </li></ul><ul><li>How can we guarantee that a protocol remains secure in such a setting? </li></ul>
    51. 58. How to guarantee security in complex protocol environments? <ul><li>One way: Keep writing more and more sophisticated definitions, that capture more and more scenarios… </li></ul><ul><ul><li>Ever more complex </li></ul></ul><ul><ul><li>No guarantee that “we got it all”. </li></ul></ul><ul><li>Alternatively: Use secure compositionality... </li></ul>
    52. 59. <ul><li>That is: </li></ul><ul><li>Strengthen the basic definition of security in a natural way. </li></ul><ul><li>Can now prove a concurrent version of the composition theorem. </li></ul><ul><li>This will guarantee all the above security properties. </li></ul>The main tool: A concurrent version of the modular composition theorem
    53. 60. Universally Composable Security [C. 98, 01, 05] <ul><li>The main difference from the basic notion: </li></ul><ul><li>The environment interacts with the adversary in an arbitrary way throughout the protocol execution. </li></ul><ul><li>(models the “adversarial information flow” between the protocol instance in question and the other instances.) </li></ul><ul><li>Other differences: </li></ul><ul><ul><li>Handles also reactive tasks </li></ul></ul><ul><ul><li>Handles multiple communication and corruption models </li></ul></ul><ul><li>(Related notions appear in [Pfitzmann-Waidner00,01]) </li></ul>
    54. 61. <ul><li>Recall: basic security : </li></ul>Z Z Z Z Ideal process: Protocol execution: P 1 P 3 P 4 P 2 A P 1 P 3 P 4 P 2 F S
    55. 62. <ul><li>UC security: </li></ul>Z P 1 P 3 P 4 P 2 F P 1 P 3 P 4 P 2 S A Ideal process: Protocol execution:
    56. 63. <ul><li>UC security: </li></ul>Z Z P 1 P 3 P 4 P 2 F P 1 P 3 P 4 P 2 S A <ul><li>Protocol securely realizes F if: </li></ul><ul><li>For any adversary A </li></ul><ul><li>There exists an adversary S </li></ul><ul><li>Such that no environment Z can tell </li></ul><ul><li>whether it interacts with: </li></ul><ul><ul><li>- A run of with A </li></ul></ul><ul><ul><li>- An ideal run with F and S </li></ul></ul>Ideal process: Protocol execution:
    57. 64. The universal composition operation: Same as the non-concurrent case, except that here multiple calls to F can be made at the same time and multiple protocol copies may run concurrently: F F F 
    58. 65. The universal composition theorem: [C. 01] <ul><li>Protocol “emulates” protocol F . </li></ul><ul><li>(That is, for any adversary A there exists an adversary A` such that no Z can tell whether it is interacting with ( , A) </li></ul><ul><ul><ul><li>or with ( F ,A`).) </li></ul></ul></ul>“ From the point of view of any protocol, having access to multiple copies Of F is essentially the same as having access to multiple copies of a protocol That realizes F.”
    59. 66. In particular: <ul><li>A protocol that realizes F zk under this notion is: </li></ul><ul><ul><li>Concurrent ZK </li></ul></ul><ul><ul><li>Non-malleable ZK </li></ul></ul><ul><li>A protocol that realizes the commitment functionality is a non-malleable commitment protocol. </li></ul>
    60. 67. Questions: <ul><li>Are known protocols UC-secure? </li></ul><ul><li>(Do these protocols realize the ideal functionalities that represent the corresponding tasks?) </li></ul><ul><li>How to design UC-secure protocols? zcyk02] </li></ul>
    61. 68. Existence results: Honest majority <ul><li>Thm: If the corrupted parties are a minority then can realize any functionality [C. 01] . (e.g. use the protocols of [BenOr-Goldwasser-Wigderson88, Rabin-BenOr89,C-Feige-Goldreich-Naor96] ). </li></ul>
    62. 69. Two-party functionalities <ul><li>Known protocols do not work. (“black-box simulation with rewinding” cannot be used). </li></ul><ul><li>Many interesting functionalities (commitment, ZK, coin tossing, etc.) cannot be realized in plain model. </li></ul><ul><li>In the “common random string model” can do: </li></ul><ul><ul><li>UC Commitment [C-Fischlin01,C-Lindell-Ostrovsky-Sahai02,Damgard-Nielsen02]. </li></ul></ul><ul><ul><li>UC Zero-Knowledge [CF01, CLOS02] </li></ul></ul><ul><ul><li>Any two-party functionality [CLOS02] </li></ul></ul><ul><ul><li>(Generalizes to any multiparty functionality with any number of faults.) </li></ul></ul>
    63. 70. The [CLOS] approach <ul><li>The protocols for honest-but-curious faults remains the same as in [GMW87]. </li></ul><ul><li>The “compiler” follows the approach of [GMW87], but replaces the components (ZK,Commitment, Coin-tossing,…) with UC counterparts. </li></ul><ul><li>(Some technical caveats have to be dealt with.) </li></ul>
    64. 71. On relaxing the definition and set-up assumption <ul><li>The UC definition is quite restrictive: Many functionalities cannot be realized in the plain model without honest majority [C01, C-Kushilevitz-Lindell03, Datta etal 06] </li></ul><ul><li>The existence of a common random string is a non-trivial trusted set-up assumption. </li></ul><ul><li>Is this the best we can do? </li></ul><ul><li>Can we have a relaxed notion that is realizable in the plain model, while maintaining security and composability? </li></ul><ul><li>Can we come up with a relaxed set-up assumption that allows realizing general functionalities? </li></ul>
    65. 72. Some rough answers <ul><li>Can we have a relaxed notion that is realizable in the plain model, while maintaining security and composability? </li></ul><ul><ul><li>No, if one wants to maintain the same level of security as provided by the basic definition [Lindell 03,04] . </li></ul></ul><ul><ul><li>Yes, if one is willing to settle for a somewhat weaker level of security (that may be sufficient in some cases) [Prabhakaran-Sahai 04] . </li></ul></ul><ul><li>Can we come up with a relaxed set-up assumption that allows realizing general functionalities? </li></ul><ul><ul><li>Yes: Can replace the CRS with several variants of a “public-key infrastructure” where, e.g., each party “proves posession of secret key” to the Certification Authority [Barak-C-Nielsen-Pass 04,Dodis-Pass-Walfish05]. </li></ul></ul>
    66. 73. Connections with formal methods for “symbolic protocol analysis” <ul><li>A popular method for analyzing cryptographic protocols using formal methods: </li></ul><ul><li> Model the cryptographic operations (encryption, signature, etc) as “symbolic operations” that assume “perfect cryptography”. </li></ul><ul><li>A quintessential example: The [Dolev-Yao81] modeling of public-key encryption. Many follow-ups exist. </li></ul>
    67. 74. The “Dolev-Yao style” symbolic modeling <ul><li>Main advantage: Analysis is much simpler. In particular, is amenable to automation (e.g., via tools for automated program verification). </li></ul><ul><li>Main drawback: Lack of soundness. There is no security guarantee once the symbolic operations are replaced with real cryptograpic protocols. </li></ul>
    68. 75. Recent endeavor: Computationally sound symbolic analysis <ul><li>Main steps: </li></ul><ul><li>[Abadi-Rogaway00]: A “calculus” of semantically secure symmetric encryption. </li></ul><ul><li>[Micciancio-Warinschi04]: Symbolic security criterion for mutual authentication protocols using asymmetric encryption. </li></ul>
    69. 76. Analysis strategy Concrete protocol Concrete security Symbolic protocol Symbolic property
    70. 77. Using UC analysis to obtain cryptographically sound symbolic modeling <ul><li>The main idea [PW00,C01,Backes-PW 03,C-Herzog04]: </li></ul><ul><li>Formalize ideal functionalities that capture the primitives in use (e.g., encryption, signatures). </li></ul><ul><li>Translate the ideal functionalities to symbolic protocol moves. </li></ul><ul><li>Use the universal composition theorem to deduce that properties of the symbolic protocol are retained by the concrete protocol. </li></ul>
    71. 78. Analysis strategy (expanded) [CH04] Concrete protocol UC concrete security Symbolic single- instance protocol Symbolic property Single-instance Setting Security using UC encryption Security for multiple instances Ideal cryptography UC theorem Simplify UC w/ joint state
    72. 79. Summary <ul><li>Reviewed a basic and general notion of security for cryptographic protocols. </li></ul><ul><li>Motivated the need for security notions that guarantee security under composition. </li></ul><ul><li>Showed that the basic notion guarantees secure composability in the non-concurrent case, but not in the concurrent case. </li></ul><ul><li>Reviewed a general notion that guarantees security-preserving concurrent composition, feasibility results for that notion. </li></ul><ul><li>Explored connections with formal analysis methods. </li></ul>
    73. 80. Further Research <ul><li>Find better notions of security for cryptographic protocols: </li></ul><ul><ul><li>Weaker, but still guarantee desired properties. </li></ul></ul><ul><ul><li>Easier to work with. </li></ul></ul><ul><li>Find better (more reasonable) setup assumptions that enable UC-secure protocols. </li></ul><ul><li>Find better proof techniques: </li></ul><ul><ul><li>Use modularity </li></ul></ul><ul><ul><li>Mechanize </li></ul></ul><ul><ul><li>Use automated tools </li></ul></ul><ul><li>Extend the model and notions of security capture quantum computation </li></ul>
    74. 81. Final Word <ul><li>Security analysis of protocols is only as good as the security notion used --- and subtleties abound. </li></ul><ul><li>It is imperative to use a security notion that is appropriate for the relevant setting. </li></ul>

    ×