A Secure and Private LBS Protocol on Mobile Communication Network

Yu-Yi Chen1,* Shin-Yi Hsiao2

1

Department of Management Information System National Chung Hsing University

Taichung 403, Taiwan, ROC [email protected]

2

Institute of Computer Science and Engineering National Chung Hsing University

Taichung 403, Taiwan, ROC [email protected]

Received 8 October 2007; Revised 15 December2007; Accepted 12 January 2008

Abstract. We have proposed a mobile mechanism [1] that offers location-based service in unfamiliar environment. Through the Mobile Network Service Provider (MNSP), subscribers can look for service providers nearby their positions. In our previous proposal, all service providers are assumed to be local dealers. However, after our further consideration, we believe that service providers may be mobile dealers. Such kind of design, Zhu has proposed a protocol [2] in 2003. However, his approach cannot be applied to current mobile communication system. In this paper, we will propose how to integrate mobile dealers into the location-based service of mobile communication system.

Keywords: Location-Based Service, Mobile Service, Security, Privacy.

1 Introduction

With the development of the internet and electronic technologies, all kinds of mobile devices, such as cell phones and PDAs are beginning to have basic computation and wireless communication capabilities. We will be able to use these mobile devices to make some electronic transactions [3-6] anywhere and anytime. Location-based service [7-11] is expected to be a suitable application for mobile transaction. It can provide a list of services nearby the mobile device’s position. For example, we can use this service to make choices about hotel and restaurant reservations as we are upon arrival to an unfamiliar place.

In 2004, Konidala proposed a “secure and privacy enhanced protocol for location-based services in ubiquitous society” [12]. However, Konidala’s scheme has the following disadvantages:

There only exist a symmetric session key between the MNSP and the subscriber. In the transaction, all messages are encrypted by the session key for security. However, the non-repudiation can not be guaranteed since there is not any signature in the transaction.

The MNSP handles all of the transaction’s details, the privacy of subscribers may be invaded.

In 2007, we have proposed a new design [1] to conquer the above problems. We introduced an “observer” character to assist subscribers to complete the transaction with non-repudiation signature and privacy protection. In our previous proposal, all service providers are assumed to be local dealers. However, after our further consideration, we believe that service providers may be mobile dealers. Such kind of design, Zhu has proposed a protocol [2] in 2003. Service providers may not be stationary, they can also be mobile users. For instance, an ill person suddenly has an accident in an unfamiliar place, he may use mobile device to search for local doctor or related medical services. Those coffee stands on wheels are another instance, mobile device may be used for people to conveniently search for their service at scenic spots.

In Zhu’s scheme (Fig.1), there are four types of component: client user, service provider, directory server, and proxy server. It assumes that a passive sensing system is set up around the area of a building, which lets mobile clients and services read location information. The sensing system consists of two types of component: reader and tag. The mobile devices of clients and services are embedded with reader function. There are many tags in the building which emit information either periodically or after readers’ requests. The service providers use the tags’ information to determine that they have moved to new locations and notify the proxy server. The clients

use the location information to search for the relevant services from the directory server. The non-repudiation and privacy are regarded as the most important issues. Under these considerations, the setup of location-base service claims the needs of powerful mobile device and public key infrastructure. The privacy of transaction will be guaranteed with the assistant of proxy server. There also need to set up a directory server for the registration of mobile service providers. Moreover, its location sensing system is using tags to label locations around the service area such that mobile device can read location information. Then mobile users can make transaction with those mobile service providers in such environment.

Fig. 1. Zhu’s scheme However, Zhu’s scheme has the following disadvantages:

The service area must have a directory server for the registration of mobile service providers. It should set up a passive sensing system, using tags to label locations around the service area. Then mobile devices can read location information. The cost will be very high if the scheme is considered to applied everywhere.

The directory server is responsible for verifying the identities of both parties under the Public Key Infrastructure. It needs to assume that all mobile devices have powerful computing ability. However, most cell phones are not so powerful, the scheme is not practical to be integrated into current mobile communication systems.

By the assistant of the proxy server, service providers can keep anonymous in the transaction. However, the users cannot keep anonymous since their certificates should be verified by the directory server. That will be unacceptable for people if their privacy cannot be guaranteed.

In this paper, we will propose how to integrate mobile dealers into location-based service of mobile communication system. In consideration of practicability, such kind of scheme should satisfy the following properties.

Anonymity:

During the transaction, people should keep anonymous.
Privacy:

