Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274-288, February 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... such as the BAN logic [12] used in [31] theorem proving, used in Isabelle [41] rank functions [29] typing [2, 13, 30] abstract interpretation [8, 9, 28, 37] model checking, rewriting, and related techniques, used in Elan [15] Brutus [16] Maude [22] FDR [33] NRL [34] the Interrogator [35], Mur [36] Athena [43] Most existing protocol veri ers based on model checking su er from the problem of the state space explosion, and they need very large resources to verify even relatively simple protocols. Moreover, in general, they limit the number of runs of the protocol This work was ....

....in practice. We have applied it to prove secrecy properties of several protocols of the literature, including Skeme [32] or to nd attacks against them. 3 Related work Logic programming and similar formalisms have already been used in a number of works on cryptographic protocols, for example [21, 22, 34, 35, 46]. We propose a more abstract representation of the protocols than [22, 34] that enables us to design a simpler and faster analysis, and to avoid limiting the number of runs of the protocol, thus improving over most model checkers. Of course, the additional approximations imply that our analysis ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2):274{ 288, Feb. 1987.

....later work on the formal analysis of cryptographic protocols is based on this model or some variant of it. Shortly later, work began on developing tools for the analysis of security protocols in general, all of which were based on the Dolev Yao model or some variant, including the Interrogator [56], the NRL Protocol Analyzer [46] and the the LongleyRigby tool [42] Others applied general purpose formal methods to the problem [39] Most of this work used some type of state exploration technique, in which a state space is defined and then explored by the tool to determine if there are any ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

.... such as the BAN logic [11] used in [23] theorem proving, used in Isabelle [33] rank functions [21] typing [2, 12, 22] abstract interpretation [7, 8, 20, 29] model checking, rewriting, and related techniques, used in Elan [13] Brutus [14] Maude [16] FDR [25] NRL [26] the Interrogator [27], Mur [28] Athena [35] Most existing protocol verifiers based on model checking suffer from the problem of the state space explosion, and they need very large resources to verify even relatively simple protocols. Moreover, in general, they limit the number of runs of the This work was partly ....

....efficient in practice. We have applied it to prove secrecy properties of several protocols of the literature, including Skeme [24] or to find attacks against them. Related work Prolog rules and similar formalisms have already been used in a number of works on cryptographic protocols, for example [16, 26, 27]. We propose a more abstract representation of the protocols, that enables us to design a simpler and faster analysis, and to avoid limiting the number of runs of the protocol, thus improving over most model checkers. Of course, the additional approximations imply that our analysis may not be able ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, Feb. 1987.

....analysis, only one type of requirement was considered, and that was the simplest: that some term or set of terms designated as secret should not be learned by the intruder. Some of the earlier work on automated cryptographic protocol analysis, such as the first versions of the Interrogator [24], also restricted itself to this limited definition of secrecy. Others, such as the earlier versions of the NRL Protocol Analyzer[20] allowed the user to specify security in terms of the unreachability of insecure states, in which it was possible to specify such a state in terms of words known by ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

....can play any of the roles in the protocol 1 (e.g. in case of two party protocols, anybody can be initiator as well as responder) We further assume that principals may run several instances of the protocol concurrently, and play different roles in different instances. As usual in the literature [8], we assume that the network is under the control of the attacker. This means that the attacker can observe every message sent via the network, furthermore, it can intercept, modify, generate, delay, and replay messages or parts of them. We assume that the attacker knows the protocol that is run ....

J. Millen, S. Clark, and S. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE- 13(2):274-288, February 1987.

....VA 22303 USA ilianoitd. nrl. navy. rail 1 Introduction The rationale of authentication has been a topic of study for about a decade and a half. First attempts at formal analysis of authentication protocols were not using logics per se, but were certainly logical. Millen s Interrogator [Mi184,MCF87] was a Prolog based tool specifically designed for authentication protocol analysis that functioned essentially as a special purpose model checker. Kemmerer used the general purpose formal specification language Ina Jo and an accompanying symbolic execution tool Inatest to specify and analyze ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Inter- rogator: Protocol security analysis. IEEE Transactions on Software Engineer- ing, 13(2):274 288, 1987.

....analysis of the Needham Schroeder protocol using the BAN logic is given in [BAN90] However, this analysis did not find the security problem subsequently reported in [Low95] although it was an authentication problem. Another approach consists of using state machines. In the Interrogator system [MCF87] the participants are modelled as communicating state machines and the network is assumed to be under the control of an intruder, which can intercept messages, destroy or modify them, or pass them through unmodified. Given a final state in which the intruder knows something which should be ....

J. Millen, S. Clark, and S. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

....are not sufficiently suited for analysis of attacks on cryptographic protocols. 2. Expert system based approaches: The knowledge of human experts is formalized into deductive rules that can be used by a protocol designer to investigate different scenarios in an automated or even interactive way [23, 29]. While this approach is well suited to analyze a protocol s resistance to known attacks it does not allow to find flaws in a protocol that are based on unknown attacking techniques [38, p. 66] Copyright at Technical University Berlin. All rights reserved. 2.3. CONCLUSION 3. Algebraic ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, 13(2):274--288, 1987.

....common and important case in which the cryptographic keys are messages of bounded size. Introduction The problem of the automatic verification of cryptographic protocols has received great attention and by now various algorithms and tools for checking security properties are available, see e.g. [13, 14, 15, 12, 21, 11, 19, 18, 22, 7]. These algorithms and tools typically analyse a formal model that describes the flow of information and the interaction between principals (as specified by the protocol) in a hostile environment, that is, in the presence of attackers. In general this analysis is infinite state. Indeed, even when ....

....M closed and M derivable (OUT) t ; #M#. P (SPLIT) t ; let (M, N) x, y) in P M, y N ] CASE) t ; case in P (MATCH) t ; if M = M then P t ; Q t # ; Q # t # ; P The entailment relation K M can be presented in different ways: by rewrite systems [13, 15], by deductive systems [21, 7] by inductive definitions [20] or by axioms [24] For our purposes, it is important that it be presented as a deductive system. The definition follows. The set of messages known to the environment is always ....

J. Millen, S. Clark, and S. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, 1987.

....simple and powerful. He can mimic very easily real world non cryptographic and non repetitive attacks on the behaviour of the protocol. The idea of explicitly introducing an intruder was first proposed in [DEK82, DY83] in another setting. This idea was then used in the Interrogator system 16 [MCF87] where the participants are modelled as communicating state machines and the network is assumed to be under the control of an intruder, which can intercept messages, destroy or modify them, or pass them through unmodified. The NRL Protocol Analyser [KMM94, Mea94] is similar to the Interrogator, ....

J. Millen, S. Clark, and S. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

....K from alone. Thus, the idealized security properties of encryption are modeled (rather than defined) They are built into the model of computation on expressions. This body of literature starts with the work of Dolev and Yao [17] DeMillo, Lynch, and Merritt [15] Millen, Clark, and Freedman [35], Kemmerer [30] Burrows, Abadi, and Needham [13] and Meadows [34] It includes many di#erent agendas and approaches, with a variety of techniques from the fields of rewriting, modal logic, process algebra, and others. Over the years, it has been used in the design of protocols, it has helped ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, February 1987.

....that a hostile intruder can not get hold of secret information (e.g. a private key) or to force unjust authentication. Unfortunately, the design of cryptographic protocols appears to be rather error prone. This gave impulse to research on the formal verification of security protocols see e.g. [13, 6, 20, 23, 18, 28, 29]. In this setting several approaches are based on Dolev and Yao s [13] where it is proposed to test a protocol explicitly against a hostile intruder who has complete control over the network, can intercept and forge messages. By an exhaustive search, one can establish whether the protocol is ....

....are based on Dolev and Yao s [13] where it is proposed to test a protocol explicitly against a hostile intruder who has complete control over the network, can intercept and forge messages. By an exhaustive search, one can establish whether the protocol is flawed or not as shown, e.g. in [23, 21, 8, 16]. Clearly, a crucial aspect in this approach is try to limit the search space explosion that occurs when modelling the intruder s behaviour . To this end, many solutions have been employed, ranging from human intervention to the use of approximations. In recent work [15, 30, 22] this problem has ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol security analysis. IEEE Trans. on Software Engineering, 13(2):274--288, 1987.

....in possible plaintext lying around on secondary storage. Encoding messages to be sent to another entity must also be carried out correctly in order for decoding to proceed without any errors and this is often a difficult task. Tools such as the NRL Protocol Analyzer [23] the Interrogator [14] and the Higher Order Logic (HOL) based cryptographic tool [10] have been developed to aid in analyzing security protocols. The Interrogator is a Prolog based program that searches for security vulnerabilities in network protocols used for automatic cryptographic key distribution, while the NRL ....

S.C. Clark, S.B. Freedman, and J.K. Millen. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

....value resulting from applying an easy function (one in EN C ) to values in has may be added to has . We restrict the reveal(u) output so that u 2 has , that is, Eve can only report a value that it has . Similar treatments of known information appear elsewhere in the literature, for example, in [12, 19, 28, 27]. Eve(C; P; A) eavesdrop(u) p;q;a , u 2 set C , p; q 2 P , p 6= q, a 2 A learn(u)a , u 2 set C , a 2 A reveal (u)a , u 2 set C , a 2 A compute(u; f)a , f 2 EN C , a 2 A has set C , initially ; u 2 has compute(u; f)a fu1 ; ukg s:has u = f(u1 ; uk ) ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274-- 288, February 1987.

....Aba97, LR97, THG98c] This attests to the importance of rigorous veri cation. Allowing an unbounded number of concurrent protocol executions makes the number of reachable states unbounded, so automated veri cation using state space exploration is not directly applicable. The case studies in [MCF87, Ros95, HTWW96, DK97, LR97, MMS97, MCJ97, MSS98, Bol98, DNL99] show that state space exploration of authentication protocols and similar cryptographic protocols is feasible when small upper bounds are imposed on the size of messages and the number of protocol executions. However, in most of those ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274-288, February 1987.

