From carbone at dist.unige.it Tue Oct 6 11:36:32 2009 From: carbone at dist.unige.it (Roberto Carbone) Date: Tue, 06 Oct 2009 17:36:32 +0200 Subject: [Avispa-users] analysis of long term evolution in avispa In-Reply-To: References: Message-ID: <4ACB6400.4070808@dist.unige.it> Dear Jiss, I have read your specs. In your case you consider as key the message Hash(Na.Nb'), which is not of "symmetric_key" type. So: 1) if you define this key of the type "symmetric_key", there is a mismatch in the types. 2) if you define the key of the most general type "message", the problem does not occur. (At page 9 of the AVISPA tutorial you can find a similar example) Notice that, if you perform an untyped analysis on case 1) by running for instance cl-atse with the option "Untyped model", you should find an attack similar to the one found when declaring the key of "message" type. Hope this helps, Best regards, Roberto JISS J NALLIKUZHY wrote: > i'm currently working on a thesis project--"analysis of long term > evolution protocols". i have modelled the protocol in hlpsl, but i'm > having different results when executed in avispa (ie safe and unsafe) > when declaring a key in message type and symmetric key type. what is the > difference between the two. i'll be glad if anybody could help. > thank you > > -- > JISS J NALLIKUZHY > M-Tech, Signal Processing > College of Engineering, Trivandrum > Kerala, India > jjnalli at gmail.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Avispa-users mailing list > Avispa-users at avispa-project.org > http://mail63.csoft.net/mailman/listinfo/avispa-users From jlopez.ha at gmail.com Mon Oct 12 11:10:44 2009 From: jlopez.ha at gmail.com (=?ISO-8859-1?Q?Jorge_L=F3pez?=) Date: Mon, 12 Oct 2009 17:10:44 +0200 Subject: [Avispa-users] Fairness in HLPSL Message-ID: Dear all, I need to prove the fairness of a fair exchange protocol I designed. In the comments I received in ARSPA-WITS'09, a suggestion was using predicates - Has(role,message) and - None(role,message) during the protocol steps, and creating a security property like - Has(A,m) /\ not(Has(B,m)) /\ None(B,m) => problem Though it would be quite straightforward and easy to implement due to my protocol design, AFAIK those predicates are not currently supported by the current HLPSL specification. Other approaches, like the one mentioned in the paper "The ASW Protocol Revisited: A Unified View", demonstrate that the fair exchange security goal can be reduced, via a meta-reasoning step, to a secrecy goal. However, in my protocol I do not manage secret items, so I am hardly able to follow this approach. Next, I show you some basic information about the protocol. In a nutshell, the protocol is fair if both SCE and R players obtain the NRA (or NRA_TTP) evidence or none of them does. % ------------------------------------------------------------------------ % There are 3 players/4 platforms: % % - Origin: 2 Platforms % --> Signature Creation Environment (SCE) % --> Transaction Confirmation Environment (TCE) % - Receiver: 1 Platform (R) % - Trusted Third Party: 1 Platform (S) % % Origin knows the message to be sent to the Receiver (Msg), and % this information is pre-shared by both Origin's Platforms % (SCE and TCE). % % Origin and Receiver also pre-share the template identifier % information (Tpl_id). % % The GOAL of the protocol is to obtain the valid evidence NRA. % Either Origin and Receiver obtain a valid evidence NRA or % none of them gain an unfair advantage over the other. % Evidence NRA can be generated by either the origin or the TTP % (if recovery protocol executed). % ------------------------------------------------------------------------ % --------------------------------------------------------------------- % Evidences (electronic signatures) generated during a protocol run % % Proof of origin % POO = Sig_sce(Msg,Label,Tpl_id) % Proof of receipt % POR = Sig_r(Msg,Label,Tpl_id) % Non-repudiation evidence of origin % NRO = Sig_tce(POR) % Non-repudiation evidence of receipt % NRR = Sig_r(NRO) % Non-repudiation evidence of acknowledgement % NRA = Sig_sce(NRR) % Non-repudiation evidence of acknowledgement (generated by the TTP) % NRA_TTP = Sig_ttp(NRR) % % Abort evidence generated by origin (SCE only) % Abort = Sig_sce(Abort,Label) % Abort evidence generated by TTP % Abort_TTP = Sig_ttp(Sig_sce(Abort,Label)) % % --------------------------------------------------------------------- % --------------------------------------------------------------------- % A protocol (main subprotocol) run without parties' misbehavior: % % 1. SCE --> R: Msg, Label, Tpl_id, POO % 2. R --> TCE: Msg, Label, Tpl_id, POO, POR % 3. TCE --> R: NRO % 4. R --> SCE: NRR % 5. SCE --> R: NRA % % Recovery subprotocol: % % 1. R --> TTP: Msg, Label, Tpl_id, POO, POR, NRO, NRR % if (aborted) % 2. TTP --> R: Abort_TTP % else % 2. TTP --> R,SCE: NRA_TTP % % Abort subprotocol: % % 1. SCE --> TTP: abort, Label, Abort % if (recovered) % 2a.TTP --> SCE: NRA_TTP % else % 2b.TTP --> SCE: Abort_TTP % % --------------------------------------------------------------------- Any help will be appreciated. I attach the HLPSL file. Thanks a lot in advance. Jorge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20091012/cb0c8cfc/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: OFEPSPv7.1.hlpsl Type: application/octet-stream Size: 15386 bytes Desc: not available Url : http://mail63.csoft.net/pipermail/avispa-users/attachments/20091012/cb0c8cfc/attachment-0001.obj From laurent.vigneron at loria.fr Mon Oct 12 11:54:54 2009 From: laurent.vigneron at loria.fr (Laurent Vigneron) Date: Mon, 12 Oct 2009 17:54:54 +0200 Subject: [Avispa-users] Fairness in HLPSL In-Reply-To: References: Message-ID: <4AD3514E.1030202@loria.fr> Dear Jorge, The AVISPA specification language permits to add such new predicates (but starting with a small letter). And the last versions of CL-AtSe handle properties with such new predicates. To get a recent version of CL-AtSe, please ask for the binary file to Mathieu Turuani (in Cc). This works very well, as we demonstrated in "Automatic Methods for Analyzing Non-repudiation Protocols with an Active Intruder" (FAST 2008, LNCS 5491), adding a "aknows" predicate. Have fun ! Laurent. PS: Note that all predicates have to hold at least one parameter (so if you do not need any, just add a constant). Jorge L?pez a ?crit : > Dear all, > > I need to prove the fairness of a fair exchange protocol I designed. In > the comments I received in ARSPA-WITS'09, a suggestion was using predicates > > - Has(role,message) and > - None(role,message) > > during the protocol steps, and creating a security property like > > - Has(A,m) /\ not(Has(B,m)) /\ None(B,m) => problem > > Though it would be quite straightforward and easy to implement due to my > protocol design, AFAIK those predicates are not currently supported by > the current HLPSL specification. > > Other approaches, like the one mentioned in the paper "The ASW Protocol > Revisited: A Unified View", demonstrate that the fair exchange security > goal can be reduced, via a meta-reasoning step, to a secrecy goal. > However, in my protocol I do not manage secret items, so I am hardly > able to follow this approach.. > > Next, I show you some basic information about the protocol. In a > nutshell, the protocol is fair if both SCE and R players obtain the NRA > (or NRA_TTP) evidence or none of them does. > > % ------------------------------------------------------------------------ > % There are 3 players/4 platforms: > % > % - Origin: 2 Platforms > % --> Signature Creation Environment (SCE) > % --> Transaction Confirmation Environment (TCE) > % - Receiver: 1 Platform (R) > % - Trusted Third Party: 1 Platform (S) > % > % Origin knows the message to be sent to the Receiver (Msg), and > % this information is pre-shared by both Origin's Platforms > % (SCE and TCE). > % > % Origin and Receiver also pre-share the template identifier > % information (Tpl_id). > % > % The GOAL of the protocol is to obtain the valid evidence NRA. > % Either Origin and Receiver obtain a valid evidence NRA or > % none of them gain an unfair advantage over the other. > % Evidence NRA can be generated by either the origin or the TTP > % (if recovery protocol executed). > % ------------------------------------------------------------------------ > > % --------------------------------------------------------------------- > % Evidences (electronic signatures) generated during a protocol run > % > % Proof of origin > % POO = Sig_sce(Msg,Label,Tpl_id) > % Proof of receipt > % POR = Sig_r(Msg,Label,Tpl_id) > % Non-repudiation evidence of origin > % NRO = Sig_tce(POR) > % Non-repudiation evidence of receipt > % NRR = Sig_r(NRO) > % Non-repudiation evidence of acknowledgement > % NRA = Sig_sce(NRR) > % Non-repudiation evidence of acknowledgement (generated by the TTP) > % NRA_TTP = Sig_ttp(NRR) > % > % Abort evidence generated by origin (SCE only) > % Abort = Sig_sce(Abort,Label) > % Abort evidence generated by TTP > % Abort_TTP = Sig_ttp(Sig_sce(Abort,Label)) > % > % --------------------------------------------------------------------- > > % --------------------------------------------------------------------- > % A protocol (main subprotocol) run without parties' misbehavior: > % > % 1. SCE --> R: Msg, Label, Tpl_id, POO > % 2. R --> TCE: Msg, Label, Tpl_id, POO, POR > % 3. TCE --> R: NRO > % 4. R --> SCE: NRR > % 5. SCE --> R: NRA > % > % Recovery subprotocol: > % > % 1. R --> TTP: Msg, Label, Tpl_id, POO, POR, NRO, NRR > % if (aborted) > % 2. TTP --> R: Abort_TTP > % else > % 2. TTP --> R,SCE: NRA_TTP > % > % Abort subprotocol: > % > % 1. SCE --> TTP: abort, Label, Abort > % if (recovered) > % 2a.TTP --> SCE: NRA_TTP > % else > % 2b.TTP --> SCE: Abort_TTP > % > % --------------------------------------------------------------------- > > Any help will be appreciated. I attach the HLPSL file. > > Thanks a lot in advance. > > Jorge. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Avispa-users mailing list > Avispa-users at avispa-project.org > http://mail63.csoft.net/mailman/listinfo/avispa-users From jlopez.ha at gmail.com Mon Oct 12 12:25:54 2009 From: jlopez.ha at gmail.com (=?ISO-8859-1?Q?Jorge_L=F3pez?=) Date: Mon, 12 Oct 2009 18:25:54 +0200 Subject: [Avispa-users] Fairness in HLPSL In-Reply-To: <4AD35420.2040506@loria.fr> References: <4AD3514E.1030202@loria.fr> <4AD35420.2040506@loria.fr> Message-ID: Thanks Laurent and Mathie for the useful information. I'll study how to do it and I'll let you know if I find any problem with that. Best, Jorge. 2009/10/12 > Hi, > > I attach the compiled version of stable version of cl-atse. > This was compiled on a x64 proc, might provoque library > problems with a 32 bit arch however. Ask me if problems. > Note there is also a bytecore version in the package. > > Mathieu > > > Laurent Vigneron a ?crit : > > Dear Jorge, >> >> The AVISPA specification language permits to add such new predicates (but >> starting with a small letter). >> And the last versions of CL-AtSe handle properties with such new >> predicates. To get a recent version of CL-AtSe, please ask for the binary >> file to Mathieu Turuani (in Cc). >> >> This works very well, as we demonstrated in "Automatic Methods for >> Analyzing Non-repudiation Protocols with an Active Intruder" (FAST 2008, >> LNCS 5491), adding a "aknows" predicate. >> >> Have fun ! >> >> Laurent. >> >> PS: Note that all predicates have to hold at least one parameter (so if >> you do not need any, just add a constant). >> >> >> Jorge L?pez a ?crit : >> >> >>> Dear all, >>> >>> I need to prove the fairness of a fair exchange protocol I designed. In >>> the comments I received in ARSPA-WITS'09, a suggestion was using predicates >>> - Has(role,message) and - None(role,message) >>> during the protocol steps, and creating a security property like >>> - Has(A,m) /\ not(Has(B,m)) /\ None(B,m) => problem >>> >>> Though it would be quite straightforward and easy to implement due to my >>> protocol design, AFAIK those predicates are not currently supported by the >>> current HLPSL specification. >>> Other approaches, like the one mentioned in the paper "The ASW Protocol >>> Revisited: A Unified View", demonstrate that the fair exchange security goal >>> can be reduced, via a meta-reasoning step, to a secrecy goal. However, in my >>> protocol I do not manage secret items, so I am hardly able to follow this >>> approach.. >>> >>> Next, I show you some basic information about the protocol. In a >>> nutshell, the protocol is fair if both SCE and R players obtain the NRA (or >>> NRA_TTP) evidence or none of them does. >>> >>> % >>> ------------------------------------------------------------------------ >>> % There are 3 players/4 platforms: >>> % >>> % - Origin: 2 Platforms >>> % --> Signature Creation Environment (SCE) >>> % --> Transaction Confirmation Environment (TCE) >>> % - Receiver: 1 Platform (R) >>> % - Trusted Third Party: 1 Platform (S) >>> % >>> % Origin knows the message to be sent to the Receiver (Msg), and % this >>> information is pre-shared by both Origin's Platforms % (SCE and TCE). >>> % >>> % Origin and Receiver also pre-share the template identifier % >>> information (Tpl_id). >>> % >>> % The GOAL of the protocol is to obtain the valid evidence NRA. >>> % Either Origin and Receiver obtain a valid evidence NRA or % none of >>> them gain an unfair advantage over the other. >>> % Evidence NRA can be generated by either the origin or the TTP >>> % (if recovery protocol executed). >>> % >>> ------------------------------------------------------------------------ >>> >>> % --------------------------------------------------------------------- >>> % Evidences (electronic signatures) generated during a protocol run >>> % >>> % Proof of origin >>> % POO = Sig_sce(Msg,Label,Tpl_id) >>> % Proof of receipt >>> % POR = Sig_r(Msg,Label,Tpl_id) >>> % Non-repudiation evidence of origin >>> % NRO = Sig_tce(POR) >>> % Non-repudiation evidence of receipt >>> % NRR = Sig_r(NRO) >>> % Non-repudiation evidence of acknowledgement >>> % NRA = Sig_sce(NRR) >>> % Non-repudiation evidence of acknowledgement (generated by the TTP) >>> % NRA_TTP = Sig_ttp(NRR) >>> % >>> % Abort evidence generated by origin (SCE only) >>> % Abort = Sig_sce(Abort,Label) >>> % Abort evidence generated by TTP >>> % Abort_TTP = Sig_ttp(Sig_sce(Abort,Label)) >>> % >>> % --------------------------------------------------------------------- >>> >>> % --------------------------------------------------------------------- >>> % A protocol (main subprotocol) run without parties' misbehavior: >>> % >>> % 1. SCE --> R: Msg, Label, Tpl_id, POO >>> % 2. R --> TCE: Msg, Label, Tpl_id, POO, POR >>> % 3. TCE --> R: NRO >>> % 4. R --> SCE: NRR >>> % 5. SCE --> R: NRA >>> % >>> % Recovery subprotocol: >>> % >>> % 1. R --> TTP: Msg, Label, Tpl_id, POO, POR, NRO, NRR >>> % if (aborted) >>> % 2. TTP --> R: Abort_TTP >>> % else >>> % 2. TTP --> R,SCE: NRA_TTP >>> % >>> % Abort subprotocol: >>> % >>> % 1. SCE --> TTP: abort, Label, Abort >>> % if (recovered) >>> % 2a.TTP --> SCE: NRA_TTP >>> % else % 2b.TTP --> SCE: Abort_TTP >>> % >>> % --------------------------------------------------------------------- >>> >>> Any help will be appreciated. I attach the HLPSL file. >>> >>> Thanks a lot in advance. >>> >>> Jorge. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Avispa-users mailing list >>> Avispa-users at avispa-project.org >>> http://mail63.csoft.net/mailman/listinfo/avispa-users >>> >>> >> _______________________________________________ >> 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/20091012/2d3416d3/attachment.htm From alshadly09 at googlemail.com Wed Oct 14 05:14:02 2009 From: alshadly09 at googlemail.com (SALEH AL-SHADLY) Date: Wed, 14 Oct 2009 11:14:02 +0200 Subject: [Avispa-users] RFID authentication Message-ID: <4AD5965A.6070305@googlemail.com> Dear all, is there any specification for RFID authentication protocol (hash lock scheme) in AVISPA lib.? cheers, Saleh From adam.walid28 at gmail.com Thu Oct 15 03:37:04 2009 From: adam.walid28 at gmail.com (walid Adam) Date: Thu, 15 Oct 2009 09:37:04 +0200 Subject: [Avispa-users] strong authentication without nonce Message-ID: <76280150910150037p1cf6a559p4898d231efcb4a31@mail.gmail.com> Dear All I have specifying this protocol in HLPSL. The goal is verifying authentication (client and server): C --- > S : {K1}_K S --- > C : {K2}_K where K is shared symmetric key. K1 and K2 is Random secret keys, shared between C and S then: C : K , K1, K2 S : K ; K1, K2 in this protocol not use the nonce. my questions for authenticate of client is: In role client: witness(C,S,aut_client,{K1}_K) In role server: request(S,C,aut_client,{K1}_K) this specification, is it correct? From alshadly09 at googlemail.com Fri Oct 16 05:13:20 2009 From: alshadly09 at googlemail.com (SALEH AL-SHADLY) Date: Fri, 16 Oct 2009 11:13:20 +0200 Subject: [Avispa-users] mapping Message-ID: <4AD83930.4000704@googlemail.com> dear all, when write this declaration role environment() def= const rkey, id : protocol_id, r, t, db : agent, key_i : text, id_i : text, h : hash_func, *keylist : hash(text) -> text,* snd, rcv : channel(dy) this: *keylist : hash(text) -> text, *give me the following error ( i'm using SPAN) %% Translation of /home/alshadly/Desktop/avispa exampls/RFID/hash_unlocking.hlpsl %% Syntax error: Line 166, Col 13 (offset 3180-3183, string "hash") %% Syn.Err(10): missing or invalid type in variables declaration what i want is to pass a mapping as parameter? any help? regards Saleh From alshadly09 at googlemail.com Mon Oct 19 10:43:43 2009 From: alshadly09 at googlemail.com (SALEH AL-SHADLY) Date: Mon, 19 Oct 2009 16:43:43 +0200 Subject: [Avispa-users] mod in HLPSL Message-ID: <4ADC7B1F.9020300@googlemail.com> dear all how to model the (mod) function in HLPSL? as in Diffie-Hellman protocol? cheers Saleh From jlopez.ha at gmail.com Sat Oct 31 07:15:39 2009 From: jlopez.ha at gmail.com (=?ISO-8859-1?Q?Jorge_L=F3pez?=) Date: Sat, 31 Oct 2009 12:15:39 +0100 Subject: [Avispa-users] Modeling resilient channels in HLPSL Message-ID: Dear all, I need to model resilient channels between the participants of a protocol and the TTP. That is, channels that reliably delivers any message to the other end, after some finite but unknown amount of time. Due to Dolev-Yao intruder model, an attack is being raised when checking the non-repudiation properties of my protocol (defined by LTL formulas). The "problem" is that the origin obtains the non-repudiation evidence of receipt while the receiver does not obtain the non-repudiation evidence of origin. Taking a look at the attack trace, the cause is that the intruder captures the message sent back by the TTP to the receiver when the recovery protocol is executed by her. As a result, the receiver does not obtain the needed evidence. I have tried to solve the situation including a transition where, if a timeout occurs at the receiver's side, then the recovery protocol is executed again (and again and again until the evidence is obtained). However, it does not seem to work, as the same attack is raised. The HLSPSL code for this interation is the next: % Recovery protocol execution 3. State = 2 --|> State' := 5 /\ SND_R_S(POO.POR.NRO.NRR) .... % other transitions % Loop to allow the receiver execute the recovery protocol again if the messages are lost (DY issues) 6. State = 5 --|> State' := 2 Below you can find the attack trace. The problematic step is (s,6) -> i. If the receiver obtained that message, the fairness would be achieved. Any help will be appreciated. Best regards, Jorge. -------- Detailed attack description : ----------------------------- i -> (sce,3): () (sce,3) -> i: {pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_sce') & Witness(sce.r.r_sce_poo.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_sce')); i -> (sce,3): () (sce,3) -> i: {abort.n1Label}#_(pub_sce') i -> (r,5): {pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_sce') (r,5) -> i: {pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r') & Witness(r.tce.tce_r_por.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')); & WRequest(sce.r.r_sce_poo.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_sce')); i -> (tce,4): {pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_sce'). {pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r') (tce,4) -> i: {pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce') & Witness(tce.r.r_tce_nro.{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')); & WRequest(r.tce.tce_r_por.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')); i -> (r,5): {pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce') (r,5) -> i: {{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')}#_(pub_r') & Witness(r.sce.sce_r_nrr.{{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')}#_(pub_r')); & WRequest(tce.r.r_tce_nro.{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')); i -> (s,6): {pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_sce'). {pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r'). {pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce'). {{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')}#_(pub_r') (s,6) -> i: {{{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')}#_(pub_r')}#_(pub_s'). token1 i -> (sce,3): {{{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')}#_(pub_r')}#_(pub_s') (sce,3) -> i: () & Add aknows.sce.sce.{{{pub_sce.pub_tce.pub_r.pub_s.{pub_sce.pub_tce.pub_r.pub_s.msg.n1Label.tpl_id}#_(pub_r')}#_(pub_tce')}#_(pub_r')}#_(pub_s') to local_facts; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20091031/cdb485c9/attachment-0001.htm From jlopez.ha at gmail.com Sat Oct 31 08:10:20 2009 From: jlopez.ha at gmail.com (=?ISO-8859-1?Q?Jorge_L=F3pez?=) Date: Sat, 31 Oct 2009 13:10:20 +0100 Subject: [Avispa-users] Modeling resilient channels in HLPSL (correction) Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20091031/9ec1b659/attachment.htm