Interfaces Verification Tool POS – Smart Card

Designing Secure Communication Protocol for Smart Card System, Study Case: E- Purse Application – Daniel Siahaan I Made Agus ISSN 1858-1633 2005 ICTS 47

4.1 Interfaces

In our e-purse system, the hardware and software interfaces look like those diagrams shown in Figure 19 and Figure 20, respectively. Figure 19 Hardware Interfaces. The terminal system consists of a personal computer which is connected with the Chip Drive via the USB port. Figure 20 Software Interfaces. The PCSC Personal Computer Smart Card, see [9] interfaces with the hardware. OCF Open Card Framework, see [10] provides a framework for inter- operable smart cards solutions used by the Terminal software. The Java applet running on the smart card uses the JCOP framework [11],[12]. IBM JCOP is an implementation of several open smart card standards like JavaCard™, GlobalPlatform and ISO 7816, 14443.

4.3 Verification Tool

In order to verify that the communication protocols used in the interfaces are indeed secure, we use a verification tool. There are a number of verification tools that implement certain verification method, such as CasperFDR, Isabelle, and CSP [1], [5], [7] and [8]. In the implementation of our e-purse system, we use CasperFDR as the verification tool. This tool provides a simple mechanism for user to check the authentication and secrecy of a communication protocol. It uses a custom input language specially tailored for security protocol checking. Furthermore, it has successfully tested a wide range of security protocol.

4.2 POS – Smart Card

For communication between the point of sales and the smart card, both sides need to be authenticated. In addition a secure session needs to be established over which messages can be sent. Iteration 0 In our first approach, we used the BKE Bilateral Key Exchange algorithm. The smart card represented by B and the POS terminal represented by A both have a public and private key pair PA, SA and PB,SB. The other party knows the public key. First, both parties authenticate and agree on a symmetric session key kab. This session key is used for the remaining communication. A Î B {na,A}{PB} A Í B {na,nb,B,kab}{PA} A Î B {nb}{kab} A Í B {OKNOK}{kab} With na, nb: Nonce; kab: session key, PL: public key of L; At this point both sides are authenticated, and a session key is available. We expected that we could use the session key without problems and verified this with Casper. A Î B {na,A}{PB} A Í B {na,nb,B, kab}{PA} A Î B {nb}{kab} A Í B {OKNOK}{kab} A Î B {m1}{kab} A Í B {m2}{kab} With na, nb: Nonce; kab: session key, PL: public key of L; m1,m2: message The message contains the function with arguments to execute, e.g. “Add25” The Casper analysis showed that a man in the middle could reuse messages that were sent encrypted with the session key. Iteration 1 To prevent this, we decided to send a sequence number along with the sent messages. In this way, reuse of sent messages can be detected. There are seemed to be an obvious way to model this in Casper. This is probably due to the possibility of infinity of the sequence numbers so it is hard for Casper to check the state space. As the solution, we modelled each sequence number as a different type. This time, no problems were found in addition, we modified the algorithm, so session keys are generated on the terminal side which is expected to have more computational power. A Î B {na,A,kab}{PB} A Í B {na,nb,B}{PA} A Î B {nb}{kab} A Í B {OKNOK}{kab} A Î B {message,0}{kab} A Í B {response,1}{kab} A Î B {message,2}{kab} Information and Communication Technology Seminar, Vol. 1 No. 1, August 2005 ISSN 1858-1633 2005 ICTS 48 A Í B {response,3}{kab} … … With na, nb: Nonce; kab: session key, PL: public key of L; message,response: message

4.4 Environment - POS