Strong Mobile AuthenticationMarko Hassinen, Konstantin Hypponen

Department of Computer ScienceUniversity of Kuopio

P.O.Box 1627, FIN-70211 Kuopio, FinlandEmail: {Marko.Hassinen, Konstantin.Hypponen}@uku.fi

Abstract- Our main contribution is a protocol that providesstrong mobile authentication with non-repudiation using SMSmessages. For ensuring these properties, governmentally con-trolled PKI, and SIM cards with electronic identity applicationare used. Moreover, our protocol provides confidentiality andintegrity of transferred content. An application that implementsthis protocol was developed and tested in a partly simulatedenvironment. Furthermore, we developed a protocol for mobilepayment for vending machines. In comparison to current systems,this protocol contains several enhancements in security, usabilityand cost both from the client as well as from the service providerpoint of view.

I. INTRODUCTIONAt the end of the year 2004 there were over 1.52 billion

mobile phone users in the world. In the first quarter of 2004,135 billion text messages were sent globally [1]. As the densityof mobile phones has increased, SMS messaging has turnedinto a media to reach masses of people.

Electronic and mobile commerce is now a major factorin modem economy. With no human-to-human contact, ithas become crucial to strongly authenticate both the sellerand the buyer. The absence of reliable methods for strongauthentication and non-repudiation has been holding backmany potential applications of mobile commerce.Lack of strong authentication has been a great obstacle for

applications where payment is made within the phone bill.Until now, only products of small monetary value have beensold this way. This is mainly due to the fact that the buyercannot be authenticated reliably.SMS messaging with Public Key Infrastructure (PKI) can

be used as a way to strongly authenticate a user in numerousapplications. A message with digital signature can be usedto show commitment, and it can provide non-repudiation [2].Confidentiality of the communication can be also guaranteed.

In this paper we propose a protocol for secure SMS mes-saging with PKI, and describe a program that implements thisprotocol.

II. PREVIOUS WORKSome mobile phone operators, such as Sonera in Finland,

have their own proprietary systems for mobile authentication.These systems have been sold mainly to businesses, wherethese systems have been used for authentication and autho-rization in back-office systems.A system for mobile authentication is described in [3]. This

system uses a dual slot phone, where the PKI application

0-7803-9206-X/05/$20.00 ©2005 IEEE

used for authentication is located in another card as the SIMapplication. An enhancement with a single slot was alsoproposed. However, the system needs several servers in theintemet. Moreover, the article doesn't discuss the portabilityof the application. Our solution is Java based, which meansthat it is portable across number of devices and can be installedto a device by the user.A system for end-to-end encryption of SMS messages was

described in [4]. It uses a symmetric algorithm and a sharedsecret password that is used for generating an encryption key.Furthermore, integrity of messages is guaranteed by usingmessage authentication codes. In our work we use severaldesign and implementation details described in [4].

III. FINEIDIn our project, we use the PKI provided by the Finnish

Population Register Centre [5]. The centre issues electronicidentity cards that contain three certificates:

1) Card holder's authentication and encryption certificate;2) Card holder's non-repudiation certificate;

(The key usage objects of these two certificates de-fine different key usage policies; otherwise certificatesare technically the same.)

3) Population Register Centre's own Certification Authority(CA) certificate.

The card holder's private keys are stored in the memory ofthis tamper resistant card. Moreover, there are no other copiesof these keys, and it is practically impossible to manufactureduplicates of the card. This suits perfectly our requirementsfor authentication and non-repudiation.

Finnish Electronic Identification (FINEID) [5] applicationmanages the contents of the electronic identity card andprovides a command interface for performing private keyoperations. User authentication is accomplished using PINcodes.

Population Register Centre maintains an online certificatedirectory (FINEID-directory). Public keys of each registeredindividual can be downloaded upon a search with appropriatecriteria. Besides that, revocation list of invalid certificates isavailable from the FINEID-directory.

Recently, it has become possible to include the FINEIDfunctionality on Subscriber Identification Module (SIM) cardsfor mobile phones. Such SIM cards are available from alocal mobile operator, and we obtained two cards for experi-ments. In our application, SIM cards perform digital signature

96

and decryption operations, whereas encryption and signatureverification are done by the mobile phone. Public keys ofthe communicating parties are obtained from the FINEID-directory.

