ARTICLE IN PRESS

Journal ofVisual Languages & ComputingJournal of Visual Languages and Computing

19 (2008) 258–290

1045-926X/$

doi:10.1016/j

�CorrespoE-mail ad

Umberto.Fer

www.elsevier.com/locate/jvlc

Visualization of cryptographic protocolswith GRACE

G. Cattaneoa, A. De Santisa, U. Ferraro Petrillob,�

aDipartimento di Informatica ed Applicazioni, Universita degli Studi di Salerno, Fisciano (Salerno), ItalybDipartimento di Statistica, Probabilita e Statistiche Applicate, ‘‘Sapienza’’ - Universita di Roma, Roma, Italy

Received 13 January 2006; received in revised form 23 April 2007; accepted 9 May 2007

Abstract

In this paper we present GRACE (graphical representation and animation for cryptography

education), a Java-based educational tool that can be used to help in teaching and understanding of

cryptographic protocols.

The tool adopts an active learning model that engages the learner by asking him to describe, in an

exemplification of a real-world scenario, cryptographic protocols using simple primitives whose

effects are visualized by means of animated sequences. To this end, the GRACE interface offers the

learner the choice of several cryptographic and non-cryptographic related operations with their

respective visualizations.

By executing a series of these operations in the proper order, a teacher is able to provide a visual

introductory description of several protocols. Moreover, since some of the cryptographic operations

are not just simulated but concretely implemented, it can be used by students to see which

elaborations are performed by each operation of a cryptographic protocol, and their effects on the

represented scenario.

GRACE comes equipped with the implementation of several cryptographic primitives and

cryptosystems. Additional primitives and cryptosystems can easily be plugged in the system.

Visualizations prepared with GRACE can be edited, navigated and saved in a file for playback.

We also present the results of an experimental lesson taught in the Security on Communication

Networks undergraduate course at the University of Salerno during the fall 2004 semester using

GRACE.

- see front matter r 2007 Elsevier Ltd. All rights reserved.

.jvlc.2007.05.001

nding author. Tel.: +39 499 10657; fax: +3906 499 59241.

dresses: cattaneo@dia.unisa.it (G. Cattaneo), ads@dia.unisa.it (A. De Santis),

raro@uniroma1.it (U. Ferraro Petrillo).

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 259

A copy of GRACE and some demo lessons featuring the visualization of some cryptographic

protocols are available at http://www.dia.unisa.it/research/grace.r 2007 Elsevier Ltd. All rights reserved.

Keywords: Educational tool; Cryptographic protocols; Protocol visualization

1. Introduction

It is quite common for teachers to explain concepts related to cryptography by usingvisual metaphors. One of the most noteworthy examples is the usage of Alice and Bob asarchetypal characters when describing cryptographic protocols. These names were chosennot only because they are politically correct since they represent both sexes, but alsobecause of their alphabetical order. Alice and Bob are often portrayed as two characterswho would like to use cryptography to safely exchange some secret documents over apublic communication channel that is being eavesdropped on by a malicious third party.Along these lines, John Gordon described, in a famous after-dinner speech [1], Alice andBob as two parties that tried to defraud insurance companies, that played poker for highstakes by mail, and that exchanged secret messages over tapped telephones. In thesesettings, a cryptographic protocol is described by illustrating the sequence of operationsperformed by the two characters.

Despite the common use of visual metaphors, there are very few specific visualizationsystems that can be used as aids in the teaching and understanding these protocols.Moreover, the approach of these systems is mainly geared toward the passive presentationof protocols. Instead, teachers usually explain these concepts by using electronic slidesshowing a sample execution of the chosen protocol. In some cases, teachers have tosimulate an execution of the protocol when preparing a lesson, in order to determine whichnumerical values should be given in the slides.

Taking this into account, we designed GRACE, a Java-based educational tool that canbe used for both the presentation and the visual experimentation of cryptographicprotocols. The user of the tool is presented with a graphical window displaying anexemplification of a real-world scenario where several virtual parties coexist. Each partyowns resources such as documents and cryptographic keys with associated operations.Parties are also able to perform a set of tasks related to communication, documents andcryptographic operations. By executing these operations in the right order, it is possible torecreate several cryptographic protocols. Moreover, each operation has an associatedanimation. Thus, the correct execution of the sequence of the operations required by aprotocol produces the visualization of that protocol. After being executed, the sequence ofoperations making up the visualization of a protocol can also be navigated or saved forlater use.

The cryptographic tasks available with GRACE are not only simulated but areconcretely implemented. For the user this means being able to visualize the behavior of acryptographic operation on real instances of data. GRACE is mainly intended as a supporttool during the teaching and the learning of cryptographic protocols. Teachers can use it toprovide students with an introduction to cryptographic protocols by means of a visualdescription of them. Students, with at least some basic knowledge about protocols, can useGRACE to interactively assemble one and see the effects of its execution in an

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290260

exemplification of a real-world setting. Students with no experience in protocols can beintroduced to how protocols work by watching a non-interactive presentation of theprotocol itself.

GRACE has a built-in support for the visualization of different types of simplecryptographic protocols, such as the communication between two parties by means ofsymmetric keys or public-key cryptography and comes with the implementation of severalcryptosystems, like RSA and Diffie–Hellman (see [2] for both). More protocols andcryptosystems can be supported by embedding their implementation in some Java classesdeveloped according to a GRACE standard interface.

1.1. Organization of the paper

In Section 2 we provide a short introduction to the topic of cryptographic protocols. InSection 3 we review the only two systems for the visualization of cryptographic protocolswe are aware of. The rationale of our proposal is discussed in Section 4 with an emphasison the intended audience for our system and its differences with respect to existing systems.Some insights on the internal architecture of GRACE and on the visual metaphors it usesare provided in Section 5. In Section 6 we outline the steps to be followed in order to addsupport for new cryptographic protocols and cryptosystems in GRACE. In Section 7 wepresent the visualization of some of the cryptographic protocols supported by GRACE. InSection 8 we present the results of an experimental lesson we conducted with GRACE. InSection 9 we provide some concluding remarks.

2. Cryptographic protocols

A ‘‘cryptographic protocol’’ may be defined as a distributed algorithm consisting of asequence of steps precisely specifying the actions required of two or more entities toachieve a specific security objective (see [2]). The steps must follow a specific order andconsist of computations, by means of cryptographic and non-cryptographic techniques,and message transmissions. Moreover, we define a ‘‘cryptosystem’’ as a set ofcryptographic primitives (or operations) used to provide some information securityservices. There are different terminologies used to denote the participants to acryptographic protocol. Two of the most widely used definitions are ‘‘parties’’ and‘‘principals’’ (see [2] for both). In this paper we will use the term ‘‘parties’’ to this end. Thecryptographic building blocks that we consider in GRACE for the construction of morecomplex protocols are:

�

Communication using a symmetric cipher: The sender and receiver share a commonprivate key. To achieve secure communication, the sender encrypts the message, whichis called the plaintext, using the private key and a symmetric cipher (e.g., DES,TripleDES, AES), obtains the ciphertext and sends it to the receiver. The receiver canuse the common private key to decipher the ciphertext and to obtain the plaintext. � Communication using public-key cryptography: In a public-key setting, each party has a

private key that is kept secret and a public key that is published for every other party.The party never publishes or transmits its private key to anyone. The sender of amessage looks up or is sent the recipient’s public key and uses it to encrypt the message.The recipient uses his private key to decrypt the ciphertext received and to obtain the

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 261

message. The public-key setting allows both secure communication and digitalsignatures.To encrypt a message, the sender uses the receiver’s public key to obtain the ciphertext.The receiver can obtain the plaintext by using his private key and the ciphertext. Noother party can decipher the message without knowing the private key. The mostcommonly used public-key system is the RSA.

� Digital signature: In a public-key setting, a party can sign a message using his private

key. Any other party can verify the signature by using only the message and the signer’spublic key. It is not feasible to forge a signature, that is to compute a party’s signatureon a new message if only the public key, without the private key, is known.

