Title: Octopus
1Octopus
CS 259
Taral Joglekar Ryan Wisnesky
2Outline
- Adhoc networks
- Octopus Protocol
- Murphi model and attacks
- CEDAR with Octopus
- Attacks on CEDAR
- Using GDH.2 attack techniques
3Ad 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
4Challenges
- 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
5Challenges (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
6Security 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
7The 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.
8Key exchange protocol
ga
A
B
gb
gab
gcd
gab
gcd
gc
C
D
gd
Shared Key
9Properties 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
10Murf 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
11Murf 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
12Murf 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
13Invariant for Key agreement
- invariant "key agreement"
- forall i CoreId do
- corei.mainState C_MAINDONE
- -gt
- forall j PeerId do
- forall kPeerId do
- (peerj.state P_GOTKEY peerk.state
P_GOTKEY) - -gt
- forall lValidAgentId do
- peerj.keyMaterial_Vl
peerj.keyMaterial_Vl - (peerj.keyMaterial_Vl true -gt
- peerj.keyMateriall
peerk.keyMateriall ) - endforall
- endforall
- endforall
- endforall
14From 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.
15Dominating 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.
16Example
MDS
17CEDAR Overview
Let N1(u) denote all the nodes that u is
connected to. Let N1(u) N1(u) u. Let
dom(u) denote us dominator. Let d(u)
N1(u). Let d(u) the number of us
neighbors that have chose u as their dominator.
This is us 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) gt 0, u joins
the core.
18Key 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)
19Questions 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 cant prove anything, but it suggests
directions.
20Two 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 nodes 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.
21A 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.
22Example
A -gt B B dom A B -gt A beacon The intruder is
listening
A
B
23Example
Topology change. A -gt C C dom A
A
B
C
24Example
Intruder blocks communication between A and C.
This means C removes itself from the core.
A
B
C
I
25Example
I -gt A Bs beacon I -gt B As beacon A -gt I
B dom A I -gt B B dom A Result A and B think
they are connected, but they are not. This
prevents correct routing.
A
B
C
I
26GDH.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.
27GDH.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
gab gab. So, we can write any use of these
services as ge1s1 e2s2 ... en sn
28GDH.2 and Octopus
- We can write the key in a similar form, to get an
equation - ge1s1 e2s2 ... en sn ge1k1 e2k2 ... 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 arent atomic, so the
equations arent trivial. If this system cant
be solved, then there isnt an attack (or so the
paper claims). If it can, then further
refinement is needed.
29GDH.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.
30GDH.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
31Conclusions
- 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