The MNSP must not know the transaction's details even the order is transferred via the MNSP.
Non-repudiation:

There already exist this kind of mobile location technology such as Cell-ID, AOA, TOA, E-OTD, and A-GPS [13]. There are five parties be involved in our scheme as follows.

User: People use cell phones or PDAs to request location-based service of mobile communication system.

Service Provider (SP): Mobile dealers can announce their services on the location-based service system.
Mobile Network Service Provider (MNSP): It provides secure and stable mobile communication system

for people.

User’s observer (U-observer): A trusted web site that acts as user’s agent.
SP’s observer (SP-observer): A trusted web site that acts as SP’s agent.

We divide the location-based service protocol into three phases: Service Registration Phase (Fig.2), Service Query Phase (Fig.3), and Service Request Phase (Fig.4). In our scheme, we involve a key role of “observer” to coordinate the transaction. It also integrates some cryptology such as public key infrastructure, hash chain, and digital signature. The notations used in our scheme are listed in the Table 1:

Table 1. Notation table Notations Description || + - ⊕ () H M H M SG X PK X SK () X S () X V X ID SP Nick SP SrvDscp X Loc SN TS TK U eq R concatenate operation additive operation subtractive operation exclusive-OR operation a one way hash function the hash value of message M the signature of message M the X’s public key

the X’s secret key

the signature function using X’s secret key to sign the verify function using X’s public key to verify the X’s identity

the nickname of service provider

the service description of the service provider, it contains transaction time, location, and price,…,etc.

the X’s current location

the serial number assigned by the MNSP in a transaction timestamp

the transaction token which contains (SN,TS,SG_SN)

the user’s request

Initially, the SP must pre-coordinate a set of hashing chain (b0_, b , ..., 1 bm_{) with the chosen SP-observer,}

where b0 _{is a random seed,} b =1 H(b0)_, b =2 H(b1)_{, ...,} bi=H(bi−1)_{.Similarity, the user also pre-coordinate a set}

of hashing chain (a0_, a1 _{, ...,} an_{) with the chosen U-observer, where} a0 _{is a random seed,} a =1 H(a0)_,

) ( 1

2 H a

a = _{, ...,} aj=H(aj−1)_{. The pre-coordination process can be run via the Internet and then the hashing chain} values are downloaded into the user’s mobile device. Out of the MNSP’s control, the hashing chain values will not be revealed to the MNSP. Moreover, the pre-coordination process must be protected by Secure Socket Layer (SSL) or any secure session communication. Afterward, the user and the chosen observer can use these hashing values to authenticate messages to each other during the transaction.

Phase 1. Service Registration Phase

Fig. 2. Service Registration Phase

Step 1. Suppose a subscriber wants to register as a mobile SP, his nickname Nick and service description SP SP

SrvDscp should be proposed to the chosen SP-observer as the following format:

2 1 2 1 1 ) || ( ) || ( − − − + ⊕ = + ⊕ = i i SP SP i i SP SP b b SrvDscp Nick R b b SrvDscp Nick R

The subscriber generates his register message M containing the above values ₁ R1 and R2, the

chosen SP-observer’s identity ID_SP−_obs and public key PKSP−obs:

) , , , ( 1 2 1 R R IDSPobs PKSPobs M = − −

Then the above register message M₁ and its hashing value

1

M

H are sent to the MNSP. Step 2. Upon receiving the above message, the integrity of the message M can be verified as follows: 1

1 ? 1)

(M HM

H =

The subscriber’s position Loc_SP can be located by the MNSP, and be combined into the following message M : ₂ ) , , ( _{1 2} 2 Loc R R M = _SP

Then the MNSP uses its secret key to sign M₂ as follows:

)) ( ( 2 2 S H M SG MNSP SK M =

The above message M₂ and its signature

2

M

SG are encrypted by the chosen SP-observer’s public key

obs SP PK − as follows: ) , ( 2 2 2 EPK M SGM C obs SP− =

After, the ciphertext C₂ , the subscriber’s identity ID , and the MNSP’s public key _SP PKMNSP are sent

Phase 2. Service Query Phase

Step 1. Suppose a mobile user makes a query Qry for looking some kinds of location-base service. He _U generates his query message M as follows ₃

U

Qry

M =

3

Then the above query message M and its hashing value ₃ 3

M

H are sent to the MNSP.

Step 2. Upon receiving the above message, the integrity of the message M can be verified as follows: 3

3

? 3)

(M HM

H =

The user’s position Loc can be located by the MNSP, and be combined into the following message _U

4 M : ) , ( 4 QryU LocU M =

Then the MNSP uses its secret key to sign M₄ as follows:

)) ( ( ₄ 4 S H M SG MNSP SK M =

The message M and its signature 4 SGM₄ are broadcasted to all SP-observers.

Step 3. For each SP-observer, upon receiving the above message, the integrity of message M4 can be verified

as follows: ) ( ) ( 4 ? 4 VPK SGM M H MNSP =

According to the user’s query

U

Qry and location Loc , all of the suitable SPs’ recorders will be _U retrieved and collected as a list {NickSP,SrvDscpSP}. Then this list is combined with the SP-observer’s

identity

obs SP

ID − and public key PKSP−obs into the following message M : 5

) ,

}, ,

