Octopus

1. CS 259 Octopus Taral Joglekar Ryan Wisnesky

2. Outline • Adhoc networks • Octopus Protocol • Murphi model and attacks • CEDAR with Octopus • Attacks on CEDAR • Using GDH.2 attack techniques

3. Ad hoc networks • Network is formed by nodes that do not have prior knowledge of the network topology, but have to discover it • No central entity • Wireless nodes participate in an ad hoc network by broadcasting their presence and also listening to similar broadcasts from other nodes • These broadcasts are often used to decide the routing information

4. Challenges • Due to its dynamic structure, many network protocols are not suitable to use with an ad hoc network • Main concerns include • Authentication • Confidentiality • Integrity • Availability • Non-repudiation

5. Challenges (cont) • Authentication is used to share a initial key but there needs to be a shared key established later between all participating parties. • Hence there are separate protocols for authentication and key establishment • Public Key as well as Shared Key secrets are used to achieve these goals • Most use some sort of trust bootstrapping for authentication

6. Security Properties for Group Key Establishment Protocol • Key establishment: All nodes must agree on a single shared key • Key maintenance: Generate / modify keys as new nodes enter and leave the groups • Key Agreement: How do you ensure that all nodes actually have the same key • Do not ensure - agents not getting right keys are as good as having left the network • Design protocol to involve all participants – too many messages, not suitable for ad hoc networks

7. The Octopus Protocol • Group Key establishment protocol • Assumes authentication has been done beforehand • Is a minimum message protocol • 2 level hierarchy • 4 - Core elements and other nodes connect to the core elements • Variant of Diffie Hellman key exchange used to generate the shared key.

8. Key exchange protocol ga A B gb gcd gab gcd gab gc C D gd Shared Key:

9. Properties to check • Key secrecy • Can a passive eavesdropper know the secret key (No, already proved in the paper) • Can an active attacker get the key (without being a part of the group, not evaluated in the paper) • Key Agreement • Can an active attacker prevent key agreement between the group members • Core formation • How do you elect the core members in a dynamic scenario? – Use another protocol like CEDAR

10. Murφ Model • Interesting questions: • How do you use the authentication scheme along with the protocol? • How do you model individual key parts? • Many ways used as model developed • 1 core – 1 peer model used DH_Core, DH_Peer • 1 Core – multiple peers used boolean arrays • 1 Core – multiple peers with active attacker used boolean array with actual nonce arrays • Could also use Power sets and key simplification rules

11. Murφ Model (cont) • Try to implement the authentication somehow in the model • Establishment of some sort of initial key • Either use Public keys of cores or use shared secret keys with cores • Public Keys • Send peer Id in clear and DH exponent encrypted using PK • If all is encrypted, core is susceptible to DOS attack • Attacks in which intruder can replace the peer name • Prevent by sending a nonce decided during authentication • Signing the DH component and putting it in the encrypted part • Replay attacks • Timestamps / challenge response / one-time passwords. • Core to peer message tampering • Use PK / Share a secret key in the initial message

12. Murφ Model (cont) • Attacker can corrupt messages if not authenticated • Interesting attack when attacker swaps the messages from two peers • Final key remains the same for everyone except the two peers • Attacks can be avoided by including the target nonce within the encrypted part

13. Invariant for Key agreement invariant "key agreement" forall i: CoreId do core[i].mainState = C_MAINDONE -> forall j: PeerId do forall k:PeerId do (peer[j].state = P_GOTKEY & peer[k].state = P_GOTKEY) -> forall l:ValidAgentId do peer[j].keyMaterial_V[l] = peer[j].keyMaterial_V[l] & (peer[j].keyMaterial_V[l] = true -> peer[j].keyMaterial[l] = peer[k].keyMaterial[l] ) endforall endforall endforall endforall

14. From Octopus to CEDAR • Octopus relies on a four node core. • Four nodes may not be a good number for all networks, and all the nodes may not have prior knowledge of what the core is. • Solution: dynamically generate the core nodes. • We need a set of core nodes where every node is ‘attached’ to exactly one member of the core. • In other words, we need a dominating set. • CEDAR approximates a MDS.

15. Dominating Sets • A dominating set of a graph (E, N) is a set of nodes such that every node in the graph is either in the dominating set or is connected to a node in the set. • A minimum dominating set is a dominating set with a minimum number of nodes. • The fewer the number of core nodes, the fewer ‘multi-party’ exchanges have to occur in the generalized octopus protocol.

16. Example MDS

