From manuelsc at um.es  Thu Apr  2 03:12:48 2009
From: manuelsc at um.es (=?ISO-8859-1?Q?Manuel_S=E1nchez_Cuenca?=)
Date: Thu, 02 Apr 2009 09:12:48 +0200
Subject: [Avispa-users] Strange intruder behavior
Message-ID: <49D46570.3020603@um.es>

Hello all,

I have modeled a protocol using HLPSL and, using CL-ATSE to validate it, 
the intruder makes some changes in the messages that I think can't be done.

This is the attack trace:

ATTACK TRACE
....

(p,9) -> i:  {n20(SessionP).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kup

 i -> (u,7):  {n20(SessionP).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kup

(u,7) -> i:  {n19(SessionA).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kua

 i -> (a,4):  {n19(SessionA).{p.a.n34(Pse).n34(Np).n11(Nid)}_(inv(kp))}_kua
....

kua is a symmetric_key only known between u and a, and Kp is the public 
key for p.

How it is possible for i to change the content of the last message if it 
includes a signature from p and is encrypted with the symmetric key 
shared between u and a?

SATMC and OFMC doens't find any attack in the protocol, only CL-ATSE 
find this strange problem.
           

-- 
-----------------------------
Manuel Sanchez Cuenca
Departamento de Ingenieria de la Informacion y las Comunicaciones
Departamento de Ingenier?a y Tecnolog?a de Computadores
Facultad de Informatica. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-364644    Fax: +34-968-364151
email: msc at dif.um.es  |  manuelsc at um.es
url: http://webs.um.es/manuelsc


From owensjp at clarkson.edu  Thu Apr  2 07:13:57 2009
From: owensjp at clarkson.edu (Jim Owens)
Date: Thu, 02 Apr 2009 07:13:57 -0400
Subject: [Avispa-users] Strange intruder behavior
In-Reply-To: <49D46570.3020603@um.es>
References: <49D46570.3020603@um.es>
Message-ID: <49D49DF5.3000704@clarkson.edu>

Manuel,

The change you're observing in that last message may be due to 
exploitation of an algebraic property, most likely XOR. According to the 
documentation, only CL-AtSe supports XOR and exponentiation, while OFMC 
supports only exponentiation. The other back-ends do not support these 
properties.

Cheers,
Jim

Manuel S?nchez Cuenca wrote:
> Hello all,
>
> I have modeled a protocol using HLPSL and, using CL-ATSE to validate it, 
> the intruder makes some changes in the messages that I think can't be done.
>
> This is the attack trace:
>
> ATTACK TRACE
> ....
>
> (p,9) -> i:  {n20(SessionP).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kup
>
>  i -> (u,7):  {n20(SessionP).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kup
>
> (u,7) -> i:  {n19(SessionA).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kua
>
>  i -> (a,4):  {n19(SessionA).{p.a.n34(Pse).n34(Np).n11(Nid)}_(inv(kp))}_kua
> ....
>
> kua is a symmetric_key only known between u and a, and Kp is the public 
> key for p.
>
> How it is possible for i to change the content of the last message if it 
> includes a signature from p and is encrypted with the symmetric key 
> shared between u and a?
>
> SATMC and OFMC doens't find any attack in the protocol, only CL-ATSE 
> find this strange problem.
>            
>
>   


From SMO at zurich.ibm.com  Thu Apr  2 10:22:11 2009
From: SMO at zurich.ibm.com (Sebastian Moedersheim)
Date: Thu, 2 Apr 2009 16:22:11 +0200
Subject: [Avispa-users] Strange intruder behavior
In-Reply-To: <49D49DF5.3000704@clarkson.edu>
References: <49D46570.3020603@um.es> <49D49DF5.3000704@clarkson.edu>
Message-ID: <OF84FB2CAA.76CC8771-ONC125758C.004E69C5-C125758C.004EF00C@ch.ibm.com>

Hi, 

maybe there are still some old versions out there, but OFMC has a generic 
support for algebraic theories (via a theory file since 2006 ;-) ). But I 
don't think that it is the problem here because the attack does not seem 
to have to do with any such operators. But sorry I do not know exactly how 
CL-AtSe got to this attack. Maybe Mathieu can help?

Cheers,
Sebastian



>From:
Jim Owens <owensjp at clarkson.edu>
To:
Manuel S?nchez Cuenca <manuelsc at um.es>
Cc:
avispa-users at avispa-project.org
Date:
04/02/2009 01:14 PM
Subject:
Re: [Avispa-users] Strange intruder behavior



Manuel,

The change you're observing in that last message may be due to 
exploitation of an algebraic property, most likely XOR. According to the 
documentation, only CL-AtSe supports XOR and exponentiation, while OFMC 
supports only exponentiation. The other back-ends do not support these 
properties.

Cheers,
Jim

Manuel S?nchez Cuenca wrote:
> Hello all,
>
> I have modeled a protocol using HLPSL and, using CL-ATSE to validate it, 

> the intruder makes some changes in the messages that I think can't be 
done.
>
> This is the attack trace:
>
> ATTACK TRACE
> ....
>
> (p,9) -> i: 
{n20(SessionP).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kup
>
>  i -> (u,7): 
{n20(SessionP).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kup
>
> (u,7) -> i: 
{n19(SessionA).{p.a.n34(Pse).n34(Np).n29(Nid)}_(inv(kp))}_kua
>
>  i -> (a,4): 
{n19(SessionA).{p.a.n34(Pse).n34(Np).n11(Nid)}_(inv(kp))}_kua
> ....
>
> kua is a symmetric_key only known between u and a, and Kp is the public 
> key for p.
>
> How it is possible for i to change the content of the last message if it 

> includes a signature from p and is encrypted with the symmetric key 
> shared between u and a?
>
> SATMC and OFMC doens't find any attack in the protocol, only CL-ATSE 
> find this strange problem.
> 
>
> 

_______________________________________________
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/20090402/2a72e21b/attachment.html 

From manuelsc at um.es  Mon Apr  6 11:39:13 2009
From: manuelsc at um.es (=?ISO-8859-1?Q?Manuel_S=E1nchez_Cuenca?=)
Date: Mon, 06 Apr 2009 17:39:13 +0200
Subject: [Avispa-users] Help with attack
Message-ID: <49DA2221.9050701@um.es>

Hello all,

I have defined the security protocol specified in the attached file
(sp_initiated_authn.hlpsl).

both OFMC and CL-ATSE find the same attack:

i -> (u,3): start
(u,3) -> i: {u.Kua(1).Nua(1)}_ka
i -> (a,3): {u.Kua(1).Nua(1)}_ka
(a,3) -> i: {a.Nua(1)}_Kua(1)
i -> (u,3): {a.Nua(1)}_Kua(1)
(u,3) -> i: {u.Kup(3).Nup(3)}_ki
i -> (u,3): {i.Nup(3)}_Kup(3)
(u,3) -> i: {u.Kusp(4).Nusp(4)}_ksp
i -> (sp,3): {u.Kusp(4).Nusp(4)}_ksp
(sp,3) -> i: {sp.Nusp(4)}_Kusp(4)
i -> (u,3): {sp.Nusp(4)}_Kusp(4)
(u,3) -> i: {{URI(6).{up.a.sp.Nu(6)}_ka.a}_inv(kvid)}_Kusp(4)
i -> (sp,3): {{URI(6).{up.a.sp.Nu(6)}_ka.a}_inv(kvid)}_Kusp(4)
(sp,3) -> i:
{{{URI(6).{up.a.sp.Nu(6)}_ka.a}_inv(kvid).Id1(7)}_inv(ksp)}_Kusp(4)
i -> (u,3):
{{{URI(6).{up.a.sp.Nu(6)}_ka.a}_inv(kvid).Id1(7)}_inv(ksp)}_Kusp(4)
(u,3) -> i:
{{{URI(6).{up.a.sp.Nu(6)}_ka.a}_inv(kvid).Id1(7)}_inv(ksp)}_Kua(1)
i -> (a,3):
{{{URI(6).{up.a.sp.Nu(6)}_ka.a}_inv(kvid).Id1(7)}_inv(ksp)}_Kua(1)
(a,3) -> i: {{pse_ap.Id2(9).a.i}_inv(ka)}_Kua(1)
i -> (u,3): {{pse_ap.Id2(9).a.i}_inv(ka)}_Kua(1)
(u,3) -> i: {{pse_ap.Id2(9).a.i}_inv(ka)}_Kup(3)
i -> (u,3): {{x541}_inv(ki)}_Kup(3)
(u,3) -> i: {{x541}_kupwd}_Kup(3)
i -> (u,3): {{i.a.pse_ap.x598.Id2(9)}_inv(ki)}_Kup(3)
(u,3) -> i: {{i.a.pse_ap.x598.Id2(9)}_inv(ki)}_Kua(1)
i -> (a,3): {{i.a.pse_ap.x598.Id2(9)}_inv(ki)}_Kua(1)
(a,3) -> i:
{{up.a.h(i.a.pse_ap.x598.Id2(9))}_inv(ka).{a.sp.Pse_asp(13).Na(13).Id1(7)}_inv(ka)}_Kua(1)
i -> (i,17): h(i.a.pse_ap.x598.Id2(9))
i -> (i,17): h(i.a.pse_ap.x598.Id2(9))

The attack is that some private information (h(i.a.pse_ap.x598.Id2(9)))
is obtained by the intruder, but I don't understand how it is possible,
because the message that contains this information is encrypted with
Kua, that is (or at least should be) only known by A and U.

Can anybody tell me what the problem is?

Best regards.



-- 
-----------------------------
Manuel Sanchez Cuenca
Departamento de Ingenieria de la Informacion y las Comunicaciones
Departamento de Ingenier?a y Tecnolog?a de Computadores
Facultad de Informatica. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-364644    Fax: +34-968-364151
email: msc at dif.um.es  |  manuelsc at um.es
url: http://webs.um.es/manuelsc


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sp_initiated_authn.hlpsl
Url: http://mail63.csoft.net/pipermail/avispa-users/attachments/20090406/27acd11f/attachment.ksh 

From SMO at zurich.ibm.com  Mon Apr  6 12:28:14 2009
From: SMO at zurich.ibm.com (Sebastian Moedersheim)
Date: Mon, 6 Apr 2009 18:28:14 +0200
Subject: [Avispa-users] Help with attack
In-Reply-To: <49DA2221.9050701@um.es>
References: <49DA2221.9050701@um.es>
Message-ID: <OF999E9E5E.BC335393-ONC1257590.005A0C0D-C1257590.005A7A29@ch.ibm.com>

Hi,

Consider the following message in your trace:
> (a,3) -> i:
> {{up.a.h(i.a.pse_ap.x598.Id2(9))}_inv(ka).{a.sp.Pse_asp(13).Na

I assume that the intruder knows ka here (public key, right?), so then he 
can obtain the hash which is probably the secret.

So maybe you have to further trace back if the above step should actually 
be possible or if there is anything wrong with that step. Maybe you can 
check the attack step by step in this way, i.e. that everything 
corresponds to a correct application of some transition? 

> The attack is that some private information (h(i.a.pse_ap.x598.Id2(9)))
> is obtained by the intruder, but I don't understand how it is possible,
> because the message that contains this information is encrypted with
> Kua, that is (or at least should be) only known by A and U.

If you have such constraints, you may also specify additional goals like 
the secrecy of that key, so you may obtain a simpler attack?

Cheers,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20090406/96b151a2/attachment.html 

From manuelsc at um.es  Mon Apr  6 12:41:51 2009
From: manuelsc at um.es (=?ISO-8859-1?Q?Manuel_S=E1nchez_Cuenca?=)
Date: Mon, 06 Apr 2009 18:41:51 +0200
Subject: [Avispa-users] Help with attack
In-Reply-To: <OF999E9E5E.BC335393-ONC1257590.005A0C0D-C1257590.005A7A29@ch.ibm.com>
References: <49DA2221.9050701@um.es>
	<OF999E9E5E.BC335393-ONC1257590.005A0C0D-C1257590.005A7A29@ch.ibm.com>
Message-ID: <49DA30CF.1070706@um.es>

Sebastian Moedersheim escribi?:
>
> Hi,
>
> Consider the following message in your trace:
> > (a,3) -> i:
> > {{up.a.h(i.a.pse_ap.x598.Id2(9))}_inv(ka).{a.sp.Pse_asp(13).Na
In theory this is not possible, because all this message is encrypted 
with a symmetric_key shared only between A and U.

the message you show is incomplete, the full message is
(a,3) -> i:  
{{up.a.h(i.a.pse_ap.x598.Id2(9))}_inv(ka).{a.sp.Pse_asp(13).Na(13).Id1(7)}_inv(ka)}_Kua(1) 

>
> I assume that the intruder knows ka here (public key, right?), so then 
> he can obtain the hash which is probably the secret.
>
> So maybe you have to further trace back if the above step should 
> actually be possible or if there is anything wrong with that step. 
> Maybe you can check the attack step by step in this way, i.e. that 
> everything corresponds to a correct application of some transition?
>
> > The attack is that some private information (h(i.a.pse_ap.x598.Id2(9)))
> > is obtained by the intruder, but I don't understand how it is possible,
> > because the message that contains this information is encrypted with
> > Kua, that is (or at least should be) only known by A and U.
>
> If you have such constraints, you may also specify additional goals 
> like the secrecy of that key, so you may obtain a simpler attack?
>
> Cheers,
> Sebastian 


-- 
-----------------------------
Manuel Sanchez Cuenca
Departamento de Ingenieria de la Informacion y las Comunicaciones
Departamento de Ingenier?a y Tecnolog?a de Computadores
Facultad de Informatica. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-364644    Fax: +34-968-364151
email: msc at dif.um.es  |  manuelsc at um.es
url: http://webs.um.es/manuelsc


From SMO at zurich.ibm.com  Mon Apr  6 13:16:08 2009
From: SMO at zurich.ibm.com (Sebastian Moedersheim)
Date: Mon, 6 Apr 2009 19:16:08 +0200
Subject: [Avispa-users] Help with attack
In-Reply-To: <49DA30CF.1070706@um.es>
References: <49DA2221.9050701@um.es>	<OF999E9E5E.BC335393-ONC1257590.005A0C0D-C1257590.005A7A29@ch.ibm.com>
	<49DA30CF.1070706@um.es>
Message-ID: <OF2614041F.F5507235-ONC1257590.005C2098-C1257590.005EDC94@ch.ibm.com>

> In theory this is not possible, because all this message is encrypted 
> with a symmetric_key shared only between A and U.
> 
> the message you show is incomplete, the full message is
> (a,3) -> i: 
> {{up.a.h(i.a.pse_ap.x598.Id2(9))}_inv(ka).{a.sp.Pse_asp(13).Na
> (13).Id1(7)}_inv(ka)}_Kua(1) 
> 

Oops, sorry, you are right. Anyway, the intruder can probably create that 
message earlier in the attack already (and only in the last step becomes a 
secret). Can you check that the "constant" pse_ap is correct? Guessing 
from the specification I assume it should be freshly created, instead. 
Maybe there is something wrong at that point? (So when can the intruder 
first create all ingredients of the secret?)

Cheers,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20090406/967339bf/attachment.html 

From laurent.vigneron at loria.fr  Tue Apr  7 04:31:48 2009
From: laurent.vigneron at loria.fr (Laurent Vigneron)
Date: Tue, 07 Apr 2009 10:31:48 +0200
Subject: [Avispa-users] Help with attack
In-Reply-To: <49DA2221.9050701@um.es>
References: <49DA2221.9050701@um.es>
Message-ID: <49DB0F74.4070500@loria.fr>

Hello Manuel,

Looking at your spec, the attack is correct, the intruder, playing role 
provider can get all the information for composing the "secret" of evidence.

But note that there is one error in your spec:
role serviceprovider has to know Kvid from the beginning (so given as 
parameter).
You have written:
   1. State   = 7  /\ RCV({{URI'.Init_st'.A}_inv(Kvid')}_Kusp)
but an agent cannot learn a key like this.
So you should add it as parameter and drop the ' here and in the 
right-had side of this transition.

One more remark, about role aggregator and its following transition:
   1. State   = 9  /\
    RCV({{{URI'.{(Up'.A).SP'.Nu'}_Ka.A}_inv(Kvid').Id1'}_inv(Ksp')}_Kua)
                   /\ in(Up'.Kvid'.Pse_ap'.P',Vids)
                   /\ in(SP'.Ksp',PKI)
                   /\ in(P'.Kp',PKI) =|> ...
The inclusion test in(P'.Kp',PKI) does not depend on any known 
information; this means that any information in PKI could be chosen, 
this could be a risk, couldn't it?

Anyway, all this does not change anything about the attack, the intruder 
can get each information that is hashed in the secret (see below the 
---> comments).

Laurent.



ATTACK TRACE
  i -> (u,3):  start
               & Test a.ka in set_193;
  (u,3) -> i:  {u.n1(Kua).n1(Nua)}_ka

  i -> (a,5):  {u.n1(Kua).n1(Nua)}_ka
               & Test a.ka in set_193;
  (a,5) -> i:  {a.n1(Nua)}_n1(Kua)

  i -> (u,3):  {a.n1(Nua)}_n1(Kua)
               & Test i.ki in set_193;
  (u,3) -> i:  {u.n2(Kup).n2(Nup)}_ki

  i -> (u,3):  {i.n2(Nup)}_n2(Kup)
               & Test sp.ksp in set_193;
  (u,3) -> i:  {u.n3(Kusp).n3(Nusp)}_ksp

  i -> (sp,4):  {u.n3(Kusp).n3(Nusp)}_ksp
                & Test sp.ksp in set_193;
  (sp,4) -> i:  {sp.n3(Nusp)}_n3(Kusp)

  i -> (u,3):  {sp.n3(Nusp)}_n3(Kusp)
  (u,3) -> i:  {{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid))}_n3(Kusp)

  i -> (sp,4):  {{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid))}_n3(Kusp)
                & Test a.ka in set_193;
  (sp,4) -> i: 
{{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n3(Kusp)

  i -> (u,3): 
{{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n3(Kusp)
  (u,3) -> i: 
{{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n1(Kua)

  i -> (a,5): 
{{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n1(Kua)
               & Test i.ki in set_193;  Test sp.ksp in set_193;
               & Test up.kvid.pse_ap.i in set_195;
  (a,5) -> i:  {{pse_ap.n28(Id2).a.i}_(inv(ka))}_n1(Kua)

  i -> (u,3):  {{pse_ap.n28(Id2).a.i}_(inv(ka))}_n1(Kua)
  (u,3) -> i:  {{pse_ap.n28(Id2).a.i}_(inv(ka))}_n2(Kup)
---> Above, i learns pse_ap and n28(Id2)

  i -> (u,3):  {{Challenge(7)}_(inv(ki))}_n2(Kup)
  (u,3) -> i:  {{Challenge(7)}_kupwd}_n2(Kup)

  i -> (u,3):  {{i.a.pse_ap.Np(29).n28(Id2)}_(inv(ki))}_n2(Kup)
---> Above, as i is the one who generates Np(29), he has all the 
required information for building the secret (as he knows the hash function)

  (u,3) -> i:  {{i.a.pse_ap.Np(29).n28(Id2)}_(inv(ki))}_n1(Kua)

  i -> (a,5):  {{i.a.pse_ap.Np(29).n28(Id2)}_(inv(ki))}_n1(Kua)
  (a,5) -> i: 
{{up.a.{i.a.pse_ap.Np(29).n28(Id2)}_h}_(inv(ka)).{a.sp.n29(Pse_asp).n29(Na).n22(Id1)}_(inv(ka))}_n1(Kua)
               & Secret({i.a.pse_ap.Np(29).n28(Id2)}_h,set_232);
               & Add a to set_232;  Add u to set_232;

From manuelsc at um.es  Tue Apr  7 04:36:22 2009
From: manuelsc at um.es (=?ISO-8859-1?Q?Manuel_S=E1nchez_Cuenca?=)
Date: Tue, 07 Apr 2009 10:36:22 +0200
Subject: [Avispa-users] Help with attack
In-Reply-To: <49DB0F74.4070500@loria.fr>
References: <49DA2221.9050701@um.es> <49DB0F74.4070500@loria.fr>
Message-ID: <49DB1086.8000804@um.es>

Laurent Vigneron escribi?:
> Hello Manuel,
Hello,

thank you for your help.
>
> Looking at your spec, the attack is correct, the intruder, playing 
> role provider can get all the information for composing the "secret" 
> of evidence.
>
> But note that there is one error in your spec:
> role serviceprovider has to know Kvid from the beginning (so given as 
> parameter).
> You have written:
>   1. State   = 7  /\ RCV({{URI'.Init_st'.A}_inv(Kvid')}_Kusp)
> but an agent cannot learn a key like this.
> So you should add it as parameter and drop the ' here and in the 
> right-had side of this transition.
>
> One more remark, about role aggregator and its following transition:
>   1. State   = 9  /\
>    RCV({{{URI'.{(Up'.A).SP'.Nu'}_Ka.A}_inv(Kvid').Id1'}_inv(Ksp')}_Kua)
>                   /\ in(Up'.Kvid'.Pse_ap'.P',Vids)
>                   /\ in(SP'.Ksp',PKI)
>                   /\ in(P'.Kp',PKI) =|> ...
> The inclusion test in(P'.Kp',PKI) does not depend on any known 
> information; this means that any information in PKI could be chosen, 
> this could be a risk, couldn't it?
>
> Anyway, all this does not change anything about the attack, the 
> intruder can get each information that is hashed in the secret (see 
> below the ---> comments).
>
> Laurent.
>
>
>
> ATTACK TRACE
>  i -> (u,3):  start
>               & Test a.ka in set_193;
>  (u,3) -> i:  {u.n1(Kua).n1(Nua)}_ka
>
>  i -> (a,5):  {u.n1(Kua).n1(Nua)}_ka
>               & Test a.ka in set_193;
>  (a,5) -> i:  {a.n1(Nua)}_n1(Kua)
>
>  i -> (u,3):  {a.n1(Nua)}_n1(Kua)
>               & Test i.ki in set_193;
>  (u,3) -> i:  {u.n2(Kup).n2(Nup)}_ki
>
>  i -> (u,3):  {i.n2(Nup)}_n2(Kup)
>               & Test sp.ksp in set_193;
>  (u,3) -> i:  {u.n3(Kusp).n3(Nusp)}_ksp
>
>  i -> (sp,4):  {u.n3(Kusp).n3(Nusp)}_ksp
>                & Test sp.ksp in set_193;
>  (sp,4) -> i:  {sp.n3(Nusp)}_n3(Kusp)
>
>  i -> (u,3):  {sp.n3(Nusp)}_n3(Kusp)
>  (u,3) -> i:  {{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid))}_n3(Kusp)
>
>  i -> (sp,4):  {{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid))}_n3(Kusp)
>                & Test a.ka in set_193;
>  (sp,4) -> i: 
> {{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n3(Kusp) 
>
>
>  i -> (u,3): 
> {{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n3(Kusp) 
>
>  (u,3) -> i: 
> {{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n1(Kua) 
>
>
>  i -> (a,5): 
> {{{n4(URI).{up.a.sp.n4(Nu)}_ka.a}_(inv(kvid)).n22(Id1)}_(inv(ksp))}_n1(Kua) 
>
>               & Test i.ki in set_193;  Test sp.ksp in set_193;
>               & Test up.kvid.pse_ap.i in set_195;
>  (a,5) -> i:  {{pse_ap.n28(Id2).a.i}_(inv(ka))}_n1(Kua)
>
>  i -> (u,3):  {{pse_ap.n28(Id2).a.i}_(inv(ka))}_n1(Kua)
>  (u,3) -> i:  {{pse_ap.n28(Id2).a.i}_(inv(ka))}_n2(Kup)
> ---> Above, i learns pse_ap and n28(Id2)
>
>  i -> (u,3):  {{Challenge(7)}_(inv(ki))}_n2(Kup)
>  (u,3) -> i:  {{Challenge(7)}_kupwd}_n2(Kup)
>
>  i -> (u,3):  {{i.a.pse_ap.Np(29).n28(Id2)}_(inv(ki))}_n2(Kup)
> ---> Above, as i is the one who generates Np(29), he has all the 
> required information for building the secret (as he knows the hash 
> function)
>
>  (u,3) -> i:  {{i.a.pse_ap.Np(29).n28(Id2)}_(inv(ki))}_n1(Kua)
>
>  i -> (a,5):  {{i.a.pse_ap.Np(29).n28(Id2)}_(inv(ki))}_n1(Kua)
>  (a,5) -> i: 
> {{up.a.{i.a.pse_ap.Np(29).n28(Id2)}_h}_(inv(ka)).{a.sp.n29(Pse_asp).n29(Na).n22(Id1)}_(inv(ka))}_n1(Kua) 
>
>               & Secret({i.a.pse_ap.Np(29).n28(Id2)}_h,set_232);
>               & Add a to set_232;  Add u to set_232;
>


-- 
-----------------------------
Manuel Sanchez Cuenca
Departamento de Ingenieria de la Informacion y las Comunicaciones
Departamento de Ingenier?a y Tecnolog?a de Computadores
Facultad de Informatica. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-364644    Fax: +34-968-364151
email: msc at dif.um.es  |  manuelsc at um.es
url: http://webs.um.es/manuelsc


From isalekul at hotmail.com  Wed Apr 15 00:08:20 2009
From: isalekul at hotmail.com (Salekul Islam)
Date: Wed, 15 Apr 2009 00:08:20 -0400
Subject: [Avispa-users] Replay attack by a sniffer
Message-ID: <COL115-W5828E90245AC1A2615E61ACF7D0@phx.gbl>


Hello,

Is there any way to model replay attack by a sniffer in Avispa? The replay attacks I have seen so far are based on the idea that the attacker will intercept the packet and will capture it. Hence, the receiver will never receive the packet the sender sent at first. I like to model a scenario where the receiver will receive the packet from the sender. The attacker will also get the same packet by sniffing and will replay it later to the receiver.

My feeling is due to the use of Dolev-Yao channels, one can not model the reception of a packet simultaneously by a receiver and an attacker. Is there any way to model it? Any of you have modeled replay attack by a sniffer?

With regards,
Salekul 

_________________________________________________________________
Create a cool, new character for your Windows Live? Messenger.
http://go.microsoft.com/?linkid=9656621
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20090415/b3c297e9/attachment.html 

From laurent.vigneron at loria.fr  Wed Apr 15 04:54:52 2009
From: laurent.vigneron at loria.fr (Laurent Vigneron)
Date: Wed, 15 Apr 2009 10:54:52 +0200
Subject: [Avispa-users] Replay attack by a sniffer
In-Reply-To: <COL115-W5828E90245AC1A2615E61ACF7D0@phx.gbl>
References: <COL115-W5828E90245AC1A2615E61ACF7D0@phx.gbl>
Message-ID: <49E5A0DC.90107@loria.fr>

Dear Salekul,

In the Dolev-Yao model, you can consider that each message received by a 
participant has also been received by the intruder.  And in fact, if you 
look at the trace of an execution with AVISPA, you will see that no 
message goes directly from an honest participant to another honest 
participant, the intruder is always used an intermediary.
If you want to consider a scenario where there is first a normal session 
between honest agents, and then a second where the intruder impersonates 
one agent, you should try to specify in the environment role two 
identical sessions between honest agents.

Best regards,
Laurent.


> Hello,
> 
> Is there any way to model replay attack by a sniffer in Avispa? The 
> replay attacks I have seen so far are based on the idea that the 
> attacker will intercept the packet and will capture it. Hence, the 
> receiver will never receive the packet the sender sent at first. I like 
> to model a scenario where the receiver will receive the packet from the 
> sender. The attacker will also get the same packet by sniffing and will 
> replay it later to the receiver.
> 
> My feeling is due to the use of Dolev-Yao// channels, one can not model 
> the reception of a packet simultaneously by a receiver and an attacker. 
> Is there any way to model it? Any of you have modeled replay attack by a 
> sniffer?
> 
> With regards,
> Salekul

From opkush.alld at gmail.com  Fri Apr 17 01:44:49 2009
From: opkush.alld at gmail.com (om prakash kushwaha)
Date: Fri, 17 Apr 2009 11:14:49 +0530
Subject: [Avispa-users] how to understand STATISTICS in avispa tool output
Message-ID: <f4cfce220904162244n3602e459j27af21d364713298@mail.gmail.com>

Hello Sir/Madam,
                         i am omprakash from india.I am an M.Tech 2nd year
student from NIT Rourkela, Orissa,India and doing my thesis work by using
Avispa Tool for varification of protocol for security. But i am unable to
understand STATISTICS output which comes in avispa tool output. So please
give me detailed explanation about STATISTICS output and terms like
parseTime,searchTime,visitedNodes,depth and plies.Please give me reply soon.


Thanks

Om Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail63.csoft.net/pipermail/avispa-users/attachments/20090417/24d6bd3a/attachment.html 

From laurent.vigneron at loria.fr  Fri Apr 17 04:14:26 2009
From: laurent.vigneron at loria.fr (Laurent Vigneron)
Date: Fri, 17 Apr 2009 10:14:26 +0200
Subject: [Avispa-users] how to understand STATISTICS in avispa tool
	output
In-Reply-To: <f4cfce220904162244n3602e459j27af21d364713298@mail.gmail.com>
References: <f4cfce220904162244n3602e459j27af21d364713298@mail.gmail.com>
Message-ID: <49E83A62.5030302@loria.fr>

Dear Om Prakash,

The statistics given by each tool are not uniform, but they help to 
understand the complexity of the considered example.
You have some timings, for parsing/translating the HLPSL specification 
into a back-end usable specification, and for the total execution time.
You also have the number of states/nodes considered in the search space.
Depending on the options used, you may see the variation of the size of 
the search space.

Laurent.


om prakash kushwaha a ?crit :
> Hello Sir/Madam,
>                          i am omprakash from india.I am an M.Tech 2nd 
> year student from NIT Rourkela, Orissa,India and doing my thesis work by 
> using Avispa Tool for varification of protocol for security. But i am 
> unable to understand STATISTICS output which comes in avispa tool 
> output. So please give me detailed explanation about STATISTICS output 
> and terms like parseTime,searchTime,visitedNodes,depth and plies.Please 
> give me reply soon.                                
>                                                                                                                             
> Thanks
>                                                                                                                         
> Om Prakash


From alshadly09 at googlemail.com  Tue Apr 28 04:50:02 2009
From: alshadly09 at googlemail.com (SALEH AL-SHADLY)
Date: Tue, 28 Apr 2009 10:50:02 +0200
Subject: [Avispa-users] i ve doubt
Message-ID: <49F6C33A.7010503@googlemail.com>

Dear all,

i really ve doubt about these things:

1. encryption using symmetry key
2. encryption using public key
3. signature and certificates

is these are same implemented in AVISPA or there is a difference?

please give me some hints .

with many regards
Saleh

From laurent.vigneron at loria.fr  Tue Apr 28 05:11:29 2009
From: laurent.vigneron at loria.fr (Laurent Vigneron)
Date: Tue, 28 Apr 2009 11:11:29 +0200
Subject: [Avispa-users] i ve doubt
In-Reply-To: <49F6C33A.7010503@googlemail.com>
References: <49F6C33A.7010503@googlemail.com>
Message-ID: <49F6C841.60504@loria.fr>

Dear Saleh,

This is a basic question, indeed, but this is always useful to recall 
such things.

The syntax for encryption is the same: {M}_K, whatever is the type of K 
(symmetric key, public key, private key).

However, when you specify transitions in a role, what you write has to 
reflect the semantics:
- if a message {M}_K is received, but the key for decryption is not 
known by the agent, you will have to write: RCV(X')
where X is of type {text}_symmetric_key or {text}_public_key or 
{text}_inv(public_key), depending on the type of K;
- if K is a symmetric key known by the agent, you will write: RCV({M'}_K)
(if M is learned by the agent; if it is already known, drop the ');
- if K is a public key, you will write: RCV({M'}_K)
if the agent know the corresponding private key;
- if K is a private key inv(L), you will write: RCV({M'}_inv(L))
if the agent know the corresponding public key L;
- last case: if the agent cannot decrypt the message, but can compose it 
(he knows M and K), you will write: RCV({M}_K)

Best regards,
Laurent.


SALEH AL-SHADLY a ?crit :
> Dear all,
> 
> i really ve doubt about these things:
> 
> 1. encryption using symmetry key
> 2. encryption using public key
> 3. signature and certificates
> 
> is these are same implemented in AVISPA or there is a difference?
> 
> please give me some hints .
> 
> with many regards
> Saleh