A Protocol for Billing Mobile Network Access Devices Operating in Foreign Networks

A Protocol for Billing Mobile Network Access Devices Operating in Foreign Networks Wei-lung Wang Chun-Wei Wu School of Computing National University o...
Author: Bertina Fleming
5 downloads 0 Views 62KB Size
A Protocol for Billing Mobile Network Access Devices Operating in Foreign Networks Wei-lung Wang Chun-Wei Wu School of Computing National University of Singapore email: {wangweil,wuchunwe}@comp.nus.edu.sg

Abstract

1.

Mobile computing is becoming pervasive, and with it comes the demand for unfettered network access for mobile users.

Mobile computing is becoming ubiquitous today and with it comes the requirement for network access for mobile users. Traditionally, mobile users obtain network access in two ways:

Currently, mobile network access is provided by a relatively small number of service providers, in part due to the high costs of operating wireless network systems and the accompanying “backbone” architectures. Mobile users have to establish proprietary billing arrangements with their service providers, and are limited to using the wireless networks run by their service provider. The existence of the Internet as the baseline network backbone with its unifying TCP/IP architecture, and the advances in low cost wireless network technology allows for a new means of wireless network access for mobile users. Small scale service providers can simply install low cost wireless network base stations and plug them into the Internet, providing network access to any willing mobile user. The low barriers to entry makes it likely that there will be a large number of service providers. A non-proprietary billing protocol used among these service providers will allow mobile users to use any service provider’s network. This leads to better wireless coverage for the mobile user. We propose one such protocol in this paper. This protocol may be implemented as an extension to the Mobile IP protocol [5], as they share certain similarities in their execution. This would spur its deployment as Mobile IP is an open standard that will likely be used by mobile users. This work was supported in part by Research Grant RP3960683 at the National University of Singapore.

Introduction

(1) via network access points managed by their own organizations/primary service providers, or (2) by accessing a network operated by a foreign service provider with a common access agreement with the user's primary network access provider. These arrangements imply a degree of trust in the billing arrangements between the primary network access provider and the foreign service provider. This works well when there are only a few major primary and foreign service providers of importance. Today, low cost, short range and high bandwidth wireless networking technologies such as Wavelan [4] are becoming common. This presents the opportunity for small-scale service providers, such as building owners, to deploy wireless network access facilities for visiting mobile users. However, the problem is that the potential number of such service providers is high. This means that mobile users’ primary network access providers will probably not have prior billing and access arrangements Copyright 1998 IEEE. Published in the Proceedings of WETICE '98, 17-19 July 1998 at Palo Alto, California. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works, must be obtained from the IEEE. Contact: Manager, Copyrights and Permissions / IEEE Service Center / 445 Hoes Lane / P.O. Box 1331 / Piscataway, NJ 08855-1331, USA. Telephone: + Intl. 732-562-3966.

with all these small-scale service providers. This arrangement is not limited to the use of wireless networks; building owners may also offer wired Ethernet access to mobile users.

The agents involved in the protocol are: - MU refers to the Mobile User, and is synonymous with the mobile user's network access device. (e.g. a laptop)

We propose a billing protocol that will allow mobile users to pay for the use of network resources in foreign networks which do not have prior access and trust arrangements with the mobile user's primary access providers. As the foreign networks do not trust the primary service providers, billing for service must be done in real time as the service is being provided, to minimize the impact of non-acknowledgment of service provided.

- HS refers to the Mobile User's Home Server, which is synonymous with the home organization / primary network access provider. (e.g. an Internet Service Provider) - FS refers to the Foreign Server, and is synonymous with the foreign network access service provider. (e.g. a building owner who installs a wireless network)

The protocol does not cover the actual payment transactions between entities. This may be done using other schemes such as [1].

- MUid, HSid, FSid refer to a unique identification for the Mobile User, Home Server and Foreign Server respectively.

The key features and benefits of the protocol are:

The protocol requires that the Home Server and the Foreign Server each have a Public-Private key pair, issued by a trusted and well known Certifying Authority. Management of these keys and the certificate authority may be done using mechanisms such as digital certificates [2, 7]. The notation is as follows:

(1) Better roaming coverage for the mobile user. He can use any service provider which uses this protocol. (2) It makes it easier for small service providers to go into business, as it is unlikely they will have the resources to establish roaming agreements with mobile users’ primary service providers. The large number of providers will likely improve overall wireless coverage. (3) It treats the mobile network access device as a “cashless” device, making it more acceptable to the user in terms of convenience (no need to “refill” the device) and loss (no “cash” is lost if the device is lost). With this protocol, a mobile user can wander into a building with a wireless local area network and get network access. Billing for the access is seamlessly done via his primary service provider. In section 2, we will introduce basic issues and notation pertaining to the protocol. We then introduce the trust relationships assumed in the protocol in section 3. The protocol proper is described in section 4, and a basic security analysis is given in section 5. Next we consider performance issues in section 6, and then we conclude in section 7 by discussing the deployment of this protocol.

2.

Preliminaries

Here, we introduce notation which we use, and assumptions on which the protocol is based.

- PBHS, PVHS the Home Server's public and private keys respectively - PBFS, PVFS the Foreign Server's public and private keys respectively The protocol also utilizes a shared secret and shared key cryptography between the Mobile User and the Home Server. The notation is as follows: - sk HS-MU the shared key between a Mobile User and the Home Server - ss HS-MU the shared secret between a Mobile User and the Home Server A shared key is also dynamically generated by the Foreign Server and shared with the Mobile User: - sk FS-MU

the dynamically generated shared key

The exact shared key and public key cryptographic algorithms used is a matter of implementation and may be any of those available, such as [3, 6, 7] The mobile computing device is assumed to have less computing power relative to non-mobile devices. Hence,

any computational requirements, such as encryption computations, should be kept to a minimum. The user may not want to carry “cash” on a portable device, due to the inconvenience of having to “refill” the device with cash, and the potential for theft or loss. Hence, this protocol is designed on the assumption that the mobile device does not carry “cash” or any other means of payment.

3.

Trust Model

We now describe the trust relationship assumptions on which the protocol is based: (1) Home Server - it trusts its Mobile User’s communications (authenticated), and trusts that the Mobile User will not renege on its transactions. - it does not trust the Foreign Server’s assessment of the amount of service provided to its Mobile User. - it trusts a Certifying Authority to certify the authenticity of other servers. (2) Foreign Server - it does not trust the Mobile User and Home Server to acknowledge its services rendered and to not renege on that acknowledgment. It needs mechanisms to ensure that: 1. its services rendered are acknowledged in a non-repudiable fashion. 2. in the event its services are not acknowledged, its losses are minimized to a definable quantity - it trusts a Certifying Authority to certify the authenticity of other servers. (3) Mobile User - it does not trust the Foreign Server to produce an accurate assessment of service provided and charged for. - it trusts any communication from its Home Server, and trusts that the Home Server will not falsify transactions. (this is similar to the model used in the retail telecommunications industry, where the

telecommunications company is trusted not to falsify the bill for telephone line use)

4.

Protocol

Here, we describe the protocol proper. The protocol consists of 2 phases: (1) the Registration phase and (2) the Per Billing Quantum phase. When a Mobile User moves into a network under the administration of a Foreign Server, it will perform a Registration. Once the Registration is complete, the foreign network will begin providing network access to the Mobile User. At predefined intervals, known as Billing Quanta, the Home Server is billed for network access provided to the Mobile User. This is the Per Billing Quantum phase.

4.1 Registration When the Mobile User enters the foreign network, it will perform a registration with the Foreign Server. This serves to inform the Foreign Server that the Mobile User wants to use its network, and serves to allow the Foreign Server to establish a billing arrangement with the Home Server. (1) Mobile User sends the following information to the Foreign Server: 1. unencrypted { MUid , HSid , TRegistrationSecret, TS(m)MU-HS } where TRegistrationSecret is: encrypted with sk HS-MU { ss HS-MU, TS(m)MU-HS} and TS(m)MU-HS is a timestamp generated by the MU, and used to uniquely identify each registration between the MU and HS. The method for generating this timestamp can be determined by the HS (eg. A running number), making its handling easier for the HS. The Home Server and the Foreign Server obtain each other’s public keys through other protocols, such as [2].