IV. PROTOCOL FOR SECURE SHORT MESSAGE EXCHANGE

Our protocol for secure message exchange contains thefollowing steps (see Fig. 1):

1) In case the communicating parties A and B have notexchanged messages before, A (sender) obtains a cer-tificate with B's (receiver) public key from the FINEID-directory. In case A already has B's public key, Aconfirms from FINEID that B's certificate is not on therevocation list.

2) A message Al written by A is encrypted with B's publickey KUB. The resulting ciphertext is C = EKUB (M).

3) A hash value H = h(C) for a signature is calculatedfrom the encrypted message C. The hash with a time-stamp, (HITS), is sent to the SIM card for signing.

4) The SIM card signs (HITS) with A's private key KRAobtaining signature SA. The signature is appended to theencrypted message, and the result (CISA) is sent to B.

5) After receiving the message (CISA), B obtains A'spublic key from the public directory, unless A and Bhave communicated before. If A and B have communi-cated before, B verifies that A's certificate is not on therevocation list. B decrypts the singature obtaining thehash H and the timestamp TS.

6) If the parties have communicated before, B comparesthe timestamp TS to the timestamp TS' of the previousmessage received from A. If TS < TS' the verificationfails. This is done in order to prevent replay attacks.In case the verification was successful, B replaces thestored value TS' with the new timestamp TS.

7) B verifies the signature by calculating H' = h(C) fromthe encrypted message and comparing the hash valuesH and H'. If the signature can be verified, B uses theFINEID application on the SIM card to decrypt C andobtains the message Ml.

We believe that handling of timestamps needs more detailedreasoning and description of the idea behind it. Absense oftimestamps would, clearly, enable the recipient B to claimthat he has received several messages from A with the samecontent. In some applications this may be a serious problem.Consider, for example, a stock exchange application with mes-sages of the sort "Buy shares of XYZ worth 10 thousand" sentbetween brokers. Moreover, an eavesdropper might interceptmessages sent from A to B and replay them. Timestampsmay, of course, be added on the application level, but havingthem already in the underlying protocol means better securityagainst this type of attacks.As usual, the most difficult problem in using the times-

tamps is proper synchronization of clocks. First of all, mobilephone clocks are not very precise. Furthermore, not all usersenable synchronization of their mobile phone clocks with

their operator's clock, and not all operators even support thisfeature. Therefore, checking the freshness of messages cannotbe performed by mere comparison of the message timestampto the mobile phone clock time.Our scheme (see the protocol) does not assume even loose

synchrony of clocks. Still, the replay attacks are thwarted,since the timestamp of each message should be greater thanthat of the previous message received from the same corre-spondent.The described scheme, however, has one drawback. Con-

sider the case when two messages are sent under the followingcircumstances:

1) Clock of the sender A is n minutes fast.2) The first message is sent, with timestamp TS1;3) Clock of A gets synchronized to a correct clock;4) The second message is sent, with timestamp TS2;5) These events happen within n minutes.

In this case TS2 < TS1, and the verification of the secondmessage fails. However, the contents of the message maystill be important to the recipient in some applications, eventhough the message cannot be relied upon. We propose thatthe message is shown to the user with a proper notificationfrom the system about the failure in verification.

In the presented example, note also that A cannot sendverifiable messages for the time period of up to n minutes.One possible way of solving this problem is to use the

FINEID directory server as a source of timestamps. A canretrieve the timestamp for the message in step 1 of theprotocol.

V. APPLICATION STRUCTURE

We developed an application that implements the proposedsecure message exchange protocol. Java 2 Micro Edition(J2ME) [6] was used as the programming platform. Theapplication uses Wireless Messaging API (WMA) [7] forsending and receiving SMS messages.

In order to access extended features of the SIM-card (theFINEID application), the J2ME environment requires an op-tional package, namely, The Security and Trust Services API(SATSA) [8]. Among other features, the SATSA specificationdefines methods for communication with applications on theSIM card, by exchanging messages in the APDU format [9].We developed and tested our application in a partly simu-

lated environment. We used a combination of:. Real SIM cards with FINEID functionality;. PC smart card readers;. Simulated mobile phone with SATSA capabilities:SATSA Reference Implementation 1.0 [10] developed bySun Microsystems, Inc.

