1. A Micro-Payment Scheme Encouraging Collaboration in Multi-Hop Cellular Networks Markus Jakobsson 1 Jean- Pierre Hubaux 2 Levente Buttyán 2,3 1 RSA Laboratories 2 Swiss Federal Institute of Technology – Lausanne (EPFL) 3 Budapest University of Technology and Economics

2. 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

3. Our model Asymmetric multi-hop cellular: –multi-hop up-stream –single-hop down-stream Energy consumption of the mobiles is further reduced

4. 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)

5. Approach Introduce benefit for collaboration … without strong security assumptions … and without large overhead

6. Idea Attach micropayments to packets … allowing collaborators to get paid … while avoiding and detecting various attacks

7. 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)

8. 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

9. 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

10. 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!)

11. The solution in a nutshell attach paymen t token check if the token is a winning ticket if so, file claim check token if correct, deliver packet submit reward claims accounting and auditing information debit/credit accounts identify irregularities honest selfish

12. Protocol (1) Setup Connectivity graph Shared user key K u (U i, d i, L i ) user distance level id to BS required Shared user key K u

13. Protocol (2) Packet origination Packet transmission p, L, U o,  packet level originator’s MAC Ku (p, L) id forward request wait for ack send Did I win? to next user U i with sufficient level L i (<L)

14. Protocol (3) Network processing MAC correct? (otherwise drop) Send towards destination Collect auditing information (send in batches)

15. Reward claim U forwarded (L, p, U o,  ) checks if f ( , K u ) = 1 if so, stores claim (U 1, U 2, , L) all such claims sent to base station when “ convenient ” Well … did I win? received from sent to

16. What is f ? “ Safe ” approach: a one-way function “ Quick & Dirty ” approach: check Hamming distance between  and K u (Note that claims leak key information - be careful!)

17. 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!)

18. 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 ” )

19. 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!

20. 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.