Section: New Results
Improving formal specifications of cryptographic protocols
The verification of cryptographic protocols has greatly improved these last years. Automated tools such as AVISPA  provide real help in finding and characterizing attacks. The counterpart is that such tool require a formal specification of the protocol, using an appropriate language such as HLPSL. Since HLPSL is a very expressive language, this stage is complicated and error-prone before a correct specification is eventually obtained. The verification tools of AVISPA are not designed to detect such specification errors. In particular, a protocol whose HLPSL text is wrong may not be fully executable. Usually, a protocol that cannot be executed cannot be attacked by an intruder since not all the messages can be exchanged. Thus, a bugged HLPSL specification may be declared as safe by AVISPA tools. Hence, as long as it contains typo-like errors, the verification of a HLPSL specification is pointless.
In order to help designers during the formalisation of their cryptographic protocols, we have developed the SPAN tool  (see 5.6 ). SPAN can be seen as a companion tool for AVISPA which interactively produce Message Sequence Charts (MSC) from the formal HLPSL specification. We used AVISPA and SPAN in order to formalise and verify some industrial protocols designed by Thomson R&D. During this work, it appears that animation of HLPSL specifications can also be of great interest during the design of the protocol itself. Instead of short-lived, laborious and intricate drawings on a black board, designing protocol specification using HLPSL and SPAN reveals to be very efficient. Using HLPSL and animation at early stages of development is a convenient way of explaining and justifying the choices made during the protocol development. Furthermore, it also permits to rapidly consider and play with different environment assumptions or different execution of the protocol.
On one of the protocol under development at Thomson R&D, we found a flaw using AVISPA and SPAN. Again the conjoint use of AVISPA for verification and SPAN for explanation revealed to be useful. Experiments on the formalisation and verification of this protocol under development have been published in  . One the one side, automatic verification of AVISPA was crucial since the protocol and the attack were too complex to be found by manual analysis. In fact, the attack needs two different protocol sessions, four distinct agents and thirteen messages. On the other side, because of the complexity of the attack, animation using SPAN was necessary to figure out if it was a real attack and not an artifact of an ambiguous specification. Then, it helped in discussing with Thomson R&D so as to understand if this attack was realistic on an industrial point of view and, finally, how critical it was. Some other specification and verification experiments on a protocol devoted to ensuring anonymity within trust communities has been published in  .
Conjointly to the development of SPAN and the verification of real-size protocols, we also made several efforts to promote cryptographic protocol verification. The first effort consists in a popularisation article explaining what is a cryptographic protocol and what are the properties to be shown. This is explained on a general public protocol: the basic credit card payment protocol with a smartcard  . On the other side, we also published an article in the french security journal MISC (Multi-system & Internet Security Cookbook)  to show that the verification tools for cryptographic protocols, such as AVISPA and SPAN, are now ready to be used in the industry.