In order to enable communication between simulated mobilephones and SIM cards with FINEID application, we developeda small utility that acts as a mediator of APDU messages.The utility establishes a connection with a SIM-card insertedin a local smart card reader. It listens to a TCP/IP port,accepts connections from a remote machine (with mobile

97

Fig. 1. Overview of the Protocol for Secure Message Exchange

PKI-SIM

Fig. 2. Testbed environment

phone simulation running there), and forwards received APDUcommands to the card. Card's response APDUs are mediatedback to the remote machine. Of course, both parts could beexecuted on the same PC. The described testbed environmentis depicted in the Fig. 2.

For applications working within the J2ME environment thiscommunication scheme is completely transparent, since theforwarding of APDU messages to a TCP/IP port is performedby the simulation engine.FINEID public directory provides certificate search ser-

vices using Lightweight Directory Access Protocol (LDAP)[11]. Since we did not find any implementations of LDAPfor the Java 2 Micro Edition platform, we had to use onemore mediator. A Java servlet accessible through an HTTPSserver accepts certificate search requests, executes them using

FINEID-directory LDAP server, and forwards search results(certificates) back to the caller. Using this mediator servlet,we implement steps 1 and 5 of our secure message exchangeprotocol. The servlet is also used for retrieving the timestampin step 1.

VI. A PROTOCOL FOR VENDING MACHINE PAYMENT

In this section we describe a payment protocol for vendingmachines. Traditionally, purchases made with vending ma-chines have been paid for either with cash or by a creditcard. Although these systems work relatively well, severalimprovements can be achieved both from the client as wellas from the service provider point of view.

Current systems require certain amount of maintenance andfrequent visits by the personnel, e.g. collecting the money fromthese machines. Moreover, there are some security problems,such as described in [12].The protocol we propose delivers the following benefits:1) Less moving parts, hence less maintenance2) No need to collect money from the machines3) The user does not need cash, especially coins can

sometimes be difficult to obtain.Our protocol for a secure vending machine payment con-

tains the following steps (see Fig. 3):1) In step 1, the user initiates the protocol with the vending

machine by choosing a product. Optionally, the protocolcan be initiated by the vending machine, which detectsthe device when it comes in the range of the bluetoothcommunication.

2) Step 1 is followed by bluetooth pairing between thevending machine and the mobile phone. In case there

98

,UMxm

Request 1.

3.

4

6.

Fig. 3. Overview of the Protocol for Vending Machine Payment

is a possibility that several devices are in the range, themachine can use a random PIN code for pairing andshow this PIN to the user on a display.After pairing the vending machine sends the phone a

message with information about available products andtheir prices. In case step I was initiated by the user, andthe product is already selected, a part of the next stepcan be omitted and only a certificate request is sent inthis step.

3) In step 3 the user is prompted by the mobile devicefor selection of a product. The information on the user

selection is sent to the vending machine. Also, thecertificate holding the user's public key is sent to thedevice. In case the product was selected using the user

interface of the vending machine, only the certificateneeds to be sent.

4) Step 4 of the protocol includes the vending machinesending the mobile device a payment challenge. Thispayment challenge is signed using the vending ma-

chine's private key and encrypted using the the publickey KUM of the mobile device. The message in step 4includes payment details, such as account number, bankid, amount and possibly a reference id of the vending

machine with a certificate of the vending machine.5) In step 5 the mobile phone uses its private key to sign

the payment order and also encrypts the payment orderusing the bank's public key. The payment order includesalso a certificate obtained from the vending machine instep 4. The payment order is sent to the bank using theprotocol described in Section IV.

6) After step 5, the bank transfers the amount of money

from the account of the buyer to the account of the seller.If the transaction can be processed and finalized, thebank initiates step 6, where it encrypts a confirmationmessage using the vending machine's public key. Theconfirmation is signed by the bank using its private key.The bank sends the confirmation to the mobile phoneusing the protocol described in Section IV.

7) Finally, in step 7, the mobile phone checks that thetransfer was successfully made and forwards the pay-ment confirmation to the vending machine. The vendingmachine finalizes the protocol by checking the paymentconfirmation and delivering the product.

In general, the vending machine would have a list of publickeys of different banks. Sometimes this may be inconvenient,in which case step 7 could include the bank sending the mobile

99

11Vendingmachine I

