Security protocols from the software verification perspective

Transcription

1 Security protocols from the software verification perspective Erik Poll 1 and Aleksy Schubert 1,2 1 Radboud University Nijmegen, the Netherlands 2 Warsaw University, Poland Abstract. We believe that it is important to verify not just the correctness of abstract security protocols, but also to verify the correctness of real implementations of security protocols. Considerable research is needed to facilitate the development process for such implementations both in terms of mathematical formalisms to describe protocols, and tools that carry out their verification. For starters, it is no longer sufficient to consider abstract, idealised (fragments) of security protocols, but we have to consider complete real-life security protocols, warts and all. The goal of this paper is to stimulate discussion on what would be the best formal languages to specify these procotols and what would be suitable methods to express and verify formal properties of their implementations. 1 Introduction It is now well-understood that the design of correct security protocols is a highly non-trivial task. The formulation of precise attacker models (e.g. [DY81]) and the application of the formal methods to the analysis of such protocols (e.g. [BAN90,BHS91,HSD + 05]) resulted in many improvements. The past decade has seen a considerable progress in the field of formal analysis of security protocols, which has resulted in many methods and tools for protocol verification (e.g. [Vig06,Bla06,Mil96]). Similarly, the last years have seen progress in the field of program verification. Many approaches emerged that allow to specify and verify many interesting properties of programs written in the full scale programming languages such as Java, C# or even C (e.g. [FLL + 02,ABB + 04,BLS04,Bar03,FM04]). Additionally, the evolution of the software engineering technologies suggests that programs should result from abstract models. Still, despite this progress, there is a considerable gap between the world of formal methods for security protocols and the world of program verification. Moreover, there is considerable gap between the world of formal methods for Supported by the Sixth Framework Programme of the EU under the MOBIUS project FP Supported supported by the Sixth Framework Programme of the EU under the SOJOURN project MEIF-CT

2 security protocols and security protocols in the real world. We believe that these are important issues to be tackled, and that these are in fact the obvious next steps to be tackled, given the progress in the field of security protocol analysis. Indeed, there is already some work in this direction, e.g. [BFG06], but we feel there needs to be more. 2 The experience of a verification We have approached the topic of security protocol verification with a case study where we analysed and formally verified an open source Java implementation of SSH, called MIDP-SSH 3. Here we give a global overview of this analysis and verification, which involved some ad-hoc manual code inspection (Section 2.1), some formal verification of basic properties (Section 2.3), and some formal specification of the protocol and formal verification that this specification is met (Section 2.4), which required some analysis of the official, informal specification of SSH (Section 2.2). For the technical details of the verification tools and techniques used we refer to [PS06]. Instead, the aim here is to highlight the issues where improvements are needed to enable more rigorous and formal analysis. 2.1 Manual inspection The first stage of our work was an ad-hoc manual inspection of the source code. We familiarised ourselves with the design of the application, considered which parts of the code are security-sensitive, and looked for possible weaknesses. This led to discovery of some common mistakes or at least bad practices which should be avoided in security-sensitive applications: 1. Weak/no authentication the SSH protocol mandates that the server should authenticate itself with the user. The normal procedure is that the user obtains an authentication data (e.g. by physical contact with the server administrator) and compares this with what is obtained through the network. This scenario, however, requires a kind of persistent storage on the client s side. In case of the implementation, there was no such storage. 2. Poor use of Java access restrictions (i.e. private, public) this is crucial if the program analysed will be part of a bigger piece of software, some parts of which might not be trusted. Poor use of access restrictions make software vulnerable to simple bugs or malicious behaviour of other components. 3. Control characters the RFCs require that all the characters which come from the network and are displayed on the terminal should be examined to make sure there is no attack by malicious sequences of control characters. The implementation does not make any special checks to this end. Still, it supports some of the control characters that may be used in attacks of this kind. 3 Available from 2

