Questions of belief are essential in analyzing protocols for the authentication of principals in distributed computing systems. In this paper we motivate, set out, and exemplify a logic specifically designed for this analysis; we show how various protocols differ subtly with respect to the required initial assumptions of the participants and their final beliefs. Our formalism has enabled us to isolate and express these differences with a precision that was not previously possible. It has drawn attention to features of protocols of which we and their authors were previously unaware, and allowed us to suggest improvements to the protocols. The reasoning about some protocols has been mechanically verified. This paper starts with an informal account of the problem, goes on to explain the formalism to be used, and gives examples of its application to protocols from the literature, both with shared-key cryptography and with public-key cryptography. Some of the examples are chosen because of their practical importance, while others serve to illustrate subtle points of the logic and to explain how we use it. We discuss extensions of the logic motivated by actual practice -- for example, in order to account for the use of hash functions in signatures. The final sections contain a formal semantics of the logic and some conclusions.

We present principles for the design of cryptographic protocols. The principles are neither necessary nor sufficient for correctness. They are however helpful, in that adherence to them would have avoided a considerable number of published errors. Our principles are informal guidelines. They complement formal methods, but do not assume them. In order to demonstrate the actual applicability of these guidelines, we discuss some instructive examples from the literature. 1

Many security protocols have the aim of authenticating one agent to another. Yet there is no clear consensus in the academic literature about precisely what "authentication" means. In this paper we suggest that the appropriate authentication requirement will depend upon the use to which the protocol is put, and identify several possible definitions of "authentication". We formalize each definition using the process algebra CSP, use this formalism to study their relative strengths, and show how the model checker FDR can be used to test whether a system running the protocol meets such a specification. 1 Introduction Many security protocols have appeared in the academic literature; these protocols often have the aim of achieving authentication, i.e., one agent should become sure of the identity of the other. The protocols are designed to succeed even in the presence of a malicious agent, called an intruder, who has complete control over the communications network, and so can intercept ...

We specify authentication protocols as formal objects with precise syntax and semantics, and define a semantic model that characterizes protocol executions. We have identified two basic types of correctness properties, namely, correspondence and secrecy, that underlie the correctness concerns of authentication protocols. We define assertions for specifying these properties, and a formal semantics for their satisfaction in the semantic model. The Otway-Rees protocol is used to illustrate the semantic model and the basic correctness properties. 1 Introduction Authentication is a fundamental concern in the design of secure distributed systems [14, 25]. In distributed systems, authentication is typically carried out by protocols, called authentication protocols. The primary goal of an authentication protocol is to establish the identities of the parties (referred to as principals in the security literature) who participate in the protocol. Many authentication protocols, however, also acc...

In a security system that allows people to choose their own passwords, those people tend to choose passwords that can be easily guessed. This weakness exists in practically all widely used systems. Instead of forcing users to choose well-chosen secrets, which are likely to be di cult to remember, we propose solutions that maintain both user convenience and a high level of security at the same time. The basic idea is to ensure that data available to the attacker is sufficiently unpredictable to prevent an off-line verification of whether a guess is successful or not. We examine common forms of guessing attacks, develop examples of cryptographic protocols that are immune to such attacks, and suggest a systematic way to examine protocols to detect vulnerabilities to such attacks.

A prerequisite for secure communication between two nodes in an ad hoc network is that the nodes share a key to bootstrap their trust relationship. In this paper, we present a scalable and distributed protocol that enables two nodes to establish a pairwise shared key on the fly, without requiring the use of any on-line key distribution center. The design of our protocol is based on a novel combination of two techniques – probabilistic key sharing and threshold secret sharing. Our protocol is scalable since every node only needs to possess a small number of keys, independent of the network size, and it is computationally efficient because it only relies on symmetric key cryptography based operations. We show that a pairwise key established between two nodes using our protocol is secure against a collusion attack by up to a certain number of compromised nodes. We also show through a set of simulations that our protocol can be parameterized to meet the desired levels of performance, security and storage for the application under consideration. 1

This paper presents a methodology to facilitate the design and analysis of secure cryptographic protocols. This work is based on a novel notion of a fail-stop protocol, which automatically halts in response to any active attack. This paper suggests types of protocols that are fail-stop, outlines some proof techniques for them, and uses examples to illustrate how the notion of a failstop protocol can make protocol design easier and can provide a more solid basis for some proposed protocol analysis methods.

We give a formal model of protocol security. Our model allows us to reason about the security of protocols, and considers issues of beliefs of agents, time, and secrecy. We prove a composition theorem which allows us to state sufficient conditions on two secure protocols A and B such that they may be combined to form a new secure protocol C. Moreover, we give counter-examples to show that when the conditions are not met, the protocol C may not be secure. I. Introduction What does it mean for a protocol to be secure? How can we reason about secure protocols? If we combine two existing protocols into a common protocol, what can we say about the security of the new protocol? This paper develops a family of tools for reasoning about protocol security. We adopt a modelbased approach for defining protocol security properties. This allows us to describe security properties in much greater detail and precision than previous frameworks for reasoning about protocol security. Some of the most a...

protocol analysis

A novel protocol has been formally analyzed using the prover Isabelle/HOL, following the inductive approach described in earlier work [11]. There is no limit on the length of a run, the nesting of messages or the number of agents involved. A single run of the protocol delivers session keys for all the agents, allowing neighbours to perform mutual authentication. The basic security theorem states that session keys are correctly delivered to adjacent pairs of honest agents, regardless of whether other agents in the chain are compromised. The protocol's complexity caused some difficulties in the specification and proofs, but its symmetry reduced the number of theorems to prove. CONTENTS i Contents 1 Introduction 1 2 The Recursive Authentication Protocol 2 3 Review of the Inductive Approach 4 4 A Formalization of Hashing 6 5 Modelling the Protocol 7 5.1 Modelling the Server . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 A Coarser Model of the Server . . . . . . . . . . . . . . . . ....