CARDIS '02 Paper
[CARDIS '02 Tech Program Index]
MICROCAST: Smart Card Based (Micro)pay-per-view for Multicast Services
Josep Domingo-Ferrer, Antoni Martınez-Ballesté and Francesc Sebé
With the increased availability of broadband fixed and mobile communications, multicast content delivery can be expected to become a very important market. Especially for wireless multicast delivery, it is important that payment collection be fine-grain: the customer should pay only for the content that she actually consumes. This can be achieved by using pay-per-view based on micropayments. This paper proposes the first method for enabling pay-as-you-watch services in a multicast content delivery environment. On the customer's side, micropayment generation is implemented in a smart card which can be plugged into the customer's receiving device (computer, digital video receiver, PDA, mobile phone, etc.). Micropayment collection and verification are distributed among multicast routers, which avoids bottlenecks inherent to many-to-one payment transmission.
Keywords: Multicast delivery, Pay-per-view, Pay-as-you-watch, Micropayments, Smart cards in the Internet.
Most multimedia delivery services operate in multicast mode to send content over the Internet. By using multicast, one single data stream can reach hundreds, thousands and even millions of target media players.
This paper describes a method for enabling pay-per-view services in a multicast content delivery environment. On the customer's side, micropayment generation is implemented in a smartcard which can be plugged into the customer's receiving device (computer, digital video receiver, PDA, mobile phone, etc.). Micropayment collection and verification are distributed among multicast routers, which avoids bottlenecks inherent to many-to-one payment transmission.
Section 2 gives some background on multicast communication; the use of pay-per-view and micropayments in multicast is also approached. Section 3 describes the architecture of MICROCAST, a system for pay-per-view multicast content delivery. The MICROCAST micropayment protocol suite is fully described in Section 4. Finally, Section 5 contains some conclusions and suggestions for future work.
Depending on the number of receivers, three types of communication can be distinguished:
If a source is to communicate with receivers, one could naively think of using unicast communications (which results in the source being an output bottleneck) or one broadcast channel (which results in the entire network being flooded). Both solutions are wasteful in terms of bandwidth. It should be noted that the Internet is nowadays already full of millions of IP packets only controlled by their time-to-live or by the TCP protocol.
A better option to avoid increasing network congestion is for receivers to join a multicast group and have the content sent to them by using their multicast group IP address [5,14]. A multicast group is a set of receivers that are interested in receiving a particular kind of information.
Efficient multicast design and implementation is currently an open issue. The multicast task is carried out by multicast routers, which join previously established multicast groups identified by a multicast IP address1. These routers are capable of sending the data flow to multicast group .
The basic tasks to be performed in multicast communication are: advertise the multicast session, manage group enrollment by the customers who want to receive the stream and, concurrently to group enrollment, build the multicast routing tree. Several multicast protocols have been proposed in the literature, such as MOSPF, PIM-DM, PIM-SM.
The name ``pay-per-view'' is certainly misleading. In current digital TV platforms, a fixed monthly fee is paid to subscribe to a basic package of channels and services. It is also possible to view some special ``pay-per-view events'' (e.g. movies, football matches) by paying in advance the price corresponding to the event. This form of pay-per-view means that the content is viewed after the customer has paid. There are at least two problems with the fee collection scheme just described. One problem is that the customer pays for a basic offer that is usually expensive for her. The other problem is that, in pay-per-view events, the customer pays for the whole piece of content: if she wants to stop watching anytime, she is losing a part of her money. Pay-per-view as contents are being streamed from the server to the customer (pay-as-you-watch) seems an option that fits better the customer needs. Successive payments can be performed every minute, for example. If a customer switches her player off, she only has paid for the minutes viewed so far. Of course, these frequent payment will be small ones, so credit card transactions or electronic payment systems like SET are too expensive, too complicated or both .
The operating costs of standard electronic payment systems are unaffordable for small amounts and can be split into communication and computation costs, the latter being caused by the use of complex cryptographic techniques such as digital signatures. Micropayments are electronic payment methods specifically designed to keep operating costs very low. In most micropayment systems in the literature, computational costs are dramatically reduced by replacing digital signatures with hash functions. For example, this is the case of PayWord and Micromint, where the security of coin minting rests on one-way hash functions.
The main barrier to using traditional micropayment schemes for fee collection in multicast environments is their lack of scalability: a large number of receiving subscribers eventually overload the source with payment implosion. The MICROCAST protocol achieves scalability by distributing the effort of micropayment collection and verification among multicast routers. Unlike traditional micropayment schemes, MICROCAST does not concentrate on minimizing computation for micropayment generation and verification. By requiring micropayments to be less frequent (say every few minutes) and verification to be distributed, MICROCAST can still use short-exponent discrete exponentiations and provide the content source with a proof that every customer has paid.
More specifically, the scalability of our system is based on the following properties not fulfilled by conventional micropayment schemes (which are inherently unicast):
Note 1 As it can be seen in Section 4.4 below, using the discrete exponentiation as a one-way function is justified by its homomorphic properties, which allow payment aggregation and single-step verification and are not shared by the (faster) one-way hash functions.
Multicast routers form a group that receives a multicast data stream. The router will possibly send the info to a hub that floods all its output connections, thus making the information reach every node in the subLAN, including nodes whose customers have not paid for the content. Cryptography should be used to prevent cheaters from being able to view the content by using packet sniffers. Customers in the multicast group have a decoding key to be able to decode the content they receive.
Hence, legitimate customers are those who pay every multicast period (a multicast period typically lasts a few minutes). When a customer does not pay, she will be considered non-legitimate; in this case, a rekeying procedure will start which consists of distributing a new decoding key to every remaining legitimate customer. As a result, the removal of a group member will involve as many unicast transmissions as legitimate customers remain in the group. Fortunately, rekeying reaches a maximum cost of when using tree structure controls[12,1]. Even if rekeying is an important multicast issue, the reader of this paper only needs to keep in mind that it is the procedure started when a customer in a multicast group is removed due to lack of valid payment or when a new customer joins the group.
As it was pointed out in Section 1, MICROCAST is a pay-as-you-watch system for multicast content delivery. A typical application for MICROCAST could the pay-as-you-watch video distribution to thousands of customers. By using her smart card plugged into her video receiver, a customer can join a multicast group when she is interested in watching an event. After joining a group, the customer makes a micropayment every period to keep watching the event.
In a conventional micropayment system, a bottleneck would arise at the video source as a result of micropayment collection, because thousands of coins arrive every period2. RFC 3170 on multicast applications recommends that multicast protocols should be able to use the multicast router link to provide bidirectional communications instead of using unicast channels to communicate receivers with the source. The MICROCAST architecture follows that design principle: multicast routers handle customers and coins, which results in a dramatical reduction of the amount of payment data sent to the content source.
The MICROCAST system consists of a source, a set of multicast routers, the customer smart cards and receivers, a rekeying system and a bank (see Figure 1). Each component is described next:
The MICROCAST protocol suite consists of protocols for bank setup, customer subscription, multicast session join, micropayment, customer removal, coin redemption and subscriber certificate revocation.
As can be inferred from the previous section, the bank is a trusted party. It has a public/private key pair which is used to issue customer subscription certificates. The bank setup protocol works as follows:
Protocol 1 (Bank setup) The bank does:
We next show that publication of does not turn factoring into an easy problem. After Protocol 1, an intruder knows , which is a divisor of . Equivalently, exists such that . Note that the intruder does not know . Therefore, the only strategy to find is by brute search until an is found such that is a divisor of . Now, according to Protocol 1, and ; therefore, the intruder only knows that , so brute search of is computationally infeasible.
In order to be able to use the system, a customer needs a subscription certificate. Through this certificate, the bank certifies that the customer has a bank account which backs the customer's payments. Subscription certificates are only valid for a period (e.g. one day) and are generated using the protocol below. Short certificate validity periods allow implicit revocation to be used in the way explained in . The duration of period is a trade-off between the cost of key generation and the risk of revoked keys being re-used as described in .
Protocol 2 (Customer subscription)
The security of the private keys generated in Protocol 2 is based on the difficulty of computing discrete logarithms in the subgroup of size generated by . This problem is similar to the modulo discrete logarithm problem used in .
Let us assume that, at micropayment period and at public key validity period , a set of customers wish to join a multicast session (see Section 3 for an explanation of what a micropayment period is). To keep the discussion simple and without loss of generality, we assume that a session starts and ends within the same public key validity period . The following joining protocol is used:
Protocol 3 (Session join)
Every time a period finishes, a customer must perform a micropayment to keep receiving the content during the next period. The micropayment collector (i.e. the router in charge of a group of customers) asks all customers in his group to perform the next payment as follows:
Protocol 4 (Micropayment request) The micropayment collector does:
Customers in a group react to micropayment request by generating a coin using the protocol below:
Protocol 5 (Coin generation) The smart card of each customer in a group does:
Coins are generated by customers that correspond to the multicast tree leaves. In the last step of Protocol 5, coins are sent by customers to parent routers. Such routers check the validity of the received coins and aggregate valid coins. Aggregation uses the homomorphic property of the discrete exponentiation (namely that ), which is one strong argument in favor of using the discrete exponentiation as one-way function (see Note 1). The aggregated coin is then forwarded by the verifying router to his parent router and so on up to the tree root (micropayment collector). Thus, depending on its level, a router can receive two kinds of coin:
The protocol to aggregate coins by an intermediate router is as follows:
Protocol 6 (Coin aggregation)
The protocol to check coin validity is:
Protocol 7 (Coin validity check)
Lemma 1 Assuming that the discrete logarithm problem as sketched in Protocol 1 and the RSA problem are difficult, coin forgery by an intruder is infeasible.
Proof: To impersonate customer and mint a single coin belonging to at public key validity period , an intruder knows and and must find and such that Equation (1) is satisfied. There are two ways to proceed:
Lemma 2 The security of a customer's private key does not decrease as the number of coins she mints increases.
Without loss of generality, compare the situation where one
coin has been minted with the situation where two coins have
been minted. Assume one coin has been generated during
and public key validity period . Then the following
where, only and are known to possible intruders (such quantities are part of the coin). Thus, there is one equation and two unknowns and , so cannot be determined. If a second coin is generated during micropayment period
the number of equations increases to two, but there are now three unknowns , and . In general, it can be seen that generation of coins results in equations with unknowns, one of which is the customer's private key . .
Customer removal from a group is caused by lack of valid payment. There may be two situations behind the lack of valid payment: 1) a customer does not send any coin to her parent router; 2) a customer sends an invalid coin to her parent router. Both situations are handled by the following protocol:
Protocol 8 (Customer removal)
During a multicast session, the micropayment collector stores the final aggregated coin for each performed micropayment. This coin contains a list including the identifiers of all customers that performed a payment. When the number of collected coins is large enough, the micropayment collector contacts the bank in order to redeem them.
Protocol 9 (Coin redemption)
It is possible for a customer to run out of funds before all of her certificates expire. In this situation, it would be possible for her to perform micropayments not backed by enough funds in her bank account. This situation is detected by the bank during coin redemption. In this case, the bank would revoke all her subscription certificates for future time intervals. The implicit revocation mechanism described in  is used: the bank does not supply any more encrypted private keys to the customer's smart card for joining the session in subsequent periods (Protocol 3).
A micropayment protocol suite for multicast pay-per-view content delivery has been presented. The customer is represented by her smart card in all protocols in the suite. The proposed scheme has been simulated and works well as long as synchronization between customers is maintained. The main goal of the protocol is to to distribute micropayment collection so as eliminate the bottleneck associated to Mto1 applications. Future work will be directed to scenarios where synchronization within a multicast group has been lost. A second line of work is to speed up coin generation by the customer smart card and coin validity check by routers: this would require replacing the discrete exponentiation with a faster homomorphic one-way function.
This work has been partly supported by the European Commission under project IST-2001-32012 ``Co-Orthogonal Codes'' and by the Spanish Ministry of Science and Technology and the European FEDER Fund under project TIC2001-0633-C03-01 ``STREAMOBILE''.
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.50)
The command line arguments were:
Antoni Martinez 2002-09-19
This paper was originally published in the
Proceedings of the Fifth Smart Card Research and Advanced Application Conference,
November 2122, 2002, San Jose, CA, USA
Last changed: 11 Oct. 2002 aw