Formal Security Protocol AnalysisBy Phillip H. Griffin – ISSA Fellow, Raleigh Chapter

Help is on the way. Help in finding flaws in cryptographic protocols before the bad people do. Help in selecting the most secure alternative for fixing a defect. Help in deciding whether a proposed protocol amendment can actually strengthen or weaken security. Help in gaining the assurance provided by security proofs long before a protocol is implemented and deployed.

cols or theoretical protocols of academic interest. Recently, these tools have shown a more practical side. Their increasing maturity has proved them capable of detecting flaws in pro-tocols defined in national, international, and industry stan-dards and deployed in commercial products.Not all of the protocol security flaws described at the SSR-2014 conference were discovered using these new automat-ed techniques. Several significant findings were the result of more traditional methods. These findings included flaws in standardized and deployed protocols, as well as important in-novations to improve and extend the capabilities of long-used cryptographic techniques. Based on these results, we can look forward to products that eliminate these flaws and offer im-proved security and privacy.

Improvements and flaws: Traditional methodsSome researchers discovered protocol improvements and flaws without the use of automated techniques. Michael Ward of MasterCard, UK, presented “Blinded Diffie-Hellman” [2] on behalf of EMVCo. His presentation introduced a new key agreement protocol for secure, privacy-preserving informa-tion exchange between a contactless payment card and a merchant terminal. This new protocol will enhance the per-formance of future financial transaction systems and better protect cardholders from stalking. New payment systems based on Blinded Diffie-Hellman will use Elliptic Curve Cryptography (ECC) to enhance their per-formance, rather than relying on RSA-based schemes. This protocol has the added benefit of the card not being required to support an ECC signature (e.g., Elliptic Curve Digital Sig-nature) algorithm or its associated cryptographic hash func-tion. The new protocol will help prevent tracking cardholders through the repeated use of their public key certificates. It

From the far reaches of current theoretical computer science research, from the depths of “strand space”1 (figure 1), the faint glimmer of practical results of pro-

tocol security proofs are beginning to emerge. These results are based on a complex process: security threat model analy-sis. This analysis relies on the use of automated tools to detect protocol flaws and to help standards developers perfect the security standards that underlie our information systems and risk management controls.

Figure 1 – Strand: Alice sends a message to Bob

Improving security standardsRoyal Holloway, University of London, UK, hosted the first in a series of Security Standardization Research (SSR) con-ferences2 in December 2014. The conference program covered a wide variety of cybersecurity topics, including biometric authentication, standardized security techniques, key man-agement, network security, smart card (ICC) security, and proposals to enhance transparency and openness in the pro-cesses used by standards development organizations. Accept-ed papers presented by industry and academic experts from around the world ranged in scope from theory to practice. Several papers presented at the conference revealed new flaws discovered in cryptographic protocol standards. In some of these papers, the flaws were detected using formal symbolic protocol analysis tools. Such tools have been under develop-ment for many years. However, their use had been confined for the most part to the analysis of either very simple proto-

1 "A strand is a sequence of events; it represents either the execution of a legitimate party in a security protocol or else a sequence of actions by a penetrator. A strand space is a collection of strands.” [1]

2 http://www.ssr2014.com/.

34 – ISSA Journal | April 2015

ISSA DEVELOPING AND CONNECTING CYBERSECURITY LEADERS GLOBALLY

©2015 ISSA • www.issa.org • editor@issa.org • All rights reserved.

Don’t Miss This Web Conference!Continuous Forensic Analytics:

Issues and Answers 2-Hour Live Event

Scheduled for 9:00 am PDT, 12:00 pm EDT, 5:00 pm London, Tuesday, April 14, 2015.

Big Data, what good is it? Given all the data we have seen, it has become obvious that we can use it for more than we are currently thinking of. It can be used for predictive security analytics as well as for forensic analsysis. With big data these can even be combined to be continuous forensic analytics. Please join us as we hear from Dipto Chakravarty, Geoff Hancock, and Tyrone Wilson.

Generously sponsored by

For more information or to register: www.issa.org/?April2015T.

Join the conversation: #ISSAWebConf

