Animation of Natural Language Specifications of Authentication Protocols

Problem Statement: A few visualization tools have been created for protocol design and analysis. Although these tools provide an environment for designing security protocols, each one has its own protocol definition language (its also called informal specification language). The problem is that the user should understand the language which related to the used tool in order to define an exist protocol or design a new one. For specification, a language needs to be intuitive as well as easily usable and understandable by the security protocol engineer. It must be able to precisely and unambiguously specify the behavior of security protocol. Approach: In this study, we propose an approach for protocol specification based on the Natural language definitions of protocol semantics. By using programmatic semantics together with animations, representational flexibility of different protocol demonstration is retained for as long as it is needed. Result: This study provides an environment that can be used by protocols designers to develop and investigate different scenarios of security protocols especially authentication protocols. Natural Language Protocol Specifications (NLPS) approach is used to define the protocol. The environment accepts the natural language text of protocol specifications and converts it to animations of protocol behavior. Conclusions/Recommendations: NLPS environment can really help protocol designer to consider and investigate the behavior of security protocols. It can also be used for teaching-learning security protocol concepts. In further, we will consider the possibility of analyzing security protocols using our NLPS environment and animation techniques in order to improve the correctness; that is determining whether or not the intended security properties of a protocol do hold.


INTRODUCTION
In the field of software engineering, graphical and diagrammatic representations are used to support many activities of the software development process such as specification design and analysis. Interactive visual representation of requirements specifications will help users to create, review and understand formal specifications which are used for protocol analysis. Providing an animated interactive environment for design security protocol will improvise readability and understandability of secure communication between individuals.
An authentication protocol is an exchange of messages having a specific form for authentication of principals using cryptographic algorithms [5] . Specifications that describe and design authentication protocols are usually very complex to read and understand with a lot of different entities of different types being passed back and forth between actors in the system. Requirements specifications of authentication protocols are usually described in an informal standard notation. The standard notation specifies these types of protocols at high level of abstraction indicating the order, the direction of flow and the contents of protocol messages. However, informal standard notation does not explicitly state the necessary actions to verify messages received by neither the principals nor the meaning of the message contents. Furthermore, many informal standard notations have been created to describe the specifications of protocol and users confused as to which one should be used for describing protocol. Although tools for designing and analyzing security protocols exist [1][2][3] , the definition of the protocol specifications are still written informally.
Natural language definitions of protocol semantics are intuitive but they are inherent ambiguities. While some see the inherent "ambiguity" of natural language as a problem, we see it as an important advantage [4] . By using natural language understanding to construct the mapping between natural language protocol specifications and object-oriented programming language details on a dynamic basis, representational flexibility is retained for as long as it is needed.
From storytelling viewpoint, it is true that every program tells a story. Programming, then, is the art of constructing a story about the objects in the program and what they do in various situations [4] . From the definition of authentication protocol [5] , it can also be mentioned that every protocol tells a story. So, it is possible for natural language protocol specifications to be converted into programs and animations in order to demonstrate the behavior of protocol. Animation technique facilitates ''reuse'' more naturally, since the basic components and functions of security protocols and animation can be reused for several different protocol animation scenarios. This is evidenced by the rapid prototyping capability of computer and video games where although the characters and story lines change, the basic animation remains constant [6] .
This research describes the possibility of an animation of Natural Language Protocol Specifications (NLPS) of authentication protocol by presenting an environment which help protocol designer to create, review and understand the behavior of security protocols.
Theoretical background: Many animated visualization tools has been developed in computer sciences education. There is a widespread belief among computer educators that visualization technology can improve the effectiveness of learning [7] . Although tools for illustrating computer networking and security protocols concepts exist [8][9][10][11] , users are not able to add For protocol design, few tools have been developed. One of the protocol visualization tools is ProtoViz which is reported by Elmqvist [1] . This tool allows arbitrary protocols to be described in a step-bystep fashion. The visualization consists of animated message packets moving back and forth between actors. It accepts a protocol description specified using a simple language (Fig. 1) and then transforms its entities and actors into a visual form.
However, this language is informal and user should understand this language in order to define and specify his protocol. GRASP [3] is another tool which employs a similar approach to ProtoViz. It describes a protocol by using a simple protocol specification language that allows an arbitrary number of actors and message passing. The language is also informal and slightly more complex than ProtoViz (Fig. 2).
Most of the tools have its own protocol specifications definition and users are not sure which one is more suitable to be used. In this research, an environment for protocol design is provided which most users who study security protocol concepts can utilize almost immediately.

MATERIALS AND METHODS
The story is a concept used by several research communities in several different ways. In regards to both security protocol specifications and programming storytelling, a story is hereby defined as a series of scenes or events.  A protocol is a series of steps, involving two or more parties, designed to accomplish a task [12] . From this definition, a "series of steps" means that the protocol has a sequence of "scenes" from start to end. Every step "scene" must be executed in turn. "involving two or more parties" means that at least two people "actors" are required to complete the protocol. A person alone does not make a protocol.
If the protocol is organized as a series of scenes, the execution of the protocol proceeds linearly through the scenes and each scene involves at least one of two things: computations by one or more of the actors, or messages sent among the actors, then this organization will be equivalent to a story.

