From avispa-users at avispa-project.org Thu Jul 14 11:38:43 2005 From: avispa-users at avispa-project.org (avispa-users@avispa-project.org) Date: Tue May 2 17:43:47 2006 Subject: [Avispa-users] usability issues Message-ID: I have been playing with AVISPA for the past few days. Overall my impressions are very positive. It is a great piece of software, the installation is painless, the documentation is good and overall I found it a lot easier to use than some of the other tools in the same space. I do, however, have a few gripes: * The xemacs mode. It does a great job of syntax highlighting. However, it is suffering from the following shortcomings/bugs: - no indentation support - the buffer refresh in the compile cycle is erratic - sometimes the result buffers refresh automatically, sometimes they don't, and at other times I get duplicate buffers (..<2> etc) - the compilation does not report any errors; one can find them by switching to the compilation buffer, but that is not at all obvious - the error locations in the compilation buffer are not of a format that emacs recognises, which makes navigating to error locations difficult * Non-executable models. As mentioned in the manual & tutorial, and evidenced by my own observations, it is very easy to make mistakes that result in the model becoming partially un-executable and the model checker consequently reporting success. The tutorial suggests using the -p option to step through the states. However, that is extremely tedious for anything but the most trivial models. Would it be possible to perform an automated check that all transitions in a model are reachable and can fire? That, I think, would catch most of the cases of non-executable models. * Secure channels. Currently, the only type of channel supported by the modelling language are Dolev-Yao channels. For modelling complex systems I find myself wanting to decompose roles into smaller entities but since the insecure D-Y channels are the only form of communication available this introduces spurious vulnerabilities. The same problem arises more generally when trying to model systems where parts of the communication are impervious to attack. Would it be possible to introduce a secure channel type? * Web interface. The downloadable distribution of AVISPA does not appear to contain the web interface and the trace->msc converter. Would it be possible to make these available? * Typed vs un-typed. In a number of cases I encountered models where I though an attack was possible but AVISPA declared the protocol safe. On closer inspection that turned out to be due to types. In one example there was a replay attack possible if a text type could be interpreted as a symmetric key type. Whether that attack is possible in reality depends on the crypto used. Turning off type-checking resulted in the attack being found. It's probably worth pointing that out in the manual/tutorial. Regards, Matthias From jacopo at dist.unige.it Fri Jul 15 05:34:00 2005 From: jacopo at dist.unige.it (Jacopo Mantovani) Date: Tue May 2 17:43:47 2006 Subject: [Avispa-users] The AVISPA Library of protocols Message-ID: <42DBA623.5040201@dist.unige.it> Dear users of the AVISPA Tool, I'm glad to inform you that the specifications of the protocols and security problems modelled in the HLPSL by the AVISPA Team (and analysed with the AVISPA tool) are now publicly available! You can either follow this link http://www.avispa-project.org/library or check the AVISPA Project web page http://www.avispa-project.org. Enjoy! Jacopo Mantovani. -- Jacopo Mantovani Artificial Intelligence Laboratory DIST - University of Genova, Italy http://www.ai.dist.unige.it/jacopo From jacopo at dist.unige.it Fri Jul 15 05:54:39 2005 From: jacopo at dist.unige.it (Jacopo Mantovani) Date: Tue May 2 17:43:47 2006 Subject: [Avispa-users] usability issues In-Reply-To: References: Message-ID: <42DBAAF8.1020205@dist.unige.it> Dear Matthias, you wrote: > I have been playing with AVISPA for the past few days. Overall my > impressions are very positive. It is a great piece of software, the > installation is painless, the documentation is good and overall I found > it a lot easier to use than some of the other tools in the same space. > Thank you very much! > * Non-executable models. As mentioned in the manual & tutorial, and > evidenced by my own observations, it is very easy to make mistakes that > result in the model becoming partially un-executable and the model > checker consequently reporting success. The tutorial suggests using the > -p option to step through the states. However, that is extremely tedious > for anything but the most trivial models. > > Would it be possible to perform an automated check that all transitions > in a model are reachable and can fire? That, I think, would catch most > of the cases of non-executable models. > > * Secure channels. Currently, the only type of channel supported by the > modelling language are Dolev-Yao channels. For modelling complex systems > I find myself wanting to decompose roles into smaller entities but since > the insecure D-Y channels are the only form of communication available > this introduces spurious vulnerabilities. > > The same problem arises more generally when trying to model systems > where parts of the communication are impervious to attack. Would it be > possible to introduce a secure channel type? > > > * Web interface. The downloadable distribution of AVISPA does not appear > to contain the web interface and the trace->msc converter. Would it be > possible to make these available? > > > * Typed vs un-typed. In a number of cases I encountered models where I > though an attack was possible but AVISPA declared the protocol safe. On > closer inspection that turned out to be due to types. In one example > there was a replay attack possible if a text type could be interpreted > as a symmetric key type. Whether that attack is possible in reality > depends on the crypto used. Turning off type-checking resulted in the > attack being found. It's probably worth pointing that out in the > manual/tutorial. > The issues you arise in your e-mail are very interesting. We'll save your suggestions for the next release of the tool. More precise answers to your questions will follow.. Best regards, Jacopo Mantovani From ug85bas at cs.bham.ac.uk Wed Jul 20 21:17:37 2005 From: ug85bas at cs.bham.ac.uk (Ben Smyth) Date: Tue May 2 17:43:47 2006 Subject: [Avispa-users] Suggestions: user-defined functions Message-ID: <002901c58d5f$b21c3610$0200a8c0@bensmyth> Dear AVISPA users, I am currently working with AVISPA and would like to make a suggestion for future development. My work requires more than the basic functions that AVISPA provides (such as xor and exp), thus supporting user-defined functions would be highly desirable. According to the documentation it would appear that this is already possible, by editing the prelude.if file, however this seems not to be the case. SATMC appears to be the only translator which uses the prelude.if file, all other back ends simply ignore it? Thus making it impossible to define one's own functions? If this is not the case I would be grateful if you could provide me with further information. Further to the above comment I would like to add; the prelude.if file is not the best place to put user-defined functions (for numerous reasons, which I won't go into here - although feel free to ask). Ideally I would suggest the inclusion of the keyword import/include within the hlpsl specification, which defines the inclusion of a user-defined prelude (in addition to the default prelude.if). Alternatively the additional prelude could be specified at the command line. Or both options could be incorporated. Personally I would prefer the include/import option. Regards, Ben Smyth PS - I apologise if you receive this email twice. I have just sent it prior to completing the sign up to this list (and it was bounced), hence why I am resending. From compa at dist.unige.it Fri Jul 22 18:23:43 2005 From: compa at dist.unige.it (Luca Compagna) Date: Tue May 2 17:43:47 2006 Subject: [Avispa-users] Suggestions: user-defined functions In-Reply-To: <002901c58d5f$b21c3610$0200a8c0@bensmyth> References: <002901c58d5f$b21c3610$0200a8c0@bensmyth> Message-ID: <42E11D8F.4000704@dist.unige.it> Dear Ben, I am going to answer to you as developer of SATMC and in name of the AVISPA team. The idea behind the prelude file has been quite controversal during the project. Ben Smyth wrote: >Dear AVISPA users, > >I am currently working with AVISPA and would like to make a suggestion for >future development. > >My work requires more than the basic functions that AVISPA provides (such as xor >and exp), thus supporting user-defined functions would be highly desirable. > >According to the documentation it would appear that this is already possible, by >editing the prelude.if file, however this seems not to be the case. SATMC >appears to be the only translator which uses the prelude.if file, all other back >ends simply ignore it? Thus making it impossible to define one's own functions? >If this is not the case I would be grateful if you could provide me with further >information. > > At the beginning we have in mind what you are saying that is to allow the user to modify the prelude file as he prefers. Then we figure out this was not so simple for the majority of the modules (translator and back-ends) in the AVISPA tool and thus we decide to not allow the user to change the prelude file i.e. the translator and the back-ends assume what there is written in the prelude file. So you may ask why to introduce a prelude file and I would say for making explicit the assumption made. SATMC (and maybe TA4SP) are the only back-ends that currently process the prelude file, but I am afraid they both do not support equations. We would like extend SATMC with algebraic equations and we plan to work on it in September (a preliminary work in this direction was started one year ago, but afterthat we did not have resources for continuing it). On the one hand I agree with you that the tool should be extended for allowing users to specify their own equational theory, goal facts, etc. On the other it is not so obvious to implement a back-end able to consider a generic equational theory. I am quite sure that on this specific point my project colleagues at INRIA and ETHZ are more prepared than me and so I would invite them to express their opinions. >Further to the above comment I would like to add; the prelude.if file is not the >best place to put user-defined functions (for numerous reasons, which I won't go >into here - although feel free to ask). Ideally I would suggest the inclusion of >the keyword import/include within the hlpsl specification, which defines the >inclusion of a user-defined prelude (in addition to the default prelude.if). >Alternatively the additional prelude could be specified at the command line. Or >both options could be incorporated. Personally I would prefer the include/import >option. > > This is a good suggestion and I agree with you that it would be a nice improvement of the AVISPA tool. best regards, Luca Compagna P.S. next week the majority of the AVISPA members (me included) will be quite busy for the project evaluation meeting. After that I will be willing to continue this discussion. >Regards, > >Ben Smyth > > >PS - I apologise if you receive this email twice. I have just sent it prior to >completing the sign up to this list (and it was bounced), hence why I am >resending. > >_______________________________________________ >Avispa-users mailing list >Avispa-users@avispa-project.org >http://www.avispa-project.org/mailman/listinfo/avispa-users > > > -- Luca Compagna PhD student E-mail: compa@dist.unige.it E-mail: compa@dai.ed.ac.uk http://www.ai.dist.unige.it/compagna ======================================================= DIST - University of Genova Viale Causa 13, 16145 Genova, ITALY phone: ++39.(0)10.353-6567 fax: ++39.(0)10.353-2948 ======================================================= School of Informatics - University of Edinburgh Appleton Tower, Crichton Street, EH8 9LE Edinburgh, UK =======================================================