For more information on our webinar schedule:www.issa.org/?page=WebConferences.

UPCOMING

has been estimated that the processing time for Blinded Dif-fie-Hellman was reduced by thirty percent over that required using a similar station-to-station protocol.Feng Hao of Newcastle University, UK, described issues found in the standardized versions of the Simple Password Exponential Key Exchange (SPEKE) protocol in a conference paper presentation.3 The paper’s authors discovered securi-ty flaws using traditional research and analysis techniques that did not rely on formal analysis tools. Though he made no claims of flaws discovered in specific applications, his presentation on “The SPEKE Protocol Revisited” [2] revealed that SPEKE was subject to both key-malleability and imper-sonation attacks. SPEKE is a popular password-authenticat-ed key exchange (PAKE) protocol that has been widely used since the middle 1990s. Both TruePass products from Entrust and BlackBerry devices from Research in Motion are com-mercial deployments based on the SPEKE protocol.My own presentation of a “Standardization Transparency” [2] paper4 described flaws in the schema definition and mes-sage designs used for secure information exchange in several international standards. Defects were evident from simply reading the schema published in these standards. These flaws are present in the ISO/IEC 19785-4 Common Biometric Ex-change Format Framework (CBEFF) – Security block format, the International Civil Aviation Organization (ICAO) stan-dard for electronic passports, and the ISO/IEC 24761 Au-thentication Context for Biometrics specifications. The schema definition flaws stem from reliance on US Na-tional Institute of Standards and Technology (NIST) and National Security Agency (NSA) approved standards that do

3 https://eprint.iacr.org/2014/585.pdf.4 http://phillipgriffin.com/innovation.htm - PUBS.

not conform to any version of the schema definition language used to define their data types. Figure 2 provides examples of these schema definition flaws. The cryptographic message design flaws come from placing data security protections in optional message fields. An adversary can remove these op-tional fields. Figure 3 illustrates a message design flaw. This message design flaw appears in other standards as well. The ANSI/NIST ITL standard for the exchange of biometric information defines a Type 98 security record. International law enforcement and government agencies use the Type 98 record to protect shared biometric data and other informa-tion. However, like the CBEFF design in figure 3, the Type 98 record is optional and easily removed by an attacker.

Protocol analysis tools and techniquesThe presentations I chaired in the session on “Analysis with Formal Methods” provided me with the most benefit. These presentations described new tools and analysis results that would set the tone of the conference. In addition, the panel discussion on “Formal Verification and Analysis of Protocols in Standards Development and Evolution” that followed pro-vided a glimpse into the future of perfecting security proto-cols and cryptographic techniques.

Figure 2 – Schema definition flaws (Source: IEEE 52.1, p. 188)

Figure 3 – Message design flaws (Source: IEEE 52.1, p. 189)

April 2015 | ISSA Journal – 35

Formal Security Protocol Analysis | Phillip H. Griffin

©2015 ISSA • www.issa.org • editor@issa.org • All rights reserved.

From the 1980s well into the 1990s, formal security protocol analysis focused on Burrows–Abadi–Needham (BAN) logic. During this period, researchers developed threat models and performed security protocol analysis by hand. This approach was successful in discovering flaws and hidden assumptions in security protocols, the rules that govern information ex-change between communicating parties that require origin authenticity, message integrity, and data confidentiality. This early success stimulated interest in the development of threat model checkers and theorem provers supported by formal protocol analysis tools. Several SSR-2014 conference papers presented results obtained from the application of some of these new tools.

Cryptographic Protocol Shapes AnalyzerThe Cryptographic Protocol Shapes Analyzer (CPSA) is a software tool that attempts to create a list of all possible “shapes” of a cryptographic protocol. Each shape represents one possible protocol execution. The authentication and con-fidentiality properties of that protocol, as well as any anom-alies and possible attacks, can be determined from the list of generated CPSA shapes. CPSA tools developed by the MITRE Corporation5 are freely available for non-commercial use (see sidebar). CPSA supported the expression of protocol security goals in a paper describing an “enrich-by-need” analysis technique pre-sented by Paul D. Rowe, “Security Goals and Evolving Stan-dards” [2]. The paper proposed a minimalist, logical language of security protocol goals, and demonstrated its effectiveness by example, the mitigation of a known flaw discovered early in the evolution of the Kerberos PKINIT protocol. The au-thors noted that in order to achieve a decidable set of security goals, it was necessary to limit the expressiveness of the lan-guage. As such, their proposed language contained no data types, arithmetic expressions, or ability to define messaging syntax or schema required to implement and test actual secu-rity products.