(2) Foreign Server sends the following data to Home Server: 1. encrypted with PVFS, then again with PBHS {MUid , TRegistrationSecret , TS(m)MU-HS, sk FS-MU }

(5) Foreign Server Verifies Approval: where sk FS-MU is dynamically generated by the Foreign Server, and is valid for the Registration session. 2. unencrypted { FSid } Verification of Home Server and Foreign Server identities and keys is then done via the Certifying Authorities, using other mechanisms such as [2].

1. Foreign Server decrypts message sent in (4) with PVFS ,then again with PBHS . 2. If Approval is valid, proceed to step (6).

(6) Foreign Server sends to Mobile User: 1. unencrypted { TSessionKey }

(3) Home Server verifies the authenticity of the Mobile User. 1. Home Server decrypts the data sent in (2) with PVHS then again with PBFS. 2. It uses MUid to determine the sk HS-MU for the Mobile User.

(7) Mobile User Obtains the Foreign Server’s Session Key. 1. Mobile User decrypts TSessionKey using sk obtain sk FS-MU.

HS-MU

to

The sk FS-MU will be used to encrypt:

3. It then decrypts TRegistrationSecret using sk HS-MU to get ss HS-MU and TS(m)MU-HS.

(1) Billing and Administrative Communication, between the Foreign Server and Mobile User, and

4. Upon confirmation of the identity of the Mobile User (ss HS-MU from TRegistrationSecret is correct for the Mobile User), and that the timestamp TS(m)MU-HS is valid (fresh), proceed to step (4).

(2) Network Traffic, between the Mobile User and the gateways in the foreign network which allow network access. This is to prevent theft of service attacks and privacy violations.

(4) Home Server sends to Foreign Server: 1. encrypted with PVHS , then again with PBFS {Approval Code, TS(m)MU-HS , MUid , TSessionKey } where TSessionKey is: encrypted with sk HS-MU { sk FS-MU, ssHS-MU, TS(m)MU-HS, Approval Code} It serves to securely transmit sk FS-MU and the HS’ approval from the HS to the MU. It also verifies to the MU that the approval is fresh and from the HS, since only the HS knows sk HS-MU and therefore only it could have produced this message. and Approval Code is a bit pattern indicating the HS’ approval.

Once registration is complete, the foreign network will begin providing network resources to the Mobile User on the basis of billing quanta. At this point: (1) The Home Server has authenticated the Mobile User, and informed the Foreign Server of the authentication (2) The identities of the Home Server and Foreign Server and the validity of their public keys have been verified (3) The sk FS-MU has been securely transmitted from the Foreign Server to the Mobile User.

4.2 Per Billing Quantum Foreign Network resources used by the Mobile User are subdivided into quanta which are billed for individually. Each quantum is referred to as a "billing

quantum". For example, a quantum may be a certain number of bytes of network traffic.

(4) Mobile User sends to Home Server - we call this the Authorized Bill :

Prior to the start of the use of billing quantum i ( known as BQ(i) ):

1. encrypted with sk HS-MU { TS(i), ss HS-MU , BR(i) } 2. unencrypted { MUid }

(1) Foreign Server sends to Mobile User - we call this the Quotation : 1. encrypted with sk FS-MU { BR(i), QS(i), TS(i) }

(5) Home Server determines Authenticity of Authorised Bill.

where BR(i) is the billing rate, or the price of the quantum

1. Home Server obtains correct sk HS-MU for the Mobile User using MUid as index

and QS(i) is the size of the quantum

2. Home Server decrypts message sent in (4) with sk HS-MU.

and TS(i) is the timestamp, which must be unique for each quantum. ( TS(i) may be any bit pattern, as long as each TS(i) is unique )

3. If ssHS-MU is correct for the Mobile User, then Authorised Bill deemed authentic. Proceed to step (6).

This allows each billing quantum to be varied . eg. The quantum for a “regular” mobile user may be larger in view of implicit trustworthiness. This reduces the protocol overhead somewhat. Once the billing quantum i has been used (resource quantity used amounting to QS(i)):

