On Automatically Patching Faulty Security Protocols Final Report

On Automatically Patching Faulty Security Protocols Final Report DAAD A/06/32941, CONACyT J110.382/2006

Ra´ ul Monroy (Host Dieter Hutter)

1

Summary

This document reports on the academic activities carried out under the grant DAAD A/06/32941, CONACyT J110.382/2006, funded by both DAAD, Germany, and CONACyT, Mexico. This grant enabled Ra´ ul Monroy to carry out a three-month research stay, visiting Dr. Dieter Hutter at DFKI, Saarbr¨ ucken. The research stay was originally planned to take place from February 1 to April 30, 2007 but was moved to the period January 7 — March 31, 2007. The motivation behind this change was severalfold, including i) avoidance of possible delays due to clashes with Easter and CIAO, a workshop in Scotland that both Dr. Hutter and Dr. Monroy were expected to attend; ii) other projects activities (e.g. preparation of BMBF and EU-funding proposals) that were unforeseen at the time of writing the proposal; and iii) the start of the academic term in April in Germany. While this report focuses on the outcome of Monroy’s visit to DFKI, it also conveys our full set of results and achievements, for the research conducted during the stay is part of a longer, ongoing collaboration. This report also outlines plans on further research.

1.1

Research Goals and Achievements

The objectives of the project, as stated in the original proposal, were to lay out the foundations for a system to support the development of complex security protocols by complementing verification with (diagnose and) repair. We suggested to address protocol repair following a two-step approach. In the first step, the system applies an existing verification tool to validate an intermediate protocol, computing an attack if the protocol is flawed. Second, it analyses the attack to localise the source of the failure, synthesising appropriate patches to the protocol. We have successfully achieved our goals. Results of our research include: • The formalisation and refinement of three patch methods which almost deal with the full class of replay attacks proposed by Syverson [7], the only exception being the type flaw attack subclass. A replay attack is a form of attack where a valid data transmission is repeated or delayed. A type flaw attack is an attack where a participant confuses a (field of a) message containing data of one type with a message data of another; • One paper [6], titled “On the Automated Correction of Security Protocols Susceptible to a Replay Attack”, submitted to the major European forum in computer security: the 12th European Symposium Research Computer Security, ESORICS’07 ; • Joint supervision of one PhD student, Juan Carlos L´ opez-Pimentel, who is expected to defend his thesis before the end of the year; and • A web page reporting on our results: http://homepage.cem.itesm.mx/juan.pimentel/pub/shrimp.htm

1

2

Automatically Fixing Security Protocols

Security protocols consist of only a few messages but are very hard to get right. Although there exist a number of verification approaches, as well as informal guidelines for strengthening their design, a lot of protocols, whether recent or not, are faulty. Thus further support for the development of security protocols is required. We have developed Shrimp, a Smart metHod for Repairing IMperfect security Protocols. Shrimp aims at speeding up the formal software development cycle, bridging the gap between design and analysis by means of diagnosis and repair. Shrimp offers benefits to practising computer security engineers, including getting a better insight into a protocol flaw and enabling an incremental protocol design. These features are all of interest because nowadays protocols are more complicated than just 3—5 steps (e.g. the SET protocol) and various parts of the protocol are intertwined, making it hard for a human to cope with all the subtle dependencies. Shrimp relies on existing state-of-the-art tools to verify an (intermediate) protocol and to find one or more of protocol runs that violate a given security requirement, called an attack. It then analyses both the protocol and the attack to pinpoint the faulty steps of the protocol and synthesises appropriate changes to fix them. This yields an improved version of the protocol that should be analysed and potentially patched again until no further flaws can be detected. To identify and patch a protocol flaw, we have translated some of the informal principles for the design of security protocols of Abadi and Needham [1] into formal requirements on sets of protocol steps. For each requirement, there is a collection of rules that transform a set of protocol steps violating the requirement into a set conforming it. The correction of security protocols incorporates the use of several of these rules. However, the patches are not independent and the application of a rule requires preconditions to be applicable and should guarantee postconditions once it has been applied. As a general framework to organise the application of such rules, we have adopted the proof planning methodology [2], developed to automate inductive theorem proving. We have hitherto focused on automatically fixing protocols subject to a replay attack, given that many known faulty protocols fail to resist it.1 During this research stay, we have formalised and refined two patching methods which, together with a generalisation of that presented in [5], almost deal with the full class of replay attacks proposed by Syverson [7], the only exception being the type flaw subclass. We have successfully tested Shrimp on 36 protocols, 21 out of which were borrowed from the Clark and Jacob library, obtaining a repair rate of 90%.

