G. Lowe. A hierarchy of authentication specifications. In 43. IEEE Computer Society Press, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....compute the hash of Order Description and Purchase Amount, and the Payment Gateway can compare them. 7. IRRELEVANT PROPERTIES Beside what failed and what succeeded, there are also other properties that are customarily proved for authentication protocols. For instance one can scan Lowe s [10] or Gollmann s [6] classification and check what is verifiable. This is a tricky question because we eliminated fields that are immaterial to the main goals of the protocol but that may be essential for other security properties. For instance we have eliminated request response identifiers which ....

G. Lowe. A hierarchy of authentication specifications. In Proc. of the 10th IEEE Comp. Sec. Found. Workshop, pages 31--43. IEEE Comp. Society Press, 1997.

....on the protocol and opponent, and techniques relying on theorem proving [Bol96, Pau98] or epistemic logics [BAN89, DMP01] which typically require lengthy expert interaction. Woo and Lam s correspondence assertions [WL93] are safety properties, specifying what is known as injective agreement [Low95]. Given a description of the sequence of messages exchanged by principals in a protocol, we annotate it with labelled events marking the progress of each principal through the protocol. We divide these events into two kinds, begin events and end events. Event labels typically indicate the names of ....

G. Lowe. A hierarchy of authentication specifications. In 10th IEEE Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1995.

....b.5) S B : N B At the end of the attack sequence B, accepts the authentication request of A even if A began a session to authenticate itself with E , i.e. there is no correspondence of intentions. This is considered a valid attack to entity authentication by many authors (see, e.g. [27, 16]) Interestingly, the attack exploits the absence of B as intended verifier in message 3. To see that, note that b.3, E forwards to B the message sent by A who is willing to authenticate with E . If the intended verifier (E in this case) were made explicit in the message, such a forwarding would ....

....Safety The purpose of the deduction rules is to generate safe traces, that is traces that provide the intended authentication guarantees for a protocol session. We formulate these guarantees as a safety property for traces following the idea of correspondence between actions of the participants [27, 16]. Intuitively, a trace is safe if every commit A B in the trace is preceded by a corresponding run A action. Formally: Definition 5 (Safety) A trace s is safe if and only if whenever s s 1 : commit A : s 2 , one has s 1 s 1 : run B : s 1 , and s 1 : s 1 : s 2 is ....

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop. IEEE press, 1997.

.... cryptographic protocols; see for example Marrero s logic for Brutus [5] Yet others, for example [1, 2] have developed generic requirements that can be applied to any protocol, for example the correspondence requirement developed in [1, 2] But even here it may make sense, as Lowe has argued in [4], to develop families of correspondence requirements suited to di#erent applications rather than a single generic requirement. The next step is to make sure that requirements are easy to read, write, and understand. This, unfortunately, is where temporal languages fall short. Even for relatively ....

G. Lowe. A hierarchy of authentication specifications. In Proceedings of 10th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, 1997.

.... is related to the verification of an entity s claimed identity [1] while message authentication should make it possible for the receiver of a message to ascertain its origin [2] In recent years there have been some formalizations of these di#erent aspects of authentication (see, e.g. [3, 4, 5, 6, 7, 8, 9, 16]) These formalizations are crucial for proofs of authentication properties, that sometimes have been automatized (see, e.g. 10, 11, 12, 13, 14] # This work has been partially supported by MURST Progetto TOSCA, Progetto AI, TS CFA and Progetto Metodi formali per la Sicurezza . We here ....

G. Lowe. "A Hierarchy of Authentication Specification". In Proc. of the 10th Computer Security Foundation Workshop. IEEE press, 1997.

....a few assumptions that seem impossible to verify. Is a guarantee with this feature still of any importance Also, the goal of authentication is merely formalised in terms of agents aliveness, whereas it may presuppose far wider requirements, as subsequently discussed using a di#erent approach [65]. New Guarantees The well known goals of integrity, authenticity, key distribution and stronger forms of authentication need to be treated. For example, even if the initiator is informed that session key confidentiality holds, it is not obvious that the responder shares the same session key and ....