(2) Foreign Server sends to Mobile User - we call this the Bill : 1. encrypted with sk FS-MU { signal that BQ(i) has been used }

(3) Mobile User processes the Bill. 1. Mobile User decrypts message sent in (2) with skFS-MU. 2. If Mobile User agrees to the charges, proceed to step (4). The Mobile User must meter its use of network resources, so that it can determine if the Bill is correct by way of comparison with its own meter. It may define an acceptable margin of discrepancy to allow for errors in measurement by either party.

(6) Home Server sends to Foreign Server - we call this the Bill Acknowledgment: 1. encrypted with PVHS, then again with PBFS { TS(i), MUid , BR(i), Acknowledgment }

(7) Foreign Server confirms that its Bill has been acknowledged. 1. Foreign Server decrypts message sent in (6) with PVFS, then again with PBHS. 2. If Bill Acknowledgment is correct, continue providing service to the Mobile User. In order to provide seamless network access to the Mobile User, the foreign network needs to continue providing the next quantum worth of network service while it is waiting for the Home Server to acknowledge the quantum of service just used. i.e. the foreign network provides BQ(i+1) when BQ(i) is being processed. If the Bill Acknowledgment for BQ(i) is not received by the time BQ(i+1) is consumed, the foreign network may elect to stop providing network service to the Mobile User. The maximum loss which the Foreign Server will then incur is the price of 2 Billing Quanta (price of BQ(i) and BQ(i+1) i.e. 2BR).

This protocol uses public-private key encryption to encrypt protocol messages. While signed hashes would also serve to authenticate the source of the messages, it would not provide secrecy. We felt that secrecy was important, and our design provided this without introducing more complexity by way of additional keys for symmetric key cryptography.

(2) Foreign Server: The Foreign Server, which receives bill acknowledgments from the Home Server, has the following safeguards: 1.

This protocol can be implemented by extending the Mobile Internet Protocol [5], which has defined entities and transactions which closely correspond to those used here.

Each Bill Acknowledgment can only be generated by the Home Server as it requires the use of the Home Server's private key. ( Section 4.2 - Step (6) ) 2.

5.

Security Analysis

Here we analyze the security of the protocol in terms of its design. A goal of our design is to ensure that malicious attackers cannot compromise the (financial) liability of any party. The security of this protocol also depends greatly on its proper implementation, and this can only be evaluated on a case by case basis when it has been coded in software. First, we explain how the protocol protects the interests of the parties involved.

Non-repudiation of Bill Acknowledgment sent by Home Server

Minimization of loss in event of dispute with Mobile User / Home Server's failure to send Bill Acknowledgments The Foreign Server can stop providing the next quantum of resource if the previous billing quantum is not paid for. The Foreign Server's losses are at most the price of 2 billing quanta (the previous quantum and the current quantum)

(3) Mobile User: The Mobile User, which consumes network resources administered by the Foreign Server, has the following assurances:

(1) Home Server: 1. The Home Server, which acknowledges bills from the Foreign Server, checks the Foreign Server from making illegitimate billing claims: 1.

If it disputes the network resource being charged for, it can opt not to send the Authorised Bill to the Home Server, thus refusing payment. Only if it agrees to the Bill will it authorize the Home Server to acknowledge the Bill. (Section 4.2 - Steps (3, 4))

Duplication (Replay) of Bill Acknowledgment for a particular Billing Quantum Each Bill Acknowledgment sent by the Home Server to the Foreign Server can only be authentically generated by the Home Server using its private key, and contains a unique TS(i). (Section 4.2 - Step (6)) For each distinct TS(i), the Home Server will only recognize the validity of one Bill Acknowledgment sent.

Check against overcharging by the Foreign Server

2.

Loss of Device In the event of loss of the Mobile User’s device, he can report it to the Home Server, who will ignore further service and payment requests from the lost device.

Next we examine cases where this protocol fails. (4) Points of Failure

2.

Spurious generation of Bill Acknowledgment by the Foreign Server The Foreign Server cannot generate a Bill Acknowledgment as it requires the use of the Home Server's private key. ( Section 4.2 - Step (6) )