2.1

Specific Outcome of Research Stay

During the research stay, Dr. Hutter and I worked together in the formalisation of security protocol repair. We distinguished that a protocol flaw arises out of an improper formulation of loose synchronisations that two or more participants conduct in order to achieve a security goal, e.g. identity authentication or key distribution. It turns out that such loose synchronisations have been formalised in the context of strand spaces [8], giving rise to so-called authentication tests [4]. We are thankful to Joshua Guttman to have pointed out this to Dr. Hutter. Using authentication tests, we have been able to develop a formalism for protocol repair. This formalism is a neat meta-logic that allows us to reason about: the encoding of messages; the ways in which messages are used by an intruder to perpetrate an attack; and the bits that need to be added to prevent a particular attack. Thus the main outcome of the research stay is a clear formulation of protocol patch methods that have been successfully applied to repair a number of protocols. This formalism has been reported in a paper [6], that has been submitted to the major European forum in computer security. Additionally, during this research stay, Dr. Hutter and I laid out some foundations on further research projects. In particular, we would like to work on the formal management of change of security protocols (see Section 4.) 1 Most

of the attacks reported in the Clark-Jacob library [3] are of type replay.

2

3

Results

Table 1 summarises our results. We considered 36 experiments, of which 20 involve protocols borrowed from the Clark-Jacob library;2 4 are variants of some of these protocols (annotated with
); and 12 are protocols output by Shrimp, a next-generation of an input protocol. Next-generation protocols are shown in a separate row within the associated entry. Protocol Andrew Secure RPC BAN ASRPC CCITTX.509(1) CCITTX.509(3) Denning-Sacco SK Needham-Schroeder SK Denning-Sacco PK Kao Chow Auth V.1 KSL Needham-Schroeder PK BAN Otway-Rees Splice/AS Clark-Jacob Splice Hwang-Chen Splice Wide Mouthed Frog WMF revisited
ASRPC prune


Woo-Lam Mutual BAN Yahalom A. Diffie Hellman
2steps SK


s T T T T T T T T T T T T T F T T T T T T T T T T T T T T T T T T T

wai T F F T F T T T T F T T F X F X T F X F T T F T T T F T X X X X T

before sai war T T X X X X F X X T F X T T X T F† T X X F X F† T X X X T X X X F F T X T X F X X F X F X X X X F X T F T X X T F X F X T X F X T F T

sar F X X X T X F F T X X T X T X X X T X X X X X X F T X X X F X F T

M B N N B N B B B B N B B E N N N B B N E B B N N B B E E N B N B B

s T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T

wai T T T T T T T T T T T T T T T T T T X T T T T T T T T T X X X T T

after sai T T X T T T T X T X T T T T X X T T X X T T X X X T T T X X X X T

war T T X T T T T T T X X T T T X T T T T X T T X T T T T T T T T T T

sar T T X T T X T T T X X T T T X X T T X X T T X X T T T T X T X T T

Table 1: Experimental results

Each row displays the result of testing a protocol against a (hierarchical) collection of properties: secrecy, s, weak authentication of the initiator, wai (respectively responder, war ) and strong authentication of the initiator, sai (respectively responder sar ), where wai < sai (respectively war < sar .) The table separates the verification results for the original protocol, before, and the mended protocol, after, as output by Shrimp. The field value that exists at the intersection between a protocol P and a property φ might be either T, meaning P satisfies φ, F, meaning P does not satisfy φ, or X, meaning this property was not tested (because P was not expected to satisfy it.) Column M specifies the method that was applied to modify each faulty protocol: message (E)ncoding, agent (N)aming or session (B)inding. Note that whenever a patch method is applied, then the revised protocol is up to satisfy the security property that the original one did not yielding the attack. Whenever applicable, 2 The Clark-Jacob library comprehends 50 protocols, 26 out of which are known to be faulty. So our validation test set contains all but 6 of these security protocols. The faulty protocols that were left out are not susceptible to a replay attack.