Some cryptographic protocols, such as the ones based on symmetric ciphers, require theparticipants to share a common secret (e.g., a DES private key), to be used for subsequentcryptographic operations. Two or more parties can be provided with a common sharedsecret by using a ‘‘key establishment protocol’’. There are two main categories of keyestablishment protocols (see, again, [2]). ‘‘Key transport protocols’’ are a key establish-ment technique where one party creates or otherwise obtains a secret value, and securelytransfers it to the other(s). ‘‘Key agreement protocols’’ are a key establishment techniquein which a shared secret is derived by two (or more) parties as a function of informationcontributed by, or associated with, each of these, (ideally) such that no party canpredetermine the resulting value. One of the most famous key establishment protocols isthe Diffie–Hellman exponential key exchange.

3. Previous work

There are many examples of visualization techniques used to help students tounderstand cryptographic protocols, such as in [3–5]. These examples usually come asJava applets that are developed ad hoc for the visualization of a particular protocol. Someof these applications also offer simple interaction primitives, such as providing the userwith the possibility of specifying the input values to be used for the execution of theprotocol.

These applications tend to be very effective as they are tailored to the visualization of aparticular cryptographic protocol. However, this may turns out to be a drawback as thevisualizations they perform cannot be customized to meet user’s needs, nor can they beeasily adapted to visualize other protocols.

A solution to this problem comes from systems that are intended for the visualization ofgeneric cryptographic protocols. These systems are able to generate the visualrepresentation of a target protocol on-the-fly.

Since this application field is relatively new, the solutions for the visualization of genericcryptographic protocols are very few. To the best of our knowledge, the only existingsystems are Protoviz [6] and the Tutorial Environment for Cryptographic Protocols [7].

Protoviz is an application that accepts, as input, a protocol description specified using asimple custom language. The representation is generated by displaying the actors involvedin the protocol and the messages they exchange during a virtual execution of the sameprotocol assuming generic input data. The provided language includes entities such asactors, documents, encrypted documents, functions and symmetric keys. The execution ofthe protocol is simulated and strictly adheres to the sequence of steps specified as input.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290262

In the same way, the generated visualization is essentially a passive representation of theprotocol provided as input. This implies that there is no way for the user to influence theexecution of the protocol nor to see how it works on real input sets.The Tutorial Environment for Cryptographic Protocols (TECP) is a visual environment

for the creation and manipulation of modular arithmetic-based cryptographic protocols. Theprotocol is ideally divided into several phases with the user being able to define, at eachphase, the next step to be taken. Some of the available actions are: introducing a new actor inthe protocol, assigning a new variable to an existing actor, letting an actor evaluate amathematical expression using his own variables or having one of the actors transmit someof his variables to another actor. The outcoming protocol is visualized using a sort of UMLsequence diagram portraying, in a timely ordered way, the steps performed by each actor. Asopposed to Protoviz, protocol variables may be assigned with real values and mathematicalexpressions are not just visualized, but also evaluated. This makes it possible to present notonly the formal specification of a protocol, but also how it works on real input values. Onthe other hand, the provided visualization is mainly geared toward the visualization of themathematical aspects of an abstract protocol. No visual metaphor exists to describe how thecryptographic primitives used by the protocol interact with the simulated scenario.

4. Our proposal

As discussed in Section 2, many cryptographic protocols can be described by means of afew building blocks made up of several simpler cryptographic and non-cryptographicprimitives. By using these primitives in the right sequence it is possible to ‘‘recreate’’ theoriginal protocol. We also observe that the cryptographic primitives used by differentprotocols are usually very different in implementation but very similar in behavior. So, it ispossible to define a general visualization for these primitives that can be reused in itsentirety to present protocols of the same type but using different cryptographic techniques.Taking this consideration as a starting point, we opted for an active learning model that

engages the learner by asking him to describe, in an exemplification of a real-world scenario,a complex cryptographic protocol using simpler primitives whose effects are visualized bymeans of animated sequences. Such an approach, which can be traced to the cognitiveconstructivism theory of effectiveness (see [8,9]), makes it possible for users with only basicknowledge of a cryptographic protocol to enhance their understanding of a protocol byinteractively recreating it while visualizing the effects of its application on the examplescenario. In the same way, learners may also make some mistakes when recreating aprotocol. In this case, they will be able to see some of the consequences of these errors on therepresented scenario. One of the main advantages of this approach is that the representationof a cryptographic protocol is not just the mere playback of an animated sequence but is thesum of the visualizations of the primitives interactively executed by the user.Using these observations as a basis, we developed GRACE, an interactive Java-based

system for the visualization of cryptographic protocols. Our system presents the user with agraphical window displaying a scenario where several virtual parties coexist (see Fig. 1 forexample). Each party has his own visual ‘‘desktop’’ containing resources like documents andcryptographic keys with associated operations. Moreover, each party can perform a set ofoperations related to communication, documents and cryptographic operations.The user of the visualization can use the GUI of the system to ‘‘instruct’’ one of the

parties to perform certain operations. For example, we may ask the party named Bob to

ARTICLE IN PRESS

Fig. 1. The visualization of a secure communication protocol using public-key cryptography. Bob has encrypted

his document using Alice’s RSA public key. The encrypted document is being sent to Alice and has been

intercepted by Devil.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 263

encrypt his document by using Alice’s RSA public key and, then, to send the resultingencrypted document to Alice (see, again, Fig. 1). Whenever the user requests one of theseoperations, it is immediately executed and its effects are visualized in the graphical windowusing an animated sequence. The execution (and the visualization) of a whole protocol canbe carried out by executing all the operations it consists of, in the proper order.

It is important to note that operations related to cryptographic operations are not onlysimulated but concretely implemented. This implies that by carrying out the propersequence of operations, the user is able not only to correctly execute a cryptographicprotocol, but also to see the way it interacts with the surrounding scenario.

Additional information on the state of the execution of a protocol can be obtained byinteracting with the visual representation of the resources in a scenario where it is beingexecuted. For example, it is possible to find out the content of a cryptographic key or thehistory of the cryptographic operations a document has undergone by clicking the rightmouse button on their representations.

The user is also provided with a history graphical window containing the list of theoperations executed up to that point. By interacting with this window the user can undo anarbitrary number of operations, thus reverting the visualization to a previous state, savethe current visualization in a file or load a previously recorded visualization.

GRACE can be used by different types of users according to their roles and levels ofexperience:

�

Teachers: Teachers can use GRACE to quickly and easily assemble a straightforwardvisual description of a cryptographic protocol. Such a description may be preparedbefore the lesson. In this case, the teacher would have to use the primitives offered by

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290264

GRACE to recreate the protocol to be taught and then save the outcoming visualizationin a file. The content of the visualization would then be played back during the lesson.During the registration of the visualization, the teacher may also comment on each stepof the protocol with short textual annotations. These annotations will be displayedduring the visualization playback.As an alternative, the teacher may choose to interactively run the tool during the lessonand show the results of the elaborations performed by the protocol when using, forexample, input suggested by students.

� Experienced students: Students with at least some basic knowledge of a cryptographic

protocol can use GRACE to interactively assemble and run it. Starting from an initialsituation (e.g., Alice owns a document that must be safely delivered to Bob) they may bechallenged to correctly execute a cryptographic protocol using the available primitives.In this way, students can see for themselves some of the advantages of using acryptographic protocol in an exemplification of a real-world setting.So, for example, it would be possible for a student to execute an RSA-based securecommunication scheme and verify that, if the steps of the protocol are executed in thecorrect order, the receiver of an encrypted message is able to access its originalunencrypted content. By the same token, an incorrect execution of the steps of aprotocol may allow students to experience by themselves some of the possibleconsequences of these errors (e.g., Bob is not able to decipher the content of Alice’smessage, using his private key, because she used her public key to encipher it).

� Inexperienced students: Students having no experience with a cryptographic protocol

can watch its visualization in order to integrate their study of that protocol. This can bedone by playing back the contents of a visualization previously presented by the teacher.Moreover, these students can improve their understanding of a protocol by repeatedlyexecuting some of its steps with the help of the history window while, at the same time,inspecting the internal state of the protocol by interacting with the current scenario.