The proposed protocol assumes that there is no collaboration between any of the three entities. Hence, the protocol will be rendered insecure if there exists:

1.

Foreign Server - Mobile User collaboration The Foreign Server may generate spurious Bills which the Mobile User authorizes and sends to the Home Server as Authorised Bills. At a later time, the Mobile User denies that it had incurred the charges (claiming theft of Mobile User device, for example). At this time, the Foreign Server may have already received actual payment from the Home Server, while the Mobile User refuses to pay the Home Server. Arbitration between the Mobile User and Home Server will have to be based on the principle that the Home Server is a trusted entity.

2.

Home Server - Foreign Server collaboration The Home Server obtains several TS(i) from the Foreign Server and uses the skHS-MU to create forged Bills. The Home Server then sends Bill Acknowledgments to the Foreign Server and subsequently payment. It then claims the charges from the Mobile User. However, this is a violation of the principle of the Mobile User holding the Home Server as a trusted entity.

3.

Home Server - Mobile User collaboration The Home Server and Mobile User collaborate to obtain free service from Foreign Servers. The Home Server sends Bill Acknowledgments to the Foreign Server for charges incurred by its Mobile User. However at a later date, the Home Server fails to make any actual payment to the Foreign Server, nor does it charge the Mobile User. Resolution of this may be done using external legal procedures. This scenario is a risk inherent in many systems based on payment on credit. It can be addressed by: (1) requiring the Home Server to send electronic cash to the Foreign Server instead of a Bill Acknowledgment, or (2) requiring Certifying Authorities to exercise due diligence in ascertaining the trustworthiness of a business enterprise.

6.

Performance Issues

We have done a basic analysis of the performance of this protocol. It shows that the performance requirements are not unrealistic. It can be found at http://www.comp.nus.edu.sg/~wangweil/protocol.html While the transaction costs of this protocol may be considered to be relatively high due to its security features, we feel that this is an acceptable trade-off. This protocol needs strong security as it has repeated transactions involving potentially sizable amounts of money. This makes it a potential target for malicious agents, especially in an open system like the Internet. We feel that the coming of high bandwidth network connections and high performance commodity processors should make transaction costs a lesser detriment.

7.

Conclusion

The ubiquity of the Internet and the existence of low cost wireless technologies allows for a new model for providing wireless network access for mobile users. This new model promises better wireless coverage in view of its inherent business model. However, for this to be successful, it is necessary that an appropriate billing protocol, such as this one, be developed and deployed. This protocol can be developed as an extension to Mobile IP, as they share many similarities in their operation. This would spur its deployment, as Mobile IP is an open standard that will likely be used by mobile users.

Acknowledgments We wish to express our deepest gratitude to Dr Y. C. Tay for his unstinting support and guidance. We also acknowledge fruitful discussions with Mr. Fong Kok Khuan. We thank the reviewers whose excellent comments have made this a better paper.

References [1] D. Chaum, A. Fiat, & M. Naor, “Untraceable Electronic Cash,” Advances in Cryptology CRYPTO '88, S. Goldwasser (Ed.), Springer-Verlag, pp. 319-327. [2] CCITT. Recommendation X.509: The Directory Authentication Framework. 1988. [3] X. Lai and J. Massey, “A Proposal for a New Block Encryption Standard”, Advances in Cryptology-EUROCRYPT ’90 Proceedings, Springer-Verlag, 1991, pp 389-404 [4] Lucent Technologies. http://www.wavelan.com

[5] Perkins, C. “IP Mobility Support”, RFC2002, October 1996 [6] R.L. Rivest. “The RC5 encryption algorithm.” CryptoBytes, 1(1): 9-11, 1995. [7] R.L. Rivest, A. Shamir, and L.M. Adleman. “A method for obtaining digital signatures and public-key cryptosystems.” Communications of the ACM, 21(2): 120-126, February 1978. [8] Schneier, B. Applied Cryptography Second Edition : protocols, algorithms, and source code in C. John Wiley & Sons, 1996 [9] Charlie Kaufman, Radia Perlman, Mike Speciner. Network security : private communication in a public world. PTR Prentice Hall, Englewood Cliffs, New Jersey, c1995.

Suggest Documents