3

each mended protocol was then further requested to satisfy the remaining, stronger properties in the hierarchy, thus explaining why some entries have several runs. Note that in the discovery of some attacks we had to specify the possibility of losing a session key (annotated with †.) We have successfully tested Shrimp on 36 protocols, 21 out of which were borrowed from the Clark and Jacob library, obtaining a repair rate of 90%. For a full account of our results, the reader is referred to the paper attached to this report [6] or to the project web page http://homepage.cem.itesm.mx/juan.pimentel/pub/shrimp.htm.

4

Further Work and Conclusions

We have developed Shrimp, a method for automatically repairing faulty security protocols. Shrimp consists of a collection of patch planning methods. Each patch method is designed to transform a set of protocol steps violating one of the design principles postulated by [1] into one conforming it, while ruling out the possibility of violating other principles. We have carried out a large number of experiments to validate Shrimp, finding that it successfully deals with the class of replay attacks, except for the subclass type flaw. While this research has contributed to security protocol development, there is still a lot of room for improvement. In the short-term, we will extend Shrimp to cope with type flaw attacks, as hinted above. In the medium-term, we plan on submitting a new proposal to carry out research on the management of protocol change, motivated by the following two observations: i) patch methods are independent of the global security requirements demanded from the faulty protocol under analysis; ii) the local change of one or two protocol steps, in combination with other protocol steps that have been not previously considered, may cause a violation to these requirements. Therefore, we would like to consider global rules that control the local patch process. We would also like to carry out research on the development of a system to support the “security-invariant” enlargement of security protocols. The system would provide development patterns and heuristics to assist the user in adding new features to protocols, fixing bugs in the design, etc.

5

Doing Research at DFKI

I thoroughly enjoyed doing research at DFKI. The Deduction and Multi-Agent-Systems research group provides an encouraging forum in which one can discuss ideas and obtain useful feedback. I am very grateful to my host and colleague, Dr. Dieter Hutter, for his careful advise on my research and on everyday aspects, without which my stay in Germany would not have been as fruitful.

References [1] M. Abadi and R. Needham. Prudent engineering practice for cryptographic protocols. IEEE Transactions on Software Engineering, 22(1):6–15, 1996. [2] Alan Bundy. The use of explicit plans to guide inductive proofs. In R. Lusk and R. Overbeek, editors, Proceedings of the 9th Conference on Automated Deduction, volume 310 of Lecture Notes in Computer Science, pages 111–120. Springer-Verlag, 1988. [3] J. Clark and J. Jacob. A survey of authentication protocol literature: Version 1.0. Technical report, Department of Computer Science, University of York, November 1997. Available at http://www.cs.sri.com/ millen/capsl/. [4] J.-D. Guttman and F.-J. Thayer. Authentication tests and the structure of bundles. Theoretical Computer Science, 283(2):333–380, 2002.

4

[5] J. C. L´ opez-Pimentel, R. Monroy, and D. Hutter. A method for patching interleaving-replay attacks in faulty security protocols. Electronic Notes in Theoretical Computer Science, 171:to appear, 2006. [6] J. C. L´ opez-Pimentel, R. Monroy, and D. Hutter. On the automated correction of security protocols susceptible to a replay attack. In Submitted to the 12th European Symposium Research Computer Security, ESORICS’07, Lecture Notes in Computer Science, page ?, 2007. [7] Paul Syverson. A taxonomy of replay attacks. In Proceedings of the 7th IEEE Computer Security Foundations Workshop, CSFW‘94, pages 187–191. IEEE Computer Society, 1994. [8] F. J. Thayer Fabrega, J.C. Herzog, and J.D. Guttman. Strand spaces: Why is a security protocol correct? In Proceedings Symposium on Security and Privacy., volume 15, pages 160–171, Oakland, CA, USA, 1998. IEEE computer Society.

5