3 4. Downloading of the session information the application allows the user to download an address of an SSH server and a login in clear-text from a web page. In certain environments, this kind of scenario is a violation of the security policy, as the association between an SSH server and a user name is revealed. New research perspectives All of these properties are relatively easy to check by hand, but of course such human code inspection cannot guarantee the absence of problems. The cases (1,3,4) can be verified by a mixture of the functional specifications written e.g. in JML [BCC + 05] (to make sure that the operation is performed properly) and the information flow techniques such as in JFlow [Mye99] (to make sure that the operation is executed on all interesting flows). Unfortunately, these two modes of specification are available in different toolsets and require a verifier to point out relevant places in the source code. There is, however, no formalism to specify a general property like this code should somewhere handle the following operation and a general formal logical mechanism to support the narrowing down of the scope of the source code relevant to the property. In case of (2), there is no tool that allows to specify this kind of property in a logical way, though there are tools that will automatically tighten access control, e.g. Jamit 4. A partial answer to these problems can be offered by source code analyser, e.g. FindBugs [HP04], which just discover syntactical patterns which suggests potential bugs. Still, such tool have limitations, as they have no full understanding of the semantics of programs. 2.2 The protocol specification in natural language The SSH protocol is specified in a series of RFC documents written in English [Ylö06c,Ylö06a,Ylö06d,Ylö06b]. These specifications are not always clear, consistent, or precise. 1. Using some form of state diagram or finite state machine (FSM) is very helpful to give a clear specification of a protocol, as is done e.g. for TCP [Pos81] an PPP [Gro94]. Unfortunately, the SSH specifications do not, and leave the notion of state implicit. (There is a notion of a protocol stage, but this is on a higher level of abstraction.) The absence of a clear notion of state is a source of unclarity in the specification. 2. The main problem is that only the scenario of a correct protocol run is described in full detail, whereas what should happen in in case something goes wrong is only alluded to, and in many places which are spread over the various RFCS that make up the specification of SSH. That makes it diffictult to figure out if upon receipt of an unexpected or ill-formatted message at a particular point during the protocol, this should be completely ignored, be reported but then ignored, or lead to disconnection. 4 Available from 3

4 3. Another source of unclarity is the way the standard keywords are used in the specifications. There is an IETF standard which precisely defines the meaning of terms such as MUST, MAY, RECOMMENDED, and OP- TIONAL [Bra97], but the SSH specification is not consistent in using of the keywords. 4. IETF requires specifications to avoid implementation-specific descriptions. This, however, is hard to achieve in practice. For instance, the description of the initialisation procedure in [Ylö06d, Section 6] suggests that both sides must send an identification string. This is interpreted in the reference implementation, OpenSSH, as the client waiting for an identification string from the server and then responding. Clearly, this interpretation may lead to non-interoperable implementations, in case both client and server wait for the other party to start. However, the sequence of events in the reference implementation was the only possibility in an earlier draft of the protocol [Ylö95]. 5. Finally, in [Ylö06d, Section 6] it is not clear if a well-formed packet may have a zero-length payload section or if such a packet should always be treated as malformed, because it is impossible to determine its type, which is crucial for any handling of the packet. The specification does not forbid such packets, but OpenSSH treats them as an error and quits the client. Not sure if I quite follow this paragraph New research perspectives The IETF standardization process includes at one of the stages a requirement for a protocol proposal to be accompanied by a reference implementation the implementation process allows to avoid certain unclarities. On the other hand, specifications should avoid the implementation details. It seems, however, that with this approach it is quite difficult to assert which requirements are implementation-specific and which are not. Moreover, all the unclarities mentioned above were spotted by us because we were faced with a specific specification task how to express the particular property to be verified. This suggests that the formal specifications with a verified implementation may provide a reasonable level of abstraction to stay away from the implementationspecific descriptions and to make the protocol descriptions clear. A focus of the research community on the needs of such specifications can result in cleaner protocol descriptions. A fundamental complication, which contributes to some of the issues above, is that SSH is in fact a family of interoperable protocols, with various options that may or may not be supported by particular implementations. This contributes to issue 3) above, as optional parts mean some behaviour MAY be supported. It also contributes to issue 2) above, as it means that an unsupported message should not always lead to disconnected, but may require a different response. Note that standard notions for abstract security protocols often also only describe the scenario of a complete, correct protocol run, leaving it implicit that the protocol run should be aborted when any deviation happen. Real protocols are not so simple, as some deviations should be accepted. 4

