TinySec: A Link Layer Security Architecture for Wireless Sensor Networks

1. TinySec: A Link Layer Security Architecture for Wireless Sensor Networks • Chris Karlof, Naveen Sastry, David Wagner • SenSys 2004

2. Motivation • Sensor networks are more open than even the internet: anyone nearby can listen or talk to your sensors over the air • Sometimes you don’t want all the information to be public (for example, inventory control or reconnaissance) • Even if you don’t mind others listening, it is good to be able to distinguish between your own sensors and impostors (who can inject false sense data or flood your network with bogus requests).

3. Observations • Secure communication isn’t hard, if we have excess network and CPU capacity (eg IPsec, TLS, Kerberos, ssh). But sensor networks don’t. • Network overhead is far more important than CPU: the energy cost for transmitting a single byte can be significant. • Luckily, the very low throughput of sensor networks reduces the amount of protection required (fewer packets can be collected for analysis or replay attacks) • Secure communication is not security: physical or DoS attacks are still possible. But we do what we can.

4. Types of Protection • Integrity: a message has not been modified during transmission. • Authenticity: the message cannot have been sent by anyone but the declared sender. This and integrity can be provided by a message authentication code, typically a one-way, collision-resistant hash (MD5 or SHA) of the message and a shared secret. • Confidentiality: the message cannot be read by anyone but the intended recipient. Encryption algorithms such as DES or AES can provide this. • Encryption does not provide the other two: it is not necessarily difficult to create a decryptable message by splicing together parts of other messages.

5. Goals • Efficiency: TinySec should not have noticeable impact on message size, latency or processor utilization. • Transparency: if it is not painless to deploy, it probably won’t be used. • Portability: it should run everywhere TinyOS runs. • Open API: it should be easy to use TinySec components to build higher-level security protocols. The end-to-end argument applies.

6. Design • TinySec provides two transport modes: authentication (TinySec-Auth) and authentication/encryption (TinySec-AE) (cf IPsec). As noted earlier, encryption without authentication can be insecure. • TinySec-Auth replaces the TinyOS packet checksum with a MAC covering the rest of the packet. Authenticated packets are only one byte longer than plain packets. • TinySec-AE is more challenging to implement, due to the requirement of an initialization vector.

7. TinySec-AE: IV • Identical messages encrypted under the same key produce identical ciphertext. This makes them vulnerable to analysis. • One option would be to rekey after every message (cf forward secrecy). But exchanging key information consumes too much bandwidth. Both sides could apply a function to the last-used key, but this would require state for every pair of nodes. This consumes too much memory. • Solution: add random data to the message before encrypting it, and include that data in plain text with the packet. This is an initialization vector.

8. TinySec-AE: IV 2 • To reduce packet size, a small IV is desirable. But the IV is most useful if it doesn’t repeat. So choosing a good IV requires some thought. • By the “birthday paradox” random IVs of length 2n can be expected to repeat within 2n/2 packets. In effect, this wastes half the bits. • If all nodes use a counter starting from 0, the first packet from each node uses the same IV. For some traffic patterns(eg predictable handshaking) this can be insecure. • TinySec constructs the IV from the packet metadata (source, destination, type, length) and a 2 byte counter, to create more than 216 IVs for each pair of nodes.

9. TinySec-AE: CBC • Stream ciphers are fast: the key and IV are cryptographically stretched to the length of the message and then simply XORed with it. The low CPU and packet size overhead makes them attractive. Unfortunately, they fall to pieces if the IV ever repeats. TinySec can’t afford an IV long enough to prevent IV repetition. • TinySec uses a block cipher in cipher block chaining mode, which degrades more gracefully if the IV repeats. CBC C(Bm) = E(K,(((C(B1) ⊕ C(B2)) ⊕ C(B3))... ⊕ C(Bm-1)) ⊕ Bm) Stream cipher vulnerability S = stretch(K,IV) C = A ⊕ S, D = B ⊕ S C ⊕ D = A ⊕ S ⊕ S ⊕ B = A ⊕ B

10. Is it secure? • 4 byte MAC means a successful forgery can probably be found after 231 attempts. • To verify the forgery, an attacker must send it to a node and see if it is accepted. At 19.2kb/s, an attacker can transmit 40 packets/sec, and 231 packets in 20 months (and fully saturate the channel, and drain node batteries). • Encryption IV reuse may happen after n*216 messages in an n-node network. If sensors communicate at low rates as is expected, the IV will not repeat for some time (eg at 1 packet/min, IV repeats in 45 days). If the node rekeys before then, IV reuse is no longer a danger.

11. Implementation • 3000 lines of portable nesC code: 728 bytes of RAM, 7146 bytes of code (and can trade some RAM for CPU) • Hooks into TinyOS radio stack at the byte level • Crypto has real-time deadline: packet must be ready by the time the start symbol has been transmitted. So TinySec introduces a two-priority scheduler to TinyOS, and runs itself at high priority. • Can be trivially added to existing applications (using a network-wide key) through a Makefile tweak and recompile.

12. Cost • Raw CPU cost (could be reduced through encryption hardware) • Network cost: longer packets mean reduced bandwidth, increased latency and energy consumption Energy cost is mostly due to increased packet size, not crypto

13. Latency • Longer packets increase latency. It is possible that CPU load could too, by delaying non-crypto tasks. Experiment with a real application (NEST Pursuit-Evasion Midterm Demo Game, 37 nodes)

14. Other security issues • TinySec only provides link-level protection: between nodes, not applications. If a node is compromised, all data passing through it is too. Applications can use TinySec primitives to build their own security. • Sensors are more vulnerable to network attacks, but also to physical attacks. If remote snooping isn’t trivial, just crack open a sensor. Key distribution becomes very important for fault isolation. • TinySec doesn’t address replay attacks, because this requires per-peer state. Applications (with better topological knowledge) may be in a better position to handle this.

15. Key distribution issues • A single shared key means one compromised node compromises the entire network. • Periodic rekeying may be necessary to prevent IV reuse. • Pairwise keys require more storage, and prevent broadcast and passive listening. Plus, distribution is harder. • In between: group keying: a set of nodes shares a key. • Work is ongoing. For some applications a key distribution server (á la Kerberos) may be suitable.

16. Related Work • GSM, WEP: flawed designs provide poor security (especially WEP). Other standards are secure, but have too much network overhead. • SNEP: unfinished? • IEEE 802.15.4: similar architecture, but uses a stream cipher (and a longer IV). Provides a replay protection option.

17. Conclusion • TinySec provides strong security guarantees at the link level, with only moderate cost. • It is easy to deploy (if we set aside the key distribution problem) • Security is always a trade-off - we spend some energy to secure the link, only to find that it makes DoS or physical attacks more attractive. But with TinySec, the link layer is not the weakest link. • These guys should have designed WEP.