....pen and paper on a specific protocol [66] while another model checker, the NRL Protocol Analyzer [75] also allows mechanised proofs by induction that certain states are out of reach. Nevertheless, no protocol goals have been discussed in detail except confidentiality and, later, authentication [65] (see 4.6) If a protocol cannot be attacked, it does not necessarily mean that all its goals are achieved. Other model checkers that have achieved results in the field are ASTRAL [35] Murphi [37, 79] SMV [33] and SPIN [10] More recently, also STEP [104] has been used to analyse the ....

G. Lowe. A Hierarchy of Authentication Specifications. In Proceedings of the 10th IEEE Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1997.

....solution to this problem in [18] was to strengthen the matching protocol runs requirement to include the condition that when A completes a protocol run with B, then not only should the two protocol runs match, but B should believe that he has been running the protocol with A. In a later paper, [19], he developed this idea further, developing a hierarchy of authentication requirements which gave conditions of varying degrees of strictness on the conclusions a principal A could draw about B s view of the protocol after completing the protocol with B. These were then formalized using the ....

G. Lowe. A hierarchy of authentication specifications. In Proceedings of the 10th IEEE Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1997.

.... is related to the verification of an entity s claimed identity [20] while message authentication should make it possible for the receiver of a message to ascertain its origin [28] In recent years there have been some formalizations of these different aspects of authentication (see, e.g. [1, 8, 14, 16, 17, 21, 27]) These formalizations are crucial for proofs of authentication properties, that sometimes have been automatized (see, e.g. 11, 18, 23, 22, 25] A typical approach presented in the literature is the following. First, a protocol is specified in a certain formal model. Then the protocol is shown ....

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop (CSFW10). IEEE press, 1997.

....not mean that the group members have any knowl edge of the group key at the end of the protocol, nor that they agree on its value. Also, it does not imply for a group member that any other member executed a session of the protocol (there is no liveness property intended in the sense of G. Lowe in [13]) 2. Perfect Forward Secrecy This property is defined in [18] as follows: The compromise of long term keys does not compromise past session keys. This property, traditionally used in a two parties setting, is exploited in a context where no message was manipulated in the past. This is natural ....

G. Lowe. A hierarchy of authentication specifications. In Proceedings of loth IEEE Computer Security Foundations Workshop, pages 31-44. IEEE Computer Society Press, 1997.

....on the protocol and opponent, and techniques relying on theorem proving [Bol96, Pau98] or epistemic logics [BAN89, DMP01] which typically require lengthy expert interaction. Woo and Lam s correspondence assertions [WL93] are safety properties, specifying what is known as injective agreement [Low95]. Given a description of the sequence of messages exchanged by principals in a protocol, we annotate it with labelled events marking the progress of each principal through the protocol. We divide these events into two kinds, begin events and end events. Event labels typically indicate the names of ....

G. Lowe. A hierarchy of authentication specifications. In 10th IEEE Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1995.

....by a key certified by Visa s CA is matched by the corresponding credit card issued by Visa, even if he does not see the credit card number. However, it has not the objective to provide authentication to the various parties as usually intended in the protocol verification literature (see Lowe [9] for some possible definitions) There is no problem here if the certification authority receives the same request more than once, or if there is a mismatch between the number of runs of the merchant and the certification authority, and so on. Such possibilities are foreseen in the specification ....

G. Lowe. A hierarchy of authentication specifications. In Proc. of the 10th IEEE Comp. Sec. Found. Workshop, pages 31--43. IEEE Comp. Society Press, 1997.

....(relation S ) corresponds to some attack in the standard model (relation ) and vice versa. In other words, the symbolic model captures all and only the attacks of the standard model. For instance, the method detects type dependent attacks, which usually escape finitestate analysis, e.g. [23]. In this kind of attacks, the adversary cheats on the type of some messages, e.g. by inserting a nonce where a key is expected according to the protocol description. We illustrate the trace analysis method and the use of the automatic tool STA on the simplified Kerberos protocol of Section 3. ....