4.1. Comparison with other systems

Our system differs from ProtoViz [6] and TECP [7] because it emphasizes not only theformal presentation of a protocol, but also its applications. This is done by giving the userthe possibility of testing the behavior of a cryptographic protocol by effectively andinteractively running it in an exemplification of a real-world setting.Moreover, the description of a new protocol with these two systems requires a solid

understanding of the protocol itself as the user is required, interactively or non-interactively, to provide a formal specification of the protocol.In our case, instead, a cryptographic protocol is expressed as a combination of several

simple cryptographic primitives that can be accessed through a visual interface. Since thedetails of these primitives are embedded in their implementations, the user is not requiredto know the details about them in advance, but may learn the way they work by usingthem.On the other hand, our approach may require some initial programming effort if the

protocol to be visualized and/or the cryptographic techniques it uses are not alreadysupported by our system. However, we observe that several of the cryptographic protocolsand cryptographic techniques commonly taught in security courses have already beenimplemented in Java and are freely available. In these cases, the only work that has to be

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 265

done to support them in GRACE is to insert the code needed to embed theseimplementations into our system.

5. The design of GRACE

The design and implementation of GRACE has been inspired by the actor-orientedprogramming paradigm [10]. According to this paradigm, any computational problem (inour case, a cryptographic protocol) can be solved by a set of collaborating andcomputationally independent components called actors. Actors interact with each other bysending and receiving messages. Each actor autonomously processes the messages hereceives, thus changing his current state. The main difference between this and object-oriented programming is that an actor system is made up of active objects which processpassive messages, while object-oriented systems are made up of passive objects on whichactive messages (object methods) are invoked. The philosophy of the actor-orientedparadigm has been used in our system to seamlessly describe and develop the inherentdynamic and mutable behavior of the entities that participate in a cryptographic protocol.Each of these entities (e.g., documents, parties, keys) has been coded as a Java object,implementing a standard set of tasks. Moreover, each entity has been provided with theability to autonomously visualize itself and the tasks it is able to perform. By properlycombining these tasks, it is possible to recreate the cryptographic protocols building blockpresented in Section 2.

The whole visualization automatically derives from the entities that are instantiated in aprotocol and from the tasks they are requested to perform. To this end, all the entitiesshare a common graphical panel representing the working scenario. The user can requestthe instantiation of new entities or their removal by interacting with one of the twotoolbars displayed by the system. Alternatively, it is possible to execute the tasks associatedwith the entities either by directly interacting with their representation (e.g., it is possible toencrypt a document with a certain key by dragging the key over the chosen document) orby using the second toolbar. Each task is visualized using a programmed animatedsequence. An entity can be requested to execute a task by the user, by means of the GUI ofthe system, or by another entity.

The visualization part of our tool has been developed with the help of the Piccolographic library [11]. Due to the large number of entities involved in the execution ofcryptographic protocols, their visualization is performed by using a zoomable bi-dimensional representation. The default view includes a visualization of all the parties thatare participating to a protocol and of their desktops. At any time, the user may switch to acloser view of a party’s desktop. Moreover, zooming primitives are automatically used bythe system to focus on the item currently selected by the user during the execution ofcryptographic operations.

5.1. The building blocks of a GRACE visualization

We have provided our system with built-in support for several entities of different typethat are commonly involved in the execution of cryptographic protocols and that can beused to recreate a wide variety of scenarios. Each of these entities is represented in oursystem with a proper visual metaphor and has been associated to a set of cryptographic

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290266

and non-cryptographic operations. In the following list, we describe all these entities aswell as the tasks they are involved in and their visual representations.

5.1.1. The party entity

Parties represent the actors who implement a protocol. They are able to generate,manipulate or delete either the cryptographic keys, created according to the cryptographictechnique being used, or documents. New parties can be added to an existing scenario byinteracting with the GUI of the system. During its creation, a party can be qualified as‘‘malicious’’. These parties are able to eavesdrop on the shared communication channel,thus automatically obtaining a copy of any resource (either document or key) sent over it.Moreover, they are able to create either documents or cryptographic keys just as if theywere generated by another party. These ‘‘fake’’ artifacts will be undistinguishable fromlegal ones unless some proper cryptographic operations are carried out to verify theidentity of their real creator.Each party is visualized by using a different image, usually displaying the face of the

party, together with a text label showing the name of that party (see Fig. 2 for an example).Moreover, each party is automatically assigned a unique color. All the resources owned bya party are contained and visualized in his ‘‘desktop’’.The portrait of a party, together with his name, is displayed in the upper left corner of

the visualization area so as to better capture the attention of the user, as suggested in [12].It is framed by a thick line whose color matches the color assigned to that party.The desktop of a party is represented as a square gray area and it is displayed under his

portrait. Malicious parties show an image of an ear (depicting their ability to eavesdrop onthe communication channel) beside the portrait of the party. By clicking the right mouse

Fig. 2. A zoom on Alice’s desktop during the execution of public-key secure communication scheme based on

RSA cryptosystem. Alice owns a plain document, a document encrypted with Bob’s public RSA key and a

document signed with her RSA private key. The smaller window shows the properties of Bob’s public key

(currently owned by Alice).

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 267

button on the desktop, it is possible to zoom into a more detailed view of the resources itcontains.

It is possible to ask a party to send one of his resources to another party by just draggingwith the left mouse button the target resource over the destination party. The transmissionof a resource is visualized by creating a replica of the resource and moving it from thedesktop of the sender party to the desktop of the receiver party. The user of thevisualization knows in advance which resource will be transmitted and to which partythanks to a line that is drawn before the transmission begins and that represents the paththat the resource will follow. If there are malicious parties eavesdropping on thecommunication channel, there will be as many additional paths, leading to these parties,that will represent the interception activity performed by these parties. These additionallines will be drawn using a much lighter color so as to mean that their interception activityis unknown to the other parties.

5.1.2. The key entity

The cryptographic keys are the artifacts used by the parties to perform crypto-graphic operations. GRACE supports three types of keys: public, private and symmetric

keys. The first two types of keys can be used to recreate public-key cryptographicprotocols. The third type of key can be used to assemble symmetric cryptographicprotocols.

A key can be generated by a single party or by a group of parties. In this second case, allthe parties who generated the key will obtain an identical copy of the key.

Keys can be used in GRACE to perform cryptographic operations on documents or onother keys. In the first case, the user has to drag the icon representing the selected key overa document owned by the same party. As a consequence, the system will present the userwith a subset of the following cryptographic operations:

�

Encrypt the document: The document will be encrypted using the selected key. Theresulting ciphertext will be added to the desktop of the party. � Decrypt the document: The document will be decrypted using the selected key. The

resulting plain document will be added to the desktop of the party.

� Sign the document: The hash of the document, evaluated using a standard hashing

function, will be signed using the selected key. A copy of the original document with thesignature attached will be added to the desktop of the party.

� Verify the signature: If the target document carries a signature, the system will use the

selected key to verify it. The result of the verification will be communicated to the userby means of a graphical message box.

The choice of which operations should be made available to the user is automaticallycarried out by the system according to the type of the key (public, private or symmetric)and the cryptosystem currently used by the party.

A cryptographic key can also be combined with another key in order to generate a newsymmetric key (like, e.g., in the Diffie–Hellman protocol). This can be done by draggingthe icon representing the selected key over the destination key. The new key will be addedto the desktop of the party. Moreover, keys can also be transmitted to other parties or to akey repository. This can be done by dragging the icon representing the target key over thedestination entity.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290268

Cryptographic keys are displayed using an icon representing a door key and their colordepends on the type of the key. Public keys are colored blue, private keys are colored redand symmetric keys are colored green. Moreover, each icon displaying a key is framed by aline whose color matches the color of the party who generated that key. Group keys’frames use colors different from those assigned to the parties. All the copies of a samegroup key are framed by a line with the same color.It is possible to access additional information about a key by right-clicking on its icon.