....about the environment, multiple instances of the protocols running concurrently, and cryptographic algorithms which are considered as black boxes described by algebraic properties. Later work in the analysis of formal protocols is inspired from their work. Tools include the Interrogator [Mil87] the NRL Protocol Analyzer [Mea96] and the LongleyRigby tool [Lon92] The basic approach is to produce a model of a small system running the protocol (for example, with one initiator and one responder) together with a model of the most general intruder who can interact with the protocol, and ....

J. Millen, S. Clark, S. Freedman. "The Interrogator: Protocol Security Analysis". IEEE Transactions on Software Engineering, 13(2):274--288, February 1987.

....such as the Shamir Rivest Adleman Three Pass Protocol[20] and the Session Hijacking attacks defined in this paper. Some cryptographic protocol analysis methods that take the state machine approach start their search for attacks by constructing a path from the initial state to an insecure state[12, 16] and or by proving insecure states are unreachable[12, 15] The intruder s possible objectives are ignored by the search process. This makes the search less efficient. That is one of the reasons the search might suffer state explosion. If one can identify the set of all the possible scenarios for ....

....all the possible scenarios for the intruder to launch attacks, one can reduce the search space by limiting the search to that set. Moreover, by enumerating the possible scenarios and looking at each scenario from the intruder s point of 1 view, some techniques 1 in addition to those proposed in [16, 12, 23] can be applied to further reduce the search space. Roles of the participating principals in protocols are important in cryptographic protocol analysis. BANlogic [4] and BAN like logic[8] approaches do not reason about the roles of the participating principals and their relationship to messages. ....