5 2.3 Basic verification The examination of the specifications in the natural language was conducted in parallel with the actual specification and verification. The standard first step in using the ESC/Java2 verification tool [CK04] is to check that the program does not produce any runtime exceptions. Just establishing exception freeness requires the formalisation of many properties about the code, as JML preconditions, invariants, and sometimes postconditions. For instance, invariants that certain reference fields cannot be null are needed to rule out NullPointerExceptions, and invariants that certain integer fields are not negative or have some maximum value are needed to rule out ArrayIndexOutOfBoundsExceptions. New research perspectives The result of the basic verification process was that the format of the incoming packets is checked in a complete way. This also allowed to discover the above-mentioned inconsistency in the protocol description concerning the packets with zero-length payload section. Interestingly enough, this work did not lead to any improvement for the outgoing packets. The formulation of specifications for this task requires more work as the code which generates the outgoing data is considerably less structured. It would be, however, interesting to see a particular method to make sure that there are no implementation flaws in this code. This requires additional research. Of course, it would be great to have similar tool support as ESC/Java offers for detecting ArrayIndexOutOfBoundsExceptions in Java programs for C programs, especially since access outside array bounds are much more of a security threat in C. 2.4 Verification with a finite state machine The next task was the verification that the implementation obeys the FSM we extracted from the RFCs. Ideally, this FSM should be of course be part of or formally related to some abstract description of the security protocol that was formally analysed and proved to meet its security goals. Obtaining the FSM was difficult. One challenge was understanding and hopefully correctly interpreting the informal protocol description. A more practical challenge was managing the size and complexity of the FSM describing the protocol: SSH involves 15 different kinds of messages and each of these messages should be somehow handled in each of at least 9 states, resulting in 135 transitions to care about. In the case of our application, it turned out that it is necessary to rewrite a part of the source code to be able to relate it to the FSM we obtained, as the implementation was seriously flawed in its handling of some messages arriving out not in the correct order. New research perspectives First of all, there is a gap between the tools that verify the synthetic protocol descriptions and the ones that generate specifications. 5

6 informal, official specification? implementation formal specification Fig. 1. The relation between the informal RFC specifications, implementation and formal specifications to be verified There are tools which are able to generate protocol implementations based on formal specifications in versions of the π-calculus [BFG06,TH04]. These, however, neglect the need to generate the source code specifications which is important as these are a good candidate as a formalism to combine properties that arise when verification of synthetic descriptions is done in different tools or when the source code of the protocol should be conjoined with other part of the source code base. Still, the tools that generate specifications (such as AutoJML [HOP04]) do not support in full the synthetic protocol specification languages. Both of these kinds of tools suffer from the lack of good formalism to handle the aforementioned size of the protocol. The process of specification, reimplementation, and verification led us to the following further question: 1. Is it possible to devise protocols for which it is impossible to handle the protocol state improperly? The answer to this question seems to be affirmative. In fact, a simple modification of the MAC generation scheme should give the right solution. The implementations should not only generate MD5 or SHA1 sum from the current packet content, but for the packet content concatenated with a message authentication code of the previous packet in the exchange (the previous packet should, however, be chosen carefully). Now that we answered the question affirmatively, we can add a further difficulty. Is it possible to verify that a particular protocol admits only safe implementations in the sense that the protocol state must be properly handled? 3 Conclusions Ideally we would have implementations of protocols that have been formally verified against formal protocol descriptions, which in turn have been formally 6

7 verified to meet their security objectives. But despite the advances in the fields of protocol verification and program verification there are still huge gaps between (i) the official, informal specifications, (ii) actual implementations, and (iii) formal models of the abstract security protocol that have been verified. In [PS06] we show that verifying a real implementation of a security protocol against a formal model is possible. Nevertheless, the formal model we use, a finite state machine (FSM), is still only an incomplete specification of the protocol and is not always easy to extract from the formal models used in security protocol verification. The idealized development of verified implementations of security protocols could look as follows: A protocol written in an RFC is formalised together with all its modalities and formally verified to meet its security objectives; then code is either generated from this formalisation, or is verified against it. The whole process allows to rewrite the original descritption in RFC to be clearer and at the appropriate level of abstraction. Moreover, it results in an implementation for which the security is assured with greater certainity. This scenario, as indicated earlier, needs many improvments in the tool and logical formalism support. The existing protocol formal description techniques usually consider only particular facets of the verification. A considerable effort is needed to combine them to enable feasible verification that can be modularised to easily handle these tasks. We presented here particular areas which could be considered to make the verification techniques more accessible for the software industry. In our opinion, improvements in this scope would be a strong point in convincing engineers to adopt these methods. References [ABB + 04] W. Ahrendt, Th. Baar, B. Beckert, R. Bubel, M. Giese, R. Hähnle, W. Mostowski, A. Roth, S. Schlager, and P. H. Schmitt. The KeY tool. Software and System Modeling, To appear. [BAN90] M. Burrows, M. Abadi, and R.M. Needham. A Logic of Authentication. ACM Transactions on Computer Systems, 8(2):18 36, [Bar03] J. Barnes. High Integrity Software: The SPARK Approach to Safety and Security. Addison Wesley, [BCC + 05] L. Burdy, Y. Cheon, D.R. Cok, M.D. Ernst, J.R. Kiniry, G.T. Leavens, K.R.M. Leino, and E. Poll. An overview of JML tools and applications. International Journal on Software Tools for Technology Transfer (STTT), 7(3): , [BFG06] Karthikeyan Bhargavan, Cédric Fournet, and Andrew D. Gordon. Verified Reference Implementations of WS-Security Protocols. In WS-FM, pages , [BHS91] F. Belina, D. Hogrefe, and A. Sarma. SDL with APPLICATIONS from PROTOCOL specification. Prentice Hall, [Bla06] Bruno Blanchet. ProVerif: Automatic Cryptographic Protocol Verifier User Manual. CNRS, Départment d Informatique, École Normale Supérieure, Paris, September available from blanchet/crypto/proverif-manual.ps.gz. 7

