In the previous four sections, we have seen how connections are established in the different roaming scenarios. We will now discuss how payment is handled during connections and at the clearing phase at the end of each connection. Recall the goals for payment in all the roaming scenarios:
3.8. The Payment Protocols without a Hop 85
Pay-2: The FN will be paid by the MD for the services the MD uses (Non-
Repudiation).
Pay-3: The FN cannot charge more than negotiated with the MD (Non-
Repudiation).
The idea of micropayment in roaming is that the MD pays one tick to the FN for each small service interval before it is provided. Each tick corresponds to a small amount of money. The worth is chosen so small that losing it without receiving service is not a big issue for the MD. This is required as the MD pays first, and receives service later. Because of the unreliable nature of wireless radio transmissions service could be disrupted even with an honest FN, e.g., from interference.
The FN is able to cash in every single tick the MD has sent, even when the MD disappears. The amount to be paid grows continuously in tick payment schemes, which is a good match for our scenario. The payment protocol used here is similar to the one suggested by Horn and Preneel [119] that was introduced in Section 2.6, but the first tick payment is integrated into the setup phase. In our protocol, the service unit (time or data volume), the size of the service interval, the number of hashes per tick, and the monetary value of a single tick have all been agreed upon during tariff negotiation in the connection setup protocol. The FN has offered a list of tariffs, and the MD has agreed on one of them by signing its payment chain. In the following, the hash function H is always used with an initialization vector
IV , but the IV is omitted from further descriptions. The parameter d describes
the amount of hash operations per tick. In the original micropayment protocol by Pedersen [119], d can be varied during the protocol run. In our solution, d is fixed.
3.8.1 Tariff Negotiation
Each FN broadcasts a list of tariffs that it offers in its service advertising message. These tariffs contain the monetary value per tick payment, the service interval type and size, the amount of hashes per tick d, and the maximum amount of hashes T , e.g., 1 cent per tick, time based, 60 seconds per tick, maximum of 1000 hashes, 1 hash per tick. The MD is able to receive the broadcast messages, and the recommendation system on the MD helps the user select the best tariff based on the data available.
3.8.2 Initialization of Tick Payment
The tariff agreement results in the monetary value per tick payment, T , d, and the service interval type and size. The MD uses this data to generates a hash chain α as such: The MD randomly chooses α0, IV and calculates αi= H(αi−1), i ∈ {1, . . . , T }.
When pairs αi = αj, i 6= j, i, j ∈ {1, . . . , T } appear, the MD starts over with new
random values.
α0 is the beginning of the hash chain and will be kept secret. αT is the end of the
payment chain and will be used in the first tick payment. The first tick is described by αT and αT −d.
86 Chapter 3. Roaming in Wireless Networks
Payer MD
Payee FN 1. Request New Tick
αT −i−d= HT −i−d(α0)
i:= i + d
2. New Tick: αT −i−d
verify:
Hd(αT −i−d)= α? T −i
i:= i + d
Figure 3.14: Basic Tick Payment Protocol
The payment data generated by the MD is summarized in b in the following. b contains the initial values of the payment protocol αT, IV , the ID(FN), a description
of the selected tariff, and the first tick payment (using d hashes) αT −d.
The MD commits to the payment data b calculating a signature on the hash of
b which is sent to the FN. The FN also receives b (in encrypted form for privacy
reasons). The FN verifies the first tick payment by testing Hd(αT −d)= α? T. MD’s signature is verified directly by HN in the online case, or by a certificate verification in the HN offline case. The FN then creates a new signature on h(b) for the MD. Now, both parties are able to prove that the other party has committed to the tariff contained in b.
The FN will now provide service to the MD until the first service interval expires. The expiration is defined by the service interval size, which denotes the time or data volume available to the MD.
3.8.3 New Service Interval
When a service interval is used up, a new tick payment is requested by the FN as illustrated in Figure 3.14. After i ticks were used, the MD provides a new tick payment to the FN by calculating αT −i−d = HT −i−d(α0) and sending αT −i−d to
the FN. The FN verifies that Hd(αT −i−d)= α? T −i. Both parties increase i by d and store i. This can be repeated until i > T , when the payment chain is exceeded. The MD always has to keep track of the service it uses so that it cannot be overcharged by the FN sending early requests.
3.8.4 Clearing Phase with HN Online During Setup
The direct connection without a Hop and HN online will be discussed first. The modifications for use with the HN offline is discussed in Section 3.8.6. The extension
3.8. The Payment Protocols without a Hop 87 payer MD payee FN bank HN 1.sigM D(ID(FN),h(b), sum) 2. E
KM H(ID(MD)),h(b), sum, sigM D(ID(FN),h(b), sum)
3. ok/nok 4. compensation
Figure 3.15: Basic Graceful Clearing Protocol after Online Setup (described in Fig. 3.7)
payee FN
bank HN 1. b, i, αT −i, t∗, CSP Messages 4 and 5
2. ok/nok 3. Compensation
Figure 3.16: Basic Abort Clearing Protocol after Online Setup (CSP = Connection Setup Protocol, see Figure 3.7)
to an MD connecting over a Hop is added in Section 3.9, including the HN offline variant.
The MD can actively close the connection to the FN by sending an ending message. This called the basic graceful clearing protocol, which is shown in Figure 3.15. The MD sends an ending message sigM D(ID(FN), h(b), sum), where sum is the total monetary amount of service used. FN sends MD’s signature to the HN together with all the data needed to verify the signature. The value h(b) is included in the signature to allow the HN to recognize which connection the signature belongs to. The HN has received and signed h(b) during the connection setup phase, after identifying the MD.
The HN will not obtain knowledge of any details the MD and the FN have agreed on. In the interest of MD’s privacy, the HN will only receive information on whom to pay how much. When the MD tries to cheat by choosing a lower amount in the ending message than it has to pay, the HN verification of MD’s ending message will fail, as the sum to pay is transmitted by the FN to the HN. Then, the FN will behave as if the MD aborted the connection.
When a connection ends without MD sending an ending message after i service intervals, the basic abort clearing protocol is run. The FN is able to collect compensation from MD’s HN as shown in Figure 3.16. During the authentication phase as described in Section 3.4.2, the FN has obtained the billing information
b from message 4 and the signature sent from HN on h(b) from message 5. The
last tick payment αT −i was obtained from the MD during the tick payment phase described above. Together, this data allows the FN to prove that the HN has to pay for the services the MD used by using the signatures of MD and HN in the connection setup protocol messages 4 and 5. The FN can prove to the HN that the
88 Chapter 3. Roaming in Wireless Networks
MD is a customer of the HN, the amount of service the FN provided to the MD, and the tariff the MD selected, which results in the amount to be paid. The HN does not have to verify the signatures by MD and itself again; these can be implemented as a database lookup when each successful verification is stored14.In this case, the
HN obtains the details about the tariff chosen by the MD and the amount of service used by the MD.
In both cases, the HN will reimburse the FN and charge the MD. During clearing and billing, the HN learns nothing about the time, date, and location of the service used by its MD with the FN in this session. When the MD aborts without sending an ending message, the HN will obtain knowledge of b and i, which includes the tariff the MD and the FN have agreed on and the amount of service the MD has used.
The HN knows the key KM H from the connection setup protocol and has stored it
together with h(b), so that it can decrypt EKM H(ID(MD)). As the HN has issued ID(MD), the HN is able to resolve ID(MD) to the real identity of the MD, so that the HN is able to bill the MD. To prevent the FN from double charging by using both the graceful and the aborted redemption messages, h(b) is included in the graceful ending message. This way, the HN can detect that these describe the same session. The FN must not accept new connections with an h(b) that was used before. This can be prevented using a lookup of previously used values, or by modifying T and
d in the offered tariffs.
The clearing between the FN and the HN can be done at anytime after the end of MD’s service usage, e.g., the FN can clear all the connections for each HN at the end of the day. The MD can also send the graceful ending message earlier, e.g., in regular intervals. Should the connection abort later, only the details about the remaining shorter session are revealed to the HN.
3.8.5 Discussion of the Payment Protocol
Recall that a fundamental property of micropayment schemes is the very low value of a single tick payment. Therefore, it is not a problem when the MD provides the first tick payment during setup and the FN does not provide service. The same holds when the connection aborts after a number of intervals, when the MD might have paid for one more tick than it could use.
The security of hash chain based micropayment schemes is well researched. Given
αi, no one can calculate αi−j for any j > 0 because H is a preimage resistant hash
function. Therefore, new ticks to an existing chain cannot be forged (Pay-3). The identity of the payer is bound to the payment chain because of MD’s signature in message 4, which is validated by the HN (Pay-1). The identity of the payee is also bound to the payment chain because the signature contains ID(FN), which is confirmed by the HN. Therefore, payments cannot be stolen (Pay-1).
Because all payment chains generated by the MD are validated over the same HN, contain a fresh value h(b) (inherited from the fresh values for αT, IV ), and as the HN
3.8. The Payment Protocols without a Hop 89 payer MD payee FN bank HN
1.sigP C(ID(FN), αT, IV, sum) 2.sigP C(ID(FN),α
T, IV, sum),
PC,αT, IV, sum
3. ok/nok 4. compensation
Figure 3.17: The Basic Graceful Clearing Protocol after Offline Setup (described in Fig. 3.11) payee FN bank HN 1.sigP C tM D, tF N, h(b),ID(FN),PC,
tM D, tF N, b, i,PC,last tick αT −i
2. ok/nok 3. compensation
Figure 3.18: The Basic Abort Clearing Protocol after Offline Setup (described in Fig. 3.11)
keeps records of accepted clearing messages, a payment chain cannot be used more than once (Pay-3). The FN cannot be tricked into accepting the same payment twice as the signature in message 4 contains tF N, which is chosen by the FN (Pay-
2). The FN does not learn the identity of the MD during payment or clearing,
as only EKM H(ID(MD)) is disclosed to the FN, which is different for each session
(inherited from the fresh values tM H and tHM).
The MD and the HN are able to collude to obtain free service from FN by HN accepting bad signatures from MD. This is an inherent risk in roaming systems when payment is done after the service was provided. The FN will detect this behavior and is able to revoke the roaming agreement to no longer accept connections from HN’s clients.
The FN and the HN are able to collude so that the FN can identify the MD. This is discussed in Section 3.12.3 on lawful data retention.
3.8.6 Modifications for use with HN Offline During Setup
The basic tick payment protocol operates exactly like in the HN online case. Thus, the service usage phase remains unchanged. However, changes to the setup and clearing protocols are required. The HN Offline Connection Setup Protocol was described in Section 3.6. The clearing protocols after the HN Offline Connection Setup Protocol are described in the following.
90 Chapter 3. Roaming in Wireless Networks
Recall the fundamental difference to the online solution is that the MD does not use a single signature key, but the one from the pseudonym certificate (PC) the MD presented to the FN (and the HN) to set up this connection.
In the setup phase (described in Fig. 3.11), the FN is able to verify MD’s signature directly, as the MD has presented its PC to the FN. The confirmation by the HN is given implicitly by HN’s signature on the PC and by HN not having revoked the PC.
In the clearing phase, the pseudonym certificate PC used by the MD in the HN offline setup protocol is forwarded to the HN by the FN. As the HN has issued all PCs, the HN is able to resolve the PC to the MD. Therefore, the HN is able to identify and bill the MD.
The basic graceful clearing protocol after HN offline setup is shown in Fig- ure 3.17. Compared to the online variant, the PC is used instead of the encrypted identifier EKM H(ID(MD)). The MD creates a signature on ID(FN), αT, IV, sum.
This includes how much to pay (sum) to whom (ID(FN)) from whom (signature by PC) and uniqueness (αT, IV ).
Figure 3.18 shows the basic abort clearing protocol after HN offline setup. It is executed when the connection ends after i service intervals, but the MD did not send a graceful ending message, or when the HN rejects MD’s signature in the basic graceful clearing protocol. The FN is able to prove to the HN that the MD agreed on a tariff by replaying sigP C tM D, tF N, h(b), ID(FN), PC from the setup
protocol and by disclosing the payment data b and the PC to the HN.
To prevent the FN from double charging by running both the graceful and the abort protocol, αT and IV are included in MD’s signature, as they are unique to each
connection. These are not normally required for the graceful billing, but do not leak sensitive information regarding MD’s privacy: IV, α0 is randomly chosen by the MD, and αT is calculated to HT(α0) in the connection setup protocol. As in
the connection setup protocol, the FN does not learn the identity of the MD.