A new Framework for Building Secure Collaborative Systems in True Ad Hoc Network

1. A new Framework for Building Secure Collaborative Systems in True Ad Hoc Network Hans-Peter Bischof Joseph Binder Alan Kaminski Rochester Institute of Technology October/10/2003

2. Current Hardware Infrastructure • ip addresses • router in place • routing tables • System administration • Sessile

3. Future Hardware Infrastructure • Ad hoc • Dynamic • Devices come • and leave unannounced • No server • No system administration • No addresses

4. New Use Cases • Un-trusted environment • No system administration expected • Cheap to run • Should be handy • Would you like to print? • How do you find a printer? • JINI services?

5. New Kind of Software Infrastructure Needed • Ad-hoc network • No predifined server and services • Keep what is accepted • Object oriented abstraction of many-to-many communication • Broadcast method invocations • Simplify deployment • No proxy compilers, code base servers, activation daemons, . . . • Automatic proxy synthesis • Simplify operation and administration • No network addresses, ad hoc routing protocols

6. M2MI: A New Paradigm for Ad Hoc Collaborative Systems • M2MI provides an object-oriented method call abstraction based on broadcasting • M2MI-based systems do not require central server • M2MI-based systems do not require network administration • M2MI simplifies system deployment by eliminating the need for always-on application servers (generating of the proxies as needed) • M2MI is well-suited for an ad hoc networking environment where central servers may not be available

7. Anhinga Project Photographs courtesy Philip Greenspun

8. Paradigm of M2MI Invocations • An invocation is broadcast throughout the network and every object that implements the method executes the method. • Selection: • All objects • Group of objects • One specific object

9. References • Omnihandle: Refers to all objects that implement an interface • Multihandle: Refers to a group of objects that implement an interface • Unihandle: Refers to one object that implements an interface

10. Omihandle • Export remote objects • M2MI.export(a, Foo.class); • Get an omnihandle • allFoos = M2MI.getOmnihandle (Foo.class); • Invoke a method on the omnihandle • allFoos.y();

11. Multihandles • Get a multihandle Foo • someFoos = (Foo)M2MI.getMultihandle(Foo.class); • Attach objects • someFoos.attach(a); • Invoke a method on the multihandle • someFoos.y();

12. Unihandles • Export remote object and get unihandle Foo b_Foo = (Foo)M2MI.getUnihandle(b, Foo.class); • Invoke a method on the unihandle b_Foo.y();

13. Semantics of M2MI Invocations • Methods may have arguments • Objects passed by copy (object serialization) • Handles give pass-by-reference • M2MI methods can not return a value • M2MI methods can not throw an exception • Parameters are passed as pass-by-value • Method calls are non-blocking

14. An Idea for a Chat Application

15. The Chat Interface public interface Chat { public void putMessage(String line); }

16. public class ChatObject implements Chat { private String myUserName; private Chat allChats; public ChatObject (String theUserName) { myUserName = theUserName; M2MI.export(this, Chat.class); allChats = (Chat)M2MI.getOmnihandle(Chat.class); } public void send(String line) { allChats.putMessage(myUserName + "> " + line); } public void putMessage(String line) { myChatFrame.addLineToLog (line); } public static void main (String args []) { String input; ChatObject aChatObject = new ChatObject( args[0] ); while ( ( input = readFromTerminal() ) != null ) aChatObject.send(input); }} The Source Code

17. Service Discovery • Service discovery today can be done for example with JINI. • Requires a server. • How can a service discovery work in an ad hoc network? • There are no sever in an ad hoc network.

18. Printer Discovery

19. M2MI Architecture

20. Status • M2MI is implemented in Java 1.4 • Tested on MacOS X, Linux, XP, Solaris 5.9 • Port to PDA is in progress • Security mechanisms will be added soon • www.cs.rit.edu/~anhinga

21. Group Key Management for Ad Hoc Networks The Next Step

22. Security Goals Ad hoc network security goals are similar to those of client server architectures: • Identity verification • Data confidentiality • Data Integrity • Access Control

23. Traditional Solutions Security is enabled by centralized, dedicated entities: • Perimeter defenses • Authentication servers • Localized access policies • Security administrators

24. Ad Hoc Network Security Requirements • Security paradigm must accommodate the networking paradigm—it must be distributed, dynamic, and fault-tolerant • Cannot rely on persistent or centralized entities • Underlying algorithms should minimize bandwidth and computation • Level of security provided should be user-defined