....formal approaches to security. Examples of these techniques include the type systems for secrecy in [1] and the one for authentication in [18] and the work on logic programs in [2] Finite state model checking has proven very effective in practice to find bugs in security protocols, e.g. [22, 23, 27]. When compared to these more traditional methods, major benefits of the equivalence based approach seem to be a host of syntax driven reasoning principles and a fully satisfactory formalization of many important properties, including implicit information flow (that may arise due, e.g. to traffic ....

G. Lowe. A Hierarchy of Authentication Specifications. In Proc. of 10th IEEE Computer Security Foundations Workshop, IEEE Computer Society Press, 1997.

....assertions can be proved by type checking. Woo and Lam s paper introduces correspondence assertions but provides no techniques for proving them. Clarke and Marrero [CM00] use correspondence assertions to specify properties of e commerce protocols, such as authorizations of transactions. Lowe [Low95] discusses several forms of authenticity property achieved by security protocols; in his terminology, correspondence assertions are injective agreement properties. Prior work on checking correspondence assertions includes a project by Marrero, Clarke, and Jha [MCJ97] to apply model checking ....

G. Lowe. A hierarchy of authentication specifications. In 10th Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1995.

....on the protocol and opponent, and techniques relying on theorem proving [Bol96, Pau98] or epistemic logics [BAN89, DMP01] which typically require lengthy expert interaction. Woo and Lam s correspondence assertions [WL93] are safety properties, specifying what is known as injective agreement [Low95]. Given a description of the sequence of messages exchanged by principals in a protocol, we annotate it with labelled events marking the progress of each principal through the protocol. We divide these events into two kinds, begin events and end events. Event labels typically indicate the names of ....

G. Lowe. A hierarchy of authentication specifications. In 10th Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1995.

....protocol which can be understood without ambiguities. In the original presentation of the protocol the step (2) was slightly di#erent: Na,Nb Pub(A) The responder B returns to A a message with only the two nonces without his own name. Sometime after the publication of this protocol Lowe [Low97] spotted an attack. In the attack a third agent Eve is able to get the responder s nonce by convincing him that is talking with A. It is both an attack on secrecy and on the authentication for B. Eve basically plays as a middleman. 30 def Decr( in K. in[Z K X] out X; Enc( in ....

....precedence and output input precedence. 38 # The ISO 5 pass protocol should guarantee some degree of authentication between the principals. Strong authentication properties can be shown for the protocol. We state these properties in terms of agreement properties following the lead of Lowe (see [Low97] In an ISO 5 pass protocol exchange three participants are involved: the initiator, the responder and the server. The initiator relies on the responder to interact with the server and to get a session key. The interaction between responder and server is transparent to the initiator. From the ....

[Article contains additional citation context not shown here]

G. Lowe. A hierarchy of authentication specifications. In Proceedings of the 10th IEEE CSFW, pages 31--43, 1997.

....protocols can both help to prove protocols correct with respect to a chosen model and to discover flaws. 1.2 Security properties There is no common agreement on how to formalise the meaning of security. Just looking at secrecy or authentication properties, there are a variety of definitions [Aba98, Aba99, AG97, Low97, Ros98b, Sch96]. A property, even the formulation of a property, may be more interesting then another, depending on the protocol and the purpose for which it was designed. Given this abundance of di#erent definitions, it is important to state precisely the properties that are proven and the conditions under ....

....M is secret if it never appears unprotected on the medium. This definition is used for example in Paulson s inductive method [Pau98] and in the strand space approach [THG98c] but originates from Dolev and Yao [DY83] A common definition of authentication is the agreement property defined in Lowe [Low97]: An initiator A agrees with a responder B on same message M if whenever A completes a run of the protocol as initiator, using M apparently with B, then there exists a previous run of the protocol where B acts as responder using M apparently with A. There are other security properties one ....

G. Lowe. A hierarchy of authentication specifications. In Proceedings of the 10th IEEE Computer Security Foundations Workshop, pages 31--43, 1997. 40

....be made precise in the Petri net model. The property should hold for each run of the protocol. We are particularly concerned about those runs in which the responder completes a protocol round. The informal correctness requirement we recalled above can be seen, following the lead of Lowe (see [13]) as an agreement property: To a completed responder round of B done apparently with A as initiator, should correspond in that protocol run a completed initiator round of A done apparently with B as responder. The messages that are exchanged should agree on their values. Formally, one can prove ....

G. Lowe. A hierarchy of authentication specifications. In Proceedings of the 10th IEEE CSFW, 1997.

....public and shared key protocols. As we mentioned in the previous section, we can generalize our awareness rules by introducing a secrecy type to capture secrets other than nonces, but this is but a first step towards generality. Au thentication can be defined (and realized) in different ways [12] and there are several other security properties that are implemented by security protocols, such as confidentiality and integrity of data. We are currently working on extending our approach to analyze these properties and, more generally, on characterizing the class of attacks upon these ....

Lowe, G., A hierarchy of authentication specifications, in: Proceedings of The loth Computer Security Foundations Workshop, IEEE Computer Society Press, 1997.

....adequate for, e.g. electronic voting, where possible values of the vote are known in advance and the goal of the protocol is to preserve the confidentiality of the association between a voter and his her chosen value. Authentication There are also many definitions of authentication (see, e.g. [Low97]) In a nutshell, an event e authenticates agent A if e can occur only if a previous message originated from A. The purpose of authentication is to ensure another agent B that he is indeed talking with A. Both secrecy and authentication are trace properties, i.e. their violations can be found by ....

G. Lowe. A hierarchy of authentication specifications. In Proc. 31--43, 1997.

....in the multiprotocol strand space ( tr ; 1 ) are equivalent if and only if, for every node n 2 1 , n 2 C iff n 2 C 0 . A set of bundles is invariant under bundle equivalences if for all equivalent bundles C and C 0 , C 2 ) C 0 2 . Agreement and non injective agreement properties [15, 28, 30] are invariant under bundle equivalences in this sense. For instance, a non injective agreement property, expressed in our framework, asserts that whenever a bundle contains nodes of a protocol strand (for instance, a responder strand) then it also contains matching nodes of another strand (for ....

Gavin Lowe. A hierarchy of authentication specifications. In 10th Computer Security Foundations Workshop Proceedings, pages 31--43. IEEE Computer Society Press, 1997.

....K is authentic) If we call d S A e f and d S A e g the labels attached to A s and B s final action, respectively, then the property might be expressed by d S A e f O x Q K a Jd S APe g O x Q K , for x a variable. In practice, all forms of authentication in Lowe s hierarchy [15] are captured by the scheme a c b, except the most demanding one that requires one to one bijection between a s and b s. However, our scheme can be easily adjusted to include this stronger form. The scheme also permits expressing secrecy, in the style of [2] To this purpose, it is convenient ....

