Trusted Computing for Protecting Ad-hoc Routing

1. Trusted Computing for Protecting Ad-hoc Routing Michael Jarrett (mjarrett@ieee.org) Paul Ward (pasward@ccng.uwaterloo.ca) Presented By: Paul Ward CNSR 2006 May 24th, 2006

2. Outline • Ad-hoc Networks and Malicious Nodes • Previous Approaches • Trusted Computing • TC For Ad-Hoc Routing • Frequently Asked Questions • Conclusions

3. So What is the Problem? • Ad-hoc networks rely on neighbouring nodes to reliably forward traffic towards its eventual destination. • There is no motivation for a node to participate honestly for others’ traffic. • ‘Lazy’ nodes can ignore requests to forward traffic to save battery power. • Malicious nodes can easily redirect and/or disrupt traffic over large portions of the network. • Greedy nodes can overuse the network, gaining more bandwidth for itself, but reducing network capacity for others.

4. Previous Solutions (1) • Mixnets encrypt packets for each hop of a source-specified path, which may visit a node more than once on the way to its destination. • A node that does not forward packets correctly risks losing traffic destined to it. • Heavy cryptographic overhead, longer routes. • Example: AD-MIX Protocol

5. Previous Solutions (2) • Economic solutions attempt to award good behaviour and punish bad behaviour, often with some sort of currency. • Often problems with starvation of remote nodes, which don’t get to forward much. • Need trustworthy way to track currency. • Example: Nuglets • Example: Ad-hoc extended cell networks.

6. Previous Solutions (3) • Monitoring approaches rely on “honest” neighbours to detect and report “dishonest” nodes. • Is the reporter honest? • Can honest nodes identify bad behaviour? • Example: Watchdog • Example: CONFIDANT

7. Previous Solutions (4) • Cryptographic approaches encrypt traffic to keep it to trusted nodes. • Prevents impersonation, blocking many malicious node attacks. • Key distribution issues, source of ‘trust’. • Doesn’t really address selfish nodes. • Example: ARAN • Example: SAODV

8. What is Trusted Computing • aka. TCPA, aka. TCG, aka. Palladium. • Hardware tamper-resistant cryptographic module (TPM) with internal key store. • Distinct from secure boot (TC does not prevent anything from running) and secure coprocessors (software still runs on the general computing device).

9. TC Operations • Process isolation • Trusted processes are strongly isolated from the rest of the system. • Secure I/O • Crypto between the PC and external devices. • Sealed Storage • Data can be sealed with a key derived from certain system measurements (and unlocked only if the measurements have not changed). • Remote Attestation • Can generate a signed version of system measurements as a credential to a remote system.

10. System to Protect Ad-Hoc Routing • Routing protocol derived from AODV. • Routing module is trusted agent. • Network driver must verify that it is secure to the routing module (presumably via ‘remote’ attestation). • Assumption: ability to verify the signatures (i.e. PKI) and judge the correctness of TC measurements.

11. Architecture Outline App App Wireless Network Network APIs Secure Ad-hoc Routing Agent (secure communication) Wireless Network Interface Driver (secure IO) Wireless Network Interface

12. Protocol - Introduction • Device has a trusted keypair stored in TPM, uniquely associated with that node. • Signed by a trusted authority. • During HELLO announcement, public key certificate for the node is broadcast. • Neighbours verify certificate, and if valid and trusted, it is stored associated with the node.

13. Protocol – Requesting a Route • A wishes to form a route to B. • Broadcasts an RREQ, like AODV, but signed and including a remote attestation with the routing module’s integrity measurements. • Intermediate receiver X verifies signature. If genuine, X stores reverse route to A. • X strips the original signature and metrics, replacing it with its own, then rebroadcasts.

14. Protocol – Establishing Route • When B receives RREQ, a RREP is unicast back towards A. • Forward route forms during return. • Same process of resigning at each hop. • A receives RREP, generates a random route ID and symmetric session key. • RKEY packet is generated with ID and key, encrypted with the public key for the next hop on the forward route, and sent back towards B. • The next hop decrypts, stores ID, key, and endpoints, encrypts for the next hop, and continues the chain.

15. Protocol - Communication • All link traffic is now encrypted with the session key, including all headers (excluding route ID). • The nodes on the route can identify the destination from the route ID. • Intermediate nodes must verify the headers (to prevent garbage being transmitted along the route by untrusted nodes). • If the route changes or an error occurs, the RKEY propagation can be performed on a new route as often as necessary.

16. Accomplishments • No node can persuasively lie about their identity. • No node can be dishonest to attempt to corrupt the routing process. • Very difficult for a node to be lazy while actively participating in the network. • Network traffic is encrypted against viewing by untrusted nodes (and trusted forwarding nodes won’t read it).

17. Disadvantages • Computational/storage cost (next slide) • Very minor compared to most approaches. • Those not running a full TC platform with the latest trusted routing module can’t participate in the network.

18. Costs • Computational • PK: 2 signatures, 2 verifications, 1 encryption, 1 decryption per node to form a route route (but using dedicated crypto hardware!) • Symmetric cryptography for communication at all nodes along the route. • Space • Store certificates for all neighbours seen recently. • Store route IDs and session key for all active routes through node.

19. FAQ: Is TC a Reasonable Assumption? • Absolutely! • Many laptop models from IBM, Dell, Toshiba, etc. already have a TPM! • Secure bootloaders, secure OS kernels already available (e.g., secure grub, Linux extensions). • Trusted drivers? Windows Vista will not run unsigned 64-bit drivers!

20. Other FAQs • Isn’t trusted computing “evil”? • No, technology itself is not inherently evil. • TC “owner override” mode? • No. We’re protecting ourselves from owners! • Replay attacks? • No - wouldn’t accomplish anything. Sequence numbers could be used trivially if they were a threat.

21. Thank You! Questions?