The displayed information includes: the portrait of the party who has supposedlygenerated the key, the portrait of the party who has really generated the key and additionalproperties of the key related to the protocol being visualized. Notice that the identity of theparty who really generated a cryptographic key is initially unknown to the other partiesand the related icon is initially absent. This icon is inserted whenever the party who holdsthe key employs the correct sequence of cryptographic operations in order to establish theauthenticity of the key (e.g., using digital certificates).

5.1.3. The document entity

Documents are defined in our system as containers of texts. They can be used to storemessages that have to be transmitted or received while guaranteeing some securityproperties. Each document has a title, a creator, a current owner, and a history of thecryptographic operations it has undergone. This information can be retrieved by clickingthe right mouse button on the icon displaying the document. Documents can betransmitted to another party by dragging the icons representing them over the destinationentity.A document can be in several states. Plain documents are represented by an icon

displaying a piece of paper filled with text. Encrypted documents are represented by an icondisplaying a piece of paper inscribed with a question mark. Signed documents are shownusing an icon displaying a piece of paper inscribed with a seal. Moreover, the iconsrepresenting both types of documents show a copy of the icon of the key used to performthe respective operation in their right lower corner.

5.1.4. The key repository entity

Key repositories serve as public directories where the public keys of the parties involvedin public-key based cryptographic protocols are stored. The only operations they supportis the transmission or the reception of keys from other parties existing in the scenario.There is no way for a party to know if a key stored in a public repository has beengenerated by the party it refers to or if it has been created by a malicious user. For thisreason, key repositories are useful in showing some of the limitations of public-key basedprotocols.According to a commonly used metaphor, we represent key repositories as cylinders.

The cryptographic keys held by a repository are stacked in lines.

5.1.5. The digital certificate entity

Digital certificates are used to attest the identity of a party. A typical digital certificatecontains the public key of a party together with some identification information releasedby a trusted third-party (the Certification Authority, CA). Moreover, digital certificates aresigned with the private key of the CA that issues them.

ARTICLE IN PRESS

Fig. 3. The main window displays an instance of a X.509 compliant Certification Authority. The other window

displays the properties of the digital certificate of the authority’s RSA public key.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 269

By examining a digital certificate, a user is able to establish if the enclosed public keytruly belongs to the claimed owner. It is also possible to extract the public key contained ina certificate and use it to perform cryptographic operations.

The authenticity of a certificate can be checked by verifying its signature using the publickey of the CA that is supposed to have issued it. If the check is successful the certificate isvalid and so is the formal identity of the key creator shown in the certificate. As aconsequence, the public key contained in the certificate will now correctly show the identityof the party who generated that key.

Digital certificates are represented using an icon displaying a paper certificate (seeFig. 3). By right-clicking on a certificate, it is possible to get additional information aboutthat certificate, such as the CA that issued it and the name of the party to whom thecertificate refers.

5.1.6. The certification authority entity

The CAs are the parties in charge of releasing digital certificates. Whenever a new CA iscreated, all parties automatically obtain a copy of its public key.

A party can ask a CA to issue a digital certificate to prove the authenticity of the pair ofcryptographic keys he has generated (in a public-key cryptosystem). To do so, the user hasto drag the icon representing one of the two keys from the party who created the keys tothe CA. The certification process ends with the generation of a digital certificate signed bythe CA, proving the identity of the party who created those keys. A copy of this certificatewill be sent to the requesting party while another copy will be held by the CA.

The visualization of the CA in GRACE is based on a commonly used metaphorfor this concept: the Greek temple (see Fig. 3). This metaphor is used because it emphasizes

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290270

the neutrality and the authority of this entity. A copy of all the digital certificatesemitted by the CA, together with the pair of CA cryptographic keys, is storedinside the area of the temple. Notice that the cryptographic keys of a CA are repre-sented using an ad hoc icon because of their difference with respect to keys generated byparties.

5.2. Recordable and reversable visualizations

As we have already said, GRACE allows users to interactively recreate a cryptographicprotocol by requesting the execution of a proper set of tasks. The interactivity of ourapproach may be burdensome at times if we are just interested in watching the passivevisualization of the behavior of a protocol. By the same token, if we want to see the effectsof a cryptographic operation at a specific point in the execution of a protocol again, wehave to interactively repeat all the operations that led to that situation. These twoexamples imply the need for the user to gain some degree of control over the content of anassembled visualization so as to play it, even partially, over and over again without furtherinteraction.One of the advantages of the actor-oriented approach we followed in designing of our

system is that the current state of a visualization is the result of the execution of a sequenceof tasks on the initially empty scenario. This approach makes it possible to navigate orplay back the contents of a visualization by just undoing or running some previouslyexecuted tasks again. In the same way, it is possible to easily record the contents of avisualization by just saving the list of tasks it consists of in a file.We implemented the possibility to ‘‘navigate’’ GRACE visualizations by making every

task supported by GRACE both ‘‘recordable’’ and ‘‘reversable’’. Recordable means that itmust be possible to annotate the details of every task executed by our system so as to run itagain at a later time. Reversable means that it must be possible to revert the effects of atask run on our system by executing a proper ‘‘inverse’’ task.During its execution, GRACE keeps a history of all the tasks performed since the

beginning of a visualization, and of all the inverse tasks. Whenever the user runs a new taskby interacting with the GUI of the system, the details of the requested task and of itsinverse are annotated in the history. Therefore, the user may choose at any time to undo anarbitrary number of tasks up to the beginning of the visualization and, in the same way,can choose to redo tasks as he likes, from the sequence of tasks that he has previouslyundone (see Fig. 4 for an example).Such a solution makes it easy to save a visualization by just downloading the contents of

the history in a file. The playback of a saved animation can be easily carried out byretrieving its history from a file and running it again. It is important to note that,since we only keep track of the operations executed during a visualization, the size of theoutcoming record files is usually very small, thus making it possible to easily share themover the Internet. Another important observation we make is that the playback of avisualization recorded by the teacher during a lesson may be more difficult to understandbecause of the lack of the teacher’s comments. For this reason, we introduced thepossibility for the user who is building a visualization to associate a textual comment toeach new task describing the meaning of that task. These comments will be saved, togetherwith the details of each task, in the history, and will be displayed during the playback ofthe visualization.

ARTICLE IN PRESS

Fig. 4. The playback with GRACE of a previously saved visualization. The user is allowed to re-run the

visualization step-by-step or in one shot. The re-execution of each step is accompanied by a textual comment

which has been provided by the original author of the visualization.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 271

6. Supporting a new protocol

The philosophy of GRACE is to produce a visualization for a protocol by animating theentities and the cryptographic and non-cryptographic primitives that are involved in itsexecution. All these entities and primitives already have an associated visualization, withthe only exception of the cryptographic primitives whose implementation is initially blank.It is up to the developer to implement these primitives according to the type of protocoland cryptosystem to be visualized. From a practical point of view, this means that thedeveloper has to select the set of GRACE Java classes representing the entities involved inthat particular case (see Fig. 5) and define, by means of object inheritance, the way inwhich the protocol and the cryptosystem being visualized and carry out the abstractoperations featured by these entities.

For instance, the implementation of a public-key cryptographic protocol based on RSArequires the definition of four Java classes as shown in Fig. 5. The first two classes areneeded to encapsulate, respectively, the RSA public key and the RSA private key. Theymust derive the Key base class and implement, respectively, the EncryptingPublicKeyand the DecryptingPrivateKey interfaces. Both classes must define the standardmethods getKeyInfo( ) and cloneKey(Party keyMantainer). The first methodis used by GRACE to present the user with the visualization of the properties of a key, thesecond method clones the key and it is used when a party has to transmit a copy of his key

ARTICLE IN PRESS

Fig. 5. The GRACE core package includes a set of generic classes that are used to visualize different types of

protocols. The support for a new cryptosystem can be added to GRACE, such as in the case of DES and RSA, by

deriving the classes related to the entities which are involved in the cryptosystem (e.g., parties and keys) and

defining an implementation for the cryptographic operations they should support.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290272