17. CEDAR Overview Let N1(u) denote all the nodes that u is connected to. Let N1’(u) = N1(u) – {u}. Let dom(u) denote u’s dominator. Let d(u) = |N1’(u)|. Let d*(u) = the number of u’s neighbors that have chose u as their dominator. This is u’s effective degree. 1. Periodically, u broadcasts a beacon (u, d*(u), d(u), dom(u)) to its neighbors. 2. If u does not have a dominator, it sets its dominator to the node v in N1(u) with the largest value for (d*(u), d(u)) in lexicographic order. It may choose itself. 3. u then sends v the message (u, {(w, dom(w))|w in N1’}) 4. If d*(u) > 0, u joins the core.

18. Key points about CEDAR • The Algorithm approximates the MDS because when choosing dominators, nodes prefer to select nodes that are already dominators and are well connected. • The algorithm depends on the order of messages. • The only way for a node to leave the core is by listening to its neighbors and discovering that its effective degree has become zero. • A node only re-chooses its dominator if that dominator disappears. • The generalized octopus protocol relies on reliable core-broadcast, which depends on each node having a correct understanding of the local topology. (This can also be attacked…)

19. Questions to ask about CEDAR • Can an intruder prevent the formation of a stable core? • Java model: do changes in the core set keep occurring in the presence of an intruder? • Can an intruder cause an inconsistency in which nodes do not agree on the core? • Java model: when the core set is no longer changing, does each node have the same ‘view’? • Can an intruder cause an incorrect core to form? • Eventually, the insight gained from the model was useful in analyzing CEDAR without tools. The Java model can’t prove anything, but it suggests directions.

20. Two example analyses • Can an intruder prevent the formation of a stable core? • A node only re-chooses its dominator if that dominator has disappeared. So if an intruder cannot make it look like a node’s dominator has disappeared, then the intruder cannot force a node to change its dominator. That means that once dominators are chosen, they cannot be changed by the intruder. And because every node will eventually choose a dominator, there is no action the intruder can take to modify the core once that point is reached. So, an intruder cannot prevent the formation of a stable core. • Assumes no topology changes.

21. A more interesting example • Can an intruder cause an incorrect core to form? • Assume the intruder can disrupt communications. • Assume authentication, so that only replay attacks are considered.

22. Example A -> B : B dom A B -> A : beacon The intruder is listening… A B

23. Example Topology change. A -> C : C dom A A C B

24. Example Intruder blocks communication between A and C. This means C removes itself from the core. A C B I

25. Example I -> A : B’s beacon I -> B : A’s beacon A -> I : B dom A I -> B : B dom A Result: A and B think they are connected, but they are not. This prevents correct routing. A C B I

26. GDH.2 and Octopus • There is a mathematical technique used to analyze the security of GDH.2. • GDH.2 is a related set of protocols; both GDH.2 and Octopus are distributed versions of DH. So, can we use these techniques for octopus? ga gab gabc gabcd Broadcast Each node uses the information in the broadcast to determine the shared secret.

27. GDH.2 and Octopus • Because of the step-wise nature of GDH.2, and the fact that each node simply raises its input to a number and sends the result to the next node, each node may be viewed as providing a ‘service’: s(ga) = gab • These services commute with each other because ga^b = gab. So, we can write any use of these services as ge1^s1 e2^s2 ... en ^ sn

28. GDH.2 and Octopus We can write the key in a similar form, to get an equation ge1^s1 e2^s2 ... en ^ sn =ge1^k1 e2^k2 ... en ^ kn So, this becomes a set of equations between exponents that we can try to solve: s1 = k1 and s2 = k2 and … and sn = kn Of course, these sn aren’t atomic, so the equations aren’t trivial. If this system can’t be solved, then there isn’t an attack (or so the paper claims…). If it can, then further refinement is needed.

29. GDH.2 and Octopus • Why does this fail for Octopus? • Our services require multiple inputs. • This leads to non-commutativity, so our resulting system is potentially infinite. Each leaf node does DH with the core node. The core node then uses processes these keys and exchanges them with another core node.

30. GDH.2 and Octopus Initial Knowledge Initial Knowledge e1 Apply s1 times e1 Apply s11 times ….. Other applications en Apply s1 times e1 Apply s1n times key key

31. Conclusions • Secure and robust group key establishment is a difficult goal to achieve • Analysis is complex and dependant on cryptographic properties • Need some way to represent symbolic knowledge in Murphi • Need better subtyping • Mathematical attacks usually geared to attack specifics in a protocol