DOC

Micropayments for Mobile Networks

By Mike Walker,2014-07-01 11:28
16 views 0
Micropayments for Mobile Networks

    Micropayments for Mobile Networks

    Michael Peirce, Donal O'Mahony

    Networks & Telecommunications Research Group,

    Computer Science Department, Trinity College Dublin, Ireland

    {Michael.Peirce | Donal.OMahony}@cs.tcd.ie

    http://ntrg.cs.tcd.ie/

    Abstract –– As mobile communications become increa-and scalability it is desirable to remove the need for this

    communication for billing purposes. singly sophisticated and ubiquitous, traditional mobile

    billing with its implicit trust relationships, will no long-

    er be adequate. With a large number of mobile net-2 MICROPAYMENTS works, a huge variety of value added service providers, A roaming user is likely to use many different network and many millions of roaming users, it is desirable to operators and value added service providers (VASPs). remove any unnecessary trust in order to increase se-Therefore it is desirable to be able to make efficient re-curity and to provide incontestable charging. We peated payments of small amounts, called micropayments, present a multi-party micropayment scheme that al-to all the parties involved in a call as the services are used. lows all parties involved in a call to be paid in real-time. Secure use of credit cards, electronic checks, and digital A pricing contract is used to allow dynamic tariffs for cash have been proposed to pay for services across a net-each leg of the call route and to prevent fraud. During a work [1]. However each of these macropayment instru-call a mobile user releases a stream of micropayment ments have a minimum transaction overhead, which make tokens into the network in exchange for the requested them unsuitable for repeated transactions of small amounts. services. We discuss the problems of mobile billing, In contrast micropayment systems minimize the communi-refer to related work in micropayment technology, and cations and computational overhead. A micropayment outline the design goals of the protocol before present-should be verifiable off-line without needing to contact a ing the details of our solution. third party to prevent double spending or cheating. In order

    to verify a payment efficiently the number of computation-1 BILLING IN MOBILE NETWORKS ally expensive operations, such as public key cryptography, In the fixed network a call detail record (CDR) or toll needs to be minimized. ticket is created for each call. This typically contains de-Micropayment research has concentrated on repeated tails about the call source, destination, duration and route. payments to a single vendor. Many of these schemes are The CDRs are forwarded to a central database where pe-based on the use of one-way hash functions to generate riodically prices are applied to generate a customer’s bill. chains of hash values, including Pederson’s phone ticks[2], Basic CDR billing has been extended to mobile networks PayWord[3], NetCard[4] and iKP micropayments[5]. The where online authentication with a home location register central idea of these schemes is that a user generates a hash

    (HLR) is used to identify the call source. If the user roams chain of length N by applying a hash function N times to a into another mobile network then the CDRs created while random value P to obtain a final hash P. The user com-N0placing calls must be transported back to the home network mits to the hash chain by digitally signing the final hash P, 0for settlement. The visiting network operator (NO) will bill and sends it to the vendor. For each micropayment the user the home network operator, perhaps at a wholesale rate. In releases the pre-image of the last hash sent to the vendor. turn the home operator will bill the mobile user. Billing P is released for the first payment, P for the second and 12based on CDRs cannot guarantee incontestable charging or so on. Since the hash function is one-way, only the user payment for any of the parties involved. could have generated the hash value. The vendor later re-To ensure payment some mobile operators have intro-deems the hash values from a broker with whom the user duced prepaid solutions. These are based on temporary has an account. prepaid accounts at the HLR. The CDRs are examined The ESPRIT project CAFE[6] used Pederson’s scheme immediately, a process known as hot billing, to allow au-to pay a single network operator for a phone call. Later, the tomatic call termination when the account value reaches ACTS project ASPECT[7] used the same scheme to pay a zero. Due to the need to track the account balance on-line VASP for additional services. Our solution is novel in that these solutions do not normally allow roaming to another it is the first time hash chains have been used to pay mul-mobile network. Those that do allow roaming are based on tiple parties at the same time. a call back service through the home network. This pre-

    vents the foreign network from having to monitor the ac-3 MULTI-PARTY MICROPAYMENTS FOR count value since the call will be initiated and tracked by MOBILES the home network. Future mobile systems will involve a large number of Current mobile billing relies on both online and offline different public and private network operators. Through contact with a home network, whether it is for prepaid hot these users will be able to access a variety of on-line ser-billing, authentication, or CDR exchanges. For efficiency vices provided by an even larger number of competing

    Network

    Operator 2

    Value-added SP3

    Network

    Operator 1

    Value-added SP1Visiting mobileNetwork

    Operator 3

    Value-added SP2

    Figure 1: Multi-Party Real-Time Payment VASPs. A mobile user might arrive in a new network, blacklists with stolen identities and equipment does place calls that are routed through several independent not scale well. networks, and use the services of both local and remote ? No user digital signatures. Use of digital signatures value-added providers. Such a scenario is illustrated in implies the existence of a public key infrastructure Figure 1. (PKI) with at least one certificate per signer. In addi-For example, when a mobile visitor arrives in a new city tion the validity of a certificate must be checked in or-he places a call through the local mobile network operator der to verify a digital signature. With millions of users, to VASP1 to obtain a city traffic report and directions to maintaining such a PKI is a huge task. A signature his hotel. He then rings an acquaintance, another mobile from a random roaming user, of which there are mil-user located in the same network, to inform her of his ar-lions, will still not guarantee payment. rival. Finally, he places a long distance call, which is ? Prevent inter-operator fraud. CDRs can be forged and routed through two independent networks, to the remote it should not be possible for NOs to receive payment VASP3 who provides him with voicemail services. Our for services which were not used. solution employs micropayment technology to allow all ? Remove roaming agreements for billing. A negotiated entities involved in the call to be paid as they provide the bi-lateral agreement between operators should not be services. necessary for a roamer to make calls from a foreign

    network. 3.1 Protocol Goals ? Verifiable dynamic tariffs. It should be possible to fix

    the charge for a call depending on the service re-The protocol was designed to solve the problems that

    quested and current network conditions. The mobile traditional CDR billing will face in future mobile networks

    user should be able to verify that charge before pay-and has the following goals:

    ment begins.

    ? Real-time payment anywhere. A mobile user should

    3.2 Purchase of a Payment Chain be able to pay all parties involved in a call in real-time

    without need for authentication or contact with a dis-A mobile user buys prepaid tokens, through their phone tant home location register. This will also remove the or terminal, from a third party broker, using an existing costs associated with subscriber billing. macropayment system. The user nominates any specific ? Remove user accountability. Since mobile users are service provider (SP), called the enforcer, through whom

    the greatest number of entities within the system they the tokens will be spent. Service providers include both

    should be trusted the least. Unlimited credit with post-NOs and VASPs.

    fact punishment is too open to abuse in a global sys-The broker creates tokens by repeatedly applying a one

    tem with hundreds of millions of users. The use of way hash function, such as the Secure Hash Algorithm

    (SHA) [8], to a root value P to generate a payment hash X

    User ASP1 (enforcer)SP2SP3

    (a value-added SPEndorsement chain EPayment chain Pin this case)

    Comm, P, Comm, E P0E0

    Assemble pricing contract

    P ,E ,EP11111H(P)=P? H(P)=P? H(P)=P?P101010H(EH(E)=E?)=E?1010

    PP ,E222

    Each SP validates

    hashes as they arrive

    PP ,ENNN

    Bearer and value-added services provided (user plane)

    Figure 2: Mobile pays all SPs with same Payment Hash, with SP1 as Enforcer

    chain. The broker commits to the hash chain, or promises create a record of the call, and link a single payment com-to honor its value, by digitally signing the payment chain mitment to multiple SPs for the call. The contract fields are: commitment (Comm), consisting of the final hash (P), P0? TID. Transaction identifier for the contract, partly the chain length, the total value of the chain, and the identi-generated by each SP. ty of the enforcer through whom it must be spent: ? SPs. The identity of each NO and VASP involved in the call. Comm = {P, Length, Chain_value, Enforcer}Sig P0Broker1? Charge. Charging mechanism and tariff rate for each SP. The commitment shows that each payment hash value . Payment chain commitment spendable ? CommPfrom the chain represents pre-paid value, redeemable at the through the enforcer. broker. The value of a single payment hash is later fixed, ? P. Starting payment hash from the chain. For a new Starton a per call basis, by the enforcer. This allows the same chain this will be P. For a partially spent chain this 0hash value to be used to pay all parties. The mobile user is will be the last spent hash value. given Comm and the secret P from which the chain val-PX? Start. Position of P in the payment chain. Startues can be generated. ? P_value. The value per payment hash for the duration

    of the call, fixed by the enforcer. 3.3 Pricing Contract ? Comm. An endorsement chain commitment, created ETo make a call the mobile user must have a payment and signed by the enforcer SP. This is used to prevent chain commitment for any one of the NOs or VASPs in-double spending of payment hashes. volved in the call. Figures 2 and 4 show the same call be-? Redeeming brokers. Each SP fixes the broker through ing made but with payment chains for different enforcer whom they will redeem payment hashes for this call. SPs along the route. In Figure 2 the local network operator, SPs within the same geographic area might use the SP1, is the enforcer. In Figure 4 the payment chain must be same local broker to clear payments with. spent through SP3. For example this could be a voicemail provider. The enforcer is responsible for ensuring that the pricing The user sends the call request details and the payment contract is constructed correctly using a three-way hand-chain commitment to the enforcer. A signed pricing con-shake protocol. Each SP signs the contract to prove that tract, shown in Figure 3, is then generated by the SPs in-they took part in the call. The enforcer always signs the volved in the call. Its purpose is to allow verifiable contract last to prevent partially signed contracts being dynamic tariffs, fix the starting hash in the payment chain,

    TID SP(s) Charge Comm P Start P_value Comm R_Broker(s) SigPStartESP(s)P Total_value Enforcer SigE Chain_length Enforcer Sig0Broker0Enforcer

    Figure 3: Contents of a Pricing Contract, Payment and Endorsement Commitments

    used for fraud. The pricing contract is presented to the user hash function on it to obtain the previous payment hash, in . The enforcer forwards the for agreement before the call is setup. 0this case the starting hash Ppayment hash and his own endorsement hash to the other

    SPs. Each SP independently verifies both the payment hash 3.4 Releasing Payments during a call and the endorsement hash. Since the hash function is one Payment is ongoing, with the user releasing payment way, payment hashes cannot be forged, and knowledge of hashes at regular intervals. For a voice call this might be the payment hash is proof of payment. When the SPs re-every second. In return for a valid payment the SPs contin-thdeem P, the 40 payment hash, they will be paid 40, 200, 40ue to provide the service they agreed to in the pricing con-and 80 cents respectively. tract. If the user does not receive these services he can The enforcer keeps a record of how much of a payment terminate the call by not releasing any more hashes. The chain has been spent and prevents double spending of total call cost per unit time, or per data unit transmitted, is payment hashes. The purpose of the endorsement chain is the sum of each SPs tariff rate in the pricing contract. The to prevent SPs from redeeming parts of a payment chain to enforcer fixes each payment hash to be worth the total cost which they are not entitled. A valid endorsement hash from per charging unit. For example in Figure 2 each SP might the enforcer gives a SP, identified in the corresponding charge 1, 5 and 2 cents per second respectively for a voice pricing contract, the right to redeem a valid payment hash. call. The enforcer assigns each payment hash to be worth 8 An endorsement chain has no monetary value and is spe-cents in the pricing contract. cific to a single call. Unused endorsement hashes are se-Every second the user releases a payment hash, in this curely deleted after the call by the enforcer. Unspent case starting with P from a new payment chain. The en-1payment hashes can be spent later on a different call, using forcer verifies that the payment is valid by performing one

    User ASP1SP2SP3 (enforcer)

    Endorsement chain EPayment chain P

    Comm, P, Comm, E P0E0

    Assemble pricing contract

    PP111PH(P)=P?10E1H(P1H(P)=P? )=P? 1010EH(EH(E)=E?)=E?1010

    PP22

    E2

    Each SP validates

    hashes independently

    PPNN

    EN

    Bearer and value-added services provided (user plane)

    Figure 4: Mobile pays all SPs with same Payment Hash, with SP3 as Enforcer

    Figure 5: Screenshot of Multi-Party Micropayment Client Application with NOMAD

    different SPs, through the same enforcer. The payment chain details are also given in text form in the

    balance details window below the balance counter. The

    graph and balance details are updated after each call. 3.5 Redeeming Payment Hashes

    The micropayment details can be hidden from an end At the end of the day each SP will redeem the highest user by only displaying the Euro counter, allowing the bal-spent payment hash from the call with their preferred bro-ance to be monitored as a call progresses. The system has ker. The broker will only accept a payment hash from an also been demonstrated with other popular multimedia identified SP if a corresponding endorsement hash and applications. Our prototype measurements show that the pricing contract accompany it. Only the redeeming broker, system is efficient enough to handle frequent sub-cent mul-fixed in the pricing contract by each SP, will redeem the ti-party payments. The bulk of the computation takes place hashes. The broker knows how much to pay each SP from in generating the contract signatures at call setup. the contents of the pricing contract. To verify the payment

    the broker will perform n hash functions on each chain, 5 CONCLUSION where n is the number of payments made, to obtain the

    starting payment and endorsement hashes. The redeeming Current billing methods for mobile networks will be-brokers later clear payment chains in bulk with the issuing come increasingly restrictive and inadequate as both the broker using a financial clearing network. number of service providers and roaming users grow. To

    solve these problems a real-time multi-party micropayment

    scheme has been proposed. It uses a single pre-paid hash to 4 STATUS

    pay all parties involved in a call in real-time. The idea of An experimental prototype has been developed in Java an enforcer and an endorsement chain were introduced. using cryptographic libraries to supply the SHA hash func-These allow unused pre-paid payment hashes to be spent tion, digital signatures and certificate functionality. through different entities without fear of double spending. A screenshot showing a mobile user making payments Previous micropayment research has concentrated on pro-for a voice telephony call is given in Figure 5. The voice viding payment to only a single party. call was demonstrated using NOMAD[9], an application The scheme improves over current mobile billing me-based on a popular Internet Telephony package. A thods by removing the need to trust users, eliminating the NOMAD call is shown in progress in the window at the need for online user authentication with a home register, right of the screenshot. The counter in the center of the and avoiding the use of user certificates. Incontestable screen shows the current balance, in Euro, for the client charging is provided with flexible dynamic tariffs. In addi-micropayment application. The counter decrements as tion the need for inter-operator trust and complex billing payment hashes are released to the multiple parties provid-agreements are removed. The scheme can be applied, not ing the call. The three buttons below the counter are used only to traditional mobile networks, but also to other sce-to stop payment hashes being released, view the balance narios where real-time multi-party payment is desirable details and display the records of previous calls respective-such as Internet Telephony and wireless ad hoc networks. ly.

    The graph to the left of the screen is a visualization of 6 REFERENCES the payment chains currently being held by the mobile user.

    In this case there are two chains where Provider1 is the [1] D. O'Mahony, M. Peirce, H. Tewari, Electronic Pay-

    enforcer, worth ?20.00 and ?6.72 respectively. Some to-ment Systems, Artech House Publishers, Bos-kens have already been spent from the second chain. There ton/London, 1997. is also a chain worth ?10.00 which must be spent through

    Provider2 and another worth ?15.00 specific to Proivder3.