Natural Language Protocol Specifications (NLPS):
the first step in designing security protocol is to define the protocol specifications using text form (natural language texts), then translate these texts into informal specifications using the standard notation. A simple protocol, where actor A (denoted to Alice) sends actor B (denoted to Bob) a message consisting of her identifier A and a random number (it is also called nonce) R A , all encrypted E with B's public key KB , would be specified as: The notation above is informal. It does not explicitly state the actions necessary to verify messages received by the actors, nor the meaning of the message contents. For specification, a language needs to be intuitive as well as easily usable and understandable by the security protocol engineer. It must be able to precisely and unambiguously specify the behavior of security protocol. Natural language definitions of protocol semantics are intuitive, but they are inherent ambiguities. By using programmatic semantics [13] together with animations, representational flexibility of different protocol demonstration is retained for as long as it is needed.
The concepts of writing natural language protocol specifications is based on the strategy used by Schneier [12] . In order to demonstrate protocols, enlisted are the aid of several actors (Table 1). Alice and Bob are the first two. They will perform all general twoperson protocols. As a rule, Alice will initiate all protocols and Bob will respond. If the protocol requires a third or fourth person, Carol and Dave will perform those roles. Other actors will play specialized roles as needed.
Rules of writing natural language protocol specifications: According to local environment, the script of protocol specifications must be written as follows: • Each protocol has its own script • Each script consists of a series of scenes • The execution of protocol proceeds linearly through the scenes • Each scene involves two actors and one message sent • Message content is explained during the scene • Operations on messages ( Table 2) should also be explained during the scene.

An example interaction:
Below is a demonstration of a run through of a brief scenario using Wide-Mouth Frog protocol [14] . This protocol is the simplest symmetric-key cryptography and Trent (a trusted server). Both Alice and Bob share a secret key with Trent. The keys are just used for key distribution and not to encrypt any actual messages between users. To demonstrate this protocol, first, the user chooses actors from actor's gallery before writing protocol script. The actor's gallery consists of images for each actor which has been enlisted in Table 1. Second, the user writes the protocol specifications as a script as below: • Alice concatenates a timestamp, Bob's name and a random session key and encrypts the whole message with the key she shares with Trent. She sends this to trent, along with her name • Trent decrypts the message from Alice. Then he concatenates a new timestamp, Alice's name an the random session key. He encrypts the whole message with the key he shares with Bob and then sends this message to Bob The input two scenes to our environment are parsed using the MontyLingua natural language understanding system [15] , the system first performs a surface parse of each input scene (one sentence or more) into VSOO (verb-subject-object-object) form, then semantic recognizer mulls over the VSOO to identify existing object-oriented semantic where each verb is interpreted as a method and nouns as an object.
A simple class is built and passed to the action animator engine to animate the appropriate methods upon the chosen actors from the actor's gallery. For the previous example, the class which is built for the first scene will be as: Class scene1{ SENDER="Alice"; RECEIVER="Trent"; The animated scenes progressively demonstrate the idea of the considered protocol is shown in Fig. 3.

NLPS environment:
In this study an environment for designing and describing security protocols, especially authentication protocols, is proposed. The introduction of NLPS approach can be used to design protocol specifications. The possibility of designing a new protocol is strongly provided. The environment consists of six components which are scene/script editor, actor's gallery, parser, semantic recognizer, action animator and protocol demonstration storage. The conceptual design of our environment is shown in Fig. 4.

Scene/script editor:
The role of this editor is to enable users to write NLPS as texts. Each protocol consists of a series of sequence scenes. Each scene demonstrates at least two actors and one way message sent.
Actor's gallery: User selects actors from actors' gallery. The important actors of protocol demonstration are enlisted in Table 1 Fig. 4: The conceptual design of NLPS environment all protocols and any other actors may be selected to respond.
The parser: The MontyLingua natural language understanding system [15] is used to parse each input script into VSOO (verb-subject-object-object) form.
Semantic recognizer: Semantic recognizer mulls over the VSOO to identify existing object-oriented semantic where each verb is interpreted as a method and noun as an object. A simple class is built and passed to action animator component.

Action animator:
The passed objects/methods class is linked to the action animator to animate the protocol specifications (actors, operations on message, message passing and messages contents).

Protocol demonstration storage:
In order to view the behavior of the protocol, storage is required so that the protocol can be demonstrated anytime.

DISCUSSION
The idea of NLPS approach is based on the Programmatic Semantics of natural language and storytelling approach. Programmatic Semantics is a mapping between natural linguistic structures and basic programming language structures, by taking the position that programming is storytelling [13] .
The presented concepts of writing natural language protocol specifications is based on the strategy used by Schneier [12] . Therefore, protocol is hereby considered as a series of scenes and each scene consists of one or more sentences which involve two or more actors and one message passing. Each sentence is parsed into VSOO. Each verb is considered as a method which will be animated together with the passed message. By using programmatic semantics together with animations, the representational flexibility of different protocol demonstration is retained as long as it is needed. An animation of NLPS certainly has the capability of improving the readability and understandability of protocol behavior and security protocol concepts.

CONCLUSION
Our environment provides the possibility of converting NLPS to classes where each verb is interpreted as a method and noun as an object. Then, action animator will animate the proper objects and methods to demonstrate the behavior of the considered protocol. We believe that such environment can really help protocol designer to consider the behavior of security protocol. The possibility of analyzing security protocols using our NLPS environment will be considered as a future work.