ON-THE-FL

Y AUTOMATIC GENERATION OF SECURITY

PROTOCOLS

Shinsaku Kiyomoto, Haruki Ota and Toshiaki Tanaka

KDDI R & D Laboratories Inc., 2-1-15 Ohara, Fujimino-shi Saitama, 356-8502, Japan

Keywords:

Security Protocol, Automatic Generation, On-The-Fly Generation, Authentication, Key Exchange.

Abstract:

In this paper, we presented an automatic generation tool for authentication and key exchange protocols. Our

tool generates a security protocol deﬁnition ﬁle from input data of requirements for the protocol. The tool

constructs a new protocol that combines a pieces of security protocols as building blocks. The transaction

time of the tool is less than one second and it is able to realize more rapid generation of security protocols in

comparison to existing generation tools.

1 INTRODUCTION

1.1 Background

Ubiquitous is a key phrase often used in relation with

new generation IT services. In a ubiquitous network,

multi-networks, multi-devices, and multi-services ex-

ist. Many services have been provided over communi-

cation networks such as the Internet and local commu-

nications. In these services, there are many security

protocols used for authentication and key exchange

that realize secure communication. The security pro-

tocol is pre-deﬁned and installed in all entities before

entities commence to communicate. Secure commu-

nication with unknown entities is impossible where

both entities know no common authentication and key

exchange protocol. This is a disadvantage in terms of

the ﬂexibility of ubiquitous environments.

On the other hand, the design process of a security

protocol is often cumbersome and expensive. Even

though security protocols are carefully designed, se-

curity ﬂaws sometimes occur in the protocol. This

must be a serious bottleneck and poses a risk in the

construction of new services and may delay or halt

provision of such services. If the protocol is ﬂawed,

high costs might be incurred, due to forced redesign

and update process. The designer may not be able to

devise the optimal protocol for given system require-

ments. Namely, conservative designers might incor-

porate overly heavy functions just to ensure the pro-

tocols are secure. Thus, schemes for automatically

generating security protocols have been considered.

If both entities have a function to generate security

protocols automatically, the entities can communicate

with each other securely. The functions enable an en-

tity to communicate with any other entity at any time

and in any place, without previously sharing a com-

mon security protocol.

However, existing automatic protocol generation

techniques are impractical because the techniques re-

quire huge transaction time to generate a security pro-

tocol.

1.2 Our Contribution

In this paper, we propose a tool that is capable of

generating security protocols automatically. Our tool

generates two-party authentication and key exchange

protocols to combine medium-size building blocks

called components. Previous tools constructs secu-

rity protocols by randomly to choosing small blocks

for security protocols; the existing methods are not

suitable for fast generation of security protocols, be-

cause the methods have to check a huge number of

candidates constructed by the small blocks. Our tool

ﬁrst selects medium-size blocks in accordance with

requirements for protocol generation and constructs

a security protocol using selected blocks. The tool

also has an efﬁcient optimization process to avoid that

redundant ﬂows and data is remained in the gener-

ated protocol speciﬁcations. Thus, an efﬁcient secu-

rity protocol deﬁnition is produced by the tool, al-

though our tool constructs a security protocol using

the medium-size blocks.

Kiyomoto S., Ota H. and Tanaka T. (2008).

ON-THE-FLY AUTOMATIC GENERATION OF SECURITY PROTOCOLS.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 97-104

DOI: 10.5220/0001677500970104

 SciTePress

The transaction time of existing tools are from

several tens of second to several hours; however, our

tool realizes security protocol generation within one

second. Therefore, the tool is able to realize more

rapid generation of security protocols in comparison

to existing generation tools.

The remainder of this paper is organized as fol-

lows: Section 2 introduces works related to auto-

matic security protocol generation. Next, we present

a tool for generating security protocols automatically

in Section 3. Evaluation results are shown in Section

4. Finally, we conclude this paper in Section 5.

2 RELATED WORK

Automatic security protocol generation is divided into

two steps; the ﬁrst step is generation of a high level

protocol deﬁnition from security and performance re-

quirements, and the second step is source code gen-

eration from the protocol deﬁnition by means of a se-

curity protocol compiler. Programs for the ﬁrst step

denote tool, and programs for the second step denotes

compiler.

There are some compilers for generating imple-

mentations of security protocols that use crypto-

graphic algorithms. F. Muller and J. Millen pro-

posed automatic Java code generation from CAPSL

or CIL speciﬁcation languages. The tool is used for

cryptographic protocols that only use symmetric key

encryption. ACG (automatic Code Generator) is a

part of the AGVI toolkit(Song et al., 2001) and it is

an automatic compiler that translates the high level

speciﬁcations of security protocols into Java source

code. COSP-J(Didelot, 2003) is a security protocol

compiler that takes a description of a security pro-

tocol in a simple, abstract language, and produces a

Java implementation of the same protocol based on

Casper(Lowe, 1997). ACG-C# produces C# imple-

mentation codes for security protocols with Casper.

Spi2Java(Pozza et al., 2004) automatically generates

Java code implementation cryptographic protocols

described in the formal speciﬁcation language spi cal-

culus(Abadi and Gordon, 1999). SPEAR II(Lukell

and Veldman, 2003) provides Java code generation

from an abstract protocol speciﬁcation. These tools

require the protocol speciﬁcation to be described in

their speciﬁc language.

On the other hand, very little research has been

conducted on tools for automatic protocol generation.

A. Perrig and D. Song proposed an automatic pro-

tocol generation tool(Perrig and Song, 2000a). A

protocol designer inputs the speciﬁcation of the de-

sired security properties and the system requirements

and generates a high-level protocol deﬁnition using

the tool. The tool ﬁrst generates all protocols be-

low a given cost threshold inputted by the designer.

After sorting the generated protocols, the tool tests

them. If one protocol satisﬁes the desired proper-

ties, the generation process can stop. Otherwise, more

protocols are generated with an increase in the cost

threshold and they are tested again. They extended

their method so it can be applied for 3-party proto-

col and improve space reduction techniques of can-

didate protocols(Perrig and Song, 2000b). However,

their scheme is not efﬁcient because their scheme ﬁrst

generates many security protocol candidates and then

chooses one protocol to test if the protocol ﬁts the re-

quirements. S. N. Foley and H. Zhou proposed a be-

lief logic approach that allows entities to realize on-

the-ﬂy generation of security protocols(Zhou and Fo-

ley, 2003). Their automatic security protocol gener-

ator uses logic-based synthesis rules to guide it in a

backward search for suitable protocols from protocol

goals(Foley and Zhou, 2003). Their tool is more ef-

ﬁcient than the previous one; however, it is still too

slow for the dynamic generation of security protocols

because all possible states are searched to generate

sub-protocols, and the number of potential protocol

candidates is small because of binding free variables

only to formulae from known assumptions inputted as

a requirements for the security protocol. Furthermore,

detailed requirements have to be written in a special

language.

In this paper, we present a tool for automatic se-

curity protocol generation. The tool generates secu-

rity protocols from a small set of requirements using

a new approach whereby the tool constructs new pro-

tocols based on the components that are pieces of pro-

tocols.

3 AUTOMATIC SECURITY

PROTOCOL GENERATION

Generally, security protocols are designed taking re-

quirements for security and performance into consid-

eration. Our automatic protocol generation tool gen-

erates a security protocol based on the requirements

for the protocol. The requirements are inputted into

the tool, and the tool then automatically generates a

security protocol deﬁnition for security protocol com-

pilers. In this section, we ﬁrst explain the language

of security protocol deﬁnition; next, we present the

whole process of security protocol generation; ﬁnally,

we shows details of the selection process for compo-

nents and data sets in the generation process and gen-

eration process of session key generation functions.

ICEIS 2008 - International Conference on Enterprise Information Systems

Entity A Entity B

Flow

FunctionData

Figure 1: Flow, Function, and Data.

3.1 Language of Security Protocol

Deﬁnition

The protocol deﬁnition is a high-level protocol spec-

iﬁcation written in XML language. The high-level

deﬁnition makes it easy to write ﬂows and calcula-

tions in the protocol and it is assumed to be inde-

pendent from environments. Furthermore, the XML

description makes it easy to add speciﬁc information

to the high-level protocol deﬁnition. For example, if

they wish, protocol designers can describe detailed

parameters such as those for cryptographic algorithms

and the initial values of variables. The description is

highly ﬂexible with regard to adding and removing in-

formation for a basic security protocol deﬁnition gen-

erated by the tool; thus, the protocol speciﬁcation can

include not only a common, high-level speciﬁcation

of the security protocol but also speciﬁc information

for environments. This ﬂexibility allows compilers

to be customized for particular environments such as

smart card. The protocol deﬁnition ﬁle can be used

for a range of security protocol compilers.

We describe security protocols based on deﬁni-

tions of data, functions, and ﬂows as Figure 1. A ﬂow

is described as all data sending by one transaction be-

tween entities and information of sender and receiver.

A function indicates a cryptographic operation and it

is described as input data and algorithm name. Data is

minimum blocks to construct a security protocol deﬁ-

nition. Security protocols deﬁnition consist of several

ﬂows, and these ﬂows consist of data and functions.

Furthermore, we describe additional information

in the protocol deﬁnitions, such as purpose of the

protocol, information of entities on a header ﬁeld.

The deﬁnition ﬁle includes information for all enti-

ties which execute the protocol. Our security protocol

deﬁnition is divided into ﬁve parts:

• Header Information Field

The header information ﬁeld deﬁnes the purpose

of a protocol such as authentication and key ex-

change, and security parameters.

• Entity Information Field

The entity information ﬁeld stores information on

each entity. Entity information includes which en-

tity should be authenticated, role of the entity (ini-

tiator of the protocol or responder to the protocol),

and the data list that the entity knows before the

protocol starts. The information also includes key

generation function info and validation function

info. The key generation function info refers to a

function for generating a session key in a key ex-

change protocol, and the validation function info

refers to a function for authentication whereby the

entity computes the function to verify the authen-

ticity of an entity.

• Data Information Field

The data information ﬁeld is for deﬁnition of data.

Data information consists of data-id, data type,

length, creator, label, algorithm, value, usage,

source, store, and comment as shown Table 1.

• Function Information Field

The function information ﬁeld consists of func-

tion deﬁnitions. Function information includes

function identiﬁer, algorithm type, length of out-

put, and input data. Function information option-

ally includes detailed information for a crypto-

graphic algorithm such as OID and padding type.

• Flow Information Field

All protocol ﬂows and computations between

ﬂows are written in the ﬂow information ﬁeld.

Flow information includes information of sender,

receiver, and sending data and function.

The data type Identi f ier, Random, Password,

Counter, and Text indicates that the data is an iden-

tiﬁer of an entity, random number, password, counter

value, and other type of data, respectively. Temporal

Public Key and Temporal Private Key indicates that

the data are respectively a public key and private key

generated in the protocol.

Functions for the security protocol are deﬁned as

the function-id, input data, function type, and length

of the output. Flows of the security protocol are de-

ﬁned as ﬂow-id, sender, receiver, and sending data

and functions. Data and functions can be referred to

data-id and function-id. A ﬂow has a special label

for deﬁning action after receiving the ﬂow. For ex-

ample, a label ”for authentication” indicates that the

ﬂow is used when the receiver entity judges whether

the sender entity is valid or not. A label ”for key ex-

change” means that the receiver entity calculates a

session key after receiving the ﬂow. A function for

each entity is deﬁned as a special function calculating

a session key in the entity information ﬁeld.

3.2 Requirements for Security Protocols

Our tool generates security protocol deﬁnitions from

requirements for security protocols. The following

parameters are inputted to the tool as security protocol

requirements:

ON-THE-FLY AUTOMATIC GENERATION OF SECURITY PROTOCOLS

Table 1: Data Information.

Field Man. Opt. Content

data-id mandatory Identiﬁer of data

data type mandatory Data type selected from

{Identiﬁer, Random, Text,

Counter, Password,

Symmetric Key,

Public Key, Private Key,

Temporary Public Key,

Temporary Private Key, }

length mandatory Length of the data

creator mandatory Name of creating the data:

entity names or public

label optional Global name of the data that

is used for other security

deﬁnition ﬁles

algorithm optional Related algorithm.

This ﬁeld is mandatory,

where the data is public key,

private key,

temporary public key, or

temporary private key.

usage optional Usage of the data

value optional (Initial) value of the data

source optional File name or pass to load

the data as a initial value

store optional File name or pass to save

the data when the protocol

is ﬁnished.

comment optional For arbitrary description

• Trustworthiness of entities

This parameter indicates which an entity should

be authenticated. An entity omits the authentica-

tion process in the case where the other entity is

trusted. Thus, this parameter determines whether

the protocol is a single-authentication protocol or

mutual- authentication protocol.

• Number of ﬂows

This parameter indicates the maximum number of

ﬂows in the protocol.

• Known keys of entities

This parameter deﬁnes the keys that each entity

has. For example, the condition where two enti-

ties have a common shared key is described.

• Lists of available cryptographic algorithms in

each entity

This parameter shows a list of cryptographic algo-

rithms that an entity can compute.

• Security parameters

These parameters choose the security level re-

quired for the protocol and assumed adversary

models (attack). The security level is deﬁned as

the length of a secret key. The length of pub-

lic/private keys is reduced to the length of a se-

cret key using reduction tables in the protocol gen-

eration process. The lengths of other data such

as random numbers are also decided according to

the level. Our tool has three adversary models:

Known Key Attack, Forward Secrecy, Unknown

Key Share Attack. The ﬁrst model assumes that

the adversary can obtain previous session keys,

and the second model assumes that the adversary

can obtain the secret keys and/or private keys of

entities after the protocol is terminated. The pa-

rameters determine if the tool has to consider each

adversary model. The tool generates a security

protocol that achieves the security level by means

of semantic security of a session key and authen-

ticity under selected adversary models. Details of

adversary models are shown in the papers (Bel-

lare and Rogaway, 1994) (Bellare and Rogaway,

1995) (Blake-Wilson et al., 1997).

• Computational power of each entity (optional)

This parameter is optional. This parameter deﬁnes

the computational power of each entity. We deﬁne

the computational power to be one of three lev-

els: Low (assumed for mobile terminals or smart

cards), Medium (assumed for laptop PCs), High

(assumed for high-end servers). The tool selects

appropriate cryptographic algorithms and proto-

cols according to the parameters.

• Size restriction for one ﬂow in the protocol (op-

tional)

This parameter is optional. This parameter deﬁnes

the size restriction for one ﬂow. The tool decides

data and length of data in ﬂows and divides one

ﬂow into two ﬂows according to the parameter.

The two optional parameters used for execution

environments. For example, if the protocol has to

be used on a smart card, the protocol should be

lightweight and data size in one ﬂow is restricted.

The parameters are inputted as XML format data

to the tool.

3.3 Automatic Generation Procedure

In this subsection, we explain the whole process of se-

curity protocol generation. In our tool, security proto-

cols are generated to combine building blocks called

components. Speciﬁcations of components are de-

ﬁed using data sets. We can make several building

blocks to replace the data sets at the components. Fig-

ure 3 and Figure 4 show component overviews for

key-exchange and authentication protocols, and Ta-

ble 2 shows examples of the data sets. The automatic

protocol generation procedure is shown in Figure 2.

A protocol is generated from a ﬁle that describes the

ICEIS 2008 - International Conference on Enterprise Information Systems

100

Combining Components of

Key Exchange Protocols

Combining Components of

Authentication Protocols

Selection of Data Sets and

Addition of Requisite Data

Remove and Marge

Redundant Flows and Data

Choose Detailed Parameters

Requirements

for a Protocol

Protocol

Definition File

Figure 2: Automatic Protocol Generation Procedure.

requirements for the protocol. The process consists of

the following ﬁve steps.

1. Combining Components of Key Exchange Proto-

cols

This step combines components for constructing

key exchange protocols. The components include

four data ﬁelds X, Y , Z

, Z

as shown in Figure

3. The data ﬁelds X and Y denote transaction data

in each ﬂow and the data ﬁelds Z

and Z

indi-

cate data that is generated by an entity and held

by the entity. Data for Z

and Z

does not include

data sent in the protocol. The data set for the data

ﬁelds is selected in the next step. Usually, the tool

uses one component for key exchange protocols.

2. Combining Components of Authentication Proto-

cols

This step combines components for constructing

authentication protocols. The components include

two data ﬁelds V , W as shown in Figure 4. The

data ﬁelds V and W denote transaction data in

each ﬂow. For mutual authentication, two com-

ponents are combined. Data for V, W is selected

in the next step. If a protocol is required for mu-

tual authentication, the tool combines two compo-

nents: the component as Figure 4 and its reverse

component that perform the role of entity A and

entity B are switched.

3. Selection of Data Sets and Addition of Requisite

Data

This step inputs a data set to data ﬁelds of the

protocol generated in the previous step. The data

set is selected from many data sets of the key ex-

change protocol and authentication protocol ac-

cording to requirements for the protocol and se-

lection rules. Examples of data sets are shown in

Table 2. Rand and Rand

indicate random num-

bers, C indicates a time-variant shared value such

as a counter value, LK indicates a long-lived key

such as a shared key between two entities and a

private key or public key for each entity, and ∗

means no data, respectively. The function F(x) is

a one-way cryptographic function using a private

key or secret key such as MAC and digital signa-

ture, G(x) is a encryption function using a pub-

lic key or secret key, and H(x) is a key exchange

function such as the Difﬁe-Hellman algorithm.

Note that a function I(x) exists and the func-

tion satisﬁes the condition I(Rand, H(Rand

))=

I(Rand

, H(Rand)). An explanation of the selec-

tion procedure is provided in a later section. In

addition, some required data such as public key

certiﬁcates and identiﬁers are appended to the pro-

tocol in this step.

4. Remove Redundant Flows and Data

This step removes redundant ﬂows and data to

merge and move data. The step consists of ﬁve

sub-steps as follows;

(3-a) Check of similarity of data and merge them:

The tool searches for data that have the same con-

ditions, same sender and responder, same type

data or same type function, and same creator. If

two pieces of data satisfy the condition, the tool

merges one piece of data with the other piece of

data on a former ﬂow.

(3-b) Combine data: The tool searches for two

functions that are of the same type, that use the

same key and are calculated by the same entity,

and generates a new function provided the input

data of the new function is input data of both func-

tions. Then the tool replaces the function on the

former ﬂow with the new function.

(3-c) Move corresponding data: The tool ﬁnds

data corresponding to data and functions that were

removed in the previous sub-steps and moves

them to the former ﬂows. If data is sent by a ﬂow

is the same as the removed data, the data is moved

to a ﬂow that has merged data and functions or has

generated a new function. If data is sent by a ﬂow

that is one ﬂow before the ﬂow of removed data,

the data is moved to a ﬂow that is one ﬂow before

the ﬂow of the merged data and functions or com-

bined functions.

(3-d) Remove known data: Known data is data

that an entity has received previously or the en-

tity knows it at the beginning of the protocol. The

tool searches for data that are known data for the

ON-THE-FLY AUTOMATIC GENERATION OF SECURITY PROTOCOLS

101

Entity A Entity B

Figure 3: Component for Key Exchange Protocol.

Entity A Entity B

Figure 4: Component for Authentication Protocol.

receiving entity and removes the data from the

ﬂows.

(3-e) Remove ﬂows: The tool searches ﬂows that

have no data and functions and removes them

from the protocol.

5. Choose Detailed Parameters

This step chooses detailed parameters of the pro-

tocol such as data length, key length, and crypto-

graphic algorithm speciﬁcation, according to the

requirements for the protocol. Then, the tool gen-

erates a function for computing a session key.

3.4 Constructing Selection Rules

The tool selects one data set from data sets according

to selection rules. The selection rules indicate the

relationship between data sets and requirements.

The selection rules are similar to ﬁltering rules for

a ﬁrewall, and the rules reduce the number of data

set candidates according to the requirements. The

data set is arranged in priority order. Thus, the tool

selects the highest priority data set when two or more

data sets remain under a requirement for the protocol.

Examples of selection rules for Table 2 are described

as follows.

For Authentication. If authentication with one

ﬂow is required, the selection rule removes the No.1

data set and the No.2 data set for authentication.

If a message authentication algorithm and a digital

signature algorithm are not available for entity B, the

selection rule removes the No.1 data set and the No.3

data sets for authentication.

For Key Exchange. If Forward Secrecy is required,

the selection rule removes the No.1 and No.3 data

sets for key exchange and G(X) in the No.2 and No.4

data sets is restricted by public key encryption using

a temporal public key. If the protocol has to be secure

against a Known Key Attack, the selection rule re-

moves the No.1 and No.2 data sets for key exchange.

If the protocol needs security against Unknown Key

Share Attack, the selection rule removes No.1, and

No.2, data sets for key exchange. If entities have no

shared key, the No.1 and No.3 data sets are removed.

Data sets are also selected according to the per-

formance requirements. For example, if one-ﬂow key

exchange and an authentication protocol are required,

the tool excludes the No.1 and No.2 data sets for au-

thentication and the No.3, No.4, and No.5 data sets

for key exchange from the candidates. If entities have

a shared key and have low computational power, the

tool removes the No.5 data set for key exchange from

the candidates.

Our tool is easily extensible to several security

protocols. To add new data sets and selection rules,

the tool generates protocols suitable for new security

requirements that are currently unknown.

3.5 Selection of Key Generation

Functions

A key generation function is related to a selected data

set for key exchange. Table 3 shows the relationship

between selected data sets and key generation func-

tions. The tool generates a key generation function for

each entity by using the relationship. The functions

F(x) and F

(x) are one-way cryptographic functions

using a private key or secret key such as MAC and

digital signature, G(x) is a encryption function using

a public key or secret key, and H(x) is a key exchange

function such as the Difﬁe-Hellman algorithm. Note

that a function I(x) exists and the function satisﬁes the

condition I(Rand, H(Rand

))= I(Rand

, H(Rand)).

4 EVALUATION

We evaluated transaction time for security protocol

generation on a PC (Pentium 4 2.6GHz, 2GB RAM).

The evaluation results are shown in Table 4.

We evaluated three cases: generation of a mutual

authentication protocol, generation of a key exchange

protocol, and generation of an authenticated key ex-

change protocol. All transaction time is less than one

second. We obtained 2999 different protocol deﬁni-

tion ﬁles from 9828 different inputs of requirements

for security protocols. The protocol deﬁnition ﬁles

was categorized into 98 patterns of protocols.

ICEIS 2008 - International Conference on Enterprise Information Systems

102

Table 2: Example of Data Sets.

For Authentication

No. V W − −

1 Rand F(Rand) - -

2 G(Rand) Rand - -

3 ∗ F(C) - -

For Key Exchange

No. X Y Z1 Z2

1 ∗ Rand

, F(LK, Rand

) ∗ Rand

2 ∗ Rand

, G(LK, Rand

), F(LK

, G(LK, Rand

)) ∗ Rand

3 Rand Rand

, F(LK, Rand, Rand

) Rand Rand

4 Rand G(LK, Rand

), F(LK

, Rand, G(LK, Rand

)) ∗ Rand

5 H(Rand), F(LK, H(Rand)) H(Rand

), F(LK, H(Rand), H(Rand

)) Rand Rand

Table 3: Example of Key Generation Function.

Data Set Function for Entity A Function for Entity B

SK = SK =

No.1 F

(LK, Rand

) F

(LK, Rand

)

No.2 Rand

Rand

No.3 F

(LK, Rand, Rand

) F

(LK, Rand, Rand

)

No.4 Rand

Rand

No.5 I(Rand, H(Rand

)) I(Rand

, H(Rand))

Table 4: Evaluation Results.

Protocol Transaction Time

Mutual Authentication 398 msec

Key Exchange 617 msec

Mutual Auth. and Key Exch. 875 msec

Transaction time required by the APG to generate

mutual authentication and a key exchange protocol is

2 hours using a 400MHz CPU and the ASPB takes

20 sec to generate the protocol using a 1.8GHz CPU

(Zhou and Foley, 2003). Thus, we think that our tool

is fast enough to generate security protocols.

5 CONCLUSIONS

In this paper, we presented an automatic generation

tool for authentication and key exchange protocols.

Our tool generates a security protocol deﬁnition ﬁle

from input data of requirements for the protocol. The

tool constructs a new protocol to that combines a

pieces of security protocols as building blocks. We

also implemented the tool and evaluated the transac-

tion time of a security protocol generation by the tool.

The transaction time of the tool is less than one sec-

ond. It is able to realize more rapid generation of se-

curity protocols in comparison to existing generation

tools. Variations in generated security protocol de-

pend on the number of data sets in our tool, and the

number of potential candidate protocols may be re-

duced; thus, optimization of data sets for real services

is a further topic of study for these tools.

ACKNOWLEDGEMENTS

A part of this work was supported by the National In-

stitute of Information and Communication Technol-

ogy (NICT).

REFERENCES

Abadi, M. and Gordon, D. (1999). A calculus for cryp-

tographic protocols the spi calculus. Inf. Comput.,

148(1):1–70.

Bellare, M. and Rogaway, P. (1994). Entity authentication

and key distribution. In Proc. of CRYPTO ’93, LNCS,

volume 773, pages 232–249. Springer Verg.

Bellare, M. and Rogaway, P. (1995). Provably secure ses-

sion key distribution: thethree party case. In Proc. of

27th Annual Symposium on the Theory of Computing,

pages pp. 57–66. ACM.

Blake-Wilson, S., Johnson, D., and Menesez, A. (1997).

Key agreement protocols and their security analy-

sis. In Proc. of 6th IMA International Conference

on Cryptography and Coding, LNCS, volume 1355,

pages pp. 30–45. Springer Verg.

Didelot, X. (2003). A compiler for se-

curity protocols. Available at http://

web.comlab.ox.ac.uk/oucl/work/gavin.lowe/Security/

Casper/COSPJ/s%ecu.pdf.

Foley, S. N. and Zhou, H. (2003). Towards a framework

for automatic security protocols. In Proc. of Security

Protocol Workshop 2003, LNCS, volume 3364, pages

49–54. Springer Verg.

Lowe, G. (1997). Casper: A compiler for the analysis of

security protocols. In Proc. of 10th IEEE Computer

Security Foundations Workshop, pages 18–30. IEEE.

Lukell, S. and Veldman, C. (2003). Automated attack anal-

ysis and code generation in a multi-dimensional se-

curity protocol engineering framework. In Proc. of

ON-THE-FLY AUTOMATIC GENERATION OF SECURITY PROTOCOLS

103

Southern African Telecommunications Networks and

Applications Conference 2003 (SATNAC 2003).

Perrig, A. and Song, D. (2000a). A ﬁrst step towards the

automatic generation of security protocols. In Proc. of

Network and Distributed System Security Symposium

NDSS 2000, pages 73–83.

Perrig, A. and Song, D. (2000b). Looking for diamonds in

the desert – extending automatic protocol generation

to tree-party authentication and key agreement proto-

cols. In Proc. of 13th IEEE Computer Security Foun-

dations Workshop, pages 64–76. IEEE.

Pozza, D., Sisto, R., and Durante, L. (2004). Spi2java: Au-

tomatic cryptographic protocol java code generation

from spi calculus. In Proc. of 18th International Con-

ference on Advanced Information Networking and Ap-

plication (AINA’04), pages 400–405. IEEE.

Song, D., Perrig, A., and Phan, D. (2001). Agvi –automatic

generation, veriﬁcation, and implementation of se-

curity protocols. In Proc. of 13th Conference on

Computer Aided Veriﬁcation (CAV), pages 241–255.

Springer Verg.

Zhou, H. and Foley, S. N. (2003). Fast automatic synthesis

of security protocols using backward search. In Proc.

of the 2003 ACM Workshop on Formal Methods for

Security Engineering, pages 1–10. ACM.

APPENDIX

This appendix shows an example of a security

protocol generated based on requirements. The

requirements for the security protocol are as shown

in Table 5. The horizontal rows Purpose, Secu-

rity, Comp. Power, Algorithm, and Initial Key

respectively indicate the purpose of the protocol,

required security level and assumed adversary mod-

els, computational power of each entity, available

cryptographic algorithm for each entity, and keys

that the entities have before the protocol starts. The

protocol generated by the tool is described as follows.

STEP1 (A → B) : R

, Pub

, M

LKey

, Pub

)

STEP2 (B → A) : I

, R

, Enc

Pub

LKey

, R

, Enc

Pub

))

STEP3 (A → B) : I

, M

LKey

, R

)

The protocol is a mutual-authenticated key ex-

change protocol between an entity A and entity B.

The function M

(Y ) is a message authentication func-

tion of Y input with a key X using the Hmac-SHA256

algorithm. The function Enc

(Y ) is an encryption

of Y with a key X using the RSA-OAEP algorithm.

Pub

, Pri

are the temporal public key and corre-

sponding private key of RSA public key encryption

that is generated by entity A at the beginning of the

protocol. I

and I

are identiﬁers of the entity A and

Table 5: Requirements for a Security Protocol.

Requirements

Purpose Mutual Authentication

Key Exchange

Security 128-bit level security

Forward Secrecy

Secure against Known Key Attack

Unknown Key Share Attack

Comp. Power Entity A: High

Entity B: Medium

Algorithm Entity A: SHA256, Hmac-SHA256,

RSA-OAEP

Entity B: SHA256, Hmac-SHA256,

RSA-OAEP

Initial Key A Shared Key

Figure 5: Picture of Generated Protocol.

entity B. R

, R

, and R

are random numbers, and

LKey is a shared key between two entities. A session

key for both entities is Hs(R

, R

, LKey) in this pro-

tocol, where Hs(X ) is a hash value of X using SHA-

256 algorithm. The lengths of RSA keys are 2048

bits and a length of output of Hmac-SHA1 is 256 bits.

The lengths of random numbers R

, R

, and R

are

128 bits. Figure 5 shows a picture of the protocol in

the tool GUI.

ICEIS 2008 - International Conference on Enterprise Information Systems

104