to another party. In addition, the class encapsulating the public key must implement amethod for encrypting documents, encryptDocument(Document doc), while theclass encapsulating the private key must implement a method for decrypting documents,decryptDocument(Document doc).The third class to be implemented is the one that specifies the process by which the party

generates new cryptographic keys. GRACE supports both the generation of single-partykeys and of group-keys. Moreover, parties can generate either symmetric keys or pairs ofpublic/private keys. Depending on which type of key is required by the protocol and by thecryptographic techniques to be supported, the user has to derive the Party base class andprovide an implementation for one of the following interfaces: singlePartyPublic-KeySystem, groupPublicKeySystem, singleSymmetricKeySystem and group-Symmetric-KeySystem.The last class to be implemented is a general class that is used to initialize the parameters

that are specific to the protocol to be visualized. It has to derive from the CryptoWindowbase class and implement the method initProtocol( ), used for initializing theprotocol variables, and the method generateParty( ), needed by GRACE to selectwhich Java class should be used for the creation of new parties.

7. GRACE at work

The standard GRACE implementation comes with the support needed for severalfrequently used cryptographic protocols and cryptosystems. In this section we present ashort review of some of these implementations. The explanation has been organized bypresenting a set of security-related topics which are commonly taught in cryptographycourses. For each topic, we provide a short formulation of the security problem it refers to,then we provide a short description of a cryptosystem that can be used to implement acryptographic protocol for solving that problem. This is followed by the description of theGRACE visualization of that protocol and by a short discussion about the way this

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 273

representation can be used to help students understand that protocol. Finally, we providesome notes on the implementation in GRACE of the cryptosystem used by that protocol.

Notice that the cryptosystems available in GRACE and the cryptographic techniquesthey use have been developed using the Java cryptography extension (JCE) library [13]developed by Sun with the exception of the RSA cryptosystem. In this last case, we haveimplemented the technique from scratch in order to be able to modify some of the internalparameters of the technique that were inaccessible in the JCE implementation.

7.1. Secure communication using a symmetric cipher

Two parties who wish to communicate in a secure way may do so by using a secretshared key to encrypt/decrypt messages.

The effectiveness of these cryptosystems relies on the secrecy of the key used to performcryptographic operations. Two parties are able to exchange messages in a secure way if,and only if, they have previously agreed on a common private key. Instead, if one of theparties uses the public communication channel to send a copy of the key in clear to theother party, then the security of the protocol may be easily broken.

7.1.1. The DES cryptosystem

The data encryption standard (DES) is one of the simplest symmetric ciphercryptosystems to be taught. It is a symmetric key cryptosystem [14] that is used toencrypt and decrypt data in 64-bit blocks by means of a 56-bit key. It consists of 3operations:

�

Generation of a secret key: The user chooses a sequence of 56 bits to be used as the secretkey k. � Encryption of a document: To encrypt the document M with secret key k the user runs 16

‘‘rounds’’ of operations that mix M and k together by means of permutations andsubstitutions. These operations are accomplished by using 16 additional subkeys whichare derived from the main secret key k.

� Decryption of a ciphertext: To decrypt the ciphertext C with secret key k, the user runs

the same algorithm used to encrypt it with a slight difference in the order in which the 16subkeys were derived.

DES is a block cipher, this means that it operates on blocks of data of fixed size. If theinput document is larger than this size, then it has to be processed using an ‘‘operationmode’’. There are several operation modes that can be used with DES [15]. Among these,we cite the electronic codebook mode (ECB), that works by splitting the input documentinto smaller parts and encrypting them separately, and the cipher-block chaining mode(CBC), where the input document is split into several blocks and each block is combinedwith the result of the encryption of the previous block before being encrypted.

There are several variants of the DES cryptosystem [2], such as TripleDES andDES–EDE, that offer improved security. These variants are based on the execution of aparticular sequence of DES encryptions and decryptions by means of a longer key. We alsocite the advanced encryption standard protocol [16], a block cipher that is considered asthe successor of DES.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290274

7.1.2. Protocol visualization

Our implementation of the DES cryptosystem presents the user, at start-up, with atypical scenario featuring three parties: two legitimate parties, called Alice and Bob, andDevil, a malicious party interested in reading the contents of the messages exchanged byAlice and Bob. It is as well possible to have one of the parties generate a new documentand send it to another party.At any time, the user of the visualization is given the possibility of selecting several

parties and having them generate a DES group key (see Fig. 6). During this process, theuser may choose to enter a password to be used as a secret key or, as an alternative, he canchoose to have GRACE generate a random secret key.As a result of the generation, all the selected parties will receive an identical copy of the

key (see Fig. 7). Once a new DES group key is generated, the encryption and thedecryption operations can be carried out by dragging the icon representing the key over atarget document and choosing the desired operation (see Fig. 8).Two parties sharing the same DES key can safely exchange secret messages by having

the sender use the shared key to encrypt the document, and the receiver use the same key todecrypt it.Suppose that a malicious third-party eavesdrops on the communication channel and gets

a copy of the encrypted document. The stolen document will be meaningless to him sincehe does not own the secret key needed to decrypt it.The same implementation can also be used to show that if a party transmits his private

key to another party using the public communication channel, then a malicious third-partyeavesdropping on the channel would be able to obtain a copy of such a key and use it todecrypt all the subsequent communications.

Fig. 6. Alice and Bob generate a new DES secret key. A third party, Devil, is eavesdropping on the

communication channel.

ARTICLE IN PRESS

Fig. 7. The window shows the properties of the key generated by Alice and Bob. It is a secret shared key to be

used with the DES cryptosystem. The value of the secret key corresponds to the first 56 bits of a secret keyword

provided by the user.

Fig. 8. Bob uses the DES secret key to decrypt Alice’s encrypted document. As an alternative, Bob may also

choose to use his key to encrypt the document again.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 275

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290276

7.1.3. Implementation notes

The implementation of DES in GRACE required the coding of three Java classes.The DESKey class implements the groupSymmetricKeySystem interface and

provides two methods for encrypting and decrypting documents by means of the DEScryptosystem. Documents are internally represented by GRACE as a stream of bytes. Theoperation mode used for performing cryptographic operations with them is the ECB.The second class, DESParty, derives the Party class and implements the method used

to generate new DES cryptographic keys by means of users’ inputs. To this end, itimplements the GRACE standard generateKeys(Object[ ] input) method. Thismethod may be run both when using GRACE in an interactive way and when playing arecorded visualization. In the first case, the secret key is requested from the user by meansof the Java standard graphic input primitives. Whenever the user inputs this value, themethod checks if they are admissible; otherwise, it rejects it with a proper error message.Once it receives a valid input, the method creates and returns an instance of the DESKeyclass. The value of the secret key is automatically saved in the history.On the contrary, if we are playing back a recorded visualization, the value of the secret

key is automatically retrieved from the history and is provided as input parameters to themethod.The last class, DESWindow, is only needed to set the DESParty class as the default type

of party to be used during the protocol visualization.

7.2. Define a shared secret key using a key agreement scheme

Communication schemes using symmetric ciphers rely on the assumption that the usersthat need to communicate have previously agreed on a shared secret. This assumption maynot always be true. Key agreement schemes allow two users to agree on a common privatekey without having previously agreed on some secret information. Instead, the users onlyhave to choose in advance some security parameters (which can be made public) to be usedin fulfilling the communication scheme.When teaching this kind of protocol, it is interesting to show that, even if

each user independently runs the scheme, the outcoming shared key will always beidentical.It is important as well to show that there is no simple method for deriving the value of a

shared key by processing the data two parties exchange in the key agreement scheme. As aconsequence, a malicious user eavesdropping on the communication channel would still beunable to determine the users’ shared key by simply examining the information they sendeach other.

7.2.1. The Diffie– Hellman key agreement protocol

The Diffie–Hellman protocol is one of the most famous key-agreement protocols. Itallows two or more parties to exchange a secret key over a public communication channelwithout sharing any prior secrets. It consists of the following steps:

(1)

The two users A and B agree to use a prime number p and a generating element g. Thevalue of g is chosen in the multiplicative group of integers modulo p, Z�p.

(2)

