2008 International Conference on Information Security and Assurance

A Security Protocol Compiler Generating C Source Codes

Shinsaku Kiyomoto, Haruki Ota, and Toshiaki Tanaka KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino-shi Saitama 356-8502, Japan kiyomoto@kddilabs.jp

Abstract
In this paper, we propose a security protocol compiler that automatically generates security protocol modules based on a security protocol denition. Our security compiler loads a security protocol denition le that can be dened as a high-level specication of the protocol written in XML and it generates a C source code from the specication. Our security protocol compiler realizes fast C source code generation under 30 msec from the high-level security protocol denition. To implement the security protocol compiler on terminals, a security protocol can be modied or replaced easily in accordance with situations. Thus, the terminal is able to use several services without implementation of all security protocols for the services, and a vulnerable security protocol is can be replaced quickly.

1. Introduction
Ubiquitous is a key phrase for new generation IT services. In a ubiquitous network, multi-network, multidevice, and multi-services exist. Many services have been provided over communication networks such as the Internet and local communication. In these services, many security protocols that are used for authentication and key exchange are provided to ensure secure communication. The security protocols are designed to meet specic security requirements that differ from service to service. For example; when a mobile terminal communicate with a gate device in a public transportation system, a fast and lightweight security protocol is needed. On the other hand, when the device connects to an ATM or mobile banking services, a strict authentication protocol is required. If a terminal uses many services, the terminal will be required to handle numerous security protocols. On the other hand, security aws on security protocols are often found and they are updated by replacing entire security protocol programs with new ones. The replacement process usually incurs a high cost and is very time

consuming, even though a part of program should be modied. Thus, a fast and efcient method for replacing security protocols is needed in order to x security aws. Security protocol compilers have been researched in order to realize dynamic generation and modication of security protocols. The compilers generate source code or executable modules of security protocols from high-level security protocol denitions. Thus, a security protocol can be changed to input a protocol denition and execute the compilers where the compilers are implemented on the terminals. However, no compiler that generates C source code for high-level security protocol specications exists. The range of executable environments of generated protocols is expanded, if a security protocol compiler generates C source code. In this paper, we propose a new security compiler that automatically generates security protocol modules based on a security protocol denition. Furthermore, we implemented the security protocol compiler and evaluated transaction time and generated code size. To implement the security protocol compiler on terminals, a security protocol can be modied or replaced easily in accordance with situations. Thus, the terminal is able to use several services without implementation of all security protocols for the services, and a vulnerable security protocol can be replaced quickly. Our contribution is summarized as follows: We designed and implemented a security protocol compiler that loads a security protocol denition le and generate a C source code. The protocol denition le can be dened as a high-level specication of the protocol and it is written in an extensible and interoperable language XML. We evaluated our security protocol compiler and the compiler realizes fast C source code generation under 30 msec from a high-level security protocol denition. The paper is organized as follows: Section 2 introduces related work on security protocol compilers. Next, we present a security protocol compiler in Section 3. Evalu-

978-0-7695-3126-7/08 $25.00 2008 IEEE DOI 10.1109/ISA.2008.13

20

ation results are shown in Section 4. Finally, we conclude this paper in Section 5.

Security Protocol Compiler

2. Related Work
Languages for describing protocol specications have been studied. Estelle[3] is a major protocol language based on a nite state machine model. Estelle can be used for semi-automatic implementations of protocols[11]. However, existing reports address only limited protocols and the description is very complicated and difcult to dene high-level specications of security protocols. Prolac[5] is a statically-typed, object-oriented language for protocol specications. The Prolac compiler compiles a Prolac specication to a C code. The compiler can apply for several protocol specications; however, the language is similar to C. Thus, writing a Prolac code is similar to programming a C code. The Austin protocol compiler[8] transforms the protocol specication written in timed abstract protocol notation to an executable code. The tool is applicable to basic protocols without cryptographic computations. There are some compilers for generating security protocol implementations from high-level specications of security protocols. F. Muller and J. Millen proposed automatic Java code generation from CAPSL or CIL specication languages [9]. The tool is used for cryptographic protocols that only use symmetric key encryption. ACG (Automatic Code Generator) is a part of the AGVI toolkit[12] and is an automatic compiler that translates high-level specications of security protocols into Java source code. COSPJ[4] is a program that take a description of a security protocol in a simple, abstract language Casper[6] and it produces a Java source code of the same program. ACG-C# produces C# implementation codes for security protocols with Casper. Spi2Java[10] automatically generates Java code implementing cryptographic protocols described in the formal specication language spi calculus[1]. SPEAR II[7] provides Java code generation from an abstract protocol specication. These tools require that the protocol specication is described in specic languages. We cannot change the granularity of information such as the addition of detailed protocol information. Thus, the description lacks exibility for minor changes of the security protocol that caused by a variety of implementation environments such as cryptographic algorithm, padding rule, and initial values for variables. Furthermore, no compiler that generates C source code for high-level specications of security protocols exists. We present a security protocol compiler generating C source code from protocol specications that can be described as a high-level and exible specication written in XML language.

In this section, we introduce hypothetical examples of the use of the security protocol compiler, and then we explain the language for security protocol denition and the mechanisms of the security protocol compiler.

3.1

Examples of Use

The security protocol compiler loads a security protocol denition le and generates an executable module of the security protocol. Thus, a terminal dynamically adds or modies functions for authentication and key exchange, enabling the security protocol compiler to be used without the need to download new program les or patches. The protocol denition le is a text le written in XML, meaning that the download process is light weight and it is not necessary to download all the modied programs. Furthermore, it is readable and easy to check whether the le corresponds to the protocol specication. If the terminal downloads additional program modules, the terminal has to verify the program: for example, checking whether a computer virus is present. Generally, it is difcult to perform a complete check for an executable program. On the other hand, the validity of the protocol denition le is ensured using a digital signature of the ie and the content of the le is readable. The following are hypothetical examples of the use of the security protocol compiler; Dynamic Generation of Security Protocols The security protocol compiler dynamically generates a security protocol if a terminal uses a new service. When a terminal uses a service for the rst time, the terminal downloads a security protocol denition le and generates modules for authentication and the key exchange protocol that is specic for each service. The service providers can use their own protocols that are designed in accordance with their security and performance requirements. Replacement of Vulnerable Security Protocols When a security protocol found to be vulnerable, the administrator can replace the vulnerable protocol with a new secure protocol by using the security protocol compiler. The administrator rst makes a new security protocol denition le and sends it to all terminals and servers. The terminals and servers execute the security protocol compiler and replace the executable module of the security protocol. Temporary Modication of Security Protocols The security protocol compiler enables rapid and temporary modications of the protocol to be made. For

21

Figure 1. Protocol Denition File example, if a network manager nd signs that an attacker has inltrated is inside the ofce network, the manager can change the security level of the ofce network. In this situation, the manager changes current security protocols to security protocols that are designed for protecting the attacker; thus, the security protocol should be changed until the attacker is removed from the network. The manager sends a security protocol denition, which satises high level security requirements, to all terminals and servers to change the security protocol temporarily. After removing the attacker, the manager sends information to all entities and the terminals and servers change the security protocol to the former protocol that meets low level security requirements but is fast and convenient.

gard to adding and removing information; thus, the protocol specication can include not only a common high-level specication of the security protocol but also specic information for environments. This exibility allows compilers to be customized for particular environments such as smart card. The protocol denition le can be used for a range of security protocol compilers. We describe security protocols based on denitions of data, functions, and ows. A ow is described as all data sending by one transaction between 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 denition. Security protocols denition consist of several ows, and these ows consist of data and functions. Furthermore, we describe additional information in the protocol denitions, such as purpose of the protocol, information of entities on a header eld. The denition le includes information for all entities which execute the protocol. Our security protocol denition is divided into ve parts: Header Information Field The header information eld denes the purpose of a protocol such as authentication and key exchange, and security parameters. Entity Information Field The entity information eld stores information on each entity. Entity information includes which entity should be authenticated, role of the entity (initiator 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 exchange protocol, and the validation function info refers to a function for authentication whereby the entity computes the function to verify the authenticity of an entity. Data Information Field The data information eld is for denition 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 function definitions. Function information includes function identier, algorithm type, length of output, and input data. Function information optionally includes detailed information for a cryptographic algorithm such as OID and padding type. Flow Information Field All protocol ows and computations between ows are

3.2

Language of Security Protocol Denition

The protocol denition for our security protocol compiler is a high-level protocol specication written in XML language. The high-level denition is easy to write ows and calculations in the protocol and it is assumed to be independent from environments. XML is a standard language and widely used for several environments; thus, the protocol denition le has interoperability between several compilers that run on different environments. Furthermore, the XML description is easy to add specic information to the high-level protocol denition. For example, if they wish, protocol designers can describe detailed parameters such as parameters for cryptographic algorithms and initial values of variables. The description is highly exible with re-

22

Table 1. Data Information

Field Name data-id data type Man. Opt. mandatory mandatory Content Identier of data Data type selected from {Identier, Random, Text, Counter, Password, Symmetric Key, Public Key, Private Key, Temporary Public Key, Temporary Private Key, } Length of the data Name of creating the data: entity names or public Global name of the data that is used for other security denition les Related algorithm. This eld is mandatory, where the data is public key, private key, temporary public key, or temporary private key. Usage of the data (Initial) value of the data File name or pass to load the data as a initial value File name or pass to save the data when the protocol is nished For arbitrary description

length creator label algorithm

mandatory mandatory optional optional

Figure 2. Protocol Input GUI

usage value source store comment

optional optional optional optional optional

3.3

Protocol Input GUI

We create a program that is used to input a security protocol using a convenient GUI as shown in Figure 2. A designer of security protocol can easily input his/her protocol and generate protocol denition les in written XML.

written in the ow information eld. Flow information includes information of sender, receiver, and sending data and function.

3.4

Architecture of Terminal

The data type Identif ier, Random, P assword, Counter, and T ext indicates that the data is an identier 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 public key and private key generated in the protocol respectively. Functions for the security protocol are dened by information of function-id, input data, function type, and length of the output. Flows of the security protocol are described as information of ow-id, sender, receiver, and sending data and functions. Data and functions can be referred using data-id and function-id. A ow has a special label for dening action after receiving the ow. For example, a label for authentication indicates the ow that the receiver entity judges whether the sender entity is valid. A label for key exchange means that the receiver entity calculates a session key after receiving the ow. A function for each entity is dened as a special function calculating a session key in the entity information eld. An example of the protocol denition le is shown in Figure 1. A digital signature of a trusted third party is attached to the security protocol denition le, and we assume that the security protocol denition le is unforgeable and trusted.

Figure 3 shows the architecture of terminals that incorporate the security protocol compiler. We assume an application program runs on each terminal. A manager program provides protocol modication and execution function for the application program. A protocol denition le is input into the protocol compiler by the manager program. The protocol compiler is executed by the manager program and returns C source code to the manager program. The manager program then executes C compiler and makes an executable module from the source. After generating the executable module, the application program can execute a new protocol to call the executable module via a common API that the manager program provides. Thus, the application ignores the modication of security protocols. The executable program uses a cryptographic library to compute cryptographic algorithms. We dene interfaces to call algorithms in the cryptographic library. The interface is dened by types of cryptographic algorithm such as symmetric key encryption, hash function, etc. To identify algorithms, input information of the interface includes algorithm name or algorithm OID.

3.5

Automatic Generation of Source Code

Execution of the security protocol compiler consists of two steps: 1) the parsing and analyzing step, and 2) the source code generation step. The compilation process of

23

Protocol Definition

Protocol

Entity Entity

Entity Table

Entity

Application Program
Execute
Flow Flow
Function Table Flow Table

Flow

Manager Program
Protocol Definition C Source C Source OK Run Protocol

Function Function Data

Protocol Definition File

Function

Data Data
Data Table

Data Data

Executable Program Security Protocol Compiler C Compiler

Cryptographic Computation

Cryptographic Lib.

Figure 5. Generation of Table Files table. After storing pointer information, the compiler ascertains the relationships between data, function, ow, and entities. The compiler updates the index table using data tables. Next, the compiler generates six lists from the data and index tables: entity list, known data list, entity data list, function list, algorithm list, and ow list. The entity list stores the pointer information of the entities. The known data list indicates data that an entity knows before starting the protocol, and the entity data list stores pointer information of data that the entity generates during the protocol. The function list and ow list are the pointer information of functions and the ows of each entity, respectively. The algorithm list shows the algorithm identiers that are used for functions by an entity. The compiler generates run-sequence description from an entity ow list and an entitys information (key generation function info and validation function info). The description denotes the execution procedure of the protocol for the entity. 3.5.2 Source Code Generation Step In the second step, the security protocol compiler generates a source code for executing a security protocol. The compiler generates source code from the lists and tables shown in Figure 6. The compiler loads the algorithm and generates the information to be included by using the algorithm list. The compiler generates codes for initialization of variables and variable declaration based on the known data list and entity data list, respectively. Then, the compiler generates code function declarations and functions (cryptographic algorithms) call based on the function list. Next, the ow is translated into codes using the ow list. The codes for ows consist of data descriptions and functions that are included in the ow and call of send/receive functions. The send and receive functions that are pre-dened functions to send or receive data, which the compiler has. Finally, the compiler writes codes for the main body of a program using a run sequence description, and adds error handling codes to the end of the source code. The source code automatically includes check logics for input of invalid data in the protocol execution, which makes the source code secure. The logic checks lengths of data and data format to protect against attacks that an attacker

Figure 3. Architecture of Terminal

Protocol Definition File

Parse XML Structure

Update Index Table

Store into Data Tables

Generate Lists from Tables

Analyze Relationships between Data

Generate Source Code

Source Code Generation Step

Parsing and Analyzing Step

Source Code

Figure 4. Compilation Process the security protocol compiler is shown in Figure 4. A generated source code is input into a general compiler program such as g.c.c. and it is transformed into an executable modules. The details of each step are as follows: 3.5.1 Parsing and Analyzing Step

In this step, the security protocol compiler rst parses a protocol denition le and dividing it into nodes, and then generates data tables as shown in Figure 5. The compiler has four data tables: ow table, entity table, function table, and data table. Data, function, ow, and entity are stored in related data tables, along with related elements. Information on each data and entity are stored in one record of the data tables. Flow information is divided into sender information and receiver information and these are stored in different records. Information on functions is also divided into input and output information and they are stored in different records. Pointer information of all the data table records is generated and stored in an index table. Next, the compiler analyzes the relationship between them and stores pointer information in the corresponding record. For example, a function record stores pointer information of all data that is input into the function, and an entity record stores pointer information of all the ows that the entity sends and receives. Furthermore, the compiler assigns outputs of all functions with new data and stores the data into the data

24

Source Code Index Table Algorithm List Data Table Known Data List

Include

Variable Declaration & Initialization

Entity Data List

Function Table

Function List

Function Declaration Source Code

Flow Table Flow List Entity Table

for protocol generation. We also evaluate generated module sizes and protocol transaction time of the generated modules. The security protocol compiler realized fast source code generation of less than 30 msec, and the program sizes of executable les and transaction time of the running protocols were shown to be feasible for real services. A security protocol can be modied or replaced easily in accordance with situations, by using our security protocol compiler.

Flow Declaration

Acknowledgement
Body
Run-sequence description

Error Routine
Information Link Source Code Generation

A part of this work is supported by the National Institute of Information and Communication Technology (NICT).

References
Figure 6. Source Code Generation Table 2. Data Information
Protocol AKEP1 AKEP2 SSL like Gen. Time. (ms) 23.00 23.67 26.33 Program Size (KB) 99 97 108 Exe. Time. (ms) 445.67 322.00 599.00

alters sending data to overow buffers of an entity and try to execute invalid programs on the entity.

Evaluation Result

We implemented the security protocol compiler on PC Linux (2.4 GHz CPU 1GB Memory, kernel-2.6.18). We generated AKEP1[2], AKEP2[2], and SSL-like authenticated key exchange protocols using a public key encryption algorithm, and we evaluated the generation transaction time. Furthermore, we generated executable modules of the protocols using gcc-4.1.1 and evaluated the transaction time of executing the protocols and program sizes of the modules. The evaluation results are shown in Table 2. Transaction time of source code generation is less than 30 msec. The program sizes of executable les and the transaction time of running protocols is feasible for real services.

Conclusion

In this paper, we proposed a new security protocol compiler that generates a C source code from a protocol denition written in an extensible and interoperable language XML. The protocol denition is written as a highlevel specication and it is exible for environmentallydependent specications. We implemented the security protocol compiler on PC Linux and evaluated transaction time

[1] M. Abadi and D. Gordon. A calculus for cryptographic protocols the spi calculus. Inf. Comput., 148(1):170, 1999. [2] M. Bellare and P. Rogaway. Entity authentication and key distribution. In Proc. of CRYPTO 93, LNCS, volume 773, pages 232249. Springer Verg., 1994. [3] P. Dembinski and S. Budkowski. Specication language estelle. The formal description technique Estelle, pages 3575, 1989. [4] X. Didelot. A compiler for security protocols. Available at http://web.comlab.ox.ac.uk/oucl/work/ gavin.lowe/Security/Casper/COSPJ/s%ecu. pdf , 2003. [5] E. Kohler, M. F. Kaashoek, and D. R. Montgomery. A readable tcp in the prolac protocol language. In Proc. of SIGCOMM 99, pages 313. ACM, 1999. [6] G. Lowe. Casper: A compiler for the analysis of security protocols. In Proc. of 10th IEEE Computer Security Foundations Workshop, pages 1830. IEEE, 1997. [7] S. Lukell and C. Veldman. Automated attack analysis and code generation in a multi-dimensional security protocol engineering framework. In Proc. of Southern African Telecommunications Networks and Applications Conference 2003 (SATNAC 2003), 2003. [8] T. M. McGuire and M. G. Gouda. The Austin protocol compiler, Advances in information security, Vol.13. Springer Verg., 2004. [9] F. Muller and J. Millen. Cryptographic protocol generation from capsl. Technical Report SRI-CSL-01-07, SRI International, 2001. [10] D. Pozza, R. Sisto, and L. Durante. Spi2java: Automatic cryptographic protocol java code generation from spi calculus. In Proc. of 18th International Conference on Advanced Information Networking and Application (AINA04), pages 400405. IEEE, 2004. [11] D. Sidhu, A. Chung, and T. P. Blumer. A formal description technique for protocol engineering. Technical Report CSTR-2505, Univ. of Maryland, July 1990. [12] D. Song, A. Perrig, and D. Phan. Agvi automatic generation, verication, and implementation of security protocols. In Proc. of 13th Conference on Computer Aided Verication (CAV), pages 241255. Springer Verg., 2001.

25