G. Lowe. A Hierarchy of Authentication Specifications. In Proc. of 10th IEEE Computer Security Foundations Workshop, IEEE Computer Society Press, 1997.

....of nodes S = n # B : n # B m is a sub bundle B 0 , when equipped with those edges of B both endpoints of which are in S [6] Suppose moreover that we are trying to establish an authentication result for a particular strand s in B. The logical form of authentication results ( 19] cp. [11,20]) requires us to show that a corresponding portion of another strand s # is also included in B. Let m be the last node on s such that m # B, and consider the sub bundle B 0 of nodes n # B m. If we can prove that the required portion of s # is included in the sub bundle B 0 , then it is ....

Lowe, G., A hierarchy of authentication specifications, in: 10th Computer Security Foundations Workshop Proceedings (1997), pp. 31--43.

....C # # # C # # #. The penetrator s behavior may di#er arbitrarily between two bundles that are equivalent in this sense, and the orderings # C and # C # may also di#er freely. Authentication goals as defined in Section 3. 12 are invariant under bundle equivalences in this sense (see also [30, 47, 49]) As such, it always concerns what nodes, representing regular activity of the protocol, must be present in bundles. Penetrator activity may or may not be present. Secrecy properties may also be expressed in a form that is invariant under bundle equivalences. We say (temporarily) that a value t ....