8 [BLS04] Mike Barnett, K. Rustan M. Leino, and Wolfram Schulte. The Spec# programming system: An overview. In Construction and Analysis of Safe, Secure and Interoperable Smart devices (CASSIS), number 3362 in LNCS, pages Springer, [Bra97] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, The Internet Engineering Task Force, Network Working Group, March [CK04] David R. Cok and Joseph R. Kiniry. ESC/Java2: Uniting ESC/Java and JML. In G. Barthe et.al., editor, CASSIS 2004, number 3362 in LNCS. [DY81] Springer, Danny Dolev and Andrew C. Yao. On the security of public key protocols. Technical report, Stanford University, Stanford, CA, USA, [FLL + 02] Cormac Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Nelson, James B. Saxe, and Raymie Stata. Extended static checking for Java. In PLDI 02, pages , New York, NY, USA, ACM Press. [FM04] Jean-Christophe Filliâtre and Claude Marché. Multi-Prover Verification of C Programs. In Sixth International Conference on Formal Engineering Methods (ICFEM), volume 3308 of Lecture Notes in Computer Science, pages 15 29, Seattle, November Springer-Verlag. [Gro94] Network Working Group. The Point-to-Point Protocol (PPP). RFC 1661, [HOP04] [HP04] The Internet Engineering Task Force, Network Working Group, July E.-M.G.M. Hubbers, M.D. Oostdijk, and E. Poll. Implementing a formally verifiable security protocol in Java Card. In Security in Pervasive Computing, SPC 03, volume 2802 of LNCS, pages Springer-Verlag, D. Hovemeyer and W. Pugh. Finding bugs is easy. In OOPSLA 04 Companion, pages ACM Press, [HSD + 05] Changhua He, Mukund Sundararajan, Anupam Datta, Ante Derek, and John C. Mitchell. A modular correctness proof of IEEE i and TLS. In CCS 05: Proceedings of the 12th ACM Conference on Computer and Communications Security, pages 2 15, New York, NY, USA, ACM Press. [Mil96] Jonathan K. Millen. CAPSL: Common Authentication Protocol Specification Language. In NSPW 96: Proceedings of the 1996 Workshop on New Security Paradigms, page 132, New York, NY, USA, ACM Press. [Mye99] A.C. Myers. JFlow: Practical mostly-static information flow control. In [Pos81] POPL, pages , J. Postel. Transmission Control Protocol. DARPA Internet Program Protocol Specification. RFC 793, The Internet Engineering Task Force, Network Working Group, September [PS06] Erik Poll and Aleksy Schubert. Verifying an implementation of SSH. Submitted, available from alx/papers/wits.pdf, [TH04] Benjamin Tobler and Andrew Hutchison. Generating Network Security Protocol Implementations from Formal Specifications. In E. Nardelli et.al., editor, IFIP World Computer Congress - Certification and Security in Inter- Organizational E-Services (CSES), [Vig06] Luca Viganò. Automated Security Protocol Analysis With the AVISPA [Ylö95] Tool. Electronical Notes Theoretical Computer Science, 155:61 86, T. Ylönen. The SSH (Secure Shell) Remote Login Protocol. Internet draft, The Internet Engineering Task Force, Network Working Group, NOV Available at 8

9 [Ylö06a] T. Ylönen. The Secure Shell (SSH) Authentication Protocol. RFC 4252, The Internet Engineering Task Force, Network Working Group, January [Ylö06b] T. Ylönen. The Secure Shell (SSH) Connection Protocol. RFC 4254, The Internet Engineering Task Force, Network Working Group, January [Ylö06c] T. Ylönen. The Secure Shell (SSH) Protocol Architecture. RFC 4251, The Internet Engineering Task Force, Network Working Group, January [Ylö06d] T. Ylönen. The Secure Shell (SSH) Transport Layer Protocol. RFC 4253, The Internet Engineering Task Force, Network Working Group, January