A Micro-Payment Scheme EncouragingCollaboration in Multi-Hop Cellular Networks

Markus Jakobsson1 Jean- Pierre Hubaux2 Levente Buttyán2,3

1 RSA Laboratories2 Swiss Federal Institute of Technology – Lausanne (EPFL)

3 Budapest University of Technology and Economics

                 

          

Multi-hop cellular

Advantages:• reduced energy consumption • reduced interference • number of base stations can be reduced / coverage of the network can be increased• ad hoc networking

Our model

Asymmetric multi-hop cellular:– multi-hop up-stream

– single-hop down-stream

Energy consumption of the mobiles is further reduced

Problem statement

While all mobile nodes stand to benefit from such a scheme, a cheater could benefit even more by being served without serving others (selfish behavior)

Approach

Introduce benefit for collaboration

… without strong security assumptions

… and without large overhead

Idea

Attach micropayments to packets

… allowing collaborators to get paid

… while avoiding and detecting various attacks

A New Twist

Traditional approach for (micro) payments:

“one transaction – one payee – one payment”

New approach:

“one transaction (packet) – several payees – several payments”

Note:– the payer (sender) does not always know who the payees

are (i.e., who is on the route)

– … he may not even know the number of payees (length of the route)

Contributions

1. Technique to determine how to route packets (may be based on size of reward, remaining battery life, how busy a node is, etc.)

2. Technique to allow base stations to verify payments, drop packets with invalid payments (nodes won’t have to do this – makes their life easier)

3. Technique for aggregation of payments (to minimize logs and requirements on storage and communication)

4. Auditing process to detect misbehavior

Related work (1)

• (Marti et al.) Watchdog and path rater does not discourage misbehavior

• (Buchegger, Le Boudec) Reputation-based collaboration vulnerability due to “flattering collusions”

• (Zhong et al) Sprite: Reputation w/o tamperproofness not lightweight, only works for “dense” networks

• (Buttyan, Hubaux) Tamperproofness & micro-payments strong assumptions, vulnerable to collusions

• (Nisan, Ronen) General treatment of collaboration

Related work (2)

• (Rivest) Aggregation using probabilistic payments not applied to routing/collaboration

“This is a $256 payment iff the preimage to your hash value y ends in 00000000”

• (Micali, Rivest) Prob. payments with deterministic debits bank deals with variance, not for routing/collaboration

• payee obtains lottery tickets

• payer pays per serial number (used consecutively)

• bank watches for deposits with duplicate serial numbers (this means cheating!)

The solution in a nutshell

attach payment token

check if the token is a winning ticket

if so, file claim

check token

if correct, deliver packet

submit reward claims

accountingandauditinginformation

debit/credit accounts

identifyirregularitieshonest

selfish

Protocol (1)

Setup

Connectivity graph

Shared

user key Ku

(Ui, di, Li)

user distance level id to BS required

Shared

user key Ku

Protocol (2)

Packet origination

Packet transmission

p, L, Uo , packet

level originator’s MACKu(p, L)

id

forward requestwait for acksendDid I win?

to next user Ui with sufficient level Li (<L)

Protocol (3)

Network processing

MAC correct?(otherwise drop)

Send towards destination

Collect auditing information(send in batches)

Reward claim

• U forwarded (L, p, Uo, )

• checks if f (, Ku) = 1

• if so, stores claim (U1, U2, , L)

• all such claims sent to base station when “convenient”

Well…did I win?

receivedfrom

sentto

What is f ?

“Safe” approach: a one-way function

“Quick & Dirty” approach: check Hamming distance between and Ku

(Note that claims leak key information - be careful!)

Accounting and Auditing

• Debit based on number of packets received by base stations

• Credit based on number of accepted claims

• Give credit both to claimant and his neighbors!– stimulates forwarding even for losing tickets

– increases granularity

• Check for “irregularities” (punish offenders!)

Potential attacks

• Packet dropping (“I’ll take this, oops”)

• Selective acceptance (“winning tickets only, please”)

• Ticket sniffing (“any winning tickets drifting by?”)

• Crediting a friend (“you will win this one!”)

• Greedy ticket collection (“let’s all pool tickets”)

• Tampering with claims (“I’ll zap your reward claim”)

• Reward level tampering (“promise big, keep small”)

Some footprints left by cheaters

• Packet dropping, selective acceptance – higher “receiving neighbor” frequency than “sending neighbor” frequency

• Packet dropping – higher frequency as claimant than sending neighbor for packets the base stations have never received

• Ticket sniffing – higher claimant frequency than sending and receiving neighbor frequencies

• Crediting a friend – impossible geography? Also: trust needed between cheaters (know the secret key of the other – can “call for free” then!)

• Greedy ticket collection – impossible geography, too long paths (too many claims/packet), unrealistic (statistical) transmission rate (too many claims/time unit) for offenders. If one cheater is nailed, consider his frequent neighbors!

Conclusion

• We have presented a heuristic method for fostering collaboration.

• Auditing techniques resembling (in spirit) those of fraud detection for existing telephony networks

• No formal model or proofs given – a difficult task, but very beneficial!

Thanks to Philippe Golle, Ari Juels and Ron Rivest for helpful discussions and feedback.