A picks a random natural number aop. The value a is assumed to be the private keyand the value ga mod p is assumed to be the public key. The public key is sent to B.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 277

(3)

Fig.

Diffi

B picks a random natural number bop. The value b is assumed to be the private keyand the value gb mod p is assumed to be the public key. The public key is sent to A.

(4)

A computes ðgbÞa mod p.

(5)

B computes ðgaÞb mod p.

At the end of the protocol, the two users have the two values ðgbÞa and ðgaÞ

b which areidentical and can be used as secret keys to run symmetric key protocols.

7.2.2. Protocol visualization

The initial scenario of our implementation of the Diffie–Hellman protocol is identical tothe one we have discussed in Section 7.1 with the only difference being that parties are ableto generate, in this case, pairs of public and private keys instead of DES secret keys. Whendoing so, the user has to first select the two parties that will run the key agreementprotocol. Then, the system will offer the user the possibility of using a default pair ofrandom values p and g generated during the start-up of the system or of generating a newpair of values that will replace them (see Fig. 9). Finally, the user will be prompted to inputthe two natural numbers to be used as private keys by the two parties, as shown in Fig. 10.

At any time, a party can be requested to get a copy of the public key of any other partyand combine it with his own private key. This operation may be done by dragging the iconrepresenting one of the two keys over the icon representing the other key.

The combination of the two keys (see Fig. 11 for an example) will result in thegeneration of a new secret key. Once generated, the new symmetric key can be used by theparty to encrypt a message using the DES cryptosystem and send it to another party.Conversely, if also the receiver of the encrypted message runs the Diffie–Hellman protocolusing his private key and the public key of the sender, he will get a symmetric key to be

9. Alice and Bob agree to generate (and use) a new pair of values p and g to be used in the execution of the

e–Hellman protocol. As an alternative, they could have chosen to use the default pair of values p and g.

ARTICLE IN PRESS

Fig. 10. The user is asked to input the value to be used as a private key by Bob in the Diffie–Hellman protocol.

Bob’s public key will be calculated according to the user’s input and to the pair of values p and g chosen in the

previous step.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290278

used to decrypt the received message using, once again, the DES cryptosystem. The user ofthe visualization can easily verify by himself that the two symmetric keys generatedseparately by the two parties are equal by recalling, with the right-mouse button, theproperties of these two keys.A malicious party eavesdropping on the communication channel would be unable to

generate the same secret key as he would not have the secret key of both parties.

7.2.3. Implementation notes

The implementation of Diffie–Hellman in GRACE required the coding of four Javaclasses. The DHPrivateKey and DHPublicKey classes are used as containers to storethe values of the private and of the public keys to be used for the key agreement.The DHKey class holds the secret key resulting from the combination of a Diffie–Hell-

man private key and the corresponding public key. It derives from the Key standard class,implements the SymmetricKey interface, and provides an implementation of the DEScryptosystem.The generation of a Diffie–Hellman secret key is carried out by the DHParty class by

means of the standard combineKeys(Key firstKey, Key secondKey) method.The last class, DHWindow implements two methods. The initProtocol( ) method is

used to generate G and g as required by the Diffie–Hellman protocol. The generated valuesare shared by all the parties participating in the execution of the protocol.The generateParty( )method sets the DHParty class as the default type of party to

be used during the protocol visualization.

ARTICLE IN PRESS

Fig. 11. Bob has combined his private key with Alice’s public key in order to generate the shared secret key. The

properties of the new key show that it has been associated, by default, with the DES cryptosystem.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 279

7.3. Secure communication using public-key cryptography

Communication schemes based on symmetric ciphers use the same key to both cipherand decrypt messages. The weakness of this approach is that if we want to send anencrypted message to another user, then we have to encrypt the message using the samekey the other user will employ to decrypt the message.

In a public-key setting, each party has a private key and a public key. The public key isknown to all the other parties and can be used to encrypt messages to be sent to that party.On the contrary, the private key is used to decrypt messages and is kept secret by the party.A message encrypted with a party’s public key will be readable only by that party, since heis the only one who owns the corresponding private key.

One of the goals to be pursued when teaching a public-key based communicationprotocol is to explain the roles of the parties involved in the protocol and how public andprivate keys are employed to perform cryptographic operations without having previouslyagreed on any shared information.

7.3.1. The RSA cryptosystem

RSA is the most famous public-key cryptosystem [17]. We give a simple description ofthe operations involved in the cryptosystem. The RSA cryptosystem consists of 3operations:

�

Generation of public and private keys: The user chooses two primes p, q, computes theproduct n ¼ p � q and chooses two integers e and d, such that e � d ¼ 1mod ðp� 1Þ�ðq� 1Þ. The public key is the pair ðn; eÞ. The private key is the pair ðn; dÞ.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290280

�

Fig

Th

Encryption of a document: To encrypt the document M with public key ðn; eÞ, the usercomputes the ciphertext C ¼Me mod n.

� Decryption of a ciphertext: To decrypt the ciphertext C with private key ðn; dÞ, the user

computes the plaintext M ¼ Cd mod n.

Notice that in order to carry out encryptions and decryptions, input documents areassumed to be represented in a numerical form. Whenever the size of M or of C exceeds thevalue n, it is split into smaller parts.

7.3.2. Protocol visualization

Our implementation of this protocol presents the user with the same scenario we haveseen in the previous protocols and featuring three parties: two legitimate parties, calledAlice and Bob, and Devil, a malicious party interested in reading the contents of themessages exchanged by Alice and Bob.Suppose we want to recreate the case where one of the two legitimate parties wants to

send a secret message to the other legitimate party. The user of the visualization may askone of the parties (e.g., Alice) to generate a new pair of RSA keys. The process can becompletely automatic or the user may choose to provide the values for the securityparameters p, q and e. During the key generation, a text window appears showing themathematical details of the process (see Fig. 12). At the end of the generation, a new pairof RSA public and private keys will appear in the desktop of the party.After generating the keys, the user asks Alice to send a copy of her public key to Bob.

Devil will eavesdrop on the communication channel and obtain a copy of such a key (seeFig. 13).

. 12. Alice generates a new pair of RSA keys. The text window shows the mathematical details of the process.

e values of p, q and e have been provided by the user at the beginning of the generation process.

ARTICLE IN PRESS

Fig. 13. Bob requests from Alice a copy of her RSA public key. Devil eavesdrops on the communication channel

and gets a copy of the key.

Fig. 14. Bob encrypts his document using Alice’s public key and sends her a copy of the encrypted document.

Devil eavesdrops on the communication channel and gets a copy of the document.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 281

Meanwhile, Bob creates a new document and fills it with the message to be sent to Alice.Then, Bob encrypts the document using Alice’s public key. The output of the process is anew encrypted document that is automatically added to Bob’s desktop.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290282

Once the document is encrypted, Bob sends a copy of it to Alice. Again, Devileavesdrop over the communication channel and obtains a copy of the encrypted document(see Fig. 14).Finally, Alice decrypts the contents of the encrypted document received by Bob using

her RSA private key (see Fig. 15). The process ends with the generation of a new plaindocument containing Bob’s original unencrypted message.As for what concerns Devil, he now has both a copy of Alice’s RSA public key and of

Bob’s encrypted document. The decryption of the document by means of Alice’s public keywill lead to meaningless results. Notice that, despite being useless, the operation ofdecrypting a ciphertext by means of an RSA public key has explicitly been added toGRACE in order to allow users to see the consequences of this action.The described visualization may be used to show that, in a public-key communication

setting, a party is able to securely transmit a message to another party without having toshare any secret with him a priori, by just using information (the public key of the targetparty) that is publicly available. The problem of decrypting a message encrypted with anRSA public key, without knowing the corresponding RSA private key, is believed to becomputationally infeasible. Thus, the correct application of this protocol may be used toshow that it is almost impossible for a malicious user to decrypt the transmitted messageusing only the information he was able to eavesdrop on the communication channel.In such a setting, it is also possible to show that when executing the steps of the protocol

in the wrong order (i.e., encrypting with a user’s private key and decrypting with auser’s public key) some of the security properties of the protocol will no longer hold.For example, it is possible to show that a malicious party eavesdropping on thecommunication channel and obtaining a copy of a document encrypted with a RSA

Fig. 15. Alice has decrypted the document received by Bob using her private key. The window reporting the

properties of the document shows the list of operations it has undergone.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 283

private key could use the corresponding RSA public key, which is publicly available, todecrypt the document.

7.3.3. Implementation notes

To support RSA, we had to create four Java classes. The first two classes,RSAPublicKey and RSAPrivateKey, are used to store, respectively, the members ofthe public pair ðn; eÞ and of the private pair ðn; dÞ. They implement the cryptographicoperations defined in the PublicKey and PrivateKey interfaces, and inherit from theKey base class.

The other GRACE standard method that both classes implement is getKeyInfo( ).This method is used by GRACE to retrieve and visualize the properties of a key. In our twoclasses, RSAPublicKey and RSAPrivateKey, this method returns the value of therespective keys together with some of the intermediary results of the expressions evaluatedduring their generation.

The third class we implemented, RSAParty, inherits from the GRACE standard Partyclass and is used to generate pairs of RSA keys. The whole key generation process isvisualized by displaying, in a graphical text window, the mathematical steps performed bythe key generation algorithm using the provided input parameters.

The fourth class we implemented, RSAWindow, is used to set RSAParty as the defaultclass to be instantiated when creating new parties.

7.4. Digital certificates and certificate authorities

One of the problems concerning the implementation of a communication schemeusing public-key cryptography is of establishing the credentials of the parties partici-pating in the protocol. Consider the example of the RSA cryptosystem. A maliciousparty C could generate a valid pair of RSA keys, announce himself with the identity ofanother party B, and distribute his keys as if they were the keys of B. A victim, party A,could be fooled by this process and could use the keys generated by C to encrypt a messagefor B.

These problems can be solved by introducing a trusted entity into the system, the CA, incharge of releasing digital certificates. A digital certificate is an electronic document thatestablishes the credentials of a user such as his name and his public key. Digital certificatesare typically signed using the CA private key. Whenever a user A obtains the digitalcertificate of another user B, he can check its validity by verifying the signature of the CA(the public key of the CA is assumed to be known a priori by all users participating to theprotocol). If the check is successful, then the information given in the certificate is assumedto be correct (since the CA can be trusted). A extracts the public key of B from thecertificate and uses it to run the desired protocol.

The key concept to be emphasized when explaining the problem of trust is why it existsand how the introduction of a trusted entity capable of running a public-key cryptosystemsolves the problem.

7.4.1. The X.509 public-key infrastructure

CA are usually part of more general frameworks called public-key infrastructure (PKI).A PKI consists of protocols, services, and standards supporting applications of public-keycryptography. One of the most noteworthy applications of PKI is to allow the identity of

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290284

users over a public network to be established by means of public-key cryptography.Among the different proposed implementations of a PKI, one of the most commonly usedis the one based on X.509 digital certificates [18]. An X.509 digital certificate is anelectronic document binding a public key to a certain identity who is distinguishable andrecognizable in the context of the PKI infrastructure. The X.509-based PKI consists of thefollowing components:

�

Fig

ide

and

A CA that is in charge of releasing and verifying X.509 compliant digital certificates.

� A Registration Authority that acts as the verifier for the certificate authority before a

digital certificate is issued to a requestor.

� One or more repositories where the certificates are stored.

7.4.2. Protocol visualization

We set up an implementation of an X.509 PKI based on the RSA cryptosystem. Whenrun, our implementation automatically initializes and visualizes the PKI. For the sake ofsimplicity, we have chosen to represent all the components belonging to the PKI in a singleentity, see Fig. 16.Whenever a new party is added to the scenario, it automatically gets a copy of the public

key of the CA. This key can be used by parties to verify the authenticity of the digitalcertificates they handle.

. 16. Bob has requested the CA to certify his pair of cryptographic keys. The outcoming certificate shows the

ntity of Bob (as the subject of the certificate), a set of standard information about the validity of the certificate

a copy of Bob’s public key. Moreover, attached to the certificate there is the CA’s signature.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 285

As far as the cryptographic keys generated by parties is concerned, these are, by default,not-certified. This means that they can be used to perform cryptographic operationsas usual but they do not carry verifiable information about the identity of their creator(a certified key can be recognized by visualizing its properties, see 5.1.2 for more details).

A party can be requested to certify his public key by dragging the icons representing thekey over the entity representing the CA. As a consequence, the CA will emit a new X.509digital certificate proving the identity of that party (as shown in Fig. 16). The certificatewill be signed with the private key of the CA and will contain a copy of the party’spublic key.

After doing so, it is possible to ask a party to send to another party a copy of his X.509digital certificate, instead of his public key. The receiver of the certificate can verify thesignature of the certificate (and thus check the validity of the information contained within)by dragging the icon representing the CA public key over the certificate (see Figs. 17 and 18for example). Note that if the digital certificate has been successfully validated, the entityrepresenting the public key contained within it will now give also the identity of the realcreator of the key. From this point on, the party can safely use the public key he hasextracted from the digital certificate, as he is sure about the identity of the creator of the key.

It is instructive to show that, in this same scenario, users can be easily fooled when usingnot-certified keys. Suppose the malicious party, Devil, is interested in reading the content

Fig. 17. Alice checks the authenticity of Bob’s certificate by verifying its signature using the CA’s public key.

ARTICLE IN PRESS

Fig. 18. Bob’s certificate has been successfully validated. Now Alice can be sure that the public key embedded in

the certificate is Bob’s and can safely use it to perform cryptographic operations.

G. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290286

of the messages that Alice sends to Bob. To do so, Devil could generate a new pair ofcryptographic keys and set the ‘‘key creator’’ field in the new keys so as to give the identityof Bob (note that it will be impossible for another party to determine the real identity ofthe keys’ creator). Then, the faked Bob public key could be put in the common repositoryof all the public keys. The party Alice could fetch a copy of such a key and use it to encrypta message to be sent to Bob. By eavesdropping on the communication channel, Devilwould be able to get a copy of such a message and decrypt it using the correspondingprivate key.

7.4.3. Implementation notes

Our implementation of an X.509 PKI required the coding of six new Java classes.The first two classes, X509PublicKey and X509PrivateKey, are just a reimple-

mentation of the RSA public and private keys.The X509CA class implements the CA. To this end, it derives the standard CA class and

implements the generateCertificate(Party subject, Key key) method whichtakes as input the identity of a party and his public key and returns a valid X.509 certificatefor that party. Digital certificates are implemented by the X509Certificate class which,in turn, derives the Certificate standard class and provides an implementation for the

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 287

getCertificationInfo( ) and verifyKey(Key key) methods. The first methodreturns the properties of the certificate and is used by GRACE for visualization purposes.The second method is invoked whenever a user tries to verify the validity of a certificate bydragging the public key of the CA, which is supposed to have released it, over it.

The last classes we implemented were X509Party, used to provide parties thecapability of generating pairs of RSA keys, and X509Window, needed for theinitializations of the PKI infrastructure.

8. Experimental study

Following the approach adopted by previous studies [9,19,20], we tested the effectivenessof our system by means of an empirical evaluation. We set up a controlled experimentconsisting of two variants of the same lesson taught to the students of the Security onCommunication Networks course at the University of Salerno during the fall 2004semester. The topic of the lesson was public-key cryptography and the RSA cryptosystem.The experiment was conducted using the learning medium approach (animation vs. noanimation) and, then, comparing the results of a post-test [19] between two groups ofstudents: one using the tool in the final part of the lesson, one using only text-basedmaterials.

The goal of the experiment was to verify if the task of recreating a cryptographicprotocol by means of GRACE could help students improve their comprehension of theprotocol. We defined to this end two learning tasks in our experiment: one related to thepublic-key cryptography topic and the other one related to the number theory topic.The first task was to understand who the parties of a public-key cryptographic protocolare, the role of the public and private keys and the way the cryptographic operationsassociated to these keys should be used to fulfill the protocol. The second was tounderstand the way the single cryptographic techniques used by the protocol work.

We expect the first task to be more easy to achieve as our system puts a strongeremphasis on the communication activity occurring in a cryptographic protocol. On theother hand, we believe that the need for the user to provide input values that are valid withrespect to the cryptographic primitives used by a protocol together with the simplevisualization of the elaboration performed by these primitives should improve also hiscomprehension of the numerical part of the protocol.

8.1. Experiment setting

A total of 52 volunteer students participated in the experiment. They were divided intotwo groups that we will refer to as group ‘‘A’’ and group ‘‘B’’.

The same lesson was given to both groups by the same teacher in two consecutivesessions with the help of some electronic slides. The content of the lesson was identical tothe content of the other lessons taught in past editions of the course. Students had all beengiven the mathematical background needed to understand public-key cryptography in aprevious lesson. The part of the lesson taught to group ‘‘A’’ with the help of electronicslides did not include any example of applications of public-key cryptography. Instead, inthe final part of this lesson, students were briefly introduced to our system and to its visualinterface. Then, they were asked to experiment with the RSA cryptosystem and to recreatesome of its application scenarios by using our system for 30min. On the contrary, the

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290288

lesson taught to group ‘‘B’’, including the discussion of some applications of public-keycryptography, was given entirely without using GRACE but only with the help ofelectronic slides.At the end of each session, students were given a test featuring five multiple-choice

questions with a time limit of 30min to answer them. The first three questions dealt withthe public-key cryptography related learning task, the other two questions dealt with thenumber-theoretic related learning task. In particular, the first question dealt with thecomponents of a communication scheme using public-key cryptography. The second andthe third questions dealt with the sequence of operations to be carried out in order tocorrectly encrypt and decrypt a message. The fourth question dealt with the theoreticcomputations of the RSA cryptosystem. The fifth question dealt with the admissible valuesfor RSA keys. During this test, students were not allowed to consult books or use anymaterials.

8.2. Results

During the experimentation, several students of group ‘‘A’’ were initially unable tocorrectly achieve the goal they were given. So, they had to repeatedly try to recreate theprotocol until the goal of the scenario was reached (e.g., the Alice’s document was safelydelivered to Bob). Such an engagement seems to have had a positive influence on theperformance of students in group ‘‘A’’ as they performed much better than students ingroup ‘‘B’’ on questions regarding the public-key cryptography learning task (see Table 1).This was especially true for questions number two and three, where the differences betweenthe two groups ranged from ten points to nearly twenty points. On the contrary, theperformance of the two groups on question number one was approximately the same. Sucha difference can be explained by considering that the first question was more general thanthe other two, and students did not derive any advantage from the visualization.We now turn our attention to the other two questions. Here we have a more balanced

situation. Group ‘‘B’’ performed slightly better than group ‘‘A’’ when answering questionnumber four, while its performance was worse for question number five. This seems tosuggest that the simple visualization of the computational steps performed by the RSAcryptographic primitives did not give students using visualization any advantage.Moreover, such behavior could also be explained by taking into considerations that therewas a gap of time between the teaching of number theoretical concepts and the executionof the test was 30min for group ‘‘A’’ (because of the GRACE experimentation session), sothat these concepts were already fading. On the other hand, students belonging to group‘‘A’’ were able to answer question number five better than students in group ‘‘B’’ probably

Table 1

Total percentage of correct answers to the questions answered by the two groups

Question Group A (%) Group B (%)

n. 1 81 81

n. 2 89 73

n. 3 77 46

n. 4 73 81

n. 5 23 8

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290 289

because they had the opportunity to interactively choose values for RSA keys that GRACE

could accept or reject with a proper explanation.

9. Conclusions

In this paper we presented GRACE, an educational tool that uses visualization tosupport the teaching and the understanding of cryptographic protocols. One of the mainadvantages of GRACE, with respect to existing visualizations of cryptographic protocols,is that it adopts an active learning model that engages the learner by asking him todescribe, in an exemplification of a real-world scenario, a cryptographic protocol using aset of cryptographic and non-cryptographic primitives. These primitives are not justsimulated, but effectively implemented, so that the user may see the effects of theirexecution on the working scenario.

The current implementation of GRACE includes support for several cryptographicprotocols and cryptographic techniques which are commonly taught in cryptography-related courses. Moreover, we have designed GRACE in a modular way so as to make iteasier to add support for new cryptographic techniques.

We also conducted some preliminary experiments in order to assess the benefits of usingvisualizations when teaching cryptographic protocols. The outcoming results seem tosuggest that students are able to better understand a protocol if they have been given thepossibility of recreating and experimenting with it, using a tool such as GRACE.

Encouraged by these results, we used GRACE more extensively in the 2005 and 2006editions of the Security on Communication Networks courses at the University of Salerno.In this context, both the teacher and students used GRACE. The teacher used it to presentcryptographic protocols and help students understand how they work and how theyprocess the input information. The students used it to watch the applications of acryptographic protocol presented by the teacher again as well as to experiment with it bytrying to recreate the same protocol from scratch using the primitives it provides.

Acknowledgments

The authors would like to thank Stefano Levialdi for an enlightening discussion onGRACE and the anonymous referee A for his valuable comments on this paper. Theauthors would also like to thank Barbara Masucci and her class of Security onCommunication Networks for their participation in our experiment.

References

[1] J. Gordon, The Alice and Bob after dinner speech, hhttp://downlode.org/etext/alicebob.htmli (April 1984).

[2] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography, second ed., CRC

Press, Boca Raton, 2001.

[3] D. Bishop, Introduction to Cryptography with Java Applets, Jones and Bartlett Publishers, 2003.

[4] Crytpography demos, hhttp://nsfsecurity.pr.erau.edu/crypto/index.htmli (August 2002).

[5] RSA demo applet, hhttp://cisnet.baruch.cuny.edu/holowczak/classes/9444/rsademoi.

[6] Protoviz—a simple protocol visualization, hhttp://www.cs.chalmers.se/�elm/courses/security/i.

[7] J. Zaitseva, TECP—tutorial environment for cryptographic protocols, Master’s Thesis, University of Tartu,

2003.

ARTICLE IN PRESSG. Cattaneo et al. / Journal of Visual Languages and Computing 19 (2008) 258–290290

[8] L.B. Resnick, Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser, Lawrence Erlbaum,

London, 1989.

[9] C.D. Hundhausen, S.A. Douglas, J.T. Stasko, A meta-study of algorithm visualization effectiveness, Journal

of Visual Languages and Computing 13 (3) (2002) 259–290.

[10] G.A. Agha, ACTORS: A Model of Concurrent Computation in Distributed Systems, MIT Press,

Cambridge, MA, 1986.

[11] Piccolo graphic library, hhttp://www.cs.umd.edu/hcil/piccolo/i.

[12] J. Raskin, The Humane Interface: New Directions for Designing Interactive Systems, Addison-Wesley,

Reading, MA, 2000.

[13] Java cryptography extension, hhttp://java.sun.com/products/jce/i.

[14] Data Encryption Standard, hhttp://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdfi (January 1977).

[15] DES modes of operation, hhttp://www.itl.nist.gov/fipspubs/i (December 1980).

[16] Advanced Encryption Standard, hhttp://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdfi (November

2001).

[17] R.L. Rivest, A. Shamir, L.M. Adelman, A method for obtaining digital signatures and public-key

cryptosystems, Communications of the ACM 21 (2) (1978) 120–126.

[18] R. Housley, W. Ford, W. Polk, D. Solo, RFC 2459: internet X.509 public key infrastructure certificate and

CRL profile, hhttp://www.ietf.org/rfc/rfc2459.txti (January 1999).

[19] M. Byrne, R. Catrambone, J.T. Stasko, Examining the effects of animation and predictions in student

learning of computer algorithms, Journal of Computers and Education 33 (7) (1999) 253–278.

[20] C.M. Kehoe, J.T. Stasko, A. Talor, Rethinking the evaluation of algorithm animations as learning aids: an

observational study, International Journal of Human Computer Studies 54 (2) (2001) 265–284.