A Trust-Building Mechanism in the Mesh

1. 07.08.08 Jeremy Flores flores1@mit.edu Jorge de la Garza Robert Falconi Kevin Kelley A Trust-Building Mechanism in the Mesh

2. One Laptop Per Child - Considerations • Limited processing power • AMD Geode, ~433 MHz • 256 MB RAM • Limited energy consumption • Sparse access to electricity for battery recharging • Open-source software • Users can alter any mechanisms • Closed-source wireless card firmware • Must implement protocols in kernel

3. One Laptop Per Child - Considerations • Potentially massive network topologies • Liberal software philosophy: “Let kids explore” • Can't implement overly-restrictive security policies • MAC spoofing entirely feasible, even encouraged

4. Issues • Very unusual networking environment • No central authority • MAC addresses not tied to users • New identities all over the place

5. Issues • “Bruce Wayne” problem • Allowed/encouraged to spoof MAC address • Can provide other ID of choice • Other concerns are more typical • Point-to-point privacy • Tamper-resistance for messages

6. Issues • Misbehaving peers • Problem is direct result of topology • Can't save self • Super-lightweight devices (~433 Mhz)‏ • Practical considerations

7. Thoughts • Disregard MAC address • Okay for routing / 802.11s / AODV • Will be spoofed, impersonated

8. Basic Solution • Generating a new identity • As simple as generating new keys • Choose new MAC address at same time • Sending a general-purpose message • Use MAC & checksum • Send public key with message • Public key effectively is identity

9. Basic Solution • Point-to-point privacy • Just add encryption on top of MACing • Behavior enforcement • “Organic/natural” model • Temporary blacklisting

10. Solution • “A Trust Model Based Cooperation Enforcement Mechanism in Mesh Networks” • Proposes PID-like trust model • Trust score • If node is deemed untrustworthy, add to blacklist • Can change parameters to better fit network and desired effects • More efficient than blacklist-sharing models (zero network overhead, no list comparing)‏ • Should be efficient enough for XOs

11. Solution • Extend the algorithm • Prioritizing Packet Forwarding • Instead of blacklist, use node's trust score to determine importance • Higher priority in packet forwarding means faster, sustained bandwidth • If sufficiently low score, actively malicious, and low overall traffic, temporarily blacklist ( t ~ 1/score )‏ • If also using blacklist sharing, false positives are only a small problem for otherwise-trustworthy nodes • Further incentive to play nice

12. Solution • Extend the algorithm • “Trust Building” • When a new node is encountered, initially has a low trust score • As the node performs dutifully, trust score increases • “Good deeds” <==> Reward (bandwidth)‏ • MAC address swapping • If legit user wants to switch identities, no problem • If switching to bypass blacklists, still must play nice to gain trust

13. Solution • Benefits • Sits in kernel: works with Cerebro • Customizable • Low overhead • Sidesteps unique identification problem • Weak penalization • To be effectively malicious on a widespread level, one must first “do good” to become trusted • Score is asymmetric towards untrustworthy, so more “good” done than “bad” overall

14. Contact: flores1@mit.edu Questions?