[Article contains additional citation context not shown here]

M. J. Millen, S. C. Clark, and S. B. Freedman. "The Interrogator: Protocol Security Analysis." IEEE Transactions on Software Engineering, SE13 (2), 1987.

....executed corresponding other actions (e.g. a payment gateway approves a charge to customer C s account only if customer C previously authorized that charge) Allowing an unbounded number of concurrent protocol instances makes the number of reachable states unbounded. The case studies in, e.g. MCF87, Ros95, HTWW96, DK97, LR97, MMS97, MCJ97, MSS98, Bol98, DNL99, MM99] show that state space exploration of security protocols is feasible when small upper bounds are imposed on the size of messages and the number of protocol instances. In most of those case studies, the bounds are not rigorously ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274-288, February 1987.

.... Oxford University Computing Laboratory, Wolfson Building, Parks Road, Oxford, OX1 3QD, UK; e mail: gavin.lowe comlab.ox.ac.uk. 1 Model checking techniques where a model checker is used to search the state space of a small system running the protocol, looking for attacks; see, for example, [13, 5, 12, 6, 10, 8, 14, 11] Direct proofs where the protocol is proved correct directly (possibly with the help of machine assistance) typically using some form of induction; see, for example, 19, 2, 15, 22] These techniques have proved successful at analysing the protocols that have appeared in the academic literature. ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The interrogator: Protocol security analysis. IEEE Transactions on software Engineering, 13(2), 1987.