Gavin Lowe. A hierarchy of authentication specifications. In 10th Computer Security Foundations Workshop Proceedings, pages 31--43. IEEE Computer Society Press, 1997.

....other public and shared key protocols. As we mentioned in the previous section, we can generalize our awareness rules by introducing a secrecy type to capture secrets other than nonces, but this is but a first step towards generality. Authentication can be defined (and realized) in di#erent ways [12] and there are 15 Accorsi, Basin, Vigan o several other security properties that are implemented by security protocols, such as confidentiality and integrity of data. We are currently working on extending our approach to analyze these properties and, more generally, on characterizing the class ....

Lowe, G., Hierarchy of authentication specifications, in: Proceedings of The 10th Computer Security Foundations Workshop, IEEE Computer Society Press, 1997 .

.... is related to the verification of an entity s claimed identity [15] while message authentication should make it possible for the receiver of a message to ascertain its origin [24] In recent years there have been some formalizations of these different aspects of authentication (see, e.g. [2, 5, 10, 13, 14, 18, 23]) These formalizations are crucial for proofs of authentication properties, that sometimes have been automatized (see, e.g. 9, 11, 16, 17, 20] We use here a basic calculus for modelling concurrent and mobile agents and we give them certain kinds of semantics, exploiting the built in mechanisms ....

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop. IEEE press, 1997.

....language equipped with abstract forms of cryptographic primitives. We expect it would not be difficult to adapt the techniques of this paper to other concurrent languages. There is a variety of different formulations of authenticity properties of protocols, and even a little controversy [BR94, Gol95, Low95, DFG00]. Still, we adopt correspondence assertions because they are simple, precise, and flexible. They are simple annotations of a protocol expressed as a program. They have a precise semantics. They are flexible in the sense that by annotating a protocol in different ways we can express different ....

G. Lowe. A hierarchy of authentication specifications. In 10th Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1995.

.... is related to the verification of an entity s claimed identity [18] while message authentication should make it possible for the receiver of a message to ascertain its origin [30] In recent years there have been some formalizations of these different aspects of authentication (see, e.g. [3, 7, 13, 16, 17, 22, 29]) These formalizations are crucial for proofs of authentication properties, that sometimes have been automatized (see, e.g. 12, 15, 20, 21, 25] A typical approach presented in the literature is the following. First, a protocol is specified in a certain formal model. Then An earlier version ....

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop. IEEE press, 1997.

....ones for authentication, secrecy, and electronic commerce. In this paper we mainly focus on the authentication and secrecy. We use similar ways for representing security properties as in [36] however, we formulate them using well formed formulas in our logic. Authentication. Gavin Lowe [19] proposed agreement properties for authentication protocols. A protocol guarantees an agreement property for a participant B (e.g. acting as a responder) for a certain vector of parameters x, if each time the principal B completes a run of the protocol as a responder using x, supposedly with A, ....

G. Lowe. A hierarchy of authentication specifications. In Proceedings of the 1997 IEEE Computer Society Symposium on Research in Security and Privacy, pages 31--43, 1997.

....the intruder and belongs to the set of honest agents, then the intruder should never perform leak.M (i.e. should never learn M ) Secrecy(tr) # = #A # Agent ; B # Honest # claimSecret.A.B.M in tr # leak.M in tr. We now define some entity authentication specifications. As explained in [7], we believe that the term authentication refers to a collection of related requirements, rather than there being a single generic authentication specification. The following is one of the more common forms of authentication: Whenever A completes a run of the protocol, apparently with B, then B ....

....when they complete a protocol run; the running events should be performed by an honest agent B at the point that it is required that B reaches when its partner A completes its run; normally this will be just before the last send event that has a causal link with a message received by A. See [7] for more details. We believe it would be completely straightforward to extend the results of this paper to other authentication specifications, such as the aliveness and noninjective agreement specifications of [7] It might also be possible to deal with completely di#erent specifications such as ....

[Article contains additional citation context not shown here]

