[IEEE 2005 2nd International Symposium on Wireless Communication Systems - Siena, Italy (05-09 Sept. 2005)] 2005 2nd International Symposium on Wireless Communication Systems - Strong Mobile Authentication

  • Published on
    11-Apr-2017

  • View
    213

  • Download
    1

Embed Size (px)

Transcript

  • 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 STRUCTUREWe developed an application that implements the proposed

    secure 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 amessage 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 userselection 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 userinterface 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 moneyfrom 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...

Recommended

View more >