Maude NPAMaude is a powerful programming language used for model-ing systems. Maude programs can model system operations, as well as how these operations interact. Category theory, a “general mathematical theory of structures and of systems of structures” [3], forms the basis of Maude semantics. In math-ematics, category theory is an alternative to set theory. Cate-gories are algebraic structures that when represented as func-tional definitions are useful in constructing security proofs of protocols. Maude-NRL (Naval Research Laboratory) Protocol Analyz-er (Maude-NPA) is a tool used to provide security proofs of cryptographic protocols and to search for protocol flaws and cryptosystem attacks. At the SSR-2014 conference, Cather-ine Meadows of NRL presented the results of new work that expanded the use of Maude-NPA to analyze the security ap-

5 http://hackage.haskell.org/package/cpsa

MITRE CPSAThe free MITRE CPSA tool distribution provides a tutorial ex-ample aimed at beginning users, the two step Blanchet key establishment protocol described in figure 4. This protocol has two roles, an initiator and a responder. Alice initiates the pro-tocol by creating a fresh symmetric key S. She signs S with the private component of her public-private asymmetric key pair. Alice then encrypts the signed key with the public component of Bob’s public-private key pair, KB. Alice sends the signed and encrypted key in a message to Bob.

Figure 4– Alice sends Bob a signed and encrypted key, and Bob responds with encrypted data

Bob receives the encrypted message from Alice. He decrypts the cipher text using the private key component of his pub-lic-private key pair to recover the signed symmetric key S. Bob then validates the signature on S using the public component of Alice’s public-private key pair to gain assurance that S has not been tampered with and that it was signed by Alice. Bob now encrypts some data D using S and sends the encrypted data to Alice, who can recover the plain text data using S, the same symmetric key she established with Bob.

The Blanchet protocol represented in CPSA in figure 5 is a set of roles and a problem description of what we assume happens when we operate the protocol described in figure 4. We can create the following CPSA example with a simple text editor:

(defprotocol blanchet basic (defrole initiator (vars (a b name) (s skey) (d data)) (trace (send (enc (enc s (privk a)) (pubk b))) (recv (enc d s)) ) ) (defrole responder (vars (a b name) (s skey) (d data)) (trace (recv (enc (enc s (privk a)) (pubk b))) (send (enc d s)) ) ))

Figure 5 –Blanchet protocol in CPSA (Source: MITRE Haskell CPSA package)

On a Windows platform, the user then clicks an icon that exe-cutes a Make.hs command on the resulting text file and types “build” to analyze the Blanchet protocol. The user can view the CPSA output in a web browser to examine what the tool inferred actually happened when the protocol was operat-ed, and what steps CPSA took to produce these results. From there, the tutorial takes the user through a detailed explana-tion of the CPSA results, then step by step though further pro-tocol refinements, modeling, and security analysis.

36 – ISSA Journal | April 2015

Formal Security Protocol Analysis | Phillip H. Griffin

©2015 ISSA • www.issa.org • editor@issa.org • All rights reserved.

thentication protocol. Unfortunately, these findings were not used at that time to detect similar faults in ISO/IEC 11770 key establishment protocols, even though these are derived from ISO/IEC 9798 authentication protocols. Improvements to ISO/IEC 11770 would have to wait for future work by Cas Cremers and Marko Horvat of the University of Oxford, presented in a paper9 at the SSR-2014 conference. In “Improving the ISO/IEC 11770 Standard for Key Man-agement Techniques” [2] the authors made use of Scyther to uncover incorrect security properties (i.e., protocol security claims) and to inform suggestions for future security im-provements. The use of automated techniques allowed them to examine variants of some 30 protocols in the 2014 edition of the standard. Their security protocol models and Scyther tools are freely available for download.10

