1 / 21

Trusted Computing for Protecting Ad-hoc Routing

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 24 th , 2006. Outline. Ad-hoc Networks and Malicious Nodes Previous Approaches Trusted Computing TC For Ad-Hoc Routing

onan
Download Presentation

Trusted Computing for Protecting Ad-hoc Routing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related