Cryptographic Protocol is and isn't like LEGO.
•
3 likes•477 views
Cryptographic protocols are widely applied to many application to enjoy security, privacy, authenticity and other features. Such protocols and cryptographic techniques are often composed to try to realize complicated features like a LEGO. It seems a good way to achieve many new security and privacy goals. However, the security of combination of cryptographic techniques cannot be thought is LEGO. This keynote talk at IWSEC 2015 explains how we are tackling with this issues for long years and how this problem is essential for future applications like blockchain. This talk was provided on August 26, 2015.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cryptographic Protocol is and isn't like LEGO.
Similar to Cryptographic Protocol is and isn't like LEGO. (20)
Recently uploaded
Recently uploaded (20)
Cryptographic Protocol is and isn't like LEGO.
- 1. Cryptographic Protocol is and isn't like LEGO Shin ichiro Matsuo August 26, 2015 IWSEC 2015
- 2. 2014 The year of SSL/TLS nightmare.
- 3. Cryptographic Protocol? 3 A rule which describes how an activity should be performed + Cryptography
- 4. At Wikipedia A security protocol (cryptographic protocol or encryption protocol) is an abstract or concrete protocol that performs a security-related function and applies cryptographic methods, often as sequences of cryptographic primitives . A protocol describes how the algorithms should be used. A suf fi ciently detailed protocol includes details about data structures and representations, at which point it can be used to implement multiple, interoperable versions of a program. 4
- 5. Cryptographic Protocol is Important • Many security technologies based on cryptography are served as Cryptographic Protocol. • We do not directly use cryptographic primitives like AES and RSA. • We have long and established study on cryptographic primitives. • How much do we know about on cryptographic protocols? 5
- 8. Key Exchange 8 Alice Bob Cannot obtain key information Share a session key Adversary
- 9. Secure Channel (Authenticated Key Exchange) 9 Alice Bob Cannot obtain key information Share a session key with an authenticated user Adversary
- 10. Blind Signature 10 Alice Bob Sign without knowing the contents Verify Signer
- 11. Time-stamping 11 Verify the existence at time t Alice Bob Calculate time- stamping token Time Stamping Authority
- 12. Electronic Voting 12 Voters Tallier Registration Prevent double voting and forgery Privacy of ballot
- 13. E-cash 13 Central Bank Bank A Bank B User 1 User 2 Prevent double spending and forgery Privacy in payment Check double spending
- 14. LEGO 14
- 15. Constructing something by LEGO Combination of blocks to realize functions designated in the instruction 15
- 16. Cryptographic Protocol is like LEGO Matching between security functionality and building blocks 16 Security Functionality Building block Authentication Anonymity Con fi dentiality Key Exchange Encryption Challenge-Response Shu ffl e
- 17. Simple Example: Challenge-Response 17 Random Bit Generator Random r Signing Key (Secret) Singing Veri fi cation Digital Signature Veri fi cation Key (Public)
- 18. SSL/TLS looks like LEGO 18 Client Server Symmetric Encryption Key Exchange Entity Authentication Negotiation Integrity Check
- 19. However, security isn t like LEGO 19 Man-in-the-Middle Attack Alice Bob Adversary Think as Bob s key
- 20. Security model of cryptographic primitive Operational environment is simple. 20 Alice Bob E( ) D( ) Encryption Key Decryption Key Adversary
- 21. Environment of real protocol • Communication channels are controlled by the adversary. • Not limited to eavesdropping • Man-in-the-middle • Some of protocol participants are controlled by the adversary. • Leakage of secret information 21
- 22. What can be done by an adversary? • Control the communication channel • Eavesdrop • Stop • Resend • Forge message • Attack on cryptography (with quite low probability) • Obtain plaintext • Forge signature • Obtain session keys, … 22
- 23. Dolev-Yao Model 23 • Cryptography is treated as ideal operation. • Only a party who has a decryption key obtains plaintext. • The other party obtains nothing. • Same treatment for digital signature and others • An adversary can control communication channel. • Eavesdrop, stop, and send any message.
- 24. How di ffi cult is it to evaluate the security? • Protocol execution produce huge number of states . • Each action produce a new state of protocol execution. • An adversary can attack on followings. We should care both. • Miscon fi guration of protocol which produce insecure state • Attack on cryptographic primitives 24
- 25. History of Evaluation 25 Formal Veri fi cation Mathematical Proof • Formal method • Find the existence of insecure state • Automated veri fi cation • Tool-aided • Rigorous proof • Estimate probability of attack • Same as cryptographic Primitive
- 26. Formal Veri fi cation • Cryptographic algorithm is idealized. • Explore the existence of state against the security property. • Dolev-Yao Model. • Omit the possibility of successful attack on underlying cryptographic algorithm. 26
- 27. Formal Veri fi cation Tools 27 Model&checking Theorem&proving Symbolic Cryptographic CryptoVerif SCYTHER ProVerif Isabelle/HOL BPW(on&Isabelle/HOL) NRL FDR AVISPA AVISPA& (TA4SP) Unbounded GamePbased&Security& Proof& on&Coq)
- 28. Mathematical Proof • Estimate the probability which the adversary breaks the security property. • Show the probability is negligible. • Like the security proof of cryptographic algorithm. 28
- 29. Universal Composability (UC) • De fi ne the ideal functionality, then prove that the actual protocol is indistinguishable against the ideal functionality. 29 F Ideal Functionality Actual Protocol Z P2 P4 P3 P1 P2 P4 P3 P1
- 30. Combination of Formal Veri fi cation and UC • Combine the merit of formal veri fi cation and mathematical rigorous proof. • Many researches from 2002 • Game-based evaluation • Crypto-verif 30
- 31. Formal Veri fi cation Tools 31 Model&checking Theorem&proving Symbolic Cryptographic CryptoVerif SCYTHER ProVerif Isabelle/HOL BPW(on&Isabelle/HOL) NRL FDR AVISPA AVISPA& (TA4SP) Unbounded GamePbased&Security& Proof& on&Coq)
- 32. Attack on standard protocols We had many attacks on standard cryptographic protocols. 32 Wireless LAN SSL/TLS WEP (2004) WPA-TKIP (2004) WPA-PSK (2011) TIME/CRIME/Lucky Thirteen Heartbleed POODLE …
- 33. An example in wireless LAN • Attack on WPA-TKIP (Beck-Tews: 2008) • Use ARP packet to fi gure the key stream • Improvement of this attack by Ohigashi and Morii (2009) 33
- 34. Attacks on SSL/TLS • SSL 2.0 (1994) Downgrade attack, CRIME, BREACH • SSL3.0 (1995) POODLE Attack • TLS1.0 (1999) BEAST Attack • TLS 1.1 (2006) Heartbleed bug 34
- 35. CRIME attack • Use compression functionality in SSL/TLS • Figure out the contents of Cookie by comparison of data size after the compression • Independent from The security of underlying cryptographic primitive 35
- 36. Heartbleed bug 36 • Bugs in OpenSSL related to Heatbeat extension • Insu ffi cient check of data size • An adversary can obtain the contents of data in the server • This attack is independent from the strength of underlying cryptographic primitives, too.
- 37. POODLE • Man-in-the-middle • Downgrade to RC4 (weak cipher) • A problem of the SSL 3.0 speci fi cation 37
- 38. Only in the speci fi cation? • Most threats come from implementation • or pitfall between the speci fi cation and implementation. 38
- 39. Pitfall between speci fi cation and implementation In the case of Heartbleed • The description in RFC document does not describe the details of implementation • Treatment of data length (ex. the case of size = 0) • No instruction is provided for developers 39
- 40. Solve the pitfall • Write protocol speci fi cation without ambiguity for implementation • Clarify the operational condition and implementation condition. 40
- 41. We need collections of knowledge • There was no trust point where collects security information on cryptographic protocols. • Protocol designers and engineers need tips and best practice. • Which protocol is secure? • What kind of design is good? • Notes for implementation 41
- 42. CELLOS (2013 12 -): International Consortium on Cryptographic Protocols 42 https://www.cellos-consortium.org
- 43. Overview of CELLOS 43 Universities and Research Institute System Vendors (Developmen t Perspective ) System Vendors (Usage Perspective ) For protocol design For system design International Standardizati on Organizations Fixing or deprecation of insecure protocols For research and education Referencers Wide-ranging and reliable security information from experts Public Information Consolidation of reliable information concerning security evaluation on a global scale Discussions align to actual ICT systems Consolidation of analysis theories, tools and results through formal verification Consolidation of analysis theories and methods other than formal verification Consolidation of detailed information on the latest attack methods Possibilities and impacts of attacks on actual ICT systems Methods for dealing with attacks on actual ICT systems Universities and Research Institutions Company CELLOS Latest analysis theories and methods and evaluation results Realistic countermeasures Detailed checking of information based on its technical validity
- 44. The action example against POODLE 44 Date/Time (JST) Action Oct. 14, 18:39 Find new in the Twitter and reported to the online discussion system. Discussed on the impacts. Oct. 15, 14:04 Started editing a prompt report Oct. 15, 14:04 1st draft of the prompt report Oct. 15, 21:48 2nd draft of the prompt report Add important descriptions on attacking condition and impacts Oct. 15, 22:20 3rd draft, add product names Oct. 15, 22:20 Edit both English and Japanese version Oct. 15, 22:52 Publish the 1st prompt report Oct. 15, 23:09 Add information on new version of OpenSSL Oct. 16, 10:07 Correct editorial errors
- 45. Evaluation of New Protocols 45 • Evaluate a cryptographic protocol proposed by member of CELLOS • Conduct formal verification by a evaluation group in the working group • The report will be publicly available on the Web site. • Used for supportive document for standardization and so on.
- 46. Requirements for the evaluation • Open • Evaluation criteria • Evaluation method • Public Veri fi able • Uni fi ed evaluation framework 46
- 47. ISO/IEC 29128 (2011 Nov.) • ISO/IEC standard on “Evaluation of Cryptographic Protocols” • Defines a workflow of protocol verification and protocol assurance levels according to verification techniques. • Workflow • A protocol designer writes documents and submit to an evaluator. • Protocol specification, Adversarial model, Security requirements and the Result. • The evaluator checks the correctness of these documents and re-execute the tool. • Introducing Four Protocol Assurance Levels 47
- 48. Protocol assurance level in ISO/IEC 29128 48 Protocol Assurance Level PAL1 PAL2 PAL3 PAL4 Protocol Specification PPS_SEMIFORMAL Semiformal description of protocol specification. PPS_FORMAL Formal description of protocol specification. PPS_ MECHANIZED Formal description of protocol specification in a tool- specific specification language, whose semantics is mathematically defined. Adversarial Model PAM_INFORMAL Informal description of adversarial model. PAM_ FORMAL Formal description of adversarial model. PAM_ MECHANIZED Formal description of adversarial model in a tool- specific specification language, whose semantics is mathematically defined. Security Property PSP_INFORMAL Informal description of security property PSP_ FORMAL Formal description of security property. PSP_ MECHANIZED Formal description of security property in a tool- specific specification language, whose semantics is mathematically defined. Self-assessment Evidence PEV_ARGUMENT Informal argument that the specification of the cryptographic protocol in its adversarial model achieves and satisfies its objectives and properties. PEV_HANDPROVEN Mathematically formal paper- and-pencil proof verified by human that the specification of the cryptographic protocol in its adversarial model achieves and satisfies its objectives and properties. PEV_BOUNDED Tool-aided bounded verification that the specification of the cryptographic protocol in its adversarial model achieves and satisfies its objectives and properties. PEV_UNBOUNDED Tool-aided unbounded verification that the specification of the cryptographic protocol in its adversarial model achieves and satisfies its objectives and properties. Accurate
- 49. Toward future applications • Cryptographic protocols are implemented to realize future applications. • Directly connected to the business • ApplePay • Bitcoin (Blockchain) 49
- 50. Blockchain • Fundamental techniques to realize Public Ledger using P2P network and chained digital signature • Used in digital currencies like Bitcoin 50 User P2P Network Ledger Each node update its distributed ledger User User User User User Ledger Ledger Ledger Ledger Ledger Change Ledge r Time: t Ledge r Time: t+1 H(Lt) H(Lt-1) Digital Signature Digital Signature
- 51. Blockchain • Fundamental techniques to realize Public Ledger using P2P network and chained digital signature • Used in digital currencies like Bitcoin 51 User P2P Network Ledger Each node update its distributed ledger User User User User User Ledger Ledger Ledger Ledger Ledger Change Ledge r Time: t Ledge r Time: t+1 H(Lt) H(Lt-1) Digital Signature Digital Signature
- 52. Application of blockchain • Digital currency • Smart Contract • Registration and certi fi cation • Publicly veri fi able storage 52
- 53. How much do we know on the security of Bitcoin? 53 Formalization Formal Analysis Coq Others Security Anti-double spneding [GKL15] [B15], [G14] Not found Anti-Money Laundering Not found Not found Not found Privacy Unlinkability [AKRSC13] Not Found Not Found Taint- resistnat [MO15] Not Found Not Found
- 54. Cryptographic Protocols are becoming the foundation • Blockchain is a foundation of public veri fi able trust • Several applications will be developed over blockchain • Several private company focus on the research of cryptographic protocols including applications of blockchain. • Application, experiment and business are arising quickly in LEGO and agile development manner. • Cryptographic protocols directly connect to business. 54
- 55. We need more study. • Insu ffi cient security evaluation for emerging cryptographic protocols, unfortunately. • Quick business development vs. security • Needs for development methods to clear the risks both for business operator and users 55
- 56. Conclusion • Abstract of cryptographic protocol • Why cryptographic protocol is and isn t like LEGO • How can we evaluate the security • Future applications • We need more study toward smart applications based on cryptographic protocols. 56