Standards defect process problemsThe scope of what researchers are looking for can limit results obtained from formal protocol analysis models. A model con-structed to detect security flaws may be blind to defects that limit privacy protections. Analysts may not examine privacy features, even when the protocol being examined claims to offer privacy protections. This was the case with the Protocol for Lightweight Authentication of Identity (PLAID), which is currently being fast-tracked as international standard ISO/

9 http://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/CH2014-iso11770.pdf.

10 http://www.cs.ox.ac.uk/people/cas.cremers/scyther/.

plication-programming interface (API) of a hardware secu-rity module (HSM), the IBM 4758. The research examined the Common Cryptographic Architecture (CCA) API of this HSM device. Her presentation described a paper, “Analysis of the IBM CCA Security API Protocols in Maude-NPA” [2], in which the authors were first ever to apply a general-purpose tool to XOR-based API analysis, rather than developing spe-cial purpose solutions.

Tamarin and ScytherThe Tamarin prover6 is an open-source tool for security pro-tocol analysis and verification. The functional programming language Haskell7 implements Tamarin, using a backend en-vironment based on the Maude System8 and language. Tama-rin relies on a symbolic message theory model of Diffie-Hell-man exponentiation and supports unbounded verification or falsification of security protocols. It can both find new attacks automatically and verify the correctness of protocols with re-spect to a model. Tamarin is in the same family of tools as Scyther, another freely available protocol analysis tool. The application of a tool set combining Tamarin and Scyther found flaws in the ISO/IEC 9798-2 Entity Authentication standard. These find-ings led to the release of an updated version of the standard to correct defects identified in one version of a mutual au-

6 http://www.infsec.ethz.ch/research/software/tamarin.html.7 https://wiki.haskell.org/Haskell.8 http://maude.cs.illinois.edu/w/index.php?title=The_Maude_System.

Guest Keynote Speaker

ANDREW MCAFEEScientist, best-selling

author, and cofounder of MIT’s Initiative on the

Digital Economy

Save $300 o� the onsite costfor a Full Conference Pass

DIAMOND SPONSORS

DIAMOND MEDIA SPONSORPLATINUM SPONSORS

FOLLOW US ON: #RSAC

Register Now! www.rsaconference.com/issa

n 3 new tracksn RSAC Innovation Sandboxn Crowdsourced sessions

Exciting features of RSA Conference 2015:n Great lineup of Keynote speakersn Our popular Peer2Peer sessionsn Live streaming video on RSAC TV

Discount ends April 17

23Tracks

350+Sessions

500+Exhibitors

April 2015 | ISSA Journal – 37

Formal Security Protocol Analysis | Phillip H. Griffin

©2015 ISSA • www.issa.org • editor@issa.org • All rights reserved.

identify cards. The attack allowed an adversary to determine all of the cryptographic keys supported by the smart card. These security and privacy defects were reported to the stan-dards development committee responsible for PLAID, along with proposed corrections. However, this action has not resulted in any corrective changes being made to the draft PLAID standard. Based on changes made in subsequent revi-sions, it appears that the standard will be progressed without addressing the reported defects.The benefits of research findings may not always find their way into security protocol standards, even when they have been presented to the committees of standards development organizations. In another event, analysis results found in the ISO/IEC 9798 Entity Authentication standard using the Scyther tool in 2012 were reported, and several problems were identified and corrected. However, these results could have been applied years earlier to the ISO/IEC 11770 Key Management standard to protocols that are derived from those in ISO/IEC 9798.

Future workHow can formal protocol analysis benefit information se-curity practitioners today? Though formal analysis tools are improving rapidly, they are not yet able to be of direct bene-fit in helping us to secure our systems. Their primary benefit today lies in their ability to detect flaws in protocols defined in information security standards, and in assisting standards developers in choosing the most secure fixes from a set of al-ternatives when correcting defects. The next Security Standardization Research 201516 confer-ence this year in Tokyo, Japan, may yield more progress. However, formal protocol analysis is not yet a requirement of standards bodies, and security proofs are not likely to be included in standards texts. As current research evolves and