25. Key Management and Ad Hoc Networks • Keys often need to be shared among multiple members • Identity verification is difficult to achieve • Wireless medium precludes the use of a secure channel • Network membership is dynamic, requiring frequent key refreshes • Computational power is very limited • Nodes are heterogeneous—symmetric computational burdens are not realistic

26. Group Key Management • Ad hoc networks often engender collaborative, many-to-many applications. • Security is greatly simplified if we are only concerned with the network participants as a whole—the network group—not individual network members.

27. Group Key Management Semantics • All messages within the group using a shared, symmetric “group” key • The group key is a function of the current network membership—everyone contributes to its creation • Group messages are only understood by the group

28. State of the Art • Key management in the context of ad hoc networks is largely underdeveloped. • We need to levy approaches from the wired domain. • Each approach uses Generalized Diffie-Hellman (GDH): • CLIQUES (Developers of GDH.1,GDH.2,GDH.3, STR) • Tree-Based Generalized Diffie-Hellman (TGDH) • Hypercube Protocol

29. Key Management: An Example Member 1 is the group initiator. It takes a known base, g, and raises it to its secret exponent, N1, and sends it to M2. Member 1 Member 1 Member 3 Member 3 Member 2 Member 2 Member 2 receives intermediate and cardinal values from Member 1, then raises the cardinal value to its secret number, N2, and then sends it and new intermediate values to M3. Member 3 receives all intermediate and cardinal values, generates the new intermediate values and broadcasts them to the group.

30. Proposed Paradigm • Employ a generative communication model to decouple key generation from location and time. • Use atomic nature of Tuple Spaces to achieve synchrony • Define key management protocol that encapsulates reliability • Enable a mechanism that detects invalid contributions

31. Tuple Spaces 101 • Global, shared, associative memory • Tuples are accessed by content and type, not addresses • Shared among collaborating processes • Tuples persist independent of the processes that create and modify them • The following atomic operations can be performed on tuples: • read() - obtain a copy of the tuple • write() - writes a tuple into the space • take()- takes the tuple out of the space

32. Tuple Spaces and Key Management • Tuple spaces allow atomic, nondeterministically ordered contributions • Synchronization is guaranteed by tuple space implementations • Members are decoupled from one another • More fault tolerant—spaces persist independent of a single member • Each take() and write() operation must be signed with the group key • Tuples are leased to avoid indefinite take() operations

33. KeyTuple KeyTuple KeyTuple KeyTuple KeyTuple KeyTuple KeyTuple Tuple Spaces: Example Member 1 Member 3 Member 2

34. Analysis—Example • Minimal exponentiations for group members • Simple semantics for add, remove, join, and eviction operations • Equally as secure as existing Generalized Diffie-Hellman implementations • Implementation of distributed, secure tuple space does not exist for M2MP (yet)

35. Questions?

36. Analysis • Reliability • Each member must contribute to the key • Each member must receive the new key • What if a member dies/leaves during key generation? • Synchronization • What if a new member joins as a key is being generated? • Expensive • Computation • Bandwidth • Requires point-to-point medium (ad hoc networks are often broadcast-based, addresses) • Synchronous creation • Especially slow in heterogeneous environments

37. Proposed Improvement • Each member maintains a queue of pending calculations • When the network is formed, each member broadcasts its key request (Ma“I need gbcd!”) • Upon receipt of the request, each member capable of calculating part of the request adds the request to its queue and broadcasts a request for the portion it cannot request (Mb“I need gcd!”) • Each member processes its queue and broadcasts the result of each calculation. (Mc“Here is gcd!”) • If a member receives a solution to one of its pending calculations, it removes the calculation from its queue (Md: “Md calculated gcd so I don’t have to”)

38. Building Request Queue forMa Ma gbcd Mb Mc Md gbc gcd gbd gbd gbc gcd Mc Md Mb Mc gc gd gc gd gd gc gb Md Mb Mc Md Mb

39. Analysis • Solution is very well-suited for dynamic and heterogeneous environments • Requires minimal group state information • Allows concurrent intermediate value calculations • Can be easily modified to include signed broadcast messages • Requires numerous redundant broadcasts • Unnecessary calculations may be made if a broadcast is missed

40. Future Work • Refine heuristics for queuing and de-queuing to minimize calculation redundancies • Consider heuristics for minimizing the number of broadcast messages • Ensure bandwidth requirements are reasonable using state of the art devices

41. Questions?