From paul.drielsma at inf.ethz.ch Thu Jun 1 10:02:32 2006 From: paul.drielsma at inf.ethz.ch (Paul Hankes Drielsma) Date: Thu Jun 1 04:03:56 2006 Subject: [Avispa-users] (no subject) In-Reply-To: <3025.131.174.32.242.1149089361.squirrel@mail.irisa.fr> References: <3025.131.174.32.242.1149089361.squirrel@mail.irisa.fr> Message-ID: Hello Vlad, The basic behaviour of a transition is that if the trigger (i.e. left- hand side) is not fulfilled, then the transition cannot fire. So it is not really any of the three possibilities you list, because NO message will be received unless there is an enabled transition that fires. It is not possible to disable the intruder completely, because we rely on him to relay messages. However, if you want to simplify the output of path mode in OFMC, then the best way to go is to specify only one session, between only honest agents, and then run path mode. This can be very useful. There will still be some transitions where the intruder can try to send his own stuff instead of just relaying the messages of the honest agents, but in general the output is quite readable. I hope this helps. Cheers, Paul. On May 31, 2006, at 5:29 PM, rusu@irisa.fr wrote: > Hi, > > I am a novice user and have a question regarding the semantics of > HLPSL. Assume the following piece of code: > > ... > local M' : message > ... > 1. State = 0 /\ Rcv(M') /\ M' = (a certain pattern) > =|> State' := 1 /\ ... > > and this is the only transition at State = 1. > > What happens if some message is received, but the condition on the > pattern is not satisfied? Some options are: > > - the message is disregarded (implicit self-loop at state 0) > - the agent enters a state where all transitions are enabled > - the agent enters a deadlock state > ... > > I have tried to guess the behaviour using OFMC in "path mode", but > with the intruder interfering it is hard to see what happens. > > BTW, is it possible to disable the intruder? This would simplify > initial debugging/simulation, before going into verification. > > Thanks in advance for your help, > > Vlad > > _______________________________________________ > Avispa-users mailing list > Avispa-users@avispa-project.org > http://www.avispa-project.org/mailman/listinfo/avispa-users From rusu at irisa.fr Thu Jun 1 12:25:02 2006 From: rusu at irisa.fr (rusu@irisa.fr) Date: Thu Jun 1 06:26:36 2006 Subject: [Avispa-users] (no subject) In-Reply-To: References: <3025.131.174.32.242.1149089361.squirrel@mail.irisa.fr> Message-ID: <4810.131.174.32.242.1149157502.squirrel@mail.irisa.fr> Thanks! So I guess I need to specify "unexpected" messages explicitly, as in local M' : message ... 1. State = 0 /\ Rcv(M') /\ M' = (a certain pattern) =|> State' := 1 /\ ... 2. State = 0 /\ Rcv(M') /\ not (M' = that pattern) =|> State' := 13 /\... which is a bit verbose, but doable. While I'm here, I might just as well ask my other questions: - are there plans to incorporate the "spontaneous" transitions (without trigger) soon? - the current version of the reference manual just mentions the witness/request constructions as plans for the future. The tutorial shows how to use them, but it would be nice if the formal semantics was documented somewhere. Maybe in a future deliverable? Cheers, Vlad > Hello Vlad, > > The basic behaviour of a transition is that if the trigger (i.e. left- > hand side) is not fulfilled, then the transition cannot fire. So it > is not really any of the three possibilities you list, because NO > message will be received unless there is an enabled transition that > fires. > > It is not possible to disable the intruder completely, because we > rely on him to relay messages. However, if you want to simplify the > output of path mode in OFMC, then the best way to go is to specify > only one session, between only honest agents, and then run path > mode. This can be very useful. There will still be some transitions > where the intruder can try to send his own stuff instead of just > relaying the messages of the honest agents, but in general the output > is quite readable. > > I hope this helps. > > Cheers, > Paul. > > On May 31, 2006, at 5:29 PM, rusu@irisa.fr wrote: > >> Hi, >> >> I am a novice user and have a question regarding the semantics of >> HLPSL. Assume the following piece of code: >> >> ... >> local M' : message >> ... >> 1. State = 0 /\ Rcv(M') /\ M' = (a certain pattern) >> =|> State' := 1 /\ ... >> >> and this is the only transition at State = 1. >> >> What happens if some message is received, but the condition on the >> pattern is not satisfied? Some options are: >> >> - the message is disregarded (implicit self-loop at state 0) >> - the agent enters a state where all transitions are enabled >> - the agent enters a deadlock state >> ... >> >> I have tried to guess the behaviour using OFMC in "path mode", but >> with the intruder interfering it is hard to see what happens. >> >> BTW, is it possible to disable the intruder? This would simplify >> initial debugging/simulation, before going into verification. >> >> Thanks in advance for your help, >> >> Vlad >> >> _______________________________________________ >> Avispa-users mailing list >> Avispa-users@avispa-project.org >> http://www.avispa-project.org/mailman/listinfo/avispa-users > > From paul.drielsma at inf.ethz.ch Fri Jun 2 14:12:35 2006 From: paul.drielsma at inf.ethz.ch (Paul Hankes Drielsma) Date: Fri Jun 2 08:14:06 2006 Subject: [Avispa-users] (no subject) In-Reply-To: <4810.131.174.32.242.1149157502.squirrel@mail.irisa.fr> References: <3025.131.174.32.242.1149089361.squirrel@mail.irisa.fr> <4810.131.174.32.242.1149157502.squirrel@mail.irisa.fr> Message-ID: <07FF2C11-48C5-4BF4-BA2F-71838FEBCF30@inf.ethz.ch> Hi Vlad, > Thanks! So I guess I need to specify "unexpected" messages explicitly, > as in > > local M' : message > ... > 1. State = 0 /\ Rcv(M') /\ M' = (a certain pattern) > =|> State' := 1 /\ ... > > 2. State = 0 /\ Rcv(M') /\ not (M' = that pattern) > =|> State' := 13 /\... > > which is a bit verbose, but doable. Of course you can do this, yes. It's really only interesting if your protocol does something interesting as a failure mechanism once it's in State 13. In general, we avoid doing this and write models where the transitions fire if messages meeting the correct pattern come in, and for other messages no transition is possible. > While I'm here, I might just as well ask my other questions: > > - are there plans to incorporate the "spontaneous" transitions > (without trigger) soon? The coming version will not include spontaneous transitions. You can emulate the same behaviour using the immediate reaction transitions. If you have 1. A --> B You can always write. 1a. A =|> State' := 99 1b. State = 99 /\ RCV(start) =|> B This is not elegant, but it should work. > - the current version of the reference manual just mentions the > witness/request constructions as plans for the future. The tutorial > shows how to use them, but it would be nice if the formal semantics > was documented somewhere. Maybe in a future deliverable? These are incorporated in the current version. The meaning is described on page 16 of the user manual, while the formal semantics is simply a (parameterized) predicate in the logic, like any other, which is true in the trace (for the given parameters) when it appears in the RHS of a transition and false everywhere else. How they are formally interpreted in the goal formulae can be found if you look, for example, the formula "authentication_on_nb" in the IF specification on page 53 of the user manual. Hope this helps. Paul. From franziska.buendgens at gmail.com Mon Jun 12 13:30:15 2006 From: franziska.buendgens at gmail.com (=?ISO-8859-1?Q?Franziska_B=FCndgens?=) Date: Mon Jun 12 06:51:41 2006 Subject: [Avispa-users] MAC modelling Message-ID: Dear all! Is it possible to model MAC functions in HLPSL using the built in hash functions? I was thinking of something like MAC = Hash(S|H(S|msg)) where S is some shared secret between 2 parties. Can this be done or is there another way to model MACs in HLPSL? Thanks for your help, kind regards Franziska From khaled.masmoudi at int-evry.fr Mon Jun 12 13:39:34 2006 From: khaled.masmoudi at int-evry.fr (Khaled Masmoudi) Date: Mon Jun 12 07:00:55 2006 Subject: [Avispa-users] MAC modelling In-Reply-To: Message-ID: <007a01c68e14$e0837700$48679f9d@micro.intevry.fr> What you described is the easiest way to model keyed hash functions or HMACs i.e. HMAC=h(K,f(msg)), K being a symmetric key. If you want to model MACs based on public key signature, you can use MAC={f(msg)}_inv(PK), where PK is a public key. Depends on the key material of your protocol... -------------------------------------------------------------------------- -- ---------- Khaled MASMOUDI Institut National des Télécommunications Wireless Networks and Multimedia Services Department (RS2M) 9, rue Charles Fourier - 91011 Evry Cedex Personal Page: www.masmoudi.net Tél : +33 1 60 76 42 65 Fax : +33 1 60 76 45 78 khaled.masmoudi@int-evry.fr -----Message d'origine----- De : avispa-users-bounces@avispa-project.org [mailto:avispa-users-bounces@avispa-project.org] De la part de Franziska Bündgens Envoyé : lundi 12 juin 2006 13:30 À : Avispa-users@avispa-project.org Objet : [Avispa-users] MAC modelling Dear all! Is it possible to model MAC functions in HLPSL using the built in hash functions? I was thinking of something like MAC = Hash(S|H(S|msg)) where S is some shared secret between 2 parties. Can this be done or is there another way to model MACs in HLPSL? Thanks for your help, kind regards Franziska _______________________________________________ Avispa-users mailing list Avispa-users@avispa-project.org http://www.avispa-project.org/mailman/listinfo/avispa-users begin 666 smime.p7s M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$' M`0``H(((YS""`F\P@@'8H ,"`0("`P_Z#C -!@DJADB&]PT!`00%`#!B,0LP M"08#500&$P):03$E,",&`U4$"A,<5&AA=W1E($-O;G-U;'1I;F<@*%!T>2D@ M3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E9 MH/ G=%O[D_7:A/8T^WSSM4G$-*9SJ10I[[1EA5M52L#FTUOO0@_LC;72.>6! M32&NCA>&I$-.)!W X ]]T?]G`CJ8>IR$R^FT'VO8?AD6"MHDPF M1PBW3S""`RTP@@*6H ,"`0("`0`P#08)*H9(AO<-`0$$!0`P@=$Q"S )!@-5 M! 83`EI!,14P$P8#500($PQ797-T97)N($-A<&4Q$C 0!@-5! <3"4-A<&4@ M5&]W;C$:,!@&`U4$"A,15&AA=W1E($-O;G-U;'1I;F%PTY-C Q,#$P,# P,#!:%PTR,#$R M,S$R,S4Y-3E:,('1,0LP"08#500&$P):03$5,!,&`U4$"!,,5V5S=&5R;B!# M87!E,1(P$ 8#500'$PE#87!E(%1O=VXQ&C 8!@-5! H3$51H87=T92!#;VYS M=6QT:6YG,2@P)@8#500+$Q]#97)T:69I8V%T:6]N(%-EE'V Q1MNIRD;"$ M7GTM#8][$M^%)74H=#I"+&,GGY5[2^]^&8<=ANJCW;G.EF0:PA1N1*Q\YH_H M30]Q'T XI@"CAWCV^92&7JWJP%YVZ]D4HUUN>GP,I4M5?P89*7^>FB;5:KLX M) AJF,>QVJ.8D?UYV^5:Q!RY`@,!``&C$S 1, \&`U4=$P$!_P0%, ,!`?\P M#08)*H9(AO<-`0$$!0`#@8$`Q^R2?D[X]9:E9V(JI/!-$6#0;XU@6&&L)KM2 M-5P(SS#[J$J6BA]B0B.,%P_TNF2<%ZQ'*=^=F%[2;&!Q7**LW'GCYVX`1Q^U M#2CH`IWDFOT3]*;9?+'XW%\C)@F1@'/0%!O>0ZF#)?+FG"\5ROZFJXH'=8L, MW5&$:^3XT2D@3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E M_0( "9->GIKN?9='%*E2%#T@$?Z>VT3QA!$ >9!ER M8+?[`@,!``&C@90P@9$P$@8#51T3`0'_! @P!@$!_P(!`#!#!@-5'1\$/# Z M,#B@-J TAC)H='1P.B\O8W)L+G1H87=T92YC;VTO5&AA=W1E4&5R,!PQ&C 8 M!@-5! ,3$5!R:79A=&5,86)E;#(M,3,X, T&"2J&2(;W#0$!!04``X&!`$B, MT5"#Z@LNS VC9JQG#W^OK+["%Z%#EI2=?TPAN/@V'ZHMGS8OP/0<4""3<#S] MK>%A8L/9.AE^A+&9&P#%&@N"=)XE4)1BQ]LG<52D@3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E2D@3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E References: Message-ID: ---------- Forwarded message ---------- From: Franziska B?ndgens Date: Jun 13, 2006 12:44 PM Subject: Protocol gets stuck help please To: avispa-users-bounces@avispa-project.org Hi all! I have here a brand new protocol designed by a fellow student. He asked me to check his protocol with AVISPA and so I did, but I seem to have made a mistake and the protocol gets stuck before the second (marked with 3. in the hlpsl file) transition of the gegenstelle role. I cannot find the reason for this. I have attached the hlpsl file and the output of the -p option. If anyone could have a look at this and give me a hint as to why I get stuck here it would be highly appreciated. Thank you! Franziska -------------- next part -------------- A non-text attachment was scrubbed... Name: ply.log Type: application/octet-stream Size: 3797 bytes Desc: not available Url : http://carroll.ai.dist.unige.it/pipermail/avispa-users/attachments/20060613/d9cd6bab/ply-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: masc.hlpsl Type: application/octet-stream Size: 2013 bytes Desc: not available Url : http://carroll.ai.dist.unige.it/pipermail/avispa-users/attachments/20060613/d9cd6bab/masc-0001.obj From Laurent.Vigneron at loria.fr Tue Jun 13 13:25:02 2006 From: Laurent.Vigneron at loria.fr (Laurent Vigneron) Date: Tue Jun 13 06:46:27 2006 Subject: [Avispa-users] Protocol gets stuck help please In-Reply-To: References: Message-ID: <1150197902.448ea08edb362@www.loria.fr> Hello Franziska, I see one problem in your specification: you assign variables Km and Ke with the result of a hash, but they are declared of type symmetric_key. This is not compatible, you shoul declare those variables of type message. The type symmetric_key is only for atomic keys. 'hope this will help, Laurent. > ---------- Forwarded message ---------- > From: Franziska B?ndgens > Date: Jun 13, 2006 12:44 PM > Subject: Protocol gets stuck help please > To: avispa-users-bounces@avispa-project.org > > > Hi all! > I have here a brand new protocol designed by a fellow student. He > asked me to check his protocol with AVISPA and so I did, but I seem to > have made a mistake and the protocol gets stuck before the second > (marked with 3. in the hlpsl file) transition of the gegenstelle role. > I cannot find the reason for this. I have attached the hlpsl file and > the output of the -p option. If anyone could have a look at this and > give me a hint as to why I get stuck here it would be highly > appreciated. Thank you! > Franziska > From s9901726 at sms.ed.ac.uk Fri Jun 16 14:15:28 2006 From: s9901726 at sms.ed.ac.uk (G Keighren) Date: Fri Jun 16 07:34:38 2006 Subject: [Avispa-users] CL-AtSE Backend Message-ID: <20060616131528.q8gl5dr0v4gsc8oc@www.sms.ed.ac.uk> Hello, I am using the CL-AtSe backend for my MSc project (I require the in-built xor handling functions) and have a few questions: 1. I notice that CL-AtSe does not process a prelude file, but instead uses a hardcoded one. However, I wanted to disable the intruder's ability to generate new instances of specific types e.g. VAR_A(12). Is there another way in which this can be done? The reason I ask is that there are a number of trivial attacks found in my models when the intruder is able to generate known symmetric keys. 2. I have two variants of a particular model, one where all the (non-deterministic) transitions are included in a single role, and one where each transition is modelled as a separate role. From the output of the -noexec option, it appears that CL-AtSe builds the entire tree of possible transition interleavings for each role. This causes a huge discrepancy in the time it takes to process each model. In the first case, the conversion from IF seems exponential in the number of transitions (due to the tree being built), whereas the latter case seems to be linear in the number of roles. I am interested to know why CL-AtSe is able to handle non-determinism between roles (i.e. from the composition of roles) almost trivially, but has serious trouble with non-determinism within a role? As mentioned, I have worked around the issue for now, but the model is less intuitive. 3. In the attack traces produced, only communications are included. Any manipulation of data by the intruder is not. This can sometimes make it quite hard to work out exactly what the intruder has done. It would be nice if it was possible to see what the intruder was doing in an attack trace. 4. When the -notypes option is not used, the intruder's ability to xor known items together seems to be lost. Also, because the 'light' unification algorithm is used, {X}_Y does not unify with {xor(A,B)}_Y. Is this intentional? It would be good if it was possible to use the full unification algorithm even when -notypes is not used. Is the intruder's ability to xor known data dependant on the unification algorithm? Again, this is not really a problem for me since using -notypes gets round it, but it may be for other people. thanks in advance, Gavin Keighren From bhavin.desai at ntlworld.com Mon Jun 26 12:47:03 2006 From: bhavin.desai at ntlworld.com (bhavin.desai@ntlworld.com) Date: Mon Jun 26 06:06:01 2006 Subject: [Avispa-users] Assistance Requested Message-ID: <20060626104703.QWAS16286.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> Hello, I got stuck trying to "make SAFE" a specification that was originally UNSAFE as presented in the HLPSL Tutorial. If you have time, please have a look at the two enclosed specifications. The one starting with ?TODO? gets translated but then fails the OFMC backend processing. I have followed the advice in the documentation regarding priming variables and the use of type-pattern declarations. I look forward to your comments and suggestions. Bhavin Desai Security Practice LogicaCMG UK Limited Chaucer House Springfield Drive Leatherhead Surrey KT22 7LP United Kingdom www.logicacmg.com Tel: +44 (0) 1372 369639 Fax: +44 (0) 1372 369834 bhavin.desai@logicacmg.com ----------------------------------------- Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information -------------- next part -------------- _______________________________________________ Avispa-users mailing list Avispa-users@avispa-project.org http://www.avispa-project.org/mailman/listinfo/avispa-users -------------- next part -------------- %% The HLPSL Tutorial %% Example 2: made SAFE (see %% below) %% %% HLPSL: role alice(A, S, B: agent, Ka : symmetric_key, SND_SA, RCV_SA, SND_BA, RCV_BA: channel(dy)) played_by A def= local State : nat, %% added Nb here: Na,Ns,Nb : text, K : symmetric_key, X : {symmetric_key.text.text.text}_symmetric_key, Y : {text}_symmetric_key, Delete : nat init State := 0 transition %% Y' is {Nb'}_Kb 1. State = 0 /\ RCV_BA(A.B.Y') =|> State':= 2 /\ Na' := new() /\ SND_SA(A.B.{Na'}_Ka.Y') %% added Nb' here: 2. State = 2 /\ RCV_SA(A.B.{K'.Na.Ns'.Nb'}_Ka.X') =|> State':= 4 /\ SND_BA(A.B.X'.{Na.Ns'.Nb'}_K') %% added Nb here since seen in 2 above. ### 2 times: 3. State = 4 /\ RCV_BA(A.B.{Ns.Na.Nb}_K) =|> State':= 6 /\ request(A,B,alice_bob_na,Na,Nb) end role role server (A, S, B : agent, Ka, Kb : symmetric_key, SND_AS, RCV_AS: channel(dy)) played_by S def= local State : nat, Ns,Na,Nb : text, K : symmetric_key init State := 1 transition %% Added Nb' here: 1. State = 1 /\ RCV_AS(A.B.{Na'}_Ka.{Nb'}_Kb) =|> State':= 3 /\ Ns' := new() /\ K' := new() /\ SND_AS(A.B.{K'.Na'.Ns'.Nb'}_Ka.{K'.Na'.Ns'.Nb'}_Kb) /\ secret(K',k,{A,B,S}) end role role bob (A, S, B: agent, Kb : symmetric_key, SND_AB, RCV_AB: channel(dy)) played_by B def= local State : nat, Ns, Na, Nb : text, K : symmetric_key init State := 100 transition %% A new first state 100 is defined 100. State = 100 /\ RCV_AB(start) =|> State':= 5 /\ Nb' := new() /\ SND_AB(A.B.{Nb'}_Kb) %% added Nb here since seen in 100 above. ### 4 times: 1. State = 5 /\ RCV_AB(A.B.{K'.Na'.Ns'.Nb}_Kb.{Na'.Ns'.Nb'}_K') =|> State':= 7 /\ SND_AB(A.B.{Ns'.Na'.Nb'}_K') /\ witness(B,A,alice_bob_na,Na',Nb') end role role session(A, S, B : agent, Ka, Kb : symmetric_key) def= local SSA, RSA, SBA, RBA, SAS, RAS, SAB, RAB : channel (dy) composition alice (A, S, B, Ka, SSA, RSA, SBA, RBA) /\ server(A, S, B, Ka, Kb, SAS, RAS) /\ bob (A, S, B, Kb, SAB, RAB) end role role environment() def= const a, b, s : agent, ka, kb, ki : symmetric_key, alice_bob_na, k: protocol_id intruder_knowledge = {a, b, s, ki} composition session(a,s,b,ka,kb) /\ session(a,s,i,ka,ki) /\ session(i,s,b,ki,kb) end role goal secrecy_of k authentication_on alice_bob_na end goal environment() -------------- next part -------------- %% The HLPSL Tutorial %% Example 2: %% %% HLPSL: role alice(A, S, B: agent, Ka : symmetric_key, SND_SA, RCV_SA, SND_BA, RCV_BA: channel(dy)) played_by A def= local State : nat, Na,Ns : text, K : symmetric_key, X : {symmetric_key.text.text}_symmetric_key init State := 0 transition 1. State = 0 /\ RCV_BA(start) =|> State':= 2 /\ Na' := new() /\ SND_SA(A.B.{Na'}_Ka) 2. State = 2 /\ RCV_SA(A.B.{K'.Na.Ns'}_Ka.X') =|> State':= 4 /\ SND_BA(A.B.X'.{Na.Ns'}_K') 3. State = 4 /\ RCV_BA(A.B.{Ns.Na}_K) =|> State':= 6 /\ request(A,B,alice_bob_na,Na) end role role server (A, S, B : agent, Ka, Kb : symmetric_key, SND_AS, RCV_AS: channel(dy)) played_by S def= local State : nat, Ns,Na : text, K : symmetric_key init State := 1 transition 1. State = 1 /\ RCV_AS(A.B.{Na'}_Ka) =|> State':= 3 /\ Ns' := new() /\ K' := new() /\ SND_AS(A.B.{K'.Na'.Ns'}_Ka.{K'.Na'.Ns'}_Kb) /\ secret(K',k,{A,B,S}) end role role bob (A, S, B: agent, Kb : symmetric_key, SND_AB, RCV_AB: channel(dy)) played_by B def= local State : nat, Ns, Na : text, K : symmetric_key init State := 5 transition 1. State = 5 /\ RCV_AB(A.B.{K'.Na'.Ns'}_Kb.{Na'.Ns'}_K') =|> State':= 7 /\ SND_AB(A.B.{Ns'.Na'}_K') /\ witness(B,A,alice_bob_na,Na') end role role session(A, S, B : agent, Ka, Kb : symmetric_key) def= local SSA, RSA, SBA, RBA, SAS, RAS, SAB, RAB : channel (dy) composition alice (A, S, B, Ka, SSA, RSA, SBA, RBA) /\ server(A, S, B, Ka, Kb, SAS, RAS) /\ bob (A, S, B, Kb, SAB, RAB) end role role environment() def= const a, b, s : agent, ka, kb, ki : symmetric_key, alice_bob_na, k: protocol_id intruder_knowledge = {a, b, s, ki} composition session(a,s,b,ka,kb) /\ session(a,s,i,ka,ki) /\ session(i,s,b,ki,kb) end role goal secrecy_of k authentication_on alice_bob_na end goal environment() From s9901726 at sms.ed.ac.uk Mon Jun 26 13:24:46 2006 From: s9901726 at sms.ed.ac.uk (G Keighren) Date: Mon Jun 26 06:43:41 2006 Subject: [Avispa-users] Assistance Requested In-Reply-To: <20060626104703.QWAS16286.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> References: <20060626104703.QWAS16286.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> Message-ID: <20060626122446.io97mksnq8gwww0g@www.sms.ed.ac.uk> Bhavin, the problem appears to be due to the extra Nb' argument to the witness and request predicates. I have not looked at the model in any great detail, so I don'y know if they're meant to be there, but removing them causes the model to be accepted and an attack found. If Nb' is necessary, then replacing Na',Nb' with Na'.Nb' works, as follows: request(A,B,alice_bob_na,Na,Nb) -- BECOMES --> request(A,B,alice_bob_na,Na.Nb) witness(B,A,alice_bob_na,Na',Nb') -- BECOMES --> witness(B,A,alice_bob_na,Na'.Nb') Hope this helps, Gavin Keighren > Hello, > > I got stuck trying to "make SAFE" a specification that was originally > UNSAFE as presented in the HLPSL Tutorial. If you have time, please > have a look at the two enclosed specifications. The one starting > with ?TODO? gets translated but then fails the OFMC backend > processing. I have followed the advice in the documentation > regarding priming variables and the use of type-pattern declarations. > > I look forward to your comments and suggestions. From compa at dist.unige.it Mon Jun 26 15:42:07 2006 From: compa at dist.unige.it (Luca Compagna) Date: Mon Jun 26 09:01:04 2006 Subject: [Avispa-users] Assistance Requested In-Reply-To: <20060626122446.io97mksnq8gwww0g@www.sms.ed.ac.uk> References: <20060626104703.QWAS16286.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> <20060626122446.io97mksnq8gwww0g@www.sms.ed.ac.uk> Message-ID: <1151329327.449fe42f71143@webmail.unige.it> Dear Bhavin, Gavin is right. When you write request(A,B,alice_bob_na,Na,Nb) you refer to a 5-ary predicate, but request is defined as a 4-ary one. As last parameter you should use "Na.Nb" to indicate that you are pairing Na with Nb. Best regards, Luca Quoting G Keighren : > Bhavin, > > the problem appears to be due to the extra Nb' argument to the witness > and request predicates. I have not looked at the model in any great > detail, so I don'y know if they're meant to be there, but removing them > causes the model to be accepted and an attack found. > > If Nb' is necessary, then replacing Na',Nb' with Na'.Nb' works, as follows: > > request(A,B,alice_bob_na,Na,Nb) -- BECOMES --> > request(A,B,alice_bob_na,Na.Nb) > witness(B,A,alice_bob_na,Na',Nb') -- BECOMES --> > witness(B,A,alice_bob_na,Na'.Nb') > > > Hope this helps, > > Gavin Keighren > > > > > > Hello, > > > > I got stuck trying to "make SAFE" a specification that was originally > > UNSAFE as presented in the HLPSL Tutorial. If you have time, please > > have a look at the two enclosed specifications. The one starting > > with ?TODO? gets translated but then fails the OFMC backend > > processing. I have followed the advice in the documentation > > regarding priming variables and the use of type-pattern declarations. > > > > I look forward to your comments and suggestions. > > > _______________________________________________ > Avispa-users mailing list > Avispa-users@avispa-project.org > http://www.avispa-project.org/mailman/listinfo/avispa-users > From bhavin.desai at ntlworld.com Mon Jun 26 17:14:51 2006 From: bhavin.desai at ntlworld.com (bhavin.desai@ntlworld.com) Date: Mon Jun 26 10:33:46 2006 Subject: [Avispa-users] Assistance Requested Message-ID: <20060626151451.VWIZ16286.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> Gavin, Luca, Thank you very much for resolving the problem. I am assessing AVISPA as part of my dissertation/project for the Information Security MSc at Royal Holloway University of London. Is there any formal acknowledgement that I should declare regarding the use of AVISPA for my project? Is there any standard text that I could include? (I will of course acknowledge the personal assistance provided by you.) It's interesting that an attack was found, even though I thought that I had fixed the protocol to be SAFE!!! This demonstrates the difficulty of protocol security (although the general protocol security problem is undecidable). If anyone has new/unpublished personal insights or comments on AVISPA that would be useful for my MSc dissertation, then please let me know. All contributions will be acknowledged. [My strict project submission deadline is 8 September 2006.] Bhavin. > > From: Luca Compagna > Date: 2006/06/26 Mon PM 02:42:07 BST > To: G Keighren > CC: bhavin.desai@ntlworld.com, Avispa-users@avispa-project.org > Subject: Re: [Avispa-users] Assistance Requested > > Dear Bhavin, > Gavin is right. When you write > > request(A,B,alice_bob_na,Na,Nb) > > you refer to a 5-ary predicate, but request is defined as a 4-ary one. As last > parameter you should use "Na.Nb" to indicate that you are pairing Na with Nb. > > Best regards, > Luca > > Quoting G Keighren : > > > Bhavin, > > > > the problem appears to be due to the extra Nb' argument to the witness > > and request predicates. I have not looked at the model in any great > > detail, so I don'y know if they're meant to be there, but removing them > > causes the model to be accepted and an attack found. > > > > If Nb' is necessary, then replacing Na',Nb' with Na'.Nb' works, as follows: > > > > request(A,B,alice_bob_na,Na,Nb) -- BECOMES --> > > request(A,B,alice_bob_na,Na.Nb) > > witness(B,A,alice_bob_na,Na',Nb') -- BECOMES --> > > witness(B,A,alice_bob_na,Na'.Nb') > > > > > > Hope this helps, > > > > Gavin Keighren > > > > > > > > > > > Hello, > > > > > > I got stuck trying to "make SAFE" a specification that was originally > > > UNSAFE as presented in the HLPSL Tutorial. If you have time, please > > > have a look at the two enclosed specifications. The one starting > > > with ?TODO? gets translated but then fails the OFMC backend > > > processing. I have followed the advice in the documentation > > > regarding priming variables and the use of type-pattern declarations. > > > > > > I look forward to your comments and suggestions. > > > > > > _______________________________________________ > > Avispa-users mailing list > > Avispa-users@avispa-project.org > > http://www.avispa-project.org/mailman/listinfo/avispa-users > > > > > > ----------------------------------------- Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information From compa at dist.unige.it Wed Jun 28 16:01:03 2006 From: compa at dist.unige.it (Luca Compagna) Date: Wed Jun 28 09:19:58 2006 Subject: [Avispa-users] FINAL CALL FOR PAPERS: Workshop on Secure Information Systems (extended deadline) Message-ID: <1151503263.44a28b9f0b984@webmail.unige.it> It might be of interested for someone of you. Best regards, Luca ----------------------------------------------------------------- FINAL CALL FOR PAPERS (extended deadline) ----------------------------------------------------------------- 1st International Workshop on Secure Information Systems (SIS'06) Wisla, Poland, November 6-10, 2006 http://www.sis2006.pti.katowice.pl/ ----------------------------------------------------------------- Extended versions of selected papers will be published as in a special issue of the Journal of Information Assurance and Security (JIAS) http://www.softcomputing.net/jias/ The 1st International Workshop on Secure Information Systems (SIS'06) will be held in Wisla, Poland on November 6-10, 2006, in conjunction with the First International Multiconference on Computer Science and Information Systems, http://www.FIMCSIT.pti.katowice.pl The SIS workshop is envisioned as a forum to promote the exchange of ideas and results addressing complex security issues that arise in modern information systems. We aim at bringing together a community of security researchers and practitioners working in such divers areas as networking security, antivirus protection, intrusion detection, cryptography, security protocols, and others. We would like to promote an integrated view at the security of information systems. As information systems evolve, becoming more complex and ubiquitous, issues relating to security, privacy and dependability become more critical. At the same time, the global and distributed character of modern computing - typically involving interconnected heterogeneous execution environments - introduces many new and challenging engineering and scientific problems. Providing protection against increasingly sophisticated attacks requires strengthening the interaction between different security communities, e.g. antivirus and networking. New technologies lead to the emergence of new threats and attack strategies, involving smart mobile devices, peer-to-peer networks, instant messaging, VoIP, mesh networks or even networked consumer devices, such as house appliances or cars. Furthermore, the increasing openness of the communications infrastructure results in novel threats and can jeopardize critical enterprise and public infrastructure, such as industrial automation and process control systems. Not only it is estimated that half of all Web applications and Internet storefronts still contain some security vulnerabilities, but secure commerce applications are also exposed to increasingly elaborate attacks, including spyware, phishing and other social engineering methods. In order to develop a secure system, security has to be considered in all phases of the lifecycle and adequately addressed in all layers of the system. At the same time, good engineering has to take into account both scientific and economic aspects of every solution: the cost of security has to be carefully measured against its benefits - in particular the expected cost of mitigated risks. Most companies and individuals treat security measures in information system as a necessary, but often uncomfortable, overhead. The increasing penetration of computing in all domains of everyday life means that security of critical business systems is often managed and maintained by personnel who are not knowledgeable in the field. This highlights the importance of usability and ease of configuration of security mechanism and protocols. Covered topics include (but are not limited to): * Access control * Adaptive security * Cryptography * Copyright protection * Cyberforensics * Honeypots * Intrusion detection * Network security * Privacy * Secure commerce * Security exploits * Security patterns * Security policies * Security protocols * Security services * Security evaluation and prediction * Software protection * Trusted computing * Threat modeling * Usability and security * Viruses and worms * Zero-configuration security mechanisms PAPER SUBMISSION AND PUBLICATION - Authors should submit papers in PDF format before July 16, 2006 (extended deadline) using the submissions site: http://www.econferences.org/multiconference/01/ - Papers should be formatted according to the LNCS style and not exceed 10 pages. - Papers will be subject to peer review and accepted on the basis of their scientific merit and relevance to the workshop topics - Papers presented at the workshop will be included in the conference proceedings and published on a CD (with an ISSN/ISBN number) - Extended versions of selected papers will be published as in a special issue of the Journal of Information Assurance and Security (JIAS) http://www.softcomputing.net/jias/ DATES Submission of Papers: July 16, 2006 (extended) Notification of Acceptance: September 1, 2006 Camera-Ready Papers: October 1, 2006 Conference: November 6-10, 2006 WORKSHOP CHAIR: Konrad Wrona, SAP Research, France LOCAL ORGANIZING COMMMITTEE: Lukasz Nitschke, Adam Mickiewicz University, Poland Michal Ren, Adam Mickiewicz University, Poland PROGRAM COMMITTEE: Hirokazu Aoshima Hitachi Research, Japan Eric Behr Northern Illinois University, USA Nicolas Courtois Axalto, France Kris Gaj Gorge Mason University, USA Silke Holtmans Nokia Research, Finland Lech Janczewski University of Auckland, New Zealand Stanislaw Jarecki University of California Irvine, USA Marek Klonowski Wroclaw University of Technology, Poland Ryszard Kossowski Warsaw University of Technology , Poland Refik Molva Eurecom Institute, France Josef Pieprzyk Macquarie University, Australia Costin Raiu Kaspersky Lab, Romania Sugata Sanyal Tata Institute of Fundamental Research, India Andreas Schaad SAP Research, Germany Mike Scott Dublin City University, Ireland Janusz Stoklosa Poznan University of Technology, Poland Johnson Thomas Oklahoma State University Tulsa, USA Thomas Walter DoCoMo Labs Europe, Germany From compa at dist.unige.it Wed Jun 28 16:19:45 2006 From: compa at dist.unige.it (Luca Compagna) Date: Wed Jun 28 09:38:42 2006 Subject: [Avispa-users] Assistance Requested In-Reply-To: <20060626151451.VWIZ16286.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> References: <20060626151451.VWIZ16286.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> Message-ID: <1151504385.44a29001b2b6b@webmail.unige.it> Dear Bhavin, you are welcome! :D To refer to AVISPA you can use this standard text: FET Open EC Project ``AVISPA: Automated Validation of Internet Security Protocols and Applications'' (IST-2001-39252), http://www.avispa-project.org) Concerning publication and material that you can use I would say you should look to http://www.avispa-project.org/publications.html Hope this help, Luca Quoting bhavin.desai@ntlworld.com: > Gavin, Luca, > > Thank you very much for resolving the problem. I am assessing AVISPA as part > of my dissertation/project for the Information Security MSc at Royal Holloway > University of London. Is there any formal acknowledgement that I should > declare regarding the use of AVISPA for my project? Is there any standard > text that I could include? (I will of course acknowledge the personal > assistance provided by you.) > > It's interesting that an attack was found, even though I thought that I had > fixed the protocol to be SAFE!!! > > This demonstrates the difficulty of protocol security (although the general > protocol security problem is undecidable). > > If anyone has new/unpublished personal insights or comments on AVISPA that > would be useful for my MSc dissertation, then please let me know. All > contributions will be acknowledged. [My strict project submission deadline > is 8 September 2006.] > > Bhavin. > > > > > From: Luca Compagna > > Date: 2006/06/26 Mon PM 02:42:07 BST > > To: G Keighren > > CC: bhavin.desai@ntlworld.com, Avispa-users@avispa-project.org > > Subject: Re: [Avispa-users] Assistance Requested > > > > Dear Bhavin, > > Gavin is right. When you write > > > > request(A,B,alice_bob_na,Na,Nb) > > > > you refer to a 5-ary predicate, but request is defined as a 4-ary one. As > last > > parameter you should use "Na.Nb" to indicate that you are pairing Na with > Nb. > > > > Best regards, > > Luca > > > > Quoting G Keighren : > > > > > Bhavin, > > > > > > the problem appears to be due to the extra Nb' argument to the witness > > > and request predicates. I have not looked at the model in any great > > > detail, so I don'y know if they're meant to be there, but removing them > > > causes the model to be accepted and an attack found. > > > > > > If Nb' is necessary, then replacing Na',Nb' with Na'.Nb' works, as > follows: > > > > > > request(A,B,alice_bob_na,Na,Nb) -- BECOMES --> > > > request(A,B,alice_bob_na,Na.Nb) > > > witness(B,A,alice_bob_na,Na',Nb') -- BECOMES --> > > > witness(B,A,alice_bob_na,Na'.Nb') > > > > > > > > > Hope this helps, > > > > > > Gavin Keighren > > > > > > > > > > > > > > > > Hello, > > > > > > > > I got stuck trying to "make SAFE" a specification that was originally > > > > UNSAFE as presented in the HLPSL Tutorial. If you have time, please > > > > have a look at the two enclosed specifications. The one starting > > > > with ?TODO? gets translated but then fails the OFMC backend > > > > processing. I have followed the advice in the documentation > > > > regarding priming variables and the use of type-pattern declarations. > > > > > > > > I look forward to your comments and suggestions. > > > > > > > > > _______________________________________________ > > > Avispa-users mailing list > > > Avispa-users@avispa-project.org > > > http://www.avispa-project.org/mailman/listinfo/avispa-users > > > > > > > > > > > > > ----------------------------------------- > Email sent from www.ntlworld.com > Virus-checked using McAfee(R) Software > Visit www.ntlworld.com/security for more information > > From johnny-06 at chadda.se Thu Jun 29 10:50:20 2006 From: johnny-06 at chadda.se (Johnny Chadda) Date: Thu Jun 29 04:09:15 2006 Subject: [Avispa-users] How to verify encrypted hashes - signatures Message-ID: <1ae9e84e0606290150r59c89e42oe27ff6d6b669b5d0@mail.gmail.com> Hello list, I have a question regarding signatures and the verification of them. In the simplified example below, role A creates a signature message and pass it on to B, which forwards it to C. I want C to verifiy that the passed identifiers (A,C) are indeed the correct ones, meaning that they correspond to the hash encrypted by A. role alice() played_by A ... transition 1. State = 0 /\ BA(start) =|> State':=1 /\ Sig' = {{A.C}_Hash}_inv(Ka) /\ AB(A.C.Sig') end role role bob() played_by B ... transition 2. State = 5 /\ AB(A.C.Sig') =|> State':=6 /\ BC(A.C.Sig') end role role caesar() played_by C ... transition 3. State = 10 /\ BC(A.C.Sig') =|> State':=11 /\ % FIXME: If {A.C}_Hash == {Sig}_Ka ... end role Is there any way to do this, or is there maybe a better way to implement this than displayed above? Thanks, Johnny From Laurent.Vigneron at loria.fr Thu Jun 29 11:06:36 2006 From: Laurent.Vigneron at loria.fr (Laurent Vigneron) Date: Thu Jun 29 04:25:29 2006 Subject: [Avispa-users] How to verify encrypted hashes - signatures In-Reply-To: <1ae9e84e0606290150r59c89e42oe27ff6d6b669b5d0@mail.gmail.com> References: <1ae9e84e0606290150r59c89e42oe27ff6d6b669b5d0@mail.gmail.com> Message-ID: <1151571996.44a3981c596fc@www.loria.fr> Hi Johnny, According to the semantics of the language, you simply have to write: 3. State = 10 /\ BC(A.C.Sig') /\ Sig' = {{A.C}_Hash}_inv(Ka) =|> State':=11 This is correct if C knows both Ka and Hash. By the way, why didn't you use a hash function Hash(A.C) instead of en encryption? Laurent. > I have a question regarding signatures and the verification of them. > In the simplified example below, role A creates a signature message > and pass it on to B, which forwards it to C. I want C to verifiy that > the passed identifiers (A,C) are indeed the correct ones, meaning that > they correspond to the hash encrypted by A. > > > role alice() played_by A > ... > transition > 1. State = 0 /\ BA(start) =|> > State':=1 /\ Sig' = {{A.C}_Hash}_inv(Ka) > /\ AB(A.C.Sig') > end role > > > role bob() played_by B > ... > transition > 2. State = 5 /\ AB(A.C.Sig') =|> > State':=6 /\ BC(A.C.Sig') > end role > > > role caesar() played_by C > ... > transition > 3. State = 10 /\ BC(A.C.Sig') =|> > State':=11 /\ % FIXME: If {A.C}_Hash == {Sig}_Ka > ... > end role > > > Is there any way to do this, or is there maybe a better way to > implement this than displayed above? From johnny-06 at chadda.se Thu Jun 29 13:59:06 2006 From: johnny-06 at chadda.se (Johnny Chadda) Date: Thu Jun 29 07:17:59 2006 Subject: [Avispa-users] How to verify encrypted hashes - signatures In-Reply-To: <1151571996.44a3981c596fc@www.loria.fr> References: <1ae9e84e0606290150r59c89e42oe27ff6d6b669b5d0@mail.gmail.com> <1151571996.44a3981c596fc@www.loria.fr> Message-ID: <1ae9e84e0606290459h4bf39874v1200986c79df6411@mail.gmail.com> Hello Laurent, Thank you for your input. It seems to be working correctly, and thank you for pointing out that Hash() is the correct way to use the function. It should have read Sig' := {Hash(A.C)}_inv(Ka) Regards, Johnny On 6/29/06, Laurent Vigneron wrote: > > Hi Johnny, > > According to the semantics of the language, you simply have to write: > > 3. State = 10 /\ BC(A.C.Sig') /\ Sig' = {{A.C}_Hash}_inv(Ka) =|> > State':=11 > > This is correct if C knows both Ka and Hash. > > By the way, why didn't you use a hash function Hash(A.C) instead of en > encryption? > > Laurent. > > > > I have a question regarding signatures and the verification of them. > > In the simplified example below, role A creates a signature message > > and pass it on to B, which forwards it to C. I want C to verifiy that > > the passed identifiers (A,C) are indeed the correct ones, meaning that > > they correspond to the hash encrypted by A. > > > > > > role alice() played_by A > > ... > > transition > > 1. State = 0 /\ BA(start) =|> > > State':=1 /\ Sig' = {{A.C}_Hash}_inv(Ka) > > /\ AB(A.C.Sig') > > end role > > > > > > role bob() played_by B > > ... > > transition > > 2. State = 5 /\ AB(A.C.Sig') =|> > > State':=6 /\ BC(A.C.Sig') > > end role > > > > > > role caesar() played_by C > > ... > > transition > > 3. State = 10 /\ BC(A.C.Sig') =|> > > State':=11 /\ % FIXME: If {A.C}_Hash == {Sig}_Ka > > ... > > end role > > > > > > Is there any way to do this, or is there maybe a better way to > > implement this than displayed above? From s9901726 at sms.ed.ac.uk Thu Jun 29 21:58:40 2006 From: s9901726 at sms.ed.ac.uk (G Keighren) Date: Thu Jun 29 15:17:35 2006 Subject: [Avispa-users] Attack no longer found by CL-AtSe with modified model Message-ID: <20060629205840.zjhv3zyfk0wwcoos@www.sms.ed.ac.uk> Hi there, I have a model which happens to take quite a long time for an attack to be found, using CL-AtSe. I had hoped that it would be faster if I split the transitions into smaller steps, thus constraining the values allowed more. For example, I changed the following command from: (Apologies for the unhelpful variable names) step1. Rcv({A'}_xor(B',C').C'.{B'}_xor(x,y)) =|> Snd({A'}_xor(x,C')) to: step1a. State = 0 /\ Rcv({B'}_xor(x,y)) =|> State' := 1 step1b. State = 1 /\ Rcv({A'}_xor(B,C')) =|> State' := 2 step1c. State = 2 /\ Rcv(C) =|> State' := 0 /\ Snd({A}_xor(x,C)) I hoped that because the initial Rcv was more tightly constrained, and later values depended on earlier ones, that some of the search space may be cut off. However, there is a problem - CL-AtSe no longer finds a particular attack. The problem appears to be in step1c where the intruder has to know the value of C. It looks like step1b is not being tried with all possible values, thus C is not able to be matched in step1c. Priming this final C causes the attack to be found (although the transition becomes semantically wrong). There are many possibilities for C', but only one or two are actually known by the intruder (in the attack, B is an xor of other terms, not all of which the intruder knows). I run the model with the -notype option, so it is not caused by CL-AtSe being unable to xor non-message types. I wanted to ask if anyone had any ideas as to what the root of the problem is? Also, I would like to know if this change is likely to have any effect on the search space, and run time, of CL-AtSe, since if it does not then I can safely ignore the problem. thanks in advance, Gavin Keighren From iwk20 at ui.edu Fri Jun 30 04:39:53 2006 From: iwk20 at ui.edu (Ilham Kurnia) Date: Thu Jun 29 21:59:10 2006 Subject: [Avispa-users] Attack no longer found by CL-AtSe with modified model In-Reply-To: <20060629205840.zjhv3zyfk0wwcoos@www.sms.ed.ac.uk> References: <20060629205840.zjhv3zyfk0wwcoos@www.sms.ed.ac.uk> Message-ID: <1151635193.12489.9.camel@riset-a-s1-112.riset.cs.ui.ac.id> Hi, I think there's a slightly different interpretation between the step1 transitions and the subtransitions, especially in step1b. > For example, I changed the following command from: > > (Apologies for the unhelpful variable names) > > step1. > Rcv({A'}_xor(B',C').C'.{B'}_xor(x,y)) > =|> Snd({A'}_xor(x,C')) > step1b. State = 1 /\ Rcv({A'}_xor(B,C')) > =|> State' := 2 > If you split the messages like that, the agent who receives {A'}_xor(B,C') must match two values: A' and C'. In the step1 transition, however, the agent can gather the value of A' because it can find, firstly, the value of B', and then the value of C' and, finally, the value of A'. I wonder if an agent can postpone a decryption of a message until it has all the values to construct the necessary key. What about uniting step1b and step1c together? So, the subtransition step1b would be something like this: step1b. State = 1 /\ Rcv({A'}_xor(B,C').C') =|> State' := 0 /\ Snd({A'}_xor(x,C')) A curious question, is it intentional that you put State' := 0? Cheers, Ilham From bhavin.desai at ntlworld.com Fri Jun 30 09:38:45 2006 From: bhavin.desai at ntlworld.com (bhavin.desai@ntlworld.com) Date: Fri Jun 30 02:57:38 2006 Subject: [Avispa-users] Easy Question(s) on Terminology Message-ID: <20060630073845.LLHJ29849.aamtaout01-winn.ispmail.ntl.com@smtp.ntlworld.com> Hello, Why does AVISPA use the terminology SAFE and UNSAFE rather than Secure and either Not-Secure, Non-Secure or Insecure? (Philosophers would probably have an interesting discussion about the subtle differences between Not-Secure, Non-Secure and Insecure!) The terms Safe, Safety, etc are usually related to analyses where there is a risk to life. The terms Secure, Security, etc are usually related to analyses where there is a risk to data or information. Is it acceptable to consider that the AVISPA term SAFE is equivalent to the usual term Secure? Bhavin Desai Security Practice LogicaCMG UK Limited Chaucer House Springfield Drive Leatherhead Surrey KT22 7LP United Kingdom www.logicacmg.com Tel: +44 (0) 1372 369639 Fax: +44 (0) 1372 369834 bhavin.desai@logicacmg.com ----------------------------------------- Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information From khaled.masmoudi at int-evry.fr Fri Jun 30 09:43:09 2006 From: khaled.masmoudi at int-evry.fr (Khaled Masmoudi) Date: Fri Jun 30 03:03:46 2006 Subject: [Avispa-users] Easy Question(s) on Terminology In-Reply-To: <20060630073845.LLHJ29849.aamtaout01-winn.ispmail.ntl.com@smtp.ntlworld.com> Message-ID: <000701c69c18$d8418ac0$9fe4bc82@micro.intevry.fr> Hi, IMHO, a protocol validated with AVISPA is safe within the scope of security goals ou specify at the end of the HLPSL file, it is not "absolutely" secure... Cheers Khaled -------------------------------------------------------------------------- -- ---------- Khaled MASMOUDI Institut National des Télécommunications Wireless Networks and Multimedia Services Department (RS2M) 9, rue Charles Fourier - 91011 Evry Cedex Personal Page: www.masmoudi.net Tél : +33 1 60 76 42 65 Fax : +33 1 60 76 45 78 khaled.masmoudi@int-evry.fr -----Message d'origine----- De : avispa-users-bounces@avispa-project.org [mailto:avispa-users-bounces@avispa-project.org] De la part de bhavin.desai@ntlworld.com Envoyé : vendredi 30 juin 2006 09:39 À : avispa-users@avispa-project.org Objet : [Avispa-users] Easy Question(s) on Terminology Hello, Why does AVISPA use the terminology SAFE and UNSAFE rather than Secure and either Not-Secure, Non-Secure or Insecure? (Philosophers would probably have an interesting discussion about the subtle differences between Not-Secure, Non-Secure and Insecure!) The terms Safe, Safety, etc are usually related to analyses where there is a risk to life. The terms Secure, Security, etc are usually related to analyses where there is a risk to data or information. Is it acceptable to consider that the AVISPA term SAFE is equivalent to the usual term Secure? Bhavin Desai Security Practice LogicaCMG UK Limited Chaucer House Springfield Drive Leatherhead Surrey KT22 7LP United Kingdom www.logicacmg.com Tel: +44 (0) 1372 369639 Fax: +44 (0) 1372 369834 bhavin.desai@logicacmg.com ----------------------------------------- Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information _______________________________________________ Avispa-users mailing list Avispa-users@avispa-project.org http://www.avispa-project.org/mailman/listinfo/avispa-users begin 666 smime.p7s M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$' M`0``H(((YS""`F\P@@'8H ,"`0("`P_Z#C -!@DJADB&]PT!`00%`#!B,0LP M"08#500&$P):03$E,",&`U4$"A,<5&AA=W1E($-O;G-U;'1I;F<@*%!T>2D@ M3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E9 MH/ G=%O[D_7:A/8T^WSSM4G$-*9SJ10I[[1EA5M52L#FTUOO0@_LC;72.>6! M32&NCA>&I$-.)!W X ]]T?]G`CJ8>IR$R^FT'VO8?AD6"MHDPF M1PBW3S""`RTP@@*6H ,"`0("`0`P#08)*H9(AO<-`0$$!0`P@=$Q"S )!@-5 M! 83`EI!,14P$P8#500($PQ797-T97)N($-A<&4Q$C 0!@-5! <3"4-A<&4@ M5&]W;C$:,!@&`U4$"A,15&AA=W1E($-O;G-U;'1I;F%PTY-C Q,#$P,# P,#!:%PTR,#$R M,S$R,S4Y-3E:,('1,0LP"08#500&$P):03$5,!,&`U4$"!,,5V5S=&5R;B!# M87!E,1(P$ 8#500'$PE#87!E(%1O=VXQ&C 8!@-5! H3$51H87=T92!#;VYS M=6QT:6YG,2@P)@8#500+$Q]#97)T:69I8V%T:6]N(%-EE'V Q1MNIRD;"$ M7GTM#8][$M^%)74H=#I"+&,GGY5[2^]^&8<=ANJCW;G.EF0:PA1N1*Q\YH_H M30]Q'T XI@"CAWCV^92&7JWJP%YVZ]D4HUUN>GP,I4M5?P89*7^>FB;5:KLX M) AJF,>QVJ.8D?UYV^5:Q!RY`@,!``&C$S 1, \&`U4=$P$!_P0%, ,!`?\P M#08)*H9(AO<-`0$$!0`#@8$`Q^R2?D[X]9:E9V(JI/!-$6#0;XU@6&&L)KM2 M-5P(SS#[J$J6BA]B0B.,%P_TNF2<%ZQ'*=^=F%[2;&!Q7**LW'GCYVX`1Q^U M#2CH`IWDFOT3]*;9?+'XW%\C)@F1@'/0%!O>0ZF#)?+FG"\5ROZFJXH'=8L, MW5&$:^3XT2D@3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E M_0( "9->GIKN?9='%*E2%#T@$?Z>VT3QA!$ >9!ER M8+?[`@,!``&C@90P@9$P$@8#51T3`0'_! @P!@$!_P(!`#!#!@-5'1\$/# Z M,#B@-J TAC)H='1P.B\O8W)L+G1H87=T92YC;VTO5&AA=W1E4&5R,!PQ&C 8 M!@-5! ,3$5!R:79A=&5,86)E;#(M,3,X, T&"2J&2(;W#0$!!04``X&!`$B, MT5"#Z@LNS VC9JQG#W^OK+["%Z%#EI2=?TPAN/@V'ZHMGS8OP/0<4""3<#S] MK>%A8L/9.AE^A+&9&P#%&@N"=)XE4)1BQ]LG<52D@3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E2D@3'1D+C$L,"H&`U4$`Q,C5&AA=W1E(%!E5593&[1I73K%?UUX_0I:8"LP9PSIPTU/.E*8%"2'$RC M_/W%=WD@%)KZWQRTF!I_IU;I[">?IA^.;8Z3$$>4"Z,RN4YT?V1A+-?0R37= MXMF$NO7G%.Y References: <000701c69c18$d8418ac0$9fe4bc82@micro.intevry.fr> Message-ID: Hi Bhavin, Yes I agree with Khaled. Also, as I recall what we discussed at the time, we wanted to emphasize that what AVISPA analyzes is the protocol in the context of the goals AND the analysis scenario given. So we wanted to avoid language like "the protocol is secure" in order to make sure that people remembered that we were not analyzing all possible executions of the protocol, only the scenario given. Cheers, Paul. On Jun 30, 2006, at 9:43 AM, Khaled Masmoudi wrote: > Hi, > IMHO, a protocol validated with AVISPA is safe within the scope of > security > goals ou specify at the end of the HLPSL file, it is not "absolutely" > secure... > > Cheers > Khaled > > ---------------------------------------------------------------------- > ---- > -- > ---------- > Khaled MASMOUDI > Institut National des T?l?communications > Wireless Networks and Multimedia Services Department (RS2M) > 9, rue Charles Fourier - 91011 Evry Cedex > Personal Page: www.masmoudi.net > T?l : +33 1 60 76 42 65 > Fax : +33 1 60 76 45 78 > khaled.masmoudi@int-evry.fr > > -----Message d'origine----- > De : avispa-users-bounces@avispa-project.org > [mailto:avispa-users-bounces@avispa-project.org] De la part de > bhavin.desai@ntlworld.com > Envoy? : vendredi 30 juin 2006 09:39 > ? : avispa-users@avispa-project.org > Objet : [Avispa-users] Easy Question(s) on Terminology > > Hello, > > Why does AVISPA use the terminology SAFE and UNSAFE rather than > Secure and > either Not-Secure, Non-Secure or Insecure? (Philosophers would > probably > have an interesting discussion about the subtle differences between > Not-Secure, Non-Secure and Insecure!) > > The terms Safe, Safety, etc are usually related to analyses where > there is > a > risk to life. The terms Secure, Security, etc are usually related to > analyses where there is a risk to data or information. > > Is it acceptable to consider that the AVISPA term SAFE is > equivalent to > the > usual term Secure? > > Bhavin Desai > Security Practice > LogicaCMG UK Limited > Chaucer House > Springfield Drive > Leatherhead > Surrey > KT22 7LP > United Kingdom > > www.logicacmg.com > Tel: +44 (0) 1372 369639 > Fax: +44 (0) 1372 369834 > bhavin.desai@logicacmg.com > > > ----------------------------------------- > Email sent from www.ntlworld.com > Virus-checked using McAfee(R) Software > Visit www.ntlworld.com/security for more information > > _______________________________________________ > Avispa-users mailing list > Avispa-users@avispa-project.org > http://www.avispa-project.org/mailman/listinfo/avispa-users > > > From iwk20 at ui.edu Fri Jun 30 10:06:51 2006 From: iwk20 at ui.edu (Ilham Kurnia) Date: Fri Jun 30 03:25:39 2006 Subject: [Avispa-users] Easy Question(s) on Terminology In-Reply-To: References: <000701c69c18$d8418ac0$9fe4bc82@micro.intevry.fr> Message-ID: <1151654811.15352.18.camel@riset-a-s1-112.riset.cs.ui.ac.id> Hi all, Please allow me to ask something further on this matter. Why does AVISPA uses the term "validation" instead of "verification"? Cheers, Ilham On Fri, 2006-06-30 at 09:59 +0200, Paul Hankes Drielsma wrote: > Hi Bhavin, > > Yes I agree with Khaled. > > Also, as I recall what we discussed at the time, we wanted to > emphasize that what AVISPA analyzes is the protocol in the context of > the goals AND the analysis scenario given. So we wanted to avoid > language like "the protocol is secure" in order to make sure that > people remembered that we were not analyzing all possible executions > of the protocol, only the scenario given. > > Cheers, > Paul. > > On Jun 30, 2006, at 9:43 AM, Khaled Masmoudi wrote: > > > Hi, > > IMHO, a protocol validated with AVISPA is safe within the scope of > > security > > goals ou specify at the end of the HLPSL file, it is not "absolutely" > > secure... > > > > Cheers > > Khaled > > > > ---------------------------------------------------------------------- > > ---- > > -- > > ---------- > > Khaled MASMOUDI > > Institut National des T?l?communications > > Wireless Networks and Multimedia Services Department (RS2M) > > 9, rue Charles Fourier - 91011 Evry Cedex > > Personal Page: www.masmoudi.net > > T?l : +33 1 60 76 42 65 > > Fax : +33 1 60 76 45 78 > > khaled.masmoudi@int-evry.fr > > > > -----Message d'origine----- > > De : avispa-users-bounces@avispa-project.org > > [mailto:avispa-users-bounces@avispa-project.org] De la part de > > bhavin.desai@ntlworld.com > > Envoy? : vendredi 30 juin 2006 09:39 > > ? : avispa-users@avispa-project.org > > Objet : [Avispa-users] Easy Question(s) on Terminology > > > > Hello, > > > > Why does AVISPA use the terminology SAFE and UNSAFE rather than > > Secure and > > either Not-Secure, Non-Secure or Insecure? (Philosophers would > > probably > > have an interesting discussion about the subtle differences between > > Not-Secure, Non-Secure and Insecure!) > > > > The terms Safe, Safety, etc are usually related to analyses where > > there is > > a > > risk to life. The terms Secure, Security, etc are usually related to > > analyses where there is a risk to data or information. > > > > Is it acceptable to consider that the AVISPA term SAFE is > > equivalent to > > the > > usual term Secure? > > > > Bhavin Desai > > Security Practice > > LogicaCMG UK Limited > > Chaucer House > > Springfield Drive > > Leatherhead > > Surrey > > KT22 7LP > > United Kingdom > > > > www.logicacmg.com > > Tel: +44 (0) 1372 369639 > > Fax: +44 (0) 1372 369834 > > bhavin.desai@logicacmg.com > > > > From marius at cs.utt.ro Fri Jun 30 10:20:44 2006 From: marius at cs.utt.ro (Marius Minea) Date: Fri Jun 30 03:39:39 2006 Subject: [Avispa-users] Call for Papers (extended): Workshop on Information and Computer Security, Timisoara, Romania Message-ID: Hope this may be of interest to some users on the list, and please forward to other interested colleagues. thanks and best regards, Marius ------------------------------------------------------------------ Call for Papers Workshop on Information and Computer Security ICS 2006 Timisoara, Romania September 29-30, 2006 The ICS 2006 Workshop, to be held in conjunction with the 8th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing (SYNASC 2006), is intended as an international forum?for researchers in all areas of information and computer security. Submissions of papers presenting original research are invited for the following workshop tracks:? Formal methods in security Decidability and complexity Language-based security Security models Security protocols Security verification Security policies and services Authentication Anonymity and privacy Electronic voting Information flow Intrusion detection Resource usage control Security for mobile computing Trust management Cryptology: We are particularly interested in work that can help build bridges between cryptology and the other two tracks. Examples of this include, but are not limited to: - Protocols that provide services in application fields such as e-government, and that are defined precisely enough to be used as reasonable targets for formal analysis tools; - Implementations of cryptographic primitives that can be formally analyzed; Work on combinatorial optimization problems that arise in cryptographic applications and that can be approximately solved using techniques from formal modeling. Submission and Proceedings Details about the submission procedure can be found on the workshop web page: http://ics.ieat.ro/. Pre-proceedings will be available during the workshop; post-proceedings will be published by Elsevier as a special issue of Electronic Notes in Theoretical Computer Science. Important Dates Deadline: July 16 (extended) Acceptance: August 28 Camera-ready version: September 10 Workshop: September 29-30, 2006 Program Committee Alessandro Armando (University of Genova, Italy) David Basin (ETH Z?rich, Switzerland) Daniele Beaquier (University of Paris 12, France) Gabriel Ciobanu (Romanian Academy, Institute of Computer Science) Catalin Dima - co-chair (University of Paris 12, France) Michael Fisher (University of Liverpool, UK) Juan Garay (Bell Labs, USA) Sigi Guergens (Fraunhofer SIT, Germany) Steve Kremer (INRIA & ENS Cachan, France) Ruggero Lanotte (University of Insubria, Como, Italy) Marius Minea - co-chair (IeAT, Romania) Rene Peralta (NIST, USA) Ferucio Laurentiu Tiplea - co-chair (University of Iasi, Romania and University of Central Florida, USA) Luca Vigan? (ETH Z?rich, Switzerland) Invited Speaker: Fabio Martinelli (IIT Pisa, CNR, Italy) Instructions for Authors Submissions must not substantially duplicate work that any of the authors has published elsewhere or has submitted in parallel to any other journal, conference, or workshop that has proceedings.? Authors of an accepted paper must guarantee that at least one of the authors will attend the conference and present their paper. ? Venue The workshop will be hosted by the Institute e-Austria Timisoara (Romania), a research and technology transfer institute in the field of information technologies. For more details, please consult the workshop home page http://ics.ieat.ro/ From paul.drielsma at inf.ethz.ch Fri Jun 30 11:02:19 2006 From: paul.drielsma at inf.ethz.ch (Paul Hankes Drielsma) Date: Fri Jun 30 04:21:10 2006 Subject: [Avispa-users] Easy Question(s) on Terminology In-Reply-To: <1151654811.15352.18.camel@riset-a-s1-112.riset.cs.ui.ac.id> References: <000701c69c18$d8418ac0$9fe4bc82@micro.intevry.fr> <1151654811.15352.18.camel@riset-a-s1-112.riset.cs.ui.ac.id> Message-ID: <2ECA3617-8E90-45DB-8E5A-26A3C9FEC60F@inf.ethz.ch> Hello Ilham, This is almost more a history question. :-) Not all of the tools do true verification, which is a word that is generally generated for infinite-session analysis and not the bounded session analysis performed by SATMC, CL-AtSe, and OFMC. TA4SP is the only tool that does verification. The general term for the kind of "bounded verification" done by the other 3 backends is "falsification" because we are searching for attacks, or traces that falsify the goals of the protocol. But AFISPA doesn't sound as good. No, I think the real reason is that our goal was both falsification and verification, not exclusively one or the other. Hence, validation. Paul. On Jun 30, 2006, at 10:06 AM, Ilham Kurnia wrote: > Hi all, > > Please allow me to ask something further on this matter. > > Why does AVISPA uses the term "validation" instead of "verification"? > > Cheers, > > Ilham From bhavin.desai at ntlworld.com Fri Jun 30 16:57:25 2006 From: bhavin.desai at ntlworld.com (bhavin.desai@ntlworld.com) Date: Fri Jun 30 10:16:18 2006 Subject: [Avispa-users] Easy Question(s) on Terminology Message-ID: <20060630145725.SSVR18889.aamtaout03-winn.ispmail.ntl.com@smtp.ntlworld.com> Thanks to Khaled and Paul for the clarifications. Protocol security (and security in general too) has so many subtle aspects. We seem to go through a regular cycle of understanding and then not really understanding... Bhavin. > > From: Paul Hankes Drielsma > Date: 2006/06/30 Fri AM 08:59:37 BST > To: khaled.masmoudi@int-evry.fr > CC: , > > Subject: Re: [Avispa-users] Easy Question(s) on Terminology > > Hi Bhavin, > > Yes I agree with Khaled. > > Also, as I recall what we discussed at the time, we wanted to > emphasize that what AVISPA analyzes is the protocol in the context of > the goals AND the analysis scenario given. So we wanted to avoid > language like "the protocol is secure" in order to make sure that > people remembered that we were not analyzing all possible executions > of the protocol, only the scenario given. > > Cheers, > Paul. > > On Jun 30, 2006, at 9:43 AM, Khaled Masmoudi wrote: > > > Hi, > > IMHO, a protocol validated with AVISPA is safe within the scope of > > security > > goals ou specify at the end of the HLPSL file, it is not "absolutely" > > secure... > > > > Cheers > > Khaled > > > > ---------------------------------------------------------------------- > > ---- > > -- > > ---------- > > Khaled MASMOUDI > > Institut National des T?l?communications > > Wireless Networks and Multimedia Services Department (RS2M) > > 9, rue Charles Fourier - 91011 Evry Cedex > > Personal Page: www.masmoudi.net > > T?l : +33 1 60 76 42 65 > > Fax : +33 1 60 76 45 78 > > khaled.masmoudi@int-evry.fr > > > > -----Message d'origine----- > > De : avispa-users-bounces@avispa-project.org > > [mailto:avispa-users-bounces@avispa-project.org] De la part de > > bhavin.desai@ntlworld.com > > Envoy? : vendredi 30 juin 2006 09:39 > > ? : avispa-users@avispa-project.org > > Objet : [Avispa-users] Easy Question(s) on Terminology > > > > Hello, > > > > Why does AVISPA use the terminology SAFE and UNSAFE rather than > > Secure and > > either Not-Secure, Non-Secure or Insecure? (Philosophers would > > probably > > have an interesting discussion about the subtle differences between > > Not-Secure, Non-Secure and Insecure!) > > > > The terms Safe, Safety, etc are usually related to analyses where > > there is > > a > > risk to life. The terms Secure, Security, etc are usually related to > > analyses where there is a risk to data or information. > > > > Is it acceptable to consider that the AVISPA term SAFE is > > equivalent to > > the > > usual term Secure? > > > > Bhavin Desai > > Security Practice > > LogicaCMG UK Limited > > Chaucer House > > Springfield Drive > > Leatherhead > > Surrey > > KT22 7LP > > United Kingdom > > > > www.logicacmg.com > > Tel: +44 (0) 1372 369639 > > Fax: +44 (0) 1372 369834 > > bhavin.desai@logicacmg.com > > > > > > ----------------------------------------- > > Email sent from www.ntlworld.com > > Virus-checked using McAfee(R) Software > > Visit www.ntlworld.com/security for more information > > > > _______________________________________________ > > Avispa-users mailing list > > Avispa-users@avispa-project.org > > http://www.avispa-project.org/mailman/listinfo/avispa-users > > > > > > > > ----------------------------------------- Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information From s9901726 at sms.ed.ac.uk Fri Jun 30 17:11:20 2006 From: s9901726 at sms.ed.ac.uk (Gavin Keighren) Date: Fri Jun 30 10:29:26 2006 Subject: [Avispa-users] Attack no longer found by CL-AtSe with modified model In-Reply-To: <1151635193.12489.9.camel@riset-a-s1-112.riset.cs.ui.ac.id> References: <20060629205840.zjhv3zyfk0wwcoos@www.sms.ed.ac.uk> <1151635193.12489.9.camel@riset-a-s1-112.riset.cs.ui.ac.id> Message-ID: Hi, thanks for your response. Here are my views on what you have said: > I think there's a slightly different interpretation between the step1 > transitions and the subtransitions, especially in step1b. > >> For example, I changed the following command from: >> >> (Apologies for the unhelpful variable names) >> >> step1. >> Rcv({A'}_xor(B',C').C'.{B'}_xor(x,y)) >> =|> Snd({A'}_xor(x,C')) > >> step1b. State = 1 /\ Rcv({A'}_xor(B,C')) >> =|> State' := 2 >> > > If you split the messages like that, the agent who receives > {A'}_xor(B,C') must match two values: A' and C'. In the step1 > transition, however, the agent can gather the value of A' because it > can > find, firstly, the value of B', and then the value of C' and, finally, > the value of A'. I should have mentioned that the agent who is receiving the information cannot be the intruder, and it is in fact the intruder who is sending the messages. He also knows information of the form {A'}_xor(B',C'), C', and {B'}_xor(x,y). As such, I was under the impression that the unification algorithm would be able to match {A'}_xor(B,C') in step 1b with a particular piece of information known to the intruder, given the fixed value of B. That is, it would be the same as replacing B by a known constant. Although the intruder cannot work out directly what the message should be, he has the required information to provide a correct message, and thus I thought the unification algorithm would mean that the intruder would in fact provide the correct message. > I wonder if an agent can postpone a decryption of a message until it > has > all the values to construct the necessary key. > > What about uniting step1b and step1c together? So, the subtransition > step1b would be something like this: > > step1b. State = 1 /\ Rcv({A'}_xor(B,C').C') > =|> State' := 0 /\ Snd({A'}_xor(x,C')) I tried this as well, but it too does not work. > A curious question, is it intentional that you put State' := 0? Yes, the aim is that the agent is initially in state 0, then has to carry out the steps in order, returning to state 0 after the final one has been carried out. thanks for your help, Gavin From s9901726 at sms.ed.ac.uk Fri Jun 30 18:58:33 2006 From: s9901726 at sms.ed.ac.uk (Gavin Keighren) Date: Fri Jun 30 12:16:24 2006 Subject: [Avispa-users] Re: Attack no longer found by CL-AtSe with modified model In-Reply-To: <20060629205840.zjhv3zyfk0wwcoos@www.sms.ed.ac.uk> References: <20060629205840.zjhv3zyfk0wwcoos@www.sms.ed.ac.uk> Message-ID: <88e1972c977934813313afbbbda1062f@sms.ed.ac.uk> Just to update interested parties, I found that the problem disappeared when I used the -ns option to CL-AtSe. I have attached an example file where a particular attack is found when the -ns option is used, and not found when it is not. Gavin Keighren -------------- next part -------------- A non-text attachment was scrubbed... Name: example.hlpsl Type: application/octet-stream Size: 2442 bytes Desc: not available Url : http://carroll.ai.dist.unige.it/pipermail/avispa-users/attachments/20060630/1af35a22/example-0001.obj