16 http://www.ssr2015.com/.

IEC DIS 25182-1.11 PLAID intends to provide a secure and private authentication protocol between a smart card (ICC) and terminal. The PLAID protocol attempts to find the middle ground between fast tag-based RFID solutions that transfer data in the clear and slower PKI-based solutions that protect data and provide authentication at the cost of speed. PLAID can support multi-factor authentication solutions that pair stan-dards-based cryptography commonly available on ICCs with biometric technologies and cardholder PINs. Security aspects of PLAID were examined to some extent using the ProVerif12 and Scyther modeling tools, but this research did not include analysis of PLAID’s privacy claims.PLAID is a national standard being promoted by the Aus-tralian Department of Defense and Department of Human Services. These agencies promote PLAID adoption by pro-viding unencumbered intellectual property and a freely available reference implementation.13 In the US, NIST has promoted the adoption of PLAID.14 The US also heads the ISO/IEC group that manages the fast-track processing of the draft PLAID standard. Responsibility for developing the ISO/IEC DIS 25182-1 standard has not been assigned to the SC 17 Cards and Personal Identification subcommittee that usually develops such card security standards.As reported at the SSR-2014 conference in the presentation by Victoria Fehr on “Unpicking PLAID,”15 “the privacy prop-erties of PLAID are significantly weaker than claimed” [2]. Using standard statistical and data cryptanalysis techniques, security researchers were able to fingerprint, and then later

11 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62591

12 http://prosecco.gforge.inria.fr/personal/bblanche/proverif/.13 http://www.humanservices.gov.au/corporate/publications-and-resources/plaid/.14 http://csrc.nist.gov/news_events/plaid-workshop/.15 https://eprint.iacr.org/2014/728.pdf.

A Wealth of Resources for the Information Security Professional – www.ISSA.org

Secure Development Life Cycle for Your Infrastructure2-Hour Event Recorded Live: Tuesday, March 24, 2015

Cybersecurity – New Frontier2-Hour Event Recorded Live: February 24, 2015

Security Reflections of 2014 & Predictions for 20152-Hour Event Recorded Live: January 27, 2015

Dorian Grey & The Net: Social Media Monitoring2-Hour Event Recorded Live: Tuesday, November 18, 2014

Cybersecurity and Other Horror Stories2-Hour Event Recorded Live: Tuesday, October 28, 2014

Encryption: The Dark Side: Things to Worry about for 20142-Hour Event Recorded Live: Tuesday, September 30, 2014

Cyber Analysis Tools: The State of the Union2-Hour Event Recorded Live: Tuesday, August 26, 2014

Global Cybersecurity Outlook: Legislative, Regulatory and Policy Landscapes2-Hour Event Recorded Live: Tuesday, June 24, 2014

Breach Report: How Do You Utilize It?2-Hour Event Recorded Live: Tuesday, May 27, 2014

Doing it Right: Organizations That Seem Immune to Security Attacks2-Hour Event Recorded Live: Tuesday, April 22, 2014

Click here for On-Demand Conferences

38 – ISSA Journal | April 2015

Formal Security Protocol Analysis | Phillip H. Griffin

©2015 ISSA • www.issa.org • editor@issa.org • All rights reserved.

We should also carefully examine the design and validity of the security protocol messages we rely on. Standards devel-opment organizations (SDOs) should correct cryptographic message design defects such as those illustrated in “Security Standardization Transparency,” and implementations based on these defective standards should be repaired. SDOs should review continued reliance on core security standards whose schema validity defects have remained incorrect since the 1990s. Reference to suitable substitutes should replace refer-ence to any flawed standards where possible. We should standardize definitions and notation used to con-struct security protocol models, so that models used for one protocol can be compared with others. We should make it possible to more easily modify and apply models to similar protocols. SDOs should be encouraged to include security proofs based on standardized models in their work, and these models should guide the design, development, and testing of vendor products. Standardization of notation and models may allow security protocol analysis models to one day feed development of the protocol test tools practitioners need for gaining assurance that vendor products implement these pro-tocols correctly.

