A Trust-Building Mechanism in the Mesh

07.08.08

Jeremy Flores flores1@mit.edu

Jorge de la GarzaRobert FalconiKevin Kelley

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

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

Issues

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

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

Issues

Misbehaving peers Problem is direct result of topology Can't save self

Super-lightweight devices (~433 Mhz) Practical considerations

Thoughts

Disregard MAC address Okay for routing / 802.11s / AODV Will be spoofed, impersonated

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

Basic Solution

Point-to-point privacy Just add encryption on top of MACing

Behavior enforcement “Organic/natural” model Temporary blacklisting

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

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

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

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

Questions?

Contact: flores1@mit.edu