({

5 NickSP SrvDscpSP IDSPobs PKSPobs

M = − −

Each SP-observer uses its secret key to sign

5 M as follows: )) ( ( ₅ 5 S H M SG obs SP SK M − =

After, the message

5

M and its signature 5

M

SG are sent to the MNSP.

Step 4. Upon receiving the above messages from each SP-observer, the MNSP can verify the integrity as follows: ) ( ) ( 5 ? 5 VPK SGM M H obs SP− =

Then all lists will be collected as the following response message M with an assigned transaction ₆ token TK : (SN,TS) S SG mp a timesta TS is mber serial nu SN is a ) (SN,TS,SG where TK }) ,PK },ID ,SrvDscp {{Nick (TK M MNSP SK SN SN obs SP obs SP SP SP = = = _{− −} , , , , 6

After, the response message M and its hashing value ₆ H_M are sent to the user.

Step 5. Upon receiving the above messages, the integrity of the message M₆ can be verified as follows: 6 ? 6) (M HM H =

Finally, the user gets the transaction token TK and all SPs’ service list }

, }, ,

{{Nick_SP SrvDscp_SP ID_SP−_obs PK_SP−_obs of current location on his mobile device.

Phase 3. Service Request Phase

Fig. 4. Service Request Phase

Step 1. Suppose a SP is selected, the user request R eqU and the SP’s nickname Nick should be proposed SP

to the chosen U-observer as the following format:

2 1 2 1 1 ) || || ( ) || || ( − − − + ⊕ = + ⊕ = j j SP U j j SP U a a TK Nick eq R N a a TK Nick eq R N

The user generates his request message M containing the above values ₇ N and ₁ N , the SP-2

observer’s identity ID_SP−_obs and public key PKSP−obs, and the chosen U-observer’s identity IDU−obs

and public key PK_U−_obs:

) , , , , , ( 1 2

7 N N IDSPobs PKSP obs IDU obs PKU obs

M = − − − −

Then the above request message M₇ and its hashing value

7 M

H are sent to the MNSP.

Step 2. Upon receiving the above messages, the integrity of the message M can be verified as follows: ₇

7

? 7)

(M HM

H =

A partial parameters of the message M will be forwarded to the U-observer: ₇

) , , , ( _{1 2} 8 N N IDSPobs PKSPobs M = − −

Then, the MNSP uses its secret key to sign M as follows: ₈ )) ( ( 8 8 S H M SG MNSPs SK M =

TK can be obtained and verified as follows: 1 2 2 ? 1 1 ) ( ) (N −aj− ⊕aj= N −aj− ⊕aj−

The U-observer should make the following “proxy-request” message M₉:

) , , ( 9 Nick Req TK M = SP U

Then the U-observer uses its secret key to sign M₉ as follows:

) ( 9 9 S M SG obs U SK M − =

The message M and its signature ₉ 9

M

SG are encrypted by the SP-observer’s public key PK_SP−_obs as

follows: ) , ( 9 9 9 EPK M SGM C obs SP− =

After, the ciphertext C and the U-observer public key ₉ PK_U−_obs are sent to the SP-observer.

Step 4. Upon receiving the above messages, the ciphertext C can be decrypted by the SP-observer’s secret ₉ key. Then the integrity of the message M can be verified as follows: ₉

) ( ) ( 9 ? 9 VPK SGM M H = _{U −obs}

Moreover, the transaction token TK =(SN,TS,SGSN) in the message M should be verified as 9

follows: ) ( ) , ( ? TK V TS SN MNSP PK =

If the above equality is hold, it means the request is guaranteed by the MNSP for its validation.

According to the nickname Nick in the message _SP M9, the corresponding SP’s identity can be

retrieved. Then the above message M and its signature ₉ 9

M

SG should be proposed to the corresponding SP as the following format:

4 3 9 4 3 2 9 3 ) || ( ) || ( 9 9 − − − − + ⊕ = + ⊕ = i i M i i M b b SG M R b b SG M R

The SP-observer should make the following “request-confirmed” message M₁₀: ) , , ( 3 4 10 R R IDSP M =

Then, the SP-observer uses its secret key to sign M₁₀ as follows:

)) ( ( 10 10 S H M SG obs SP SK M − =

The message M₁₀ and its signature

10 M

SG are encrypted by the MNSP’s public key PK_MNSP as follows: ) , ( 10 10 10 EPK M SGM C MNSP =

After, the ciphertext C is sent to the MNSP. ₁₀

Step 5. Upon receiving the above messages, the integrity of the message M can be verified as follows: ₁₀ ) ( ) ( 10 ? 10 EPK SGM M H obs SP− =

Only parameters R₃ and R will be forwarded to the corresponding SP: ₄ )

, ( _{3 4}

11 R R

M =

Then the above message M and its hashing value ₁₁ 11

M

H are sent to the SP.

Step 6. After receiving the above messages, the integrity of the message M can be verified as follows: 11

11

? 11)

(M HM

H =

The SP uses the pre-coordinated hashing values of bi−₂, bi−3, and bi−4 to decrypt the message R 3

and R . Then the message ₄ M and its signature 9 SGM9 can be obtained and verified as follows:

3 4 4 ? 2 3 3 ) ( ) (R −bi− ⊕bi− = R −bi− ⊕bi−

According to the user’s request R eq_U, which is contained in the message M , the SP will provide his ₉ service on the requested time and location.

3 Analysis

A. Anonymity Issue:

In our design, the user and SP will not know each other when they are transacting, because:

I . In step 5 of the service query phase, the user gets the list {{NickSP,SrvDscpSP},IDSP−obs,PKSP−obs}.

Clearly, there is no any identity of the SPs. The user just needs to appoint the nickname in his service request, then the request will be forwarded to the corresponding SP finally.

II . In step 6 of the service request phase, the SP gets the user’s request R eqU. Of course, there is no any

identity in the request message. It’s just the time and location information for the SP needs to know.

B. Privacy Issue:

In our protocol, the transaction message will be transferred by the MNSP. However, the transaction’s detail such like SP’s service description SrvDscp and user’s request _SP R eq_U should not be known by the MNSP for the reason of privacy:

I . In step 1 of the service registration phase, the registration message is performed as follows:

2 1 2 1 1 ) || ( ) || ( − − − + ⊕ = + ⊕ = i i SP SP i i SP SP b b SrvDscp Nick R b b SrvDscp Nick R

The above message then be forwarded to the chosen SP-observer via the MNSP. The MNSP will not be able to decrypt R and ₁ R2 without bi, bi−1, and bi−2, thus preventing it from obtaining the

SP’s service description SrvDscp . _SP

II . In step 4 of the service query phase, the MNSP will collect all of the suitable SPs’ recorders: }

, }, ,

{{Nick_SP SrvDscp_SP ID_SP−_obs PK_SP−_obs

There will only be known the nickname of the SPs, the MNSP will not know who the SPs are. III . In step 1 of the service request phase, the request message is performed as follows:

2 1 2 1 1 ) || || ( ) || || ( − − − + ⊕ = + ⊕ = j j SP U j j SP U a a TK Nick eq R N a a TK Nick eq R N

The above message then be forwarded to the chosen U-observer via the MNSP. The MNSP will not be able to decrypt N and ₁ N without ₂ a , _j aj−₁, and aj−2, thus preventing it from obtaining the

user’s request

U

eq R .

Moreover, the user’s request will be further forwarded to the SP-observer in step 3 of the service request phase. And the request message is then embedded in the following message M : ₉

4 3 9 4 3 2 9 3 ) || ( ) || ( 9 9 − − − − + ⊕ = + ⊕ = i i M i i M b b SG M R b b SG M R

The above message then be forwarded to the corresponding SP via the MNSP. Clearly, the MNSP will not be able to decrypt

3

R and R4 without bi−2, bi−3, and bi−4, thus preventing it from

obtaining the user’s request R _eqU contained in message

9

M .

denied if it has been received by the SP to provide his service.

Suppose the user denies his request, the SP will show the “proxy-request” message M and its signature ₉

9

M

SG to the MNSP. Then it can be verified by the U-observer’s public key PK_U−_obs as follows: ) ( ) ( 9 ? 9 VPK SGM M H obs U − =

Moreover, the transaction token TK =(SN,TS,SG_SN) in the message

9

M should be verified as follows: ) ( ) , ( ? TK V TS SN MNSP PK =

If the above equality is hold, the user’s identity will be retrieved according to the serial number SN which is assigned by the MNSP in step 4 of the service query phase. Therefore, the SP will not worry about the user’s repudiation.

D. Simplicity and Practicability Issue:

In our protocol, we assume that all communication is secure between the MNSP and the mobile device. There is not necessary to design extra encryption for those communication. Only exclusive-OR, addition, and hash operations are used in mobile device. All of these operations are easy to implement into current cell phone hardware. Moreover, our protocol can be easily applied to current mobile communication system without need of extra infrastructures. The setup cost of our scheme will be more reasonable than Zhu’s scheme.

4 Conclusion

We propose scenarios that include the registration, query, and request phase for providing location-based service on mobile communication system. Our proposal contributes a practical protocol that meets all important issues: anonymity, non-repudiation, and simplicity.

References

[1] Y.-Y. Chen and S.-Y. Hsiao, “The Study on Secure Location-Based Service,” Proceedings of the 17th Information Security Conference, June 2007.

[2] F. Zhu, M. Mutka, and L. Ni, “A Secure, Private, and Location-aware Service Discovery Protocol Supporting Mobile Services,” Proceedings of the First IEEE International Conference on Pervasive Computing and Communications (PerCom 2003), pp.235-242, Mar. 2003.

[3] P. Ahonen and R. Savola, “Security Threats to Mobile Service Development in the Age of Digital Convergence,” Proceedings of the International Conference on Computer as a Tool (EUROCON 2005), Vol. 2, pp.1052-1055, 2005. [4] G. Bartolomeo, N. BlefariMelazzi, G. Cortese, A. Friday, G. Prezerakos, R. Walker, and S. Salsano, “Simplifying Mobile

Services - for Users and Service Providers,” Proceedings of the International Conference on Internet and Web Applications and Services/Advanced International Conference on Telecommunications (AICT-ICIW '06), pp.209-213, Feb. 2006.

[5] S. Ryu, S. K. Park, D. Oh, G. Sihn, K. Han, and S. Hwang, “Research activities on next-generation mobile communications and services in Korea,” IEEE - Communications Magazine, Sept. 2005, pp.122-131.

[6] J. Tacken, T. Janssen, S. Flake, and D. Fischer,” A service creation environment for interactive, menu-driven mobile services,” Proceedings of the 20th International Conference on Advanced Information Networking and Applications (AINA 2006 ), Apr. 2006.

[7] C. Ardagna, M. Cremonini, E. Damiani, SDC di Vimercati, and P. Samarati, “Supporting location-based conditions in access control policies,” Conference on Computer and Communications Security, Proceedings of the 2006 ACM Symposium on Information, computer and communications security, Taipei Taiwan, pp. 212-222, March 2006.

[8] A. H. John Cardiff, P. Magee, and J. Doody, “An architecture and development methodology for location-based services,” Electronic Commerce Research and Applications, Vol. 5, No. 3, pp.201-208, 2006.

[9] J. C. Kim, T. W. Heo, J. W. Kim, and J. H. Park, “Ubiquitous location based service,” 2005 IEEE Proceedings - Intelligent Transportation Systems, pp.841-845, Sep. 2005.

[10] M. F. Mokbel and C. Y. Chow, “Challenges in Preserving Location Privacy in Peer-to-Peer Environments,” Proceedings of the Seventh International Conference on Web-Age Information Management Workshops (WAIM 06), pp.1-8, June 2006.

[11] S. Y. Wu and K. T. Wu, “Effective location based services with dynamic data management in mobile environments,” Wireless Networks, Vol. 12, No. 3, pp.369-38, 2006.

[12] D. M. Konidala, Y. Y. Chan, and K. Kwangjo, “A secure and privacy enhanced protocol for location-based services in ubiquitous society,” Proceedings of the IEEE GLOBECOM '04 - Global Telecommunications Conference, pp.2164-2168, Nov. 2004.

[13] W. Tsui, C. Y. Yin, and C. N. Chen, “A Survey on Current Mobile Location Technology,” ICL Technical Journal, Vol.115, pp.54-60, Mar. 2006.