1 / 29

Enhancing Security in Ad Hoc Wireless Networks

This project addresses the critical security vulnerabilities in wireless ad hoc networks, including node identity, packet insertion, and man-in-the-middle attacks. We aim to develop a more practical and economical security solution that ensures minimal start-up time and low CPU overhead, while allowing protocol independence. Our goals include a flexible security paradigm that integrates seamlessly with existing systems, safeguarding data transmission within trusted group environments. The design will include a robust authentication mechanism and secure communication channels tailored to application-specific security needs.

shing
Download Presentation

Enhancing Security in Ad Hoc Wireless Networks

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. Security in Ad Hoc Wireless NetworksProject Overview

  2. Agenda • Problem Description • Existing Research • Project Goals • Design Description

  3. 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

  4. Existing Security Information • PGP (Pretty Good Privacy) • Diffie-Hellman • Larns-Arne Mattsson Thesis

  5. 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!

  6. Project Goals Provide a “reasonable” security mechanism with: • Minimal start-up time • Low CPU overhead • Insertion protection • Protocol independence

  7. What aren’t we doing? • Denial of service protection • Packet routing • Protocol reliability • Developing an “unbreakable” security mechanism

  8. 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

  9. 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

  10. The Solution • A protocol-level mechanism to provide primary security mechanism. • An application-level API, which provides transparent, flexible security features

  11. Application SecureGroup API Architectural Sketch SecureChannel SecureStream M2MP TCP/IP

  12. 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

  13. 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

  14. Secure Group—Specification The Secure Group API provides the following features • Group Announcement • Member Authentication • Secure Group Data Transmission

  15. 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

  16. Initiator Announcement Example—1 Node 2 Group Annc. Group Id User Id Node 3 This is a really Important group …. MyGroup Node 1

  17. 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

  18. 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

  19. Node 5 Authentication Example—1 Group B sounds nifty. May I join? Maybe. Who are you? Group B Node 1

  20. Authentication Example—2 Node 5 Okay. I have your public key. I’m Node 5 Group B Node 1

  21. 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

  22. Node 5 Authentication Example—5 Node 2 Group A Node 3 Group B Node 1

  23. 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

  24. 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

  25. SecureChannel—Specification • The SecureChannel is an extension of the M2MP Channel interface • Links one packet to another to detect packet insertion

  26. 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

  27. 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

  28. 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

  29. Questions Comments Criticisms

More Related