phone its certificate and the mobile device forwarding thiscertificate to the vending machine.

The vending machine needs a connection to the networkto obtain a certificate containing mobile device M's publickey KUAI. This requirement may become limiting factorin the use of the protocol. Fortunately, there is a way tohandle this problem, namely the mobile device M can send acertificate with its public key to the vending machine. Sincea certificate revocation list (CRL) should be consulted beforeusing a certificate, the vending machine would still need anetwork connection. Our solution to this problem is to leavethe certificate verification to be done by the bank. This way thevending machine could operate without a network connection.A clear benefit of this protocol to the user is that she doesn't

have to worry about carrying cash, often in form of coins.Moreover, since the payment is made as a bank transfer, theservice provider gets the payment instantly, hence there are noassets lying around in vending machines.

A. PrivacyFor an electronic transaction it is important that participating

parties have certain privacy. The bank doesn't need to knowwhat the customer is buying, and the seller doesn't need toknow the details of buyers banking information. A protocolcalled SET (Secure Electronic Transaction) has been devel-oped to achieve these goals. For a description we refer to[13]. SET uses a dual signature to tie the order information(01) with the payment information (PI). This way the sellercannot claim that a payment made by the customer belongsto some other purchase than the one the user made. The dualsignature (DS) is

DS = EKRc(H(H(OI) IH(PI))) (1)

where H is a hash fuction and EKRC means encryption underthe customer's private key.

In our protocol, the buyer doesn't send the bank anyinformation about the purchase, which would tell the bankwhat she is buying. Also, the vending machine gets a paymentconfirmation (PC) signed by the bank. The PC tells thevending machine that the payment has been done, but doesn'tgive any details about the buyer's bank account, except thebrand of bank the user is using. The brand of the bank isnecessary in order for the vending machine to verify thesignature on the PC. A dual signature made by the buyer isused to bind 01's to corresponding PI's.

VII. SUMMARYStrong user authentication is a crucial requirement for

the development of commercial mobile services. The use ofgovemmentally contolled PKI can significantly increase trustin modem electronic commerce, to the benefit of both serviceproviders and their customers.We have proposed a protocol for secure SMS message ex-

change that provides strong authentication of communicatingparties, non-repudiation, and confidentiality. A program thatimplements this protocol was developed and tested in a partlysimulated environment.We have also presented a scheme in which a mobile handset

with a PKI-SIM card is used for a vending machine payment.In this protocol, strong user authentication is performed inorder to initiate a bank transfer.

REFERENCES

[1] GSM World: Facts and Figures.http://www.gsmworld.com/

[2] Schneier B.: Applied Cryprography. Protocols, algorithms and sourcecode in C. John Wiley and Sons, Inc. 1996.

[3] Chanson S., Cheung T.: Design and Implementation of a PKI-BasedEnd-to-End Secure Infrastructure for Mobile e-Commerce. Kluwer Aca-demic Publishers, 2002

[4] Hassinen M.: SafeSMS - End-to-End encryption for SMS messages.Proceedings of the 8th International Conference on Telecommunications- ConTEL 2005.

[5] Population Register Centre. FINEID-S4-1 Electronic ID Application.http://www.fineid.fi

[6] Sun Microsystems, Inc. Java 2 Platform, Micro Edition (J2ME).http://java.sun.com/j2me/

[7] Java Community Process: JSR-000120 Wireless Messaging API.http://jcp.org/aboutJava/communityprocess/final/jsrl 20/

[8] Java Community Process: JSR-000177 Security and Trust Services APIfor J2ME. http://jcp.org/aboutJava/communityprocess/final/jsr]77/

[9] ISO/IEC 7816-4:1995. Integrated circuit(s) cards with contacts. Part 4:Interindustry commands for interchange.

[10] Sun Microsystems, Inc. Reference Implementation of the SATSA spec-ification ver. 1.0. http://java.sun.com/products/satsa/

[11] RFC 1777 Network Working Group. Lightweight Directory Access Pro-tocol. http://www.ietf.org/rfc/rfcl777.txt

[12] University of Texas at Austin, Police Department: BankATMs Converted to Steal IDs of Bank Customershttp://www.utexas.edu/admin/utpd/atm.html

[13] Stallings W.: Cryptography and network security, Principles and Prac-tice. Prentice-Hall, 1999.

100