G. Lowe. A hierarchy of authentication specifications. In Proceedings of 10th IEEE Computer Security Foundations Workshop, 1997.

....authentication, because most authentication protocols rely upon the secrecy of some data item to prove authentication. There are many different forms of authentication, and our result does not extend immediately to all of these. For example, a common authentication requirement, called agreement in [14], is that when two agents complete a run with one another, they should agree upon a data item, such as a key. Consider the following version of the Otway Rees protocol (adapted slightly to meet the 43 assumptions of this paper) Message 1a: init resp : na Message 1b: init serv : finit; na; ....

....A; Bg shared(B;S) Message 3 0 : S I B : Na; fA; N b; Kab 0 g shared(B;S) Message 4 0 : S A : fNa;B;Kab 0 g shared(A;S) Hence the results of this paper do not extend to agreement specifications. Similarly, our results do not extend to the so called injective agreement properties of [14], where each run of one agent should correspond to a unique run of their partner. Many protocols allow attacks where an agent A can end up in a state where he believes he has completed two runs of the protocol with B, but where B believes he has completed only a single run with A. It is clear that ....

Gavin Lowe. A hierarchy of authentication specifications. In Proceedings of 10th IEEE Computer Security Foundations Workshop, 1997.

No context found.

G. Lowe. A hierarchy of authentication specifications. In 43. IEEE Computer Society Press, 1995.

No context found.

G. Lowe. A hierarchy of authentication specifications. In 10th Computer Security Foundations Workshop, pages 31--43. IEEE Computer Society Press, 1995.

No context found.

G. Lowe. A hierarchy of authentication specifications. In PCSFW: Proceedings of The 10th Computer Security Foundations Workshop. IEEE Computer Society Press, 1997.

No context found.

G. Lowe. A Hierarchy of Authentication Specifications. In Proc. of 10th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, 1997.

No context found.

Lowe, G., A hierarchy of authentication specifications, in: Proc. CSFW '97, Rockport (1997), pp. 31--44.

No context found.

G. Lowe. A hierarchy of authentication specifications. In Proc. 10th Computer Security Foundations Workshop, pages 31--44. IEEE, 1997.

No context found.

Lowe, G.: A hierarchy of authentication specifications. In: Proc. 10th Computer Security Foundations Workshop, IEEE (1997) 31--44

No context found.

G. Lowe. A hierarchy of authentication specifications. In Proc. 10th IEEE Computer Security Foundations Workshop, pages 31--43, 1997.

No context found.

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop. IEEE press, 1997.

No context found.

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop. IEEE press, 1997.

No context found.

G. Lowe. A hierarchy of authentication specifications. In Proc. CSFW'97. IEEE Computer Society Press, 1997.

No context found.

G. Lowe. A hierarchy of authentication specifications. In Proc. CSFW'97. IEEE Computer Society Press, 1997.

No context found.

G. Lowe. A hierarchy of authentication specifications. In Proceedings of 10th IEEE Computer Security Foundations Workshop, pages 31--44, Rockport, USA, 1997. IEEE Computer Society Press.

No context found.

G. Lowe. A hierarchy of authentication specification. In Proceedings of the 10th Computer Security Foundation Workshop, pages 31--43. IEEE press, 1997.

No context found.

G. Lowe. A hierarchy of authentication specifications. In Proceedings of 10th IEEE Computer Security Foundations Workshop, 1997.

No context found.

G. Lowe, "A Hierarchy of Authentication Specifications," pp. 31--43, 1997.

No context found.

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop, pages 31--44. IEEE press, 1997.

No context found.

Lowe, G.: A hierarchy of authentication specifications. In: PCSFW: Proceedings of The 10th Computer Security Foundations Workshop, IEEE Computer Society Press (1997)

No context found.

G. Lowe. A hierarchy of authentication specifications. In Proc. 10th Computer Security Foundations Workshop, pages 31--44. IEEE, 1997.

No context found.

G. Lowe. "A Hierarchy of Authentication Specification". In Proceedings of the 10th Computer Security Foundation Workshop. IEEE press, 1997.

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