SelfHealing Key Distribution with Revocation

1
Self-Healing Key Distribution with Revocation

• Presented by Matt Palombi
• 11/18/2004

2
Authors

• Xerox PARC - May 28, 2002
• Jessica Staddon
• Sara Miner
• Matt Franklin
• Dirk Balfanz
• Michael Malkin
• Drew Dean

3
Session Keys

• We want to ensure secure multicast communication.
• One solution is having a common session key
  shared by all group members.

4
Key Distribution

• A central group manager that periodically
  distributes new keys.
• New key every session.
• How can this be conducted over an unreliable
  network, such as the Internet?

5
Interactive Approach

• Require user to contact the group manager in
  order to resend the session key.
• Not practical in large groups
• Added traffic on a congested network
• Could overwhelm group manager
• Not desirable in certain high-security
  environments
• User wants to avoid sending unnecessary messages

6
A Non-Interactive Approach

• Self-Healing Key Distribution
• A group member that does not receive a key can
  recover it on its own
• Uses data from previous and subsequent key
  distribution broadcasts to recover the missing
  session key

7
Properties of Self Healing

• In a sequence of m sessions, all key broadcasts
  except the first and last could be lost, and all
  m sessions keys would be recoverable
• Using sandwiching broadcasts allows the use of a
  flat key management system

8
Flat Key Distribution

• Benefits
• Each user has a unique personal key
• Enables traceability
• Costs
• Increased communication overhead due to a key for
  every user

9
Revoking and Adding Users

• The key distribution scheme must also allow the
  group manager to add or remove users from the
  group at any time.
• Must be resistant to collusion attacks

10
Meeting Requirements

• These requirements can be met with simple,
  polynomial-based secret sharing techniques
• An unconditionally secure construction can be
  achieved with (t2m) log q bits.
• q is the session key size
• t is the size of the largest coalition the system
  is resistant to
• m is the number of sessions over which self
  healing is possible

11
Meeting requirements 2

• Can reduce broadcasts to (t2 mt) log q bits by
  shifting some computation to users end.
• In all versions, recovery from loss is possible
  with no delay after receiving a key broadcast
  transmission.

12
Related Work

• Other non-interactive methods of providing
  resistance to packet loss
• Error correcting codes provide information about
  previous keys (Keystone)
• Packets contain hints for previous keys,
  requires significant work on users end to
  recover (ELK)

13
Related Work (cont.)

• These approaches have some drawbacks
• Small broadcast size requires hierarchical key
  distribution
• Hierarchical keys apply to subsets of users, make
  traceability difficult
• Offline member cannot rejoin without intervention
  from group manager
• In ELK keying info is paired with content, only
  useful if group manager is only sender

14
Basic Definitions

• Session key the key used for group
  communication during a session
• Session A fixed interval of time
• t-revocation capability it is possible to
  prevent t users from learning the new session key

15
Basic Definitions (cont.)

• There is a group manager and n users, U1, , Un
• All operations take place in a finite field Fq,
  where q is a prime greater than n
• Each user, Ui, stores a personal key Si
• k is a single key (an element of Fq)

16
Definition 1 Key Independence

• There are m sessions and the session keys are K1
  through Km
• R is the set of revoked users. If a user is not
  in R, it is said to be a member or an active user
• For j Î 1, , m, Kj is sent to the group
  members through broadcast Bj

17
Definition 1 (Cont.)

• The information that the user knows by having
  both Bj and Si is represented by zi,j
• If Ui is a group member, zi,j will include Kj and
  possibly information on other authorized group
  keys
• If Ui is not a group member, there is no
  information about Kj in zi,j
• Users personal keys contain sensitive
  information, this guards against collusion attacks

18
Definition 2 Session Key Distribution

• Let t, i Î 1, , n, and j Î 1, , m
• D is a session key distribution scheme if
• Kj is determined by zi,j
• A set of less than t users cannot determine
  anything about Si from the session key
  broadcasts
• What a user learns is not determined by their
  personal key or broadcasts alone

19
Definition 2 (Cont.)

• D has t-revocation capability if
• The size of R is less than t, and the group
  manager can generate a broadcast that allows all
  members to recover the key, but does not allow
  any user in R to recover it.

20
Definition 2 (Cont.)

• D is self-healing if for any
• 1 j1 lt j lt j2 m this is true
• Kj is determined by the set of information known
  by any member in sessions j1 and j2
