From carbone at dist.unige.it Fri Nov 13 06:51:19 2009 From: carbone at dist.unige.it (Roberto Carbone) Date: Fri, 13 Nov 2009 12:51:19 +0100 Subject: [Avispa-users] Modeling resilient channels in HLPSL In-Reply-To: References: Message-ID: <4AFD4837.6070902@dist.unige.it> Dear Jorge, LTL formulae are handled by the HLPSL translator, but in the current version of the AVISPA tool, no backend does use them. Besides the work described by Laurent in a previous email, we have also done some work in this direction: we have extended the AVISPA backend SATMC to support model checking of LTL formulae. Unfortunately, we have not integrated this extension in the AVISPA tool yet. Our extension allows the protocol designer to specify directly - complex security properties such as fair exchange - constraints on the behaviour of the honest agents (e.g. timeout) - communication channels different from DY channels (e.g. resilient channels) These aspects are particularly relevant in the context of contract signing protocols (in particular, we have analysed the ASW protocol) More details can be found at Armando, A., Carbone, R., and Compagna, L. 2007. LTL Model Checking for Security Protocols. In Proceedings of the 20th IEEE Computer Security Foundations Symposium (July 06 - 08, 2007). CSF. IEEE Computer Society, Washington, DC, 385-396. DOI= http://dx.doi.org/10.1109/CSF.2007.24. Available at http://www.ai-lab.it/satmc/publications.html If you need further details, please do not hesitate to contact me. Hope this helps, best regards, Roberto Jorge L?pez wrote: > Dear all, > > Sorry for the last mail. I interpreted badly the attack trace. The > receiver wasn't executing the recovery protocol, she was just following > the normal flow of the main one. > > However, the attack still remains (with cl-atse backend), and I guess > that may be due to the LTL formulas. The recovery protocol is not being > executed by the receiver, though it should, as a timeout should be > raised since the receiver is not obtaining the last expected item. Is it > possible that, once the EOR is known by the origin agent, the LTL > formula is evaluated and thus considered unfulfilled? > > For a better comprehension of the situation, I indicate the transitions > for the receiver: > > %Main subprotocol > 0. State = 0 /\ RCV_R_SCE(POO') > /\ POO' = > {Pub_sce.Pub_tce.Pub_r.Pub_s.Msg'.Label'.Tpl_id}_inv(Pub_sce) =|> > State' := 1 /\ POR' := > {Pub_sce.Pub_tce.Pub_r.Pub_s.Msg'.Label'.Tpl_id}_inv(Pub_r) > /\ SND_R_TCE(POO'.POR') > /\ witness(R,TCE,tce_r_por,POR') > /\ wrequest(R,SCE,r_sce_poo,POO') > > 1. State = 1 /\ RCV_R_TCE(NRO') > /\ NRO' = > {Pub_sce.Pub_tce.Pub_r.Pub_s.POR}_inv(Pub_tce) =|> > State' := 2 /\ NRR' := {NRO'}_inv(Pub_r) > /\ SND_R_SCE(NRR') > /\ witness(R,SCE,sce_r_nrr,NRR') > /\ wrequest(R,TCE,r_tce_nro,NRO') > > 2. State = 2 /\ RCV_R_SCE(NRA') > /\ NRA' = {NRR}_inv(Pub_sce) =|> > State' := 3 /\ wrequest(R,SCE,r_sce_nra,NRA') > /\ aknows(R,receiver,NRA') > > 3. State = 1 --|> > State' := 4 > > % Recovery subprotocol > 4. State = 2 --|> > State' := 5 /\ SND_R_S(POO.POR.NRO.NRR) > > % - Protocol successfully recovered > 5. State = 5 /\ RCV_R_S(NRA_TTP') > /\ NRA_TTP' = {NRR}_inv(Pub_s) =|> > State' := 6 /\ aknows(R,receiver,NRA_TTP') > > % - Protocol already aborted by origin > 6. State = 5 /\ RCV_R_S(Abort_TTP') > /\ Abort_TTP' = > {{abort.Label}_inv(Pub_sce)}_inv(Pub_s) =|> > State' := 7 /\ aknows(R,receiver,Abort_TTP') > > % Loop... > 7. State = 5 --|> > State' := 2 > > The steps shown in the attack trace contained in the previous email > indicated that the receiver had executed steps 0 and 1, going to state > 2. However, step 4 (recovery subprotocol execution) is not launched... > > LTL formulas for non-repudiation properties are the next: > > [] (((aknows(SCE,sce,NRA) \/ aknows(SCE,sce,NRA_TTP)) \/ > aknows(SCE,sce,Abort_TTP)) => > ((aknows(R,receiver,NRA) \/ aknows(R,receiver,NRA_TTP)) \/ > aknows(R,receiver,Abort_TTP))) > > [] (((aknows(R,receiver,NRA) \/ aknows(R,receiver,NRA_TTP)) \/ > aknows(R,receiver,Abort_TTP)) => > ((aknows(SCE,sce,NRA) \/ aknows(SCE,sce,NRA_TTP)) \/ > aknows(SCE,sce,Abort_TTP))) > > At the end of the attack trace, agent sce has (and then knows) item > NRA_TTP, while agent receiver got nothing. > > Again, thanks for any help. > > Jorge. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Avispa-users mailing list > Avispa-users at avispa-project.org > http://mail63.csoft.net/mailman/listinfo/avispa-users From mohamed.abid at it-sudparis.eu Fri Nov 13 09:10:00 2009 From: mohamed.abid at it-sudparis.eu (abid_moh) Date: Fri, 13 Nov 2009 15:10:00 +0100 Subject: [Avispa-users] Bilinear pairing with AVISPA In-Reply-To: <4AFD4837.6070902@dist.unige.it> References: <4AFD4837.6070902@dist.unige.it> Message-ID: <43E708D044C34FBD8FB2B284F46178E3@micro.intevry.fr> Dear AVISPA Users, Did anyone tried or had done a validation of Identity Based Cryptography IBC with AVISPA. I essentially want to know how to formulate the Bilinear pairing? Regards Mohamed ABID From jlopez.ha at gmail.com Sat Nov 14 05:23:48 2009 From: jlopez.ha at gmail.com (=?ISO-8859-1?Q?Jorge_L=F3pez?=) Date: Sat, 14 Nov 2009 11:23:48 +0100 Subject: [Avispa-users] Modeling resilient channels in HLPSL In-Reply-To: <4AFD4837.6070902@dist.unige.it> References: <4AFD4837.6070902@dist.unige.it> Message-ID: Dear Roberto, Thanks for your response. I was told that CL-ATSE could handle aknows predicates and supports LTL formulae. It seems to be true, since each time I modify the predicate or the LTL formula, I obtain different results. Please Laurent, confim me that.. On the other hand, the work you have mentioned is really intesting to me! The three new properties apply to my protocol as well (fairness, timeouts, and resilient channels). When do you expect to integrate it in AVISPA tool?? All the best, Jorge. 2009/11/13 Roberto Carbone > Dear Jorge, > > LTL formulae are handled by the HLPSL translator, but in the current > version of the AVISPA tool, no backend does use them. > > Besides the work described by Laurent in a previous email, we have > also done some work in this direction: we have extended the AVISPA > backend SATMC to support model checking of LTL formulae. > Unfortunately, we have not integrated this extension in the AVISPA > tool yet. > > Our extension allows the protocol designer to specify directly > - complex security properties such as fair exchange > - constraints on the behaviour of the honest agents (e.g. timeout) > - communication channels different from DY channels (e.g. resilient > channels) > > These aspects are particularly relevant in the context of contract > signing protocols (in particular, we have analysed the ASW protocol) > > More details can be found at > Armando, A., Carbone, R., and Compagna, L. 2007. LTL Model Checking > for Security Protocols. In Proceedings of the 20th IEEE Computer > Security Foundations Symposium (July 06 - 08, 2007). CSF. IEEE > Computer Society, Washington, DC, 385-396. DOI= > http://dx.doi.org/10.1109/CSF.2007.24. Available at > http://www.ai-lab.it/satmc/publications.html > > If you need further details, please do not hesitate to contact me. > > Hope this helps, > best regards, > Roberto > > Jorge L?pez wrote: > > Dear all, > > > > Sorry for the last mail. I interpreted badly the attack trace. The > > receiver wasn't executing the recovery protocol, she was just following > > the normal flow of the main one. > > > > However, the attack still remains (with cl-atse backend), and I guess > > that may be due to the LTL formulas. The recovery protocol is not being > > executed by the receiver, though it should, as a timeout should be > > raised since the receiver is not obtaining the last expected item. Is it > > possible that, once the EOR is known by the origin agent, the LTL > > formula is evaluated and thus considered unfulfilled? > > > > For a better comprehension of the situation, I indicate the transitions > > for the receiver: > > > > %Main subprotocol > > 0. State = 0 /\ RCV_R_SCE(POO') > > /\ POO' = > > {Pub_sce.Pub_tce.Pub_r.Pub_s.Msg'.Label'.Tpl_id}_inv(Pub_sce) =|> > > State' := 1 /\ POR' := > > {Pub_sce.Pub_tce.Pub_r.Pub_s.Msg'.Label'.Tpl_id}_inv(Pub_r) > > /\ SND_R_TCE(POO'.POR') > > /\ witness(R,TCE,tce_r_por,POR') > > /\ wrequest(R,SCE,r_sce_poo,POO') > > > > 1. State = 1 /\ RCV_R_TCE(NRO') > > /\ NRO' = > > {Pub_sce.Pub_tce.Pub_r.Pub_s.POR}_inv(Pub_tce) =|> > > State' := 2 /\ NRR' := {NRO'}_inv(Pub_r) > > /\ SND_R_SCE(NRR') > > /\ witness(R,SCE,sce_r_nrr,NRR') > > /\ wrequest(R,TCE,r_tce_nro,NRO') > > > > 2. State = 2 /\ RCV_R_SCE(NRA') > > /\ NRA' = {NRR}_inv(Pub_sce) =|> > > State' := 3 /\ wrequest(R,SCE,r_sce_nra,NRA') > > /\ aknows(R,receiver,NRA') > > > > 3. State = 1 --|> > > State' := 4 > > > > % Recovery subprotocol > > 4. State = 2 --|> > > State' := 5 /\ SND_R_S(POO.POR.NRO.NRR) > > > > % - Protocol successfully recovered > > 5. State = 5 /\ RCV_R_S(NRA_TTP') > > /\ NRA_TTP' = {NRR}_inv(Pub_s) > =|> > > State' := 6 /\ aknows(R,receiver,NRA_TTP') > > > > % - Protocol already aborted by origin > > 6. State = 5 /\ RCV_R_S(Abort_TTP') > > /\ Abort_TTP' = > > {{abort.Label}_inv(Pub_sce)}_inv(Pub_s) =|> > > State' := 7 /\ aknows(R,receiver,Abort_TTP') > > > > % Loop... > > 7. State = 5 --|> > > State' := 2 > > > > The steps shown in the attack trace contained in the previous email > > indicated that the receiver had executed steps 0 and 1, going to state > > 2. However, step 4 (recovery subprotocol execution) is not launched... > > > > LTL formulas for non-repudiation properties are the next: > > > > [] (((aknows(SCE,sce,NRA) \/ aknows(SCE,sce,NRA_TTP)) \/ > > aknows(SCE,sce,Abort_TTP)) => > > ((aknows(R,receiver,NRA) \/ aknows(R,receiver,NRA_TTP)) \/ > > aknows(R,receiver,Abort_TTP))) > > > > [] (((aknows(R,receiver,NRA) \/ aknows(R,receiver,NRA_TTP)) \/ > > aknows(R,receiver,Abort_TTP)) => > > ((aknows(SCE,sce,NRA) \/ aknows(SCE,sce,NRA_TTP)) \/ > > aknows(SCE,sce,Abort_TTP))) > > > > At the end of the attack trace, agent sce has (and then knows) item > > NRA_TTP, while agent receiver got nothing. > > > > Again, thanks for any help. > > > > Jorge. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Avispa-users mailing list > > Avispa-users at avispa-project.org > > http://mail63.csoft.net/mailman/listinfo/avispa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20091114/f3b3a2ce/attachment-0001.htm From gharout at gmail.com Thu Nov 19 11:41:28 2009 From: gharout at gmail.com (=?ISO-8859-1?Q?Sa=EFd_GHAROUT?=) Date: Thu, 19 Nov 2009 17:41:28 +0100 Subject: [Avispa-users] Alice and Bob In-Reply-To: References: Message-ID: Thank you Sebastian. cheers. Sa?d GHAROUT 2009/9/15 Sebastian Moedersheim > > Hi, > > AVANTSSAR is a successor project of AVISPA, and the AVANTSSAR website > distributes the latest version of OFMC and SATMC: > > www.avantssar.eu -> platform > > The latest version of OFMC supports Alice and Bob notation and ships with > several examples like H.530. > > I guess this could be of interest to all those AVISPA users who try to > formulate the classical protocols in Alice and Bob notation and I include > the spec of h530 and nspk as those were explicitly discussed here... > > Cheers, > Sebastian > > > > > _______________________________________________ > Avispa-users mailing list > Avispa-users at avispa-project.org > http://mail63.csoft.net/mailman/listinfo/avispa-users > > -- --------------------------------------------------------------- Sa?d GHAROUT, Lab. Heudiasyc, UMR CNRS 6599 University of Technology of Compi?gne Centre de Recherche Royallieu B.P. 20529, 60205 Compi?gne Cedex, France. Phone : +33 3 44 23 49 54 Fax : +33 3 44 23 44 77 Email: sgharout at hds.utc.fr Web: http://www.hds.utc.fr/~sgharout ------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20091119/18b0b477/attachment.htm