[2] T. Pederson, "Electronic Payments of Small

    Amounts", Security Protocols, LCNS 1361, pp. 59-68,

    M. Lomas, Ed., Springer-Verlag, Berlin 1997.

    [3] R. Rivest, A. Shamir, "PayWord and MicroMint:

    Two Simple Micropayment Schemes", Security Pro-

    tocols, LCNS 1361, pp. 69-87, M. Lomas, Ed., Sprin-

    ger-Verlag, Berlin 1997.

    [4] R. Anderson, H. Manifavas, C. Sutherland, "NetCard

    - A Practical Electronic Cash System", in Fourth

    Cambridge Workshop on Security Protocols, Cam-

    bridge, UK, 1996.

    [5] R. Hauser, M. Steiner, M. Waidner, "Micro-payments

    based on iKP", in 14th Worldwide Congress on

    Computer and Communications Security Protection,

    pp. 67-82, Paris, 1996.

    [6] J. Boly, A. Bosselaers, R. Cramer, R. Michelsen, S.

    Mjolsnes, F. Muller et al., “The ESPRIT Project

    CAFE - High Security Digital Payment Systems”, in

    Computer Security - ESORICS ‘94, LNCS 875, pp.

    217-230, Springer-Verlag, Berlin 1994.

    [7] G. Horn, B. Preneel, “Authentication and Payment in

    Future Mobile Systems”, in Computer Security

    ESORICS ’98, LNCS 1485, pp. 277-293, Springer-

    Verlag, Berlin 1998.

    [8] National Institute of Standards and Technology

    (NIST). FIPS Publication 180: Secure Hash Stan-

    dard (SHS), May 1993.

    [9] D. O'Mahony, L. Doyle, H. Tewari, M. Peirce,

    "NOMAD - An Application to Provide UMTS Te-

    lephony Services on Fixed Terminals in COBUCO", rd ACTS Mobile Communications Summit, Vol 1, in 3pp. 72-76, Rhodes, Greece, June 1998.

Report this document

For any questions or suggestions please email
cust-service@docsford.com