INTEGRATION OF A SECURE MOBILE PAYMENT SYSTEM IN A GSM/UMTS SIM SMART CARD Ioannis G. Askoxylakis, Michael Pramateftakis, Diomedes D. Kastanis and Apostolos P. Traganitis Foundation for Research & Technology – Hellas Institute of Computer Science P.O.Box 1385, Heraklion, Crete, GR-71110 GREECE {asko, tragani,}@ ics.forth.gr,
[email protected],
[email protected] have nonetheless improved the prospects for a feasible electronic replacement for cash. One smart card application of particular interest to central banks is the electronic purse or wallet, which can be used as a means of payment for a variety of small-value purchases. Over the years a number of electronic cash schemes [2,3] have been proposed, which try to mimic today’s cash based schemes. There are a number of features that should be expected from these schemes. The basic features are outlined below. Security. The system should be at least as secure as the traditional cash payment system. Security is the most important characteristic for all economical transactions. It is of greatest importance, since even if a digital payment system is built, having the best user-friendly features, it will be condemned to failure if it does not fulfil this basic requirement. Anonymity. Privacy advocates believe that it should not be easy for a bank or governments to be able to trace information that maps the identity of an individual to a particular transaction. Otherwise it should be possible to monitor the activities of individual users and build profiles about their spending habits. On the other hand, from the point of view of governments, fully anonymity could be used as a tool by criminals for illegal activities such as money laundering. Off-line operation. The ability for two parties to complete a transaction without the intervention of a third party such as the issuing bank or an authentication server is a highly desirable feature. Scalability. There should be no reliance on a centralized architecture, as this can become a point of failure in the system. It also acts as bottleneck during periods of high usage. In order a scheme to be successful for mass deployment, it must be capable of distributed operation. A number of electronic payment schemes have been proposed in the past [2,3]. They can be classified in two broad categories. Schemes that are pure software solutions and do not make use of any specialized hardware like smart cards, and schemes that rely on secure hardware for their security. CAFE (Conditional Access for Europe) [4,5] was a project funded to develop banking organization in 1990, and in 1996, is an off-line smart card electronic-purse scheme that allows card-to-
ABSTRACT The idea of electronic money and the digitalization of economic transactions are appealing as a result of the nowadays’ technological evolution. Many proposals have been presented and several projects have been implemented in this direction, however there is still a long way ahead to widely commercially deployed applications. In this paper a new counter-based electronic payment system is introduced. Guidelines to that are high-level system security, user mobility, user anonymity, off-line operation ability, system scalability, and entity transferability. We introduce a new electronic purse application, with the corresponding payment protocol. The application mainly intends to serve subscribers of cellular networks, by enabling them to hold electronic means of money, and use it for commercial purposes. KEY WORDS Cryptographic Protocols and Applications, Mobile Commerce, Electronic Payment, Electronic Purse, Threshold Cryptography
1. Introduction The rapid technological evolution in the recent years led to massive growth and radical changes in many fields that affect society. Futurists have been speculating about several prospects. One of the predictions that became more frequent, following the introduction of the new technology of the smart cards in the mid-1970s, was the expectation for a future cashless society [1]. The term cashless society refers to the elimination of all forms of paper and coin based cash (physical cash) as an economical transaction medium, and its substitution with an electronic payments system scheme. In other words it is the digitalisation process of the classical payment scheme. While it is doubtful that physical currency will fall into disuse in the foreseeable future, growing familiarity with smart card technology and the substantial reductions in the unit production costs of smart cards in recent years a secure, anonymous, off-line electronic payment system. Mondex [5], which was developed at a major UK 589-047
40
Mobile Users. Numerically this is the biggest group of the system. Mobile users have an account with their network/service provider from which they can withdraw and deposit money. They also hold the electronic purse where they keep the withdrawn money. They can act both as payee and as payer entities and can realise transactions with merchants, as well as with each other. Merchants. This is the second biggest group of the system. Their characteristics as entities are identical to the mobile user entities. However, from a practical point of view, these entities do not need to be mobile since they represent typical trading stores, and they do not need to withdraw money from the network database since their role is mainly to collect money from the customers and to deposit it to a bank.
card transfer of electronic cash. Digital Cash [6,7,8] is an anonymous digital cash protocol, which is essentially an on-line software solution. Despite the efforts of the above-mentioned large-scale projects, there are several disadvantages that we should mention. CAFÉ uses strong cryptographic algorithms to enhance system security, does not support coin reusability, and it may face scalability problems under certain conditions. Mondex is a close scheme, as the company has not disclosed the details of the payment protocol, and does not support user anonymity. Digital Cash is an on-line system that can also face scalability problems, since the electronic coins can be spent only once. Other important projects include NetCheque [9], Netcard [10], MMPS [11] and Programmable Banknotes [12,13].
2.2 Electronic Purse
2. System Overview
2.1 System Entities
An electronic purse is defined as any card or function of a card, which contains real value in the form of electronic money, which someone has paid for in advance, which can be reloaded with further funds and which can be used for a range of purposes [16]. The electronic purse is intended to facilitate a variety of retail transactions and so is a clear substitute for currency. An electronic purse functions in many ways. A common way is the following: Monetary value is loaded onto the card, with a corresponding debit to the cardholder’s account at a financial institution. In a retail transaction, monetary value is transferred from the purchaser’s card into the merchant’s terminal in an off-line mode. The value of consumer purchases made with electronic purses would accumulate in the merchant’s terminal and would be transferred to the merchant’s account at a financial institution from time to time through on-line transactions. In the proposed payment system every end-user of the holds a cellular phone. A cellular phone consists of two elementary entities: the mobile equipment and the subscriber identity module card (SIM). The electronic purse is designed to be embedded on the SIM card. The electronic purse is an independent application with special structure and characteristics, which holds the currency in an electronic form. It also contains cryptographic keys that prove its validity and allow its activation for a transaction.
The entities that comprise the system are:
2.3 Transaction process
Bank Organisation. Maintains network accounts. It distributes and accepts money from the different mobile network providers. Mobile Service Provider. This is the most important entity in the entire system. It has many responsibilities and realises several operations. It holds information about all the system entities and their economic activities. It is responsible for the distribution of digital cash to end-users. It is also responsible for the acceptance of payments from end-users and point of sales terminals.
There are three types of transaction processes in the system. First there is the withdrawal process, where a mobile user requests electronic money from the network/service provider. If the user fulfils the necessary requirements, the provider proceeds and sends the requested money. The payment process is the system main function. Payment process enables every mobile user to send electronic money to other mobile users, carrying an identical e-purse application, and to Point of Sales Terminals (Merchants). PoSTs also carry an epurse application. Finally, there is the deposit process,
In this section an overview of the payment system is presented. It consists of a number of entities that communicate with each other in order to realise an economic transaction. At this point there is only a logical presentation and physical description of the entities and their communication interface. The system design principles are based on previous work of [14,15]. Fig.1 System Overview
41
where mobile users and PoSTs send the money on their purses back to the network database.
3.1 Electronic Purse Application (EPA) The electronic purse is an application integrated into the SIM card. The SIM is an entity that, from a logical point of view contains files according to ISO/IEC 7816 [18]. A similar file structure should correspond to the electronic purse. This file structure is depicted in Fig.2. We can observe four files and two directory levels under the Master File of the SIM.
3. Mobile Payment System Architecture In cellular networks, the subscribed user is uniquely identified by the Subscriber Identity Module card [17]. The electronic purse is a personalized application, since there must exist a direct mapping of each electronic purse application to its owner-subscriber. This consideration leads to the conclusion that such an application is should be SIM-based. Existing electronic purses can be distinguished into two broad categories, according to the form of electronic money that they hold. In the first category, money is represented in an electronic coin form, meaning that every coin of the system is a string of bytes, and is unique in the system. In the second category, money is represented by the value of a counter file. Due to the SIM memory constrains, the electronic purse was implemented in a counter-based form. Dealing with money demands high security requirements. A first approach is a comparison of the system to be built, with the traditional form of money and payments. Building a system at least as secure as the traditional one is essential for the future of the application. Another important requirement is user anonymity. The system has to be implemented in such a way that shall not allow any information, related to a legal payment procedure, to be extracted by any system entity. In this way the system users can be certain for the privacy of their transactions. On the other hand it should have the ability to trace illegal transactions the in same way is done with cash. The electronic purse application is intended to be integrated in an already existing module. Backwards compatibility, with the already existing applications is required as well. The electronic purse has to be an independent application in order to fulfil this requirement. Another expectation is off-line operation ability of the system. Two parties should be able to realize a transaction, without the need for intervention of any kind by an authority. Finally, the system should provide transferability, meaning that each entity can act both as payer and as payee, and user mobility, meaning that a payment procedure can be realized irrespectively of the physical location of the transaction pair. To summarize, this paper presents an electronic payment scheme, where the electronic purse is integrated in the GSM SIM module, it is counter-based and designed to fulfil security, user anonymity, off-line operation ability, user mobility, backwards compatibility, and entity transferability.
3.1.1 DF_EPURSE This is the dedicated file of the electronic purse. This file is logically located right under the SIM master file. DF_EPURSE provides an efficient grouping of all the application-related files. It can be accessed by the MF or any other DF of the same level. DF_EPURSE has an access condition value that must be fulfilled for function to be able to be performed to any of its elementary files. This value is different than the value of CHV1. The access condition value prevents any unauthorized user from using the electronic purse application. 3.1.2 EF_PURSE EF_PURSE is the elementary file that holds the digital cash. It has cyclic structure. The content of this file is a binary number. This binary number represents the currency of the purse. Like all the files at this level, EF_PURSE can be accessed only if the access condition value of the DF_EPURSE is fulfilled. The functions that can be performed on the file are READ_COUNTER, INCREASE_COUNTER, and DECREASE_COUNTER. Fig.2 SIM EPA
42
entity B. Every purse is a counter file. Before payment takes place, both purses-counters have an initial value. This is demonstrated in stage 1 of Fig.4. Without loss of generality, we can also assume that entity A wants to pay to entity B an amount of money. Assume that this amount has value m. A payment process has been successfully performed when it has reached stage 3 of Fig.4. At this stage the counter file of entity A has final value equal to the initial value minus m, and the counter file of entity B has final value equal to its initial value plus m. A payment process cannot be performed unless it passes through stage 2, which is in between stage 1 and stage 3. Stage 2 of Fig.4 provides a visual representation of the idea behind the transaction protocol. Both the Payer and the Payee entity are assigned a key by the application authority. In Fig.4 this key is Key A for entity A and key B for entity B. Each key cannot perform any operation on its own. However when these two keys-“shadows” come together, they built the transaction key K. When key K is built, the transaction process can take place. In other words, without the transaction key K, it is impossible for both electronic purses to change the value of their counter files.
3.1.3 EF_RSA This file has a linear fixed structure. It has two records, which contain a pair of RSA keys [19]. These keys are used during a payment process for message confidentiality. 3.1.4 EF_SHADOW This file has a linear fixed structure too. It can have one or more records containing shadows. Shadow is a term used in cryptography. This file is also required for the payment protocol. It serves security purposes. The “shadows” that this file contains are partial keys of a master key of a threshold scheme based on RSA [19] or elliptic curve[20,21,22] cryptography. The latter is very promising for smart card applications [23]. 3.2 Payment Process For the electronic purse application, there are only two types of system entities. The Sending (Payer) Entity, which sends the electronic means of money (pay), and the Receiving Entity (Payee), which receives it (get paid). In this way the system is more efficient to study and to implement. Each system entity can be either Payer or Payee during one payment process, but it can operate in both modes in different processes. Thus the transferability requirement is fulfilled.
Fig.4 A Payment Procedure
Fig.3 Payment General Structure
Fig.3 shows the general structure of the system. Sending and Receiving Entities can be a SIM card, a secure hardware of a Point of Sales Terminal, or the network/service provider. Sending and Receiving Application is the Electronic Purse Application (EPA). The transport mechanism can be the GSM/GPRS/UMTS [24,25], IrDA[26,28] and Bluetooth[27,28]. Currently we implement a new version that will also support WLAN and WiMAX. The only requirement for the transport mechanism is to provide a point-to-point secure connection between the transaction parties, which is supported by all mechanisms.
The introduction of stage 2 and the use of threshold asymmetric cryptography for the generation of the transaction key K is indispensable for the realization of a transaction and provides several benefits to the electronic purse application. The transaction key provides a means of linking the two electronic purses. This connection is necessary in every money transfer, since such a transfer requires two parties to be involved. Keys A and B provide each purse a way of application authentication (mutual authentication), meaning that if a purse application has a valid key, the application itself is valid. Thus there is no need for a centralized authentication authority during a payment process. This fact fulfils two of the basic requirements for the application: the requirement for off-line operation ability, and the user anonymity. Finally, the fact that both keys are required for the transaction provides security against unreliable
3.3 Main Idea The most important part for the application is the transaction protocol. Before going into details of the protocol, an introduction of its principles is necessary. We can imagine a payment process as Fig.4 shows. The payment always involves two entities each holding a purse. For a general case let these entities be entity A and
43
Finally on top of the TCP is the Electronic Purse Application EPA described in the previous section. This application enables the subscribers of a cellular network to realize cash transactions
users, which could attempt to increase the counter value of their purse without realizing a payment. Stand-alone change of the value of counter file is not allowed due to this specification. As the entire system has a lot more than two entities, and a basic requirement is that every entity should be able to interact with every other one in the system. There must be defined a way, to create a big number of keys, where any couple of them results to the same transaction key K. Asymmetric Threshold Cryptography solves this problem[29,30].
5. Transaction Control Protocol The transaction control protocol can be considered as a sequence of procedures, as shown in Fig.6. A procedure is a sequence of commands and responses exchanged between the Sending (Payer) and Receiving (Payee) Entities aiming to perform a well-defined, applicationoriented task. TCP includes three basic procedures, which are depicted in a chronological order at the left side of Fig.6. The fist procedure is the HANDSHAKE INITIATION. It is initiated by the Sending Entity, and it defines the beginning of a transaction process. Having performed this procedure successfully, the next procedure to be executed is the TCP PAYMENT PROCESS. This procedure consists of four other elementary procedures, presented at the right side of Fig.6.
4. EPA Layer Stack This section provides the protocol layering of the electronic purse application. We can distinguish three layers, as shown in Fig.6. Each layer serves the one above it. The lowest layer consists of three sublayers: The GSM/GPRS/UMTS, the IrDA and the Bluetooth. These are the three wireless mechanisms over which the application is designed to operate. According to the ISO layer standardization, this layer includes three ISO layers, the Physical, the Data-link, and the Network layer. These layers are required in order to provide a wireless, point-to-point, connection oriented, and error free link, between a Sending and Receiving Entity of the EPA. The existing specification and standardization of all three sublayers fulfil this requirement.
Fig.6 Transaction Control Protocol
Fig.5 EPA Layer Stack
The first procedure of TCP PAYMENT PROCESS is the CRYPTOGRAPHIC KEY AGREEMENT. This procedure provides a mechanism for data confidentiality. SHADOW EXCHANGE is the next procedure. At this point Sending and Receiving Entities exchange the shadows that they hold. MONEY ORDER is the next procedure, where the Sending Entity informs the Receiving about the amount of money that will be transferred. PROOF OF KNOWLEDGE OF K is the last procedure at this level. During this procedure both parties have proof that each other has a valid shadow, and consequently the payment process can take place. The last TCP procedure is HANDSHAKE CLOSE. After the protocol is successfully executed, this procedure terminates it. Figure 7 presents the message flow chart of the Transaction Control Protocol in detail. The design and implementation of the entire protocol has taken account of any message corruption by using appropriate message timers for each message pair and procedure timers (TPr) for normal execution of the entire sequence of the procedures.
Above the first layer is located the Transaction Control Protocol (TCP). It is designed to control a secure transaction process. It is the “heart” protocol for the EPA. The following sections provide a detailed description of the TCP design. Key components of TCP are Timers and Messages accompanied with Acknowledgments. Timers provide a means of time control during the execution of the protocol, Messages are the communication modules, and Acknowledgments, which are Messages, are used to inform the communicating Entities whether a Message has reached its destination. An important aspect for the design of TCP is protocol failure. Protocol failure may exist, due to link corruption. There is a study on protocol failure for each part of TCP. TCP can be integrated in the Transport Layer of OSI.
5.1 HANDSHAKE INITIATION HANDSHAKE INITIATION is the first procedure of TCP PAYMENT PROCESS. There are two messages exchanged during this procedure. Init is the message sent
44
procedures, will be encrypted according to the symmetric key K. A normal CRYPTOGRAPHIC KEY AGREEMENT procedure is shown in Fig.7, and works as follows: The Sending Entity selects an AES key K randomly and encrypts it by calculating Kesmod(n). Then it sets a timer T and sends the message. As soon as the Receiving Entity receives the message, it sets an own timer T, and raises the received message to the power of its encryption key er. Then it sends the message ((Kes) er)mod(n), which from the protocol point of view is an acknowledgment of Kesmod(n). As soon as the SE receives the message, it sets a new timer T and raises the message to the power of its decryption key ds. Result of this calculation is Ker. This is the message sent to the RE. When the message arrives to the RE, the RE sends back an acknowledgment to the SE, Ack(Kermod(n)), and calculates the AES key K by raising the received message to the power of its decryption key dr. From this point on, every message of a procedure is being encrypted before sent, and is being decrypted after it has been received.
by the Sending Entity to activate the Receiving Entity. At the same time a timer T is set. When the Receiving Entity receives Init, it sends back an acknowledgment message Ack(Init). In a normal procedure, this message arrives to the Sending Entity before the timer T expires. This way the HANDSHAKE INITIATION procedure has been successfully performed and the protocol can continue with the next procedure. Fig.7 TCP Message Exchange
5.3 SHADOW EXCHANGE AND MONEY ORDER SHADOW EXCHANGE and MONEY ORDER are two separate procedures of TCP PAYMENT PROCESS, they can be realized however in one procedure, as demonstrated in Fig.7. The first procedure is used for shadow exchange between the transaction entities, and the second one carries the money order of the SE to the RE. In normal operation the procedure begins with the transfer of the message ShA,m from the SE to the RE. ShA is the shadow of the SE and m represents the amount of money that the SE wants to pay. At the same time, the SE sets a timer Ts. When the RE receives the message, it also sets a timer Tr and responds by sending the SE its shadow ShB together with the money number m. After the SE receives the ShB,m it sends back an acknowledgment Ack(ShB,m).
5.2 CRYPTOGRAPHIC KEY AGREEMENT This procedure is employed in the TCP protocol, to provide message confidentiality between the Sending and the Receiving Entity. The operation of the procedure is according to a protocol devised by Shamir, but never published. With this protocol, two parties can communicate securely without any exchange of either secret or public keys in advance. The requirements of this procedure are that both Sending and Receiving Entity hold a pair of keys. For the Sending Entity the key pair is es ,ds and for the Receiving Entity the key pair is er ,dr. e denotes encryption key, d denotes decryption key, and the indicators refer to the Entity that holds each pair (s for Sending, r for Receiving). The encryption/decryption is done according RSA [18] public key cryptography. The goal of this procedure is to transfer a key K from the Sending, to the Receiving Entity. The key K is an AES symmetric key. Once K has been transferred to the Receiving Entity, all messages exchanged in the next
5.4 PROOF OF KNOWLEDGE OF KEY K This is the last procedure of TCP PAYMENT PROCESS. The procedure enables both parties of the transaction process to prove that they hold a valid shadow of the secret key K. The procedure is based on the challenge-response protocol method. There are two pairs of challenge-response messages. The first is denoted with ChallengeA-ResponseA and is initiated by the SE, and the second is denoted with ChallengeBResponseB and is initiated by the RE. Both challengeresponse communication pairs operate in a similar way. Challenge message The entity initiating the challenge-response generates a random number. If the initiating entity is the SE the number is denoted as xa, if it is the RE, the number is denoted as xb. The entity, which has already calculates the secret K of the electronic purse, by solving the
45
equation system using both the shadow received by the other party, and the shadows that it already holds, calculates the Challenge message according to the relation: Challenge = x⊕K, where ⊕ is the XOR operand. The challenges generated by the SE and RE are: • ChallengeA = KA⊕ xa (1) •
5.5 HANDSHAKE CLOSE This is the last procedure of the Transaction Control Protocol. When the procedure has been successfully performed, the money transfer from the SE to the RE is accomplished. HANDSHAKE CLOSE procedure provides a means of secure and successful TCP termination, by informing both the SE and the RE that all the protocol procedures have been successfully performed. It is initiated by the SE, which sets timer Ts and sends the message CloseA. As soon as the message is received by the RE, the RE sets timer Tr and sends CloseB back. CloseB acts as an acknowledgment message of CloseA. When the SE receives CloseB, it responds by sending the acknowledgment Ack(CloseB).
ChallengeB = KB⊕ xb (2)
Response message When an entity receives a challenge it generates the corresponding response. This is done by XOR multiplication of the challenge with the secret K that the entity has calculated: • Response = Challenge⊕K.
6. Identifying security weaknesses
The responses of the RE and SE are: • ResponseA=ChallengeA⊕KB •
The Transaction Control Protocol fulfils all the predefined requirements; however several cases can lead to system failure. The system is strongly based on the SIM card’s tamper resistance. However, should somebody manage to break it, he is able to introduce fake money to the system, without the system being able to detect him. This would lead to total system failure. Another more probable case is SIM card damage. In this case the system user loses his money, without the ability to prove the amount of money he was holding before damage occurred. Another disadvantage of the system is that it does not provide a way to the SE to prove that it has sent the amount of money during a transaction. In other words, if the payee claims that he was not paid after a transaction, the payer cannot prove the opposite even though the money is sent. Finally, there is a dangerous case for transactions, related to the protocol operation. It is known as the last message problem in communication protocols. The problem is located in the HASNDSHAKE CLOSE procedure, which is the last protocol procedure, and specifically in its last message. According to the protocol specification if the Ack(CloseB) is corrupted, the RE sends the previous message CloseB again, in order the SE to repeat the corrupted message. Assume the extreme case that Ack(CloseB) is corrupted and at the same time the connection between the SE and the RE is lost. Even if the RE sends the CloseB message, the message never reaches its destination. In this case the SE believes that the protocol was successfully executed, and the RE believes that the protocol failed. Consequently, the SE decreases its counter without the RE increasing it. It may be positive for the protocol that no new money is introduced to the system, still money can be lost. These are important problems the system faces and have to be resolved. At the same time the system requirements must be fulfilled. A solution to this problem is the introduction of Transaction Identification Number (TIN) in every transaction process, and the ability of the network provider to supervise the system.
ResponseB = ChallengeB⊕KA
If we use the equations of the challenges (1) & (2), the corresponding responses appear to be: • ResponseA = KA⊕ xa⊕KB (3) •
ResponseB=KB⊕ xb⊕KA (4)
If KA = KB (3) and (4) becomes: • ResponseA = xa⊕1 (5) •
ResponseB = xb⊕1
(6)
Equations (5) and (6) mean that if both sides have correctly calculated the electronic purse secret K, they shall both receive the same random number that they generated before the initiation of the procedure back. If one of the transaction entities is not able, for any reason, to calculate the right secret K, the procedure will fail and both entities shall be aware of it, since they shall both receive a different number than the random number that had generated in the first place. The normal operation of the procedure is demonstrated in Fig.7. The first challenge-response pair is initiated by the SE. It sets the timer Ts and sends ChallengeA. As soon as the RE receives ChallengeA, it initiates the second challenge-response protocol by sending ChallengeB. At the same time it sets timer Tr. When the SE receives ChallengeB, it calculates ResponseB according to equation (4), it sets a timer Ts and the procedure is continued by sending the message to the RE. As soon as the RE receives the message, it calculates the ResponseA according to equation (3), it sets the timer Tr and then sends the ResponseA. When the SE receives this message, it sends Ack(ResponseA), which is an acknowledgement of ResponseA. During the procedure each exchanged message after the first one, is considered a. acknowledgment of the previous message.
46
7. Transaction (TINs)
Identification
User B has withdrawn mb from the network operator and has paid m2 to user C, has been paid m1 from A, and m3 from D. User C has withdrawn mc from the network operator and he has paid m2 to user A and m1 to D, he has been paid m2 from B. User D has withdrawn md from the network operator and has paid m3 to A, m3 to B, and he has been paid m1 from C. The history file of user A contains -m1, TIN(A,B)m1, + m2, TIN(A,C)m2, + m3, TIN(A,D)m3 with:
Numbers
During each payment process, every corresponding entity creates a Transaction Identification Number. This number is stored by each entity, creating a transaction history module. It can be stored in an EF of the SIM card (in such a case the DFEPURSE specification must include one more EF with linear fixed structure), or it can be stored in the memory of the Mobile Equipment. The TINs are stored according to two modes. When an entity receives money (gets paid) it stores the corresponding TIN in a memory space that it is designated to hold TINs for received money. In case of SIM storage of TINs, this memory space can be an elementary file with linear fixed structure EFRMTIN (RMTIN stands for Received Money TIN). When an entity is sending money (pay), it stores the corresponding TIN in memory space designed to keep TINs of transactions, which occurred while sending (paying) money. The corresponding EF in case of SIM storage is EFSMTIN (SMTIN stands for Sent Money TIN). The network provider can control the entire payment system in the following way: the network provider has full knowledge about the money that each subscriber has withdrawn. Periodically, the provider requests information from the users that shall enable him to control the payment system operation. It requests all the users to provide their purse currency (the amount still on their purse), and their transaction history, meaning all the amounts of money that they have exchanged with other users. For example if user A has withdrawn an amount m from the operator, and has paid an amount m1 to user B, received m2 from user C and m3 from user D, he has to send the numbers m, -m1, +m2, +m3. The Transaction Identification Number TIN must be added to the numbers corresponding to a transaction where the user got paid. Under this condition the entire message becomes: m, m1, m2TINm2, m3TINm3. A minus in front of the message denotes that the amount has been paid to another user and therefore the counter of the electronic purse has been decreased. The message contains the positive values escorted with the corresponding TIN, and the negative values by themselves. This way the network operator is not able trace a transaction by comparing identical TINs. There is no loss of anonymity by sending the TIN, because the network operator cannot extract the shadows from a TIN, since he only knows the shadow of the user sending the information, and not the other shadow and the AES key used during that transaction. In the same way all the users send their history files to the network operator. Without loss of generality, we assume that there are four users in our system, which are A, B, C, D. The transactions realized in the system are:
TIN(A,B)m1=ShA⊕ShB⊕KAES1. TIN(A,C)m2=ShA⊕ShC⊕KAES2. TIN(A,D)m3=ShA⊕ShD⊕KAES3.
(7) (8) (9)
The history file of user B contains +m1, TIN(B,A)m1, m2, TIN(B,C)m2, + m3, TIN(B,D)m3 with: TIN(B,A)m1=ShB⊕ShA⊕KAES1. TIN(B,C)m2=ShB⊕ShC⊕KAES4. TIN(B,D)m3=ShB⊕ShD⊕KAES5.
(10) (11) (12)
The history file of user C contains -m1, TIN(C,D)m1, m2, TIN(C,A)m2, +m2, TIN(C,B)m2 with: TIN(C,D)m1=ShC⊕ShD⊕KAES6. TIN(C,A)m2=ShC⊕ShA⊕KAES2. TIN(C,B)m2=ShC⊕ShB⊕KAES4.
(13) (14) (15)
The history file of user D contains –m3, TIN(D,A)m1, +m3, TIN(D,B)m3, + m1, TIN(D,C)m1 with: TIN(D,A)m1=ShD⊕ShA⊕KAES3. TIN(D,B)m2=ShD⊕ShB⊕KAES5. TIN(D,C)m1=ShD⊕ShC⊕KAES4.
(16) (17) (18)
During the network request procedure, users send the following messages: User A: ma, m1, m2 TIN(A,C)m2, m3 TIN(A,D)m3 User B: mb, m2, m1 TIN(B,A)m1, m3 TIN(B,D)m3 User C: mc, m1, m2, m2 TIN(C,B)m2 User D: md, m3, m3 TIN(D,B)m3, m1 TIN(D,C)m1 The network checks the initial counter values, adds all the received values ma, mb, mc, md and then adds all values corresponding to transactions. For this example this is done in the following way: SUM = (-m1+m2+m3)+(m2+m1+m3)+ + (m1m2+m2)+(m3+m3+m1) The first parenthesis corresponds to the information sent by user A, the second to the information of user B, the third to the information of user C and the fourth to the information of user D. In a normal case, where there has been no attack to a counter file of a SIM electronic purse
User A has withdrawn ma from the network operator and he has paid m1 to user B, he has been paid m2 from user C and m3 from user D. 47
or there was no money loss due to the last message problem of the TCP protocol, the SUM is equal to zero. In case there was been an attack at a counter file, either the initial value of the counter has been increased, or a positive value m in the form of a transaction has been added. The first is easy to check, by comparing the values of the withdrawn money from the users, to the values sent after the network request. There are two ways of attack related to the second case. Either the attacker has sent a transaction value m with a corresponding fake TIN, or he has sent the value alone. If the value m has been sent alone, it is easy to be traced, since the specification demands that every positive value has to be sent with the corresponding TIN attached. The case where the attacker has attached a fake TIN is more difficult to deal with. However in such a case the SUM is a positive number. As soon as the network finds out that the SUM value is positive, it initiates a procedure in order to trace the fake money. It first calculates the SUM values for transactions with identical money exchange, SUM1, SUIM2, SUMm, ….., SUM max. The number 1 denotes one coin (the counter values during such transactions been changed by 1), 2 denotes two exchanged coins, and max denotes the maximum transaction allowed by the system. In normal operation all these SUM values should be zero. If there have been to the system with certain amounts of fake money introduced, the corresponding SUMs shall be positive. For example, if an attacker introduces 123 coin to the system, SUM123 shall be 123 instead of zero. While the system has no special knowledge of the TINs attached to each transaction value, the only information that is extracted is the group of users, which includes the attacker. Up to this point the system operates anonymously. In the next step, the network/service provider requests from all users, which have paid the same amount (in our example 123), to send the corresponding TIN. It is useful to recall that the payee entity of a transaction does not send the corresponding TIN in the first place. At this point the anonymity of transactions that have been realized with this value is lost but the network operator is now in position to find out the honest users and therefore trace the attacker. Another case is money loss due to the problem of the last message of the Transaction Control Protocol. In this case the purse of the payer entity is reduced by m, without the purse of the payee entity to be increased. However, money is not completely lost, it is only disabled. According to the already described scheme, the network provider requests the contents of history file of all the users. When the provider calculates the SUM value, the result will be negative. Next step is to find which transaction value corresponds to the negative result. At the same time, the user holding disabled money has to contact the provider and inform him accordingly. The network checks whether there is correspondence to the user’s claim. If there is, the user is given the new money amount in place of the disabled one.
8. Implementation Aspects The implementation part of this research work is divided in three parts. The first part is the implementation of the file structure of the electronic purse application in a smart card with SIM characteristics. The file structure is implemented according to Fig.2. The second part refers to the implementation of part of the necessary software, required to handle the corresponding SIM files. The last part deals with the realization of a shadow generator. Fig.7 presents the main idea behind EPA and TCP software development, Fig.8 depicts the main menu of the application and an example of a payment process. Future plans include the integration of our system in Java cards [31] in order to extend it to PDAs/Laptop users that use 802.11 technology and the development of the corresponding Applet system, according to [32]. Fig.7 Software Development
9. Conclusion This paper introduces a novel payment system. It intends to facilitate subscribed users of cellular networks by enabling them to act as economical entities with the ability to realize transactions. This is possible with the proposed electronic purse application, an application designed to be SIM integrated, in conjunction with the transport control protocol TCP designed to be added to the existing mobile equipment operation system. EPA provides a means of digital money storage, while TCP provides the interconnection required between two EPAs, for the payment process. The payment system is designed to incorporate several features required for the deployment of a successful transaction tool. Security is a crucially significant one. The level of security accepted for a digital payment system can only be defined by comparing the system security with the classical payment scheme. The security of the classical system is based on a combination of disclosed security issues like the type of paper and ink used for money, the watermarking details etc, and the high-tech mechanical implementation coming along with it. However, this is not security in terms of cryptology. If an attacker has the corresponding knowledge and equipment, he can cause immense and irrecoverable damage to the entire system. As this is very difficult, the
48
authentication takes place during the PROOF OF KNOWLEDGE OF SECRET K process. Off-line operation ability denotes anonymity during a payment process. Besides the GSM/GPSRS/UMTS carrier, the system is designed to operate over IrDA, Bluetooth while current research focuses on the extension to WLAN(802.11) and WiMAX wireless technologies. All these mechanisms make the payment system scalable. This way traffic load is shared among all mechanisms and reduces the possibility of bottleneck phenomena appearing during periods of high system usage. An additional feature of the payment system due to the many communication mechanisms is user mobility. A transaction can be realized everywhere when IrDA or Bluetooth is employed as far as the transaction parties are physically close enough, and everywhere in the network coverage area, if GSM/GPRS/UMTS is used. Transferability is another system characteristic. A system entity can act both as payer and as payee, within the same application. Limitations of the payment system include the transaction identification numbers used for network control of the system result to computational overload from the network point of view. They increase the traffic load of the system and require extra memory allocation in the EPA, especially in cases that a mobile user wants to realize many transactions. Anonymity is further problem; in case of system attack many honest users may lose their anonymity for the sake of tracing down the bad guy responsible. SIM is considered as a secure hardware but there are always ways for hardware attack. TCP is a protocol sheltering many procedures which themselves consist of a plethora of exchanged messages. In conjunction with the TCP real time operation requirement appears to be quite demanding, should the transaction be completed in a reasonable time. Finally TCP faces the last message problem - even if money is not lost, it is disabled for some time. Although this does not pose any harm to the system, users will most likely find this situation very annoying, as their money is temporarily freezed. The question arises, if this suggested payment scheme is viable in the real world. Quick, easy and safe transactions anywhere and anytime in every-day life - the purpose of the system in the first place – will probably meet broad approval by the public, especially since millions of people are already acquainted and satisfied by GSMprovided services. The enhancement of those services with a financial transaction capability is certainly not a giant leap, at least conceptually, for everyone who owns a cellular phone. In many cases, it is even expected. Besides, one shouldn’t omit the fact that most marketing experts agree on: successful mass deployment of a new product mainly depends on user familiarity rather than pure quality. The technology involved may guarantee safe, fast and reliable operation in most cases; still, it is not bulletproof. This leaves a considerable amount of research to be done, in order to find the correct balance between safety
classical system operation is still efficient and functional. Security is based on the tamper resistance of the SIM card, on TCP security, and on network control of the entire system. TCP security is based on RSA confidentiality, and on threshold cryptography authentication. Fig.8 Main Menu and Payment example
Compromising TCP confidentiality is as difficult as attacking RSA (key length 1024). Combining it with the threshold cryptography scheme, it becomes even harder. Attacking the SIM card is easier. There are several ways of chip card attacks. Most important is destructive reverse engineering of the silicon circuit, including the contents of the ROM. This attack uses electron beam lithography. The corresponding technology is expensive and only few organizations worldwide posses it. Even if the SIM is compromised, the system does not collapse due to network system control. The network provider has the ability to check the system transaction via the transaction identification number. However tracing of fake transactions cancels transaction anonymity. Anonymity is another important required feature. The proposed system is fully anonymous during normal operation. No entity outside the transaction pair can extract information related to a transaction. However in case the system is attacked or money of a purse has been disabled due to the last message protocol problem, anonymity is lost. At this point it is important to mention that governments do no accept payment systems that do not have the possibility to trace a transaction under certain conditions. Anonymity revealing under certain conditions, provides a means of defence against economic crimes. Another characteristic of the payment system is that it features off-line operation. The system users realize transactions without the need for intervention of the system authority. The connection of two EPAs during a transaction is of point-to-point nature. EPA mutual 49
[16] Susan Stepney. David Cooper. Jim Woodcock, An Electronic Purse. Specification, Refinement, and Proof. Technical Monograph PRG-126. ISBN 0–902928–41–4 [17] ETSI ETS 300 922, Digital cellular telecommunications system; Subscriber Identity Modules (SIM); Functional characteristics, GSM 02.17 version 5.0.1, 1997 [18] International Standardization Organization ISO (http://www.iso.ch) standards ISO/IEC 7816-1, ISO/IEC 7816-2, ISO/IEC 7816-3, ISO/IEC 7816-4 [19] R.Rivest, A. Shamir, L. Adleman, A Method for Obtaining Digital Signatures& Public-Key Cryptosystems, Communications of the ACM, 1978 [20] Kiyomichi Araki, Takakazu Satoh, Shinji Miura, Overview of Elliptic Curve Cryptography, PKC98 proceedings, Lecture Notes in Computer Science Vol.1431, 29-49,bSpringer-Verlag, 1998 [21] N.Koblitz, A Course in Number Theory and Cryptography, 2nd edition Springer-Verlag, 1994 [22] A. Menezes, T. Okamoto and S. Vanstone, Reducing elliptic curve logarithms to logarithms in a finite field, IEEE Transactions on Information Theory, 39, 1639-1646, 1993 [23] D.Kastanis, I. Askoxylakis, A.Traganitis, An efficient authentication scheme for contactless smartcards using elliptic curve cryptography, Third IASTED International Conference on Communication, Network, and Information Security, Cambridge, MA, USA. IASTED/ACTA Press 2006, ISBN 0-88986-636-8, pp28-33, 2006 [24] ETSI ETS 300 608, Digital cellular telecommunications systems (Phase2)- Specification of the Subscriber Identity Module-Mobile Equipment (SIMME) interface, version 4.21.1, 1999 [25] ETSI TS 101 180, Digital cellular telecommunications systems (Phase2+): Security mechanisms for the SIM Application Toolkit; Stage1, GSM 02.48, version 7.0.0, 1998 [26] Infrared Data Association, Specification for Ir Mobile Communications (IrMC), version1.1, Mar 1999 [27] R. Mettala, Bluetooth Protocol Architecture, 1999 [28] D. Suvak, IrDA and Bluetooth: A Complementary Comparison, Extended Systems Inc. [29] Y. Desmedt, Y.Frankel, Threshold Cryptosystems, Advances In Cryptology – Crypto’89 (Lecture Notes in Computer Science 435) Springer-Verlag, p.307-315, 1990 [30] Y. Desmedt, Y.Frankel, Shared Generation of Authenticators and Signatures, Advances In Cryptology – Crypto’91 (Lecture Notes in Computer Science 576) Springer-Verlag, pp457-569, 1992 [31] Chaumette, S., Markantonakis, K., Mayes, K., Sauveron, D.: The Mobile Java Card Grid Project. In Proceedings of e-Smart 2006, Nice, France, 2006 [32] Fabrizio Baiardi, Alessandro Falleni, Riccardo Granchi, Fabio Martinelli, Marinella Petrocchi, Anna Vaccarelli: SEAS: A Secure E-Voting Applet System. 318-329 2nd International Symposium on Software Security, Tokyo 2003
and efficiency. However, this work moves away from the technical scope and more towards the field of IT risk management.
References [1] Garcia-Swartz, Daniel D. Hahn, Robert W. and Layne-Farrar, Anne, The Move toward a Cashless Society: A Closer Look at Payment Instrument Economics, AEI-Brookings Joint Center Working Paper No. 04-20, 2004 [2] Xiaolin Zheng, Deren Chen, Study of Mobile Payments System, IEEE International Conference on ECommerce Technology (CEC'03), pp24, 2003 [3] Westland, J. C. and Clark, T. Global electronic commerce: Theory and case studies, London: MIT Press, pp.493-513, 1999 [4] J.P.Boly, The ESPRIT Project CAFÉ- High Security Digital Payment System ESORICS 94, Springer-Verlag, v. 875, pp 217-230, 1994 [5] D. O’Mahony, M Peirce, H. Tewari, Electronic Payment Systems, Arthech House Publishers, Boston, 1997 [6] D. Chaum, A. Fiat and N. Naor, Untraceable Electronic Cash, Proceeding of Crypto 88, SpringerVerlag, v. 403, pp 319-327, 1990 [7] D. Chaum, Security without Identification: Transaction systems to Make Big Brother Obsolete, Communications of the ACM, v28, , pp. 1030-1044, 1985 [8] D. Chaum, Achieving Electronic Privacy, Scientific American, v.267,n. 2, pp76-81, 1992 [9] Medvinsky, G. and Neuman, B.C. Requirements for Network Payment: The NetChequeTM Perspective, In Proceedings of the IEEE CompCon'95, San Francisco, pp. 32-36, 1995 [10] Ashutosh Saxena, Manik Lal Das, Anurag Gupta, MMPS: a versatile mobile-to-mobile payment system, IEEE International Conference on Mobile Business, 1113, pp400 – 405, 2005 [11] R. Anderson, C. Manifavas, and C. Sutherland, NetCard - A Practical Electronic Cash Scheme, (4th) Cambridge Workshop on Security Protocols, Lecture Notes in Computer Science 1189, pp. 49-57, Springer 1997, ISBN 3-540-62494-5, 1996 [12] Michael Pramateftakis, An introduction to Programmable Banknotes, 14 SIT-Smartcard-Workshop, Darmstadt, 2004 [13] Michael Pramateftakis, Programmable Banknotes, an alternative approach to electronic money, ShakerVerlag, ISBN: 978-3-8322-4287-9, 2005 [14] I. Askoxylakis, Integration of an electronic purse in a GSM SIM module, Master Thesis, Department of Electrical Engineering and Information Technology, Technical University of Munich, 2000 [15] I. Askoxylakis, D. Kastanis, A. Traganitis, MCommerce API Package for Mobile Phones, ERCIM Newsletter, Special Theme :Applications and Service Platforms for the Mobile User, Vol 54, pp32-33, 2003
50