....protocol, and to use a state exploration tool to discover if the system can enter an insecure state, that is, whether there is an attack upon the protocol. A number of different authors have used this approach, either with general purpose [10, 13, 17, 21, 4, 11] or special purpose model checkers [20, 10, 18]; some tools (for example, the NRL Protocol Analyzer [10, 19] combine aspects of theorem proving and model checking to try to show that it is enough to consider only a finite set of states, and then to search those states. These approaches have discovered a number of attacks upon security ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The interrogator: Protocol security analysis. IEEE Transactions on software Engineering, 13(2), 1987.

....VA 22303 USA iliano itd.nrl.navy.mil 1 Introduction The rationale of authentication has been a topic of study for about a decade and a half. First attempts at formal analysis of authentication protocols were not using logics per se, but were certainly logical. Millen s Interrogator [Mil84,MCF87] was a Prolog based tool speci cally designed for authentication protocol analysis that functioned essentially as a special purpose model checker. Kemmerer used the general purpose formal speci cation language Ina Jo and an accompanying symbolic execution tool Inatest to specify and analyze ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, 13(2):274-288, 1987.

....no trace. Such attacks are already manifesting [33] with little corresponding effort to address this threat in a dynamic, systematic way. The security of the information provided by trusted services at the application layer is dependent on security protocols. Extensive work has been done to test [19] and verify [16] security protocols, and significant progress has been made in these areas. Nonetheless, no method provides complete, or even measurable, confidence in security protocols. In fact, based on the nature of security protocols and their environment, it may be impossible to accurately ....

....attack detection and define the architecture for our system. We close with a short summary. Section 2. Security Protocol Verification Security protocol analysis research to date focuses on applying pseudo software engineering techniques to formally verify that protocols are error free [DY83] [19], BAN88] 12] SVO94] 20] 26] LOWE96] LOWE98] 30] 25] 21] 27] 2] 6] and many others. Previous work concentrates on analysis of a single protocol in a laboratory environment, considering only a modeled symbolic representation of protocol execution. Security protocol ....

Millen, J.K., Clark, S. C., and Freedman, S. B. "The interrogator: Protocol security analysis". IEEE Trans. Sofw. eng. SE-13, 2(Feb. 1987), pp. 274-288 18

....E Mail: teshrim ucdavis.edu 1 on strings at all. Instead, typically, they see encryption as a formal symbol, the properties of which are modeled (not de ned) by the manner in which this formal symbol may be manipulated. There are many such formal views towards cryptography; see, for example, [9, 17, 12, 6, 16, 15, 18, 2]. Building bridges. Quite recently, some work has emerged which starts to bridge the computational view and the formal one. Lincoln, Mitchell, Mitchell and Scedrov [14] develop a formal model that blends in computational aspects. P tzmann, Schunter and Waidner [19] and then P tzmann and Waidner ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274-288, February 1987.