References[1] Fábrega, F. J. T., Herzog, J. C., & Guttman, J. D. (1998, May). Strand Spaces: Why is a security protocol correct?. Se-curity and Privacy, 1998. Proceedings. 1998 IEEE Symposium on (pp. 160-171). IEEE. Retrieved February 22, 2015, from http://www.dtic.mil/dtic/tr/fulltext/u2/a459060.pdf.[2] Chen, L., & Mitchell, C. (Eds.). (2014). Security Standard-isation Research, First International Conference, SSR 2014, London, UK, December 16-17, 2014. Proceedings (Vol. 8893). Springer. Retrieved February 22, 2015, from http://www.springer.com/computer/security+and+cryptology/book/978-3-319-14053-7.[3] Marquis, Jean-Pierre. Category Theory, The Stanford En-cyclopedia of Philosophy (Winter 2014 Edition), Edward N. Zalta  (ed.). Retrieved February 22, 2015, from http://plato.stanford.edu/archives/win2014/entries/category-theory/.[4] Menezes, A. (2007). Another look at HMQV. Mathemati-cal Cryptology JMC, 1(1), 47-64. Retrieved February 22, 2015, from http://eprint.iacr.org/2005/205.pdf.

About the AuthorPhillip H. Griffin, CISM, has over 20 years experience in the development of commer-cial, national, and international security standards and cryptographic messaging protocols. Phil has a Master of Information Technology, Information Assurance and Se-curity degree and he has been awarded nine US patents at the intersection of biometrics, radio frequency identification (RFID), and information security management. He may be reached at phil@phillipgriffin.com.

protocol analysis tools mature, their use promises in the fu-ture to strengthen our ability to assess the security properties of implementations, and one day to gain greater assurance in the effectiveness of the products we rely on.Before that can happen, there are gaps to bridge between cur-rent protocol analysis tools, the standards development pro-cess, and the tools needed to test and evaluate protocol imple-mentations and products. On the front end of the process, a common notation should be developed to define models, so that there is an agreed way to define messages, such as the one shown in figure 6. The ISO/IEC JTC 1/SC27 IT Security Techniques group17 could take the lead in this area, and make a standard modeling notation freely available to other indus-try, national, and international standards groups.

Figure 6 – Two notations for encrypting message M with key K

A standardized model representation could have many bene-fits. Having standardized models might encourage standards bodies to include them in their publications. A standard modeling notation would allow comparison of models and make them easier to modify and apply to similar protocols. In addition, a standard model notation could make it easier to combine current and future tools for protocol analysis. The current tool-specific models could be mapped to a standard model without requiring tool modifications.On the other end of the process, where implementers build products that security professionals use to mitigate security risk, there are other gaps to bridge. Test case messaging needs to flow from protocol analysis tools. Such messages defined in a standardized schema can provide product implementers with test cases and expected test case results for each pro-tocol examined. By successfully passing or failing test cases as expected by formal protocol analysis, product developers can gain assurance that they have correctly implemented a given security protocol. Standardized protocol test case suites might pave the way for product validation and certification activities, such as those offered by NIST and other organiza-tions.

ConclusionsAs security researcher Alfred Menezes wisely cautions, any claim that “a cryptographic protocol is ‘provably secure’ should always be met with a healthy dose of skepticism” [4]. As the case of “Unpicking PLAID” revealed, we should ensure that the protocol model used to provide assurance covers all, and not just some, of its claims. We must question and thor-oughly test the validity of all assumptions that support the model. The proof should cover the types of attacks and “at-tackers that one could expect in the environments in which the protocol will eventually be deployed” [4]. Finally, we need to ensure that the correctness of the proofs we rely on are checked and their claims of correctness adequately verified.

17 http://www.iso.org/iso/iso_technical_committee.html?commid=45306.

April 2015 | ISSA Journal – 39

Formal Security Protocol Analysis | Phillip H. Griffin

©2015 ISSA • www.issa.org • editor@issa.org • All rights reserved.