Octopus

1
Octopus
CS 259
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
gab
gcd
gab
gcd
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
Murf 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
Murf 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
Murf 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
• 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

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

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 -gt B B dom A B -gt A beacon The intruder is
listening
A
B
23
Example
Topology change. A -gt C C dom A
A
B
C
24
Example
Intruder blocks communication between A and C.
This means C removes itself from the core.
A
B
C
I
25
Example
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
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
  gab gab. So, we can write any use of these
  services as ge1s1 e2s2 ... en sn

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

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