A critical look at sensor network securityA personal odysseyNaveen Sastry ([email protected])November 17, 2005Outline1. Claim: conventional wisdom2. Counter-claim: my view3. Tools4. Design example5. The real worry6. Recap & rant1. A ClaimConventional wisdomSensor network security is different fromfixed infrastructure securityConventional wisdom: evidence (1)• Resource constraints• TinyPackets• TinyProcessors• TinyMemory• TinyOperatingSystemsSoftware solutions not feasiblee.g. no public keyConventional wisdom: evidence (2)• Mismatch between attacker & victim network• No physical security (maybe the blackberries will bring some bears to watch over…)• Compromised nodes•JammingVsHold up: What are the problems?• Securing communications • Confidentiality• Integrity• Access Control•Keying• Key distribution & update• Any-to-any communication• Detecting compromised nodes• Secure infrastructure servicesRoutingSecure + LocalizationTime synchronization2. CounterclaimCounterclaimSensor network security is different fromfixed infrastructure securitySensor network security is similar enough to fixed infrastructure securityThreat models• Commercial (buildings/industrial plants/…): • Nodes under single administrative control• Minimal / low mobility• Single install time• No DoS worries• Pretty good physical security• Millitary• Mobility!• Smart adversaries• Rich adversaries• DoS is the objective3. ToolsLink layer encryptionSPINS (‘01)Sender, receiver synch problemsTinySec (’04)All software, <8% overhead802.15.4 (’04)In hardware, essentially freeSecure 2-way communicationAssumes: Pre-shared keysPrevents packetinjectionmodificationeavesdropping• Based on symmetric key cryptography• Efficient (worst problem: ~8-16 bytes per message)• Shared keys required• Keys must be protectedPublic key encryption• Sizzle from Sun• Uses elliptic curve cryptography• RSA is slow, large (1024 bit operations)• ECC is just as secure at 160 bits, much fasterFrom Vipul Gupta, CENTS Retreat Jan 2005; CHES 20048 Mhz Atmel 128Tamper resistance•Single chips• Good also for security• Careful hardware design• Eliminate side channels (power & timing attacks)• Packaging• iButton & smartcards•~ $1IncreasingcostFor the paranoid…• IBM 4758: No known physical attacks• Mitigate cost: two tiered network• Trusted & protected infrstructure•Ordinary nodes• Jamming proof radios: • Frequency hop based on shared secrets• Spread spectrum4. Design ExampleSecuring refinery infrastructure [Pister TRUST]• Need to be able to deploy additional nodes to replace busted ones• Problem: How to get existing nodes to recognizenew node? How to exchange keys?Details…KK• New node needs some credentialsfor master to accept it• Standard options: • Key rotations• Public key• Location limited channel: bring new node next to master• Alternative: PDAKK5. The real worryWormholes: routingKKKKKKKKKKK KK KADV• Forwards traffic• No keying required• Increases load• Traffic analysis• Selective forwarding• Disrupts routing propertiesOther wormhole attacks: localizationKKKKKKKKKKK KK KADV• Rebroadcasts at different signal strength• Still no key requiredOther wormhole attacks: time syncrhonizationKKKKKKKKKKK KK KADV• Delays traffic• Still no key requiredWormhole directions?• Packet leashes: • Nodes know layout• Have tight time synchronization (e.g. from GPS)• Time each packet in flight. • Doesn’t help for time synchronization application• Frequency hopping radios• Must use keyed hop schedule• Must hop quickly (every symbol?) • Generally, military grade radios• Nothing cheap or particularly
View Full Document
Unlocking...