300 likes | 400 Views
Security in Ad Hoc Wireless Networks Project Overview. Agenda. Problem Description Existing Research Project Goals Design Description. Problem Description. The following are known security concerns in wireless ad hoc networks: Node identity—who am I really talking to Packet insertion
E N D
Agenda • Problem Description • Existing Research • Project Goals • Design Description
Problem Description The following are known security concerns in wireless ad hoc networks: • Node identity—who am I really talking to • Packet insertion • Packet capture—the man in the middle
Existing Security Information • PGP (Pretty Good Privacy) • Diffie-Hellman • Larns-Arne Mattsson Thesis
Problems With Existing Paradigms • Break the notion of “ad hoc” • Too robust for small devices • Only practical for long network sessions We need a more economical and practical solution!
Project Goals Provide a “reasonable” security mechanism with: • Minimal start-up time • Low CPU overhead • Insertion protection • Protocol independence
What aren’t we doing? • Denial of service protection • Packet routing • Protocol reliability • Developing an “unbreakable” security mechanism
Design Goals - 1 • Provide a platform and protocol independent security paradigm • Allow security features to be easily integrated into existing systems • Minimize the overhead required for security • Use existing techniques/paradigms whenever possible
Design Goals - 2 • Allow the level of security to be application defined • Make intricacies of security mechanism transparent to the application • Provide programming interfaces that are flexible and extensible
The Solution • A protocol-level mechanism to provide primary security mechanism. • An application-level API, which provides transparent, flexible security features
Application SecureGroup API Architectural Sketch SecureChannel SecureStream M2MP TCP/IP
Secure Group–Design Assumptions • Ad hoc wireless sessions frequently require transmission of sensitive information within a group • Members within the group trust each other • The level of security required is application dependent • Applications should have the ability to choose the underlying protocol and security mechanism
Design Assumptions—2 • Nodes should be able to join the secure group at any time • Network groups will frequently, but not always, be comprised of two or more members of a known group—a company, group of friends, etc. • There is not necessarily a “group master,” who maintains the group infrastructure
Secure Group—Specification The Secure Group API provides the following features • Group Announcement • Member Authentication • Secure Group Data Transmission
Initiator of a group broadcasts the existence of a group to the network via a well-known address or handle OR Node asks the network which groups are available via well-known address or handle Each node replies with its identity and the groups to which it belongs Group Announcement
Initiator Announcement Example—1 Node 2 Group Annc. Group Id User Id Node 3 This is a really Important group …. MyGroup Node 1
Node 5 I’m Node 3 and I’m in Group A and Group B I’m Node 2 and I’m in Group A Node 2 Group A What groups are out there? Node 3 I’m Node 1 and I’m in Group B Group B Node 1
Member Authentication • Group members are authenticated using a very robust algorithm—PGP, for example • Initiator of the group authenticates the first node that requests group membership • Subsequent requestors are authenticated by any member of the group
Node 5 Authentication Example—1 Group B sounds nifty. May I join? Maybe. Who are you? Group B Node 1
Authentication Example—2 Node 5 Okay. I have your public key. I’m Node 5 Group B Node 1
Node 5 Authentication Example—4 Okay, now that our transmission is encrypted, I’ll send you the session key Group B Session Key (Secret) Node 1
Node 5 Authentication Example—5 Node 2 Group A Node 3 Group B Node 1
Data Transmission • Data is encrypted using a group session key (less robust) • New members are sent the session key via the secure connection created during authentication • If PGP was not used during the authentication, Diffie Hellman will be used to create an encrypted connection and send the session key • Reliability is handled exclusively by the underlying protocol
SecureChannel—Design Assumptions • Some ad hoc wireless applications only require a limited level of security • Packet insertion is considered the biggest threat • Devices are resource sensitive • Integrating security into an application should be painless
SecureChannel—Specification • The SecureChannel is an extension of the M2MP Channel interface • Links one packet to another to detect packet insertion
SecureChannel—Design Description • Each packet contains a hash, which is encrypted using a 64- • bit key • The subsequent packet contains the key required to • validate/decrypt packet • Packet insertion is limited by the time it takes for an intruder • to generate key
SecureChannel—Design Description (2) Packet N Packet N +1 64-B 64-B 128-B M2MP Data ID Key Hash . . . Key . . . MD5 Hash DES Encrypted
For Next Time… • Detailed description of class structure • Demonstration of reference application (Simple FTP) • Report of findings • Known bugs • M2MP issues • Remaining work/enhancements • Conclusion