• no information on Kj can be computed by two
  disjoint sets of users as long as they number
  less than t

21
Self Healing

• In every broadcast, a user learns either the
  actual key or a share of the actual key for all m
  sessions
• The following diagram gives a simple example of
  how this might work

22
Self-Healing Explanation
23
Construction 1Self-Healing without Revocation

• This meets the self-healing requirement, but not
  revocation
• Three phases
• Setup
• Broadcast
• Session Key and Shares Recovery in Session j

24
Construction 1 Setup

• Pick t based on desired collusion resistance
• Group manager generates at random
• 2m polynomials of degree t in the finite field
  Fqx
• h1, , hm and p1, , pm
• m session keys K1 through Km

25
Construction 1 Setup (Cont.)

• For every j, define a polynomial
• qj(x) Kj pj(x)
• Each user Ui will store its personal key
• Si i, h1(i), ,hm(i)

26
Construction 1 Broadcast

• The broadcast for session j is
• Bj h1(x) p1(x), , hj-1(x)
  pj-1(x) h1(x) Kj,
• hj1(x) qj1(x), , hm(x) qm(x)

27
Construction 1 Session Key and Shares Recovery

• Finding Session Key
• Evaluate hj(x) Kj at i and subtract hj(i)
• Finding Session Key Shares
• Done in similar manner to session key, but
  involves data from two sandwiching broadcasts

28
Construction 2Key Distribution Scheme with
t-revocation and no self-healing

• Meets requirement for revocation capability, but
  not self-healing
• Generalization of Naor-Pinkas form for a common
  key over a broadcast channel
• Must ensure distinct shares to provide collusion
  resistance
• Three phases
• Setup
• Broadcast
• Key Recovery

29
Construction 2 Setup

• An integer t is chosen based on the desired
  collusion resistance
• N Î Fq, and is an element not equal to the index
  of any users index
• Group manager generates at random a polynomial,
  s(x,y) a0,0 a1,0x a0,1y at,t,xtyt.
  This is within the finite field Fqx,y
• User Ui stores the personal key, (N,i,s(i,i)).

30
Construction 2 Broadcast

• The manager chooses a random polynomial of degree
  t, called f(x)
• W is the set of the indices of the users barred
  from the system
• The broadcast consists of these polynomials
• f(x) s(N,x) È w,s(w,x) w Î W

31
Construction 2 Key Recovery

• A valid user (index not in W) evaluates s(w,x) at
  x i and uses the results in combination with
  its personal key in a series of computations to
  produce the individual key f(i)

32
Construction 3Secure self-healing session key
distribution

• Combines the techniques of constructions 1 and 2
• Three phases
• Setup
• Broadcast
• Session key and key shares recovery in session j
• Essentially a straightforward combination of the
  two previous constructions
• There are two broadcasts for each session
• Total broadcast size is O((mt2 mt) log q)

33
Construction 4Reduced overhead version of
Construction 3

• The broadcast size of construction 3 can be
  reduced to O((t2 mt) log q) by a few small
  changes.
• A pseudorandom sequence is made public and the
  original list of polynomials is reduced in size.
• Users use this sequence to generate the remaining
  polynomials.

34
Proofs

• All these constructions are proved secure in the
  appendices of the paper
• To cover these proofs would be well beyond the
  scope of this presentation

35
Practical Issues 1

• Can these constructions be used in real-world
  applications?
• The authors considered groups of 10,000 or more
  members with frequently changing membership
• Broadcast size isnt related to number of
  members, and the parameters that affect the size
  grow much more slowly

36
Practical Issues 2

• Session keys late in the m sessions more prone to
  packet loss since less likelihood of getting a
  good broadcast after current session
• One solution a sliding window version of the
  key distribution schemes
• Any two packets that sandwich a missing
  transmission closely enough can be used to
  recover the key

37
Contributions

• Extends older research on group key distribution
  to allow use in real-world applications where
  packet loss is an issue
• Puts forth a provably secure solution to these
  problems with a efficient broadcast solution

38
Weaknesses

• Considers only a broadcast based approach with a
  non-interactive recovery from loss.
• Mostly a result of the assumptions of a large
  group size peer-to-peer solutions with
  interactive loss recovery could work quite well
  with smaller groups.

39
Any Questions?