Octopus

CS 259

Taral JoglekarRyan Wisnesky

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

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

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

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

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

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.

Key exchange protocol

A

C

B

D

ga

gb

gc

gd

gabgcd gabgcd

Shared Key: cdgabgg

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

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

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

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

Invariant for Key agreementinvariant "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

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.

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.

ExampleMDS

CEDAR OverviewLet 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.

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…)

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.

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.

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.

Example

A B

A -> B : B dom AB -> A : beacon

The intruder is listening…

Example

A B

Topology change.A -> C : C dom A

C

Example

A B

Intruder blocks communication between A and C. This means C removes itself from the core.

C

I

Example

A B

I -> A : B’s beaconI -> B : A’s beaconA -> I : B dom AI -> B : B dom A

Result: A and B think they are connected, but they are not. This prevents correct routing.

C

I

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.

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 ge

1^s

1 e

2^s

2 ... e

n ^ s

n

GDH.2 and OctopusWe can write the key in a similar form, to get an

equationge

1^s

1 e

2^s

2 ... e

n ^ s

n = 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.

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.

GDH.2 and Octopus

Initial Knowledge Initial Knowledge

e1

en

Apply s1 times

Apply s1 times

…..

key

e1

e1

key

Apply s11 times

Apply s1n times

Other applications

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