....of the design process and offers a powerful and flexible test bed for security protocol design. There are languages available that allow the formal specification of protocols and tools which have been developed in the research of cryptographic logics (e.g. NRL analyzer [16] the Interrogator [14], HOL based Cryptographic logic tool [3] To our knowledge, however, there are no tools that allow for the easy specification of cryptographic protocols combining both the logics and the formal protocol specifications in such a way as to distil the critical issues and present the user with a ....

J.K. Millen, S.C. Clark, and S.B. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

.... based on the Ina Jo specification language, but using the BAN logic [9] to model belief, Bieber s approach [6] based on the for mal specification language B [2] and finally the approach of Meadows [19, 20, 21, 22] based on communicating processes and which builds upon the approach of Millens [23] and the approach of Dolev and al. 13] With the exception of Meadows approach, most of these approaches do not allow for the verification of general authentication properties or do not allow for the definition of a large class of protocols. Meadows approach on the other hand mainly focuses on ....

....of the intruder knowledge is used. This is indeed a specificity of the proposed approach. Other formal method based approaches use some restricted subset of logics so as to allow for more automation. The most representative approaches are the approach of Dolev and Yaho [13] Millen s approach [23] and Meadows approach in the NRL analyzer [21] We will mainly focus on this latter approach, which builds on and extends most interesting points introduced in the two others, namely and respectively the use of term rewriting techniques and the backward wandering through states to show the ....

J. K. Millen, S.C. Clark, and S.B. Freedman. The interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, 13(2), 1987.

....BAN90, WL94, AN95, AN96, Low96, Aba97, LR97, THG98c] This attests to the importance of rigorous veri cation. Allowing an unbounded number of concurrent protocol instances makes the number of reachable states unbounded, so state space exploration is not directly applicable. The case studies in [MCF87, Ros95, HTWW96, DK97, LR97, MMS97, MCJ97, MSS98, Bol98, DNL99] show that state space exploration of authentication protocols and similar cryptographic protocols is feasible when small upper bounds are imposed on the size of messages and the number of protocol instances. However, in most of those ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274{ 288, February 1987.

....A:Text) B S: e kab pks) Respond To Server(A,B:User,kab:Key) S A: e kab ka) Return Key(A,S:User, C:Text) A B: e important data kab) Get Key(A,B:User,important data:Text) Figure 2. 4 Chapter 2: Previous Research Regarding Cryptographic Protocol Verification 49 In [MCF87] Millen, Clark and Freedman offer a testing tool designed to be used for verification of the subset of cryptographic protocols called Key Distribution Protocols. Their tool is called Interrogator. Interrogator is a series of Prolog programs which take a black box view of the Key Distribution ....

....the design. It may also be useful to provide an interface from this tool to other existing tools for protocol evaluation. Potentially, this tool could one day be part of a protocol evaluation workbench which includes our specification verification system, a testing system (such as Interrogator [MCF87]) a BAN implementation (such as [CHEN90] etc. Another sub component of such a system would be a language translator to take a protocol specified in CPAL and convert it to the language used by Interrogator to provide a fully integrated environment. For now, CPAL ES is a fully functional ....

Millen, J.K., Clark, S. C., and Freedman, S. B. "The interrogator: Protocol security analysis". IEEE Trans. Sofw. eng. SE-13, 2(Feb. 1987), pp. 274-288

....relation(many, R , E2 ) Figure 1: Integrating three different specification languages in PRISMA variables or ranging on infinite domains have no translation. There is a field in which Prolog has been largely used for animating and testing specifications: communication protocols [126, 133, 170, 191]. An example is the Mockingbird system, discussed in Sect.3.1. 2.1.4 Prolog as notational integrator A problem in the specification phase is that possibly several notations are used for describing the product to be developed. In [143, 144, 129] Prolog has been used as an integration strategy ....

.... rule initializes the working context of a programmer: do working context(R,W,X,Item) 26 Product Specification [2, 9, 43, 47, 52, 58, 62, 68, 102, 114, 121, 124, 128, 139, 143, 182, 186, 191] Process Management [3, 13, 33, 35, 85, 77, 84, 146, 155, 196, 163] Validation and prototyping [24, 53, 56, 71, 82, 98, 99, 104, 115, 120, 133, 148, 170, 176, 177, 179, 188, 197] Design [8, 4, 38, 44, 63, 106, 109, 118, 147, 160, 162, 202] Editing and Compiling [10, 18, 48, 36, 78, 158, 136, 150, 194] Debugging and testing [21, 42, 46, 59, 67, 74, 76, 81, 92, 123, 154, 181] Maintenance and Reuse [23, 25, 26, 29, 30, 31, 66, 79, 110, 117, 193, 201, 7, 60, 93, 135, 142, ....

J. Millen, S. Clark, and S. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, 13(2):274--288, February 1987.

....the restrictions do not hide many important subtleties and attacks. 2 From Politeness to Formality With varying degrees of explicitness, many of these simplifications have been embodied in symbolic algorithms, proof systems, and other formal methods for the analysis of security protocols (e.g. [4, 9, 11 13, 16, 19, 21, 23, 25, 27, 29, 31]) The power of the formal methods is largely due to these simplifications. In these methods, keys, nonces, and other fresh quantities are typically not defined as ordinary bitstrings. They may even be given a separate type. While all bitstrings can be enumerated by starting from 0 and adding 1 ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE13 (2):274--288, February 1987.

....CP Logics, we refer to that group of logics, and the generally accepted facilities shared by the majority of them, including the SEES, SAYS, BELIEVES, and FRESH constructs. Page 9 i.e. the infamous idealization problem. Other tools such as the NRL Protocol Analyzer [MEAD91] and The Interregator [MIL87] focus on data, actions, or both, but do not consider the beliefs of principals as they manipulate data and send and receive messages. 4.1 Combining CPAL and Other Logical Notations Recall that CP logics are a combination of formula notation (the logical language) and rules of inference. To use ....

....can provide an interface between other existing tools for protocol evaluation. Potentially, CPAL ES could one day be part of a protocol evaluation workbench which includes our specification verification system implementing numerous different CP logics, a testing system (such as Interrogator [MIL87]) a BAN implementation (such as [CHEN90] etc. Another subcomponent of such a system would be a language translator to take a protocol specified in CPAL and convert it to the language used by Interrogator to provide a fully integrated environment. For now, CPAL ES is a functioning system written ....

Millen, J.K., Clark, S. C., and Freedman, S. B. "The interrogator: Protocol security analysis". IEEE Trans. Sofw. eng. SE-13, 2(Feb. 1987), pp. 274-288

....key K. The final result, though, concerns x rather than K. 6. 2 Secrecy and inductive definitions Approaches based on predicates on behaviors rely on a rather di#erent definition of secrecy, which can be traced back to the influential work of Dolev and Yao [30] and other early work in this area [41, 57, 54]. According to that definition, a process preserves the secrecy of a piece of data M if the process never sends M in clear on the network, or anything that would permit the computation of M , even in interaction with an attacker. Next we show one instantiation of this general definition, again ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, February 1987.

....from M K alone. Thus, the idealized security properties of encryption are modeled (rather than defined) They are built into the model of computation on expressions. This body of literature starts with the work of Dolev and Yao [15] DeMillo, Lynch, and Merritt [14] Millen, Clark, and Freedman [28], Kemmerer [23] Burrows, Abadi, and Needham [13] and Meadows [27] It includes many di#erent agendas and approaches, with a variety of techniques from the fields of rewriting, modal logic, process algebra, and others. Over the years, it has been used in the design of protocols, it has helped ....

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, February 1987.

....state machine based analysis of cryptographic protocols described in the previous subsection, these systems begin with an undesirable state and attempt to discover if this state is reachable from an initial state. One of the earliest system of this approach is the Interrogator by Millen et al. [MCF87]. In the Interrogator, protocol participants are modelled as communicating state machines whose messages to each other are intercepted by the intruder who can either destroy messages, modify them, or let them pass through unmodified. Given a final state, in which the intruder knows some word which ....

J. Millen, S. Clark, and S. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, February 1987.

....Such attacks are already manifesting [WAYN00] with little corresponding effort to address this threat in a dynamic, systematic way. The security of the information provided by trusted services at the application layer is dependent on security protocols. Extensive work has been done to test [MCF87] and verify [KMM93] security protocols, and significant progress has been made in these areas. Nonetheless, no method provides complete, or even measurable, confidence in security protocols. In fact, based on the nature of security protocols and their environment, it may be impossible to ....

....attack detection and define the architecture for our system. We close with a short summary. Section 2. Security Protocol Verification Security protocol analysis research to date focuses on applying pseudo software engineering techniques to formally verify that protocols are error free [DY83] [MCF87], BAN88] KEM89] SVO94] MEAD95] ROS95] LOWE96] LOWE98] THG98] PAUL99] MEAD99] SONG99] BRAK00] DM00] and many others. Previous work concentrates on analysis of a single protocol in a laboratory environment, considering only a modeled symbolic representation of protocol ....

Millen, J.K., Clark, S. C., and Freedman, S. B. "The interrogator: Protocol security analysis". IEEE Trans. Sofw. eng. SE-13, 2(Feb. 1987), pp. 274-288

....later work on the formal analysis of cryptographic protocols is based on this model or some variant of it. Shortly later, work began on developing tools for the analysis of security protocols in general, all of which were based on the Dolev Yao model or some variant, including the Interrogator [34], the NRL Protocol Analyzer [27] and the the Longley Rigby tool [23] Others applied general purpose formal methods to the problem [20] Most of this work used some type of state exploration technique, in which a state space is defined and then explored by the tool to determine if there are any ....

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol Security Analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

....the state of a protocol party as a Prolog term, and a message is also a term, so that the global state of the environment is a list of such states and messages. A global state transition updates some party s state and may add a new message. The Interrogator, a Prolog program for protocol analysis [12], was a set of Prolog rules expressing a relation reachable(H,Q) meaning that global state Q was reachable via the message sequence H. In a typical reachability query, Q was partly instantiated to an insecure state, and H was a variable, to be instantiated by a successful Prolog seach for an ....

J. Millen, S. Clark, and S. Freedman. The Interrogator: protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274-288, February 1987.

No context found.

Jonathan K. Millen, Sidney C. Clark, and Sheryl B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274-288, February 1987.

No context found.

J. K. Millen, S. C. Clark, S. B. Freedman, "The Interrogator: Protocol Security Analysis", IEEE Transactions on Software Engineering, SE-13(2):274-288, 1987.

No context found.

J. K. Millen, S. C. Clark, S. B. Freedman, "The Interrogator: Protocol Security Analysis", IEEE Transactions on Software Engineering, SE-13(2):274-288, 1987.

No context found.

J. K. Millen, S. C. Clark, S. B. Freedman, "The Interrogator: Protocol Security Analysis", IEEE Transactions on Software Engineering, SE-13(2):274-288, 1987.

No context found.

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, February 1987.

No context found.

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274--288, February 1987.

No context found.

J. K. Millen, S. C. Clark, S. B. Freedman, "The Interrogator: Protocol Security Analysis", IEEE Transactions on Software Engineering, SE-13(2):274-288, 1987.

No context found.

J. K. Millen, S. C. Clark, S. B. Freedman, "The Interrogator: Protocol Security Analysis", IEEE Transactions on Software Engineering, SE-13(2):274-288, 1987.

No context found.

J. K. Millen, S. C. Clark, S. B. Freedman, "The Interrogator: Protocol Security Analysis", IEEE Transactions on Software Engineering, SE-13(2):274-288, 1987.

No context found.

J.K. Millen, S.C. Clark, and S.B. Freedman. The interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2), 1987.

No context found.

J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, 13(2):274--288, 1987.

No context found.

J.K.Millen, S.C.Clark, and S.B.Freedman, The Interrogator: Protocol Security Analysis, IEEE Transactions on Software Engineering, SE-13#2#, #1987#.

No context found.

Millen, Jonathan K., Clark, Sidney C., and Freedman, Sheryl B., "The Interrogator: Protocol Security Analysis", IEEE Transactions on Software Engineering, Volume SE13, Number 2, February 1987, pp. 274-288.

No context found.

Millen, J.K., Clark, S. C., and Freedman, S. B. "The interrogator: Protocol security analysis". IEEE Trans. Sofw. eng. SE-13, 2(Feb. 1987), pp. 274-288

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC