OOTI - Group 2 - Loyalty Card Case

On the Inuence of Formal Methods in Developing a Java Card Application

Version 1.0

B.J.T. Golsteijn M. Iota C. Nair K. Sigdel

Contents
1 Introduction 2 System Overview 2.1 System Description 2.2 Requirements . . . 2.3 Assumption . . . . 2.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 4 5 5 5 6 6 6 7 7 7 7 8 8 8 8 9 10 10

3 Process 3.1 Planning . . . . . . . . . . . . . . . . 3.2 Gathering Requirements . . . . . . . 3.3 Designing Security Protocol . . . . . 3.4 Designing Card Applet and Terminal 3.5 Implementation and Testing . . . . . 3.6 Verication . . . . . . . . . . . . . .

4 Design 4.1 Security Objectives . . . . . . . . . . . . . . . . . . . . . . 4.2 Security Protocol . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Formal Analysis using Scyther . . . . . . . . . . . 4.2.3 Description using Finite State Machines . . . . . . 4.3 Applet Life Cycle Description using Finite State Machines

5 Implementation and Verication 11 5.1 Checking Applet Source Code using ESC/Java2 . . . . . . . . 11 5.2 Checking Terminal Source Code using JMLrac . . . . . . . . 13 5.3 Other Implementation Issues . . . . . . . . . . . . . . . . . . 13 6 Conclusion 14

Chapter 1

Introduction
The Formal Methods in the Software Life Cycle course is part of the PostMasters educational program provided by the Stan Ackermans Institute (SAI) of the Eindhoven University of Technology (OOTI program). The aim of this course was to do some programming using Java Card on smart cards. Another goal was to use a variety of state-of-the-art techniques for formal specication and analysis. Both this goals were used for the implementation of the security protocol and for the Java (Card) source code. To accomplish the given goals, a Loyalty Card application was developed. Its purpose is to provide a system that allows shops to oer its customers with bonus cards, with which they can collect loyalty points when they buy items at the store. When the amount of loyalty points is sucient, customers can use loyalty points to buy articles or get discounts at the shop. Besides providing an overview of the design and implementation of this application, this document presents the inuence of the formal modeling on the design and implementation of the Loyalty Card application. It shows where formal methods helped and where they did not. Also, it describes the experience with the various tools used during this project.

Chapter 2

System Overview
In this chapter a short overview of the loyalty card application which was developed is given. The main components of the system, together with their basic functionality is presented. Furthermore, the most signicant requirements, assumptions and constraints considered during the whole project are listed.

2.1

System Description

The main components of the system are: 1. Master Terminal. A master terminal is the place where loyalty card can be initialized, activated and deactivated. 2. Point-Of-Sale (POS) Terminal. A POS terminal is the place where loyalty points can be added to or removed from the loyalty card, after authentication of both the loyalty card and the POS terminal. 3. Loyalty Card. The Loyalty Card is a smart card that runs the loyalty applet. This applet takes care of validating the POS terminal and keeping track of the loyalty points. Each card has a unique ID.

Figure 2.1: System Overview

Loyalty Card

Design

The system provides the following basic functionality: Set-up secure communication between POS terminal and loyalty card Add loyalty points Remove loyalty points Return the number of stored loyalty points

2.2

Requirements

The basic requirements which came out for the given project are: Loyalty applet stores loyalty points POS Terminal instructs applet to add/remove loyalty points No unauthorized changes are allowed to the card balance

2.3

Assumption

The main assumptions made are listed below: 1. Terminals in the supermarket and Loyalty cards cannot be compromised 2. The system will not authenticate the user (PIN code is not required) 3. Customers do not have to acknowledge the actions on the card (they do not have to agree with the addition or the removal of the loyalty poits on/from the card) 4. When the maximum amount of points have been accumulated on the card, further additions are not possible 5. JavaCard and RMI are fool-proof with respect to memory leaks, security considerations etc

2.4

Constraints

1. The balance on a loyalty card is non-negative and integer 2. The maximum number of loyalty points that can be stored on a loyalty card is 216 1

Copyright c 2006 B.J.T. Golsteijn, C. Nair, M. Iota, and K. Sigdel

Chapter 3

Process
The process of developing the Loyalty Card application went through the following steps: 1. Planning 2. Gathering requirements 3. Designing the security protocol for mutual authentication 4. Designing the card applet and terminal 5. Implementation and testing 6. Verication These steps are discussed briey in the following sections.

3.1

Planning

A project plan was created containing an initial schedule, a list of deliverables and an overview of the available resources.

3.2

Gathering Requirements

After collecting the main user requirements for the Loyalty Card application, the main system requirements including security objectives for the system were identied. In addition, the assumptions and constraints on the system were specied.

Loyalty Card

Design

3.3

Designing Security Protocol

Based on the requirements, a security protocol was designed to provide mutual authentication and key exchange. The protocol was rst developed on paper. It was then modeled as a Scyther [4] protocol denition le. Scyther was then used to check for proof of correctness of the claims made in the protocol. The feedback from Scyther was used to improve the security of the protocol.

3.4

Designing Card Applet and Terminal

A Finite State Machine (FSM) describing the security protocol for the applet and terminal was created. In addition, for the applet, a FSM describing the applet life cycle was created. The interface between the applet and terminal were dened and described.

3.5

Implementation and Testing

The applet was implemented using Java Card[1] and the terminal using Java. During the implementation, some of the methods and elds were annotated using JML [7]. However, ESC/Java2 [5] and jmlc/jmlrac[2] were not used to test the annotations, as the annotations were not yet complete. Basic testing of the applet was done in parallel to implementation.

3.6

Verication

For verication of the security requirements, the applet and terminal were specied using JML. ESC/Java2 was used to check the applet and jmlc/jmlrac were used to compile and test the terminal code. The output from the tools was then used to improve the code and add more specication to verify that the implementation was correct with respect to the FSM for the security protocol and applet states.

Copyright c 2006 B.J.T. Golsteijn, C. Nair, M. Iota, and K. Sigdel

Chapter 4

Design
In this chapter, the design of applet, terminals, and their communication is described.

4.1

Security Objectives

The major security concern for the system is the mutual authentication between the POS terminal and the loyalty card. Customers should not be able to increase the number of loyalty points on their loyalty cards themselves, unless they buy products at the store. On the other hand, only customers in possession of a valid loyalty cards should be able to trade in loyalty points for benets. These observations lead to the following security requirements: The loyalty card needs to authenticate the POS terminal, in order to avoid fake terminals from increasing the balance on the card. The POS terminal needs to authenticate the loyalty card, in order to avoid the terminal from allowing fake cards to be used to obtain benets.

4.2
4.2.1

Security Protocol
Design

BKE [3] was not used for mutual authentication, because this would have required all terminals to have access to an up-to-date list of valid card public keys. Instead, a new security protocol was developed that provides mutual authentication without the need for terminals to know all valid card public keys1 . A graphical representation of this protocol in form of a message
1 If all terminals would need to know the encryption keys of all valid cards, either a centralized system with a central server is needed, or a (large) database of valid card encryption keys in each terminal. Both options are undesirable in this case.

Loyalty Card

Design

Figure 4.1: MSC of the used Security Protocol sequence chart (MSC) is shown in Figure 4.1. In this protocol, asymmetric encryption is used for authentication symmetric encryption is used for exchanging messages Both encryption keys and decryption keys are kept secret. Each card has a unique encryption/decryption key pair, whereas all terminals share the same encryption/decryption key pair. This makes sure that cards do not have to be updated or replaced when terminals are added or removed from the system. Furthermore, when when one card might get compromised, only that card has to be disabled and the security of the rest of the system is not in danger.

4.2.2

Formal Analysis using Scyther

Scyther [4] was used to verify the safety of newly developed protocol. During this verication, Scyther helped to make the protocol less vulnerable to attacks. It pointed out that the value of the used nonce had to change every time it is used in a message. On the other hand however, there were some problems using Scyther. The rst problem was the lack of documentation. Initially, it was very dicult to understand the input format and the graphical output from Scyther. Another problem was that due to the rather limited sanity checks on the input,
Copyright c 2006 B.J.T. Golsteijn, C. Nair, M. Iota, and K. Sigdel

Loyalty Card

Design

10

the program crashed several times while generating output. In the end, a protocol description resembling the new protocol was produced and this description was accepted by Scyther. A problem however was, that it was not possible to translate the complete protocol into Scyther format. The main problem was translating the meaning of the Card ID2 to Scyther. Therefore, Scyther could not provide a Proof of Correctness for all claims in the protocol description, but on the other hand, it could not nd any violations of these claims.

4.2.3

Description using Finite State Machines

The security protocol was also described as two FSMs, one for the applet part and one for the terminal part. The states in these FSMs represent the dierent stages in the course of the protocol run. These FSMs served as the basis for the implementation of both the applet and the terminal. Furthermore, these FSMs formed the basis for the formal verication of the protocol state transitions, which were specied using JML. More information about these specications can be found in the next chapter.

4.3

Applet Life Cycle Description using Finite State Machines

The applet life cycle is described as a FSM that describes the stages in the applet life cycle, as described in [6]. Figure 4.2 shows this applet life cycle.

Figure 4.2: Applet Life Cycle

CID, see Figure 4.1 for more information about the CID and the protocol in general.

Copyright c 2006 B.J.T. Golsteijn, C. Nair, M. Iota, and K. Sigdel

Chapter 5

Implementation and Verication

This chapter discusses the inuence of formal modeling on the implementation of the Loyalty Card application. This chapter describes the use of the Java Modeling Language (JML) [7] (and tools that support JML) to ensure that the Loyalty Card implementation correctly implements the applet life cycle and the protocol as described in the previous chapter. In this project, JML was used to formally specify the behavior of the applet and the security protocol. For this two dierent tools were used for JML specication - namely ESC/Java2 and run time assertion checker (jmlrac). The Loyalty Card applet was checked using ESC/Java2 and Loyalty terminal was checked using jmlrac.

5.1

Checking Applet Source Code using ESC/Java2

ESC/Java2 tries to prove correctness of JML specications at compile-time. The JML specication provides the possible values of the applet state and the guarantees the correctness of the protocol states. As shown in the following snippet of the code, ensures keyword checks for the previous appletstate and ensures the new appletstate in the applet life cycle is the correct. This helps to check the correct implementation of the applet life cycle.
\\@ ensures \old(appletState) == STATE_SELECTED ==> appletState == STATE_ACTIVE;

The same holds for the protocol renement and state implementation. As shown in the following snippet of the code, the JML helped to ensures the correctness of the protocol state and its implementation.

11

Loyalty Card

Design

12

\\@ ensures \old(protocolState[0]) == PS_MSG2_SENT ==> protocolState[0] == PS_KEY_ESTABLISHED;

On the other hand, there were lots of issues using the ESC/Java2 tool. ESC/Java2 was not very user friendly. The tool was not able to clearly explain the error messages and it was hard to gure it out what and where the actual error was. It took a while to be familiar with these error messages and after gaining some experience with them, the tool became more easy to use. Another issue was the cascading eect caused by changing the preconditions of the methods being called by other methods. For changing the precondition for one method required changing the preconditions of all methods that called that method. This can be explained more in detail from following snippet of code. The method desDecCipher requires precondition desDecCipher. initialized for the method implementation. However, it was necessary to provide this precondition from the method checkMessageIntegrity that called this method. And in turn it was also necessary to provide this precondition from the method removePoints that called checkMessageIntegrity.
//@ requires desDecCipher._initialized; private short desDecrypt(byte[] input, byte[] output) { ... desDecCipher.doFinal(input, (short) 3, encLength, output, (short) 0); ... }

//@ requires desDecCipher._initialized; private void checkMessageIntegrity(short increment, byte[] message) { ... short originalMessageLength = desDecrypt(message, temp); ... }

//@ requires desDecCipher._initialized; public void removePoints(short decrement, byte[] message) { ... checkMessageIntegrity(decrement, message); ... }

Due to the high quality of code resulting from regular testing and code review, very few bugs were found using ESC/Java2 and most of the time was spent to provide ESC/Java2 with correct annotations.

Copyright c 2006 B.J.T. Golsteijn, C. Nair, M. Iota, and K. Sigdel

Loyalty Card

Design

13

5.2

Checking Terminal Source Code using JMLrac

Jmlrac tries to prove correctness of JML specications at run-time. The experience of using jmlc/jmlrac was similar to using ESC/Java2. Ghost variables had to be used in one case to aid specication.Instead of throwing exceptions, null or false for example, were used as return value of some methods. This meant that it was not always interesting or easy to specify these methods using JML, except that the clients of the methods had to properly check the return value before continuing.

5.3

Other Implementation Issues

Programming the Java Card was rather dierent from regular Java programming. First of all, it took a while to get the development environment running, especially the communication with the card. Also, Java Card uses shorts instead of integers, can transmit only small messages, need a lot of conversions and is not ecient in randomly allocating the memory. Furthermore, there was limited support for cryptographic algorithms on the Smart Card. During the implementation of the security protocol, more issues appeared. It turned out that Java Card cannot encrypt blocks of data which are larger then 128 bytes (without padding) and even less with padding (176 bytes). The maximum length of messages that can be transmitted between the card and the terminal is 251 bytes when RMI is used. There was another problem encountered with dierent version of Java. Different Java versions were needed for dierent tools support. ESC/Java2 and jmlrac did not support JRE 1.5 and only could run with JRE 1.4. At the same time some cryptographic algorithms were not supported by JRE 1.4. A dierent cryptographic provider was required and the default settings for cryptography were dierent. Debugging Java Card software was tricky. The debugging of the Java Card was only possible with the simulation environment and not with the actual Java Card. However, this was discovered only towards the end of the project.

Copyright c 2006 B.J.T. Golsteijn, C. Nair, M. Iota, and K. Sigdel

Chapter 6

Conclusion
Formal methods are very useful in software development. Depending on the non-functional requirements of security, correctness etc, the usage of formal methods can help to achieve many good results, at the expense of additional eort initially. However, in most cases the eort spent in using these methods for the rst time pays back immediately. In the long term, these methods can provide signicant benets with respect to improving the quality of software.

14

Bibliography
[1] http://java.sun.com/products/javacards. [2] www.jmlspecs.org. [3] John A. Clark and Jeremy L. Jacob. A survey of authentication protocol literature. Technical Report 1.0, 1997. [4] C.J.F. Cremers. Scyther: Automatic verication of security protocols. [5] C. Flanagan, K. Leino, M. Lillibridge, C. Nelson, J. Saxe, and R. Stata. Extended static checking for java, 2002. [6] E. Hubbers, M. Oostdijk, and E. Poll. Implementing a formally veriable security protocol in Java Card. In Proceedings of the 1st International Conference on Security in Pervasive Computing, volume 2802 of LNCS, pages 213226. Springer-Verlag, 2004. [7] G. Leavens, A. Baker, and C. Ruby. Jml: A notation for detailed design, 1999.

15