Some are not thieves!

1
Some are not thieves!

• Alexandr Andoni (MIT)
• (work done while at PARC)
• Jessica Staddon (PARC)

2
Model

• Content distributor
• Broadcast channel (accessible to all)
• E.g., Pay-TV, Online service
• Content encrypted to limit access
• Users
• Privileged ones that can decrypt the content ?
• Revoked whose privileges where revoked due to
  non-payment, expiration, etc ?
• Key management protocol (revocation protocol)
• More on this later

3
Problem

• 0/1 (?/?) user hierarchy is too rigid
• Ineffective, disruptive when the revocation
  happened unexpectedly, in error, etc
• Imagine unfortunate scenario
• User is late on the monthly payment
• gt is revoked by the distributor
• gt misses favorite TV show
• gt has to ask for reinstatement high logistical
  cost
• Want
• Graceful revocation
• Cues on pending revocation inherent to the
  content

4
Basic Solution

• Service degradation
• Degrade quality of service (e.g., content is
  delayed or partial)
• Affects users that are a little late on payment
• Cue of pending revocation degradation itself
• What means degradation?
• Our definition
• Degraded it takes more effort to decrypt the
  content but all content is decrypted in the end
• Other possible definitions (not considered here)
• Video is choppy Abdalla-Shavitt-Wool03

5
How?

• Enforce user classes via key management protocols
  (a.k.a. revocation protocols)
• Revocation protocol can target any set P of
  users
• Degradation protocol is a specialization of the
  revocation protocol, but hope to improve
  parameters
• Effort to decrypt via variably hard functions
• Computing the function incurs computational
  effort
• The amount of computational effort is
  parametrizable
• Related to pricing functions Dwork-Naor92,
  proofs of work Jakobsson-Juels03 (in the
  context of spam-fighting)

6
Variably Hard Functions

• Inspired from the idea of proofs of work
  proposed mostly for fighting spam
• For an email m, have to attach F(m) such that
• Moderately hard to compute F(m) (e.g., 10secs)
• Easy/fast to check that ltm,F(m)gt is valid
• We need
• Parametrizable moderately hard function F
• A degraded user gets m and a hardness parameter
  p
• For fixed m, F(m) must be the same for all p

7
Definition Variably Hard Functions

• F is variably hard if
• There is some test function g(x) (think g(x)m)
• For each x, there is a collection of hints
  Hints(x)
• A hint is a set Y(p)(x) of size 2p s.t. x?Y(p)(x)
• It takes O(2p) time to compute F(x) given only
  g(x) and some Y(p)(x) (x is not given)
• Hardness in not knowing x
• Can compute F(x) in 2p given g(x), Y(p)(x)
• Just try all possible x?Y(p)(x) and test with g(x)

8
Construction via OW Permutation

• Let P be a one-way permutation
• Define test function g(x)P(x)
• Define F(x)x
• Computing F(x) knowing g(x) is equivalent to
  inverting P
• A hint Y(p)(x) is the set of ys that have same
  first k-p bits as x

k bits
x
01001
11010...
Y(p)(x)
01001
...
p bits
9
Using Variably Hard Functions

• Encrypt the content with a session key SKF(x)
• Broadcast g(x)
• Distribute hints of x using revocation protocol
• Privileged users P receive complete hint gt easy
  to compute SK
• Degraded users D receive partial hint gt
  moderate to compute
• Revoked users R receive no hint gt impossible to
  compute
• Inefficient
• Have to be able to
• target only P
• More direct approach?

10
Revocation Protocols

• Non-trivial
• If all users have the same key, how do we take
  back the key from a revoked user?
• Studied since 90s
• Stateful users have state but might be fatal
  if they miss a part of the broadcast
• Stateless
• Most common (stateless) are based on e.g.,
  Shamir-like secret sharing

11
Improve Revocation

• Illustration for revocation based on secret
  sharing
• Revocation protocol of Kumar-Rajagopalan-Sahai99
  in two steps
• 1st step uses cover free families
• Let U be a universe of keys
• Users get distinct subsets Su ?U (all Su form
  cover-free family)
• A message SK is broadcasted as
• Ek1SK, Ek2SK EksSK , for some Tk1ks?U
• If Su?T??, then the user can decrypt SK
• Design sets Su such that
• for any Su (privileged user), and S1,S2,Sr
  (revoked)
• Su\S1\S2\...SraSu, where a is a constant

12
Revocation via Secret Sharing (2)

• 2nd step reduce communication blow-up
• For revoked S1,S2,Sr, encrypt with all
  TU\S1\S2\...Sr
• Parameters so far
• User storage SuO(r log n) keys
• Communication blow-up UO(r2 log n)
• Can improve a privileged user gets aSu copies
  of SK
• Use a secret sharing scheme!
• Create U shares of SK such that any aSu shares
  are enough to reconstruct SK
• Obtain parameters KRS99, randomized
• User storage O(rlog n)
• Communication blowup O(r)

13
Secret Sharing for Degradation

• KRS99 establishes
• A privileged user gets aSuO(r log n) shares of
  SK
• A revoked user gets 0 shares
• Design such that a degraded user gets, e.g.,
  (1-c)aSu shares (0ltclt1)
• These shares constitute a hint Y(p)(x), pcaSu
• A degraded user recovers SK in 2caSu steps
• Indeed can modify the KRS99 cover-free family
• If key k?U belongs to D but not R, choose k to be
  in T with some probability p1-c

14
Deficiencies

• Can obtain some slightly better bounds, but messy
• Many parameters (max revoked, max degraded)
• Have to know the parameters in advance (same for
  KRS99)
• Not collusion resistant against degraded users
• Several degraded users may get all the necessary
  shares
• Not a big problem
• Degradation mainly serves as a cue
• Act of colluding is sufficient to serve as a cue

15
Towards (more) practical protocols

• Observations
• Not necessary to redistribute hints for each new
  session if user classes dont change
• Want finer division into classes
• Privileged class P
• Degraded classes D1, D2, DL (progressively worse
  service quality)
• Revoked class R
• Known degradation schedule sometimes we know
  when somebody will probably be degraded

16
Practical Degradation Protocols

• Will present two
• Known degradation schedule trial period scenario
• Unknown degradation schedule general scenario

17
Trial Period Scenario Model

• Trial period scenario
• In the period 30,40 days, the service is
  progressively worse
• 1 degraded class per day D1,D2,D10
• Each Di has its hardness parameter

18
Trial Period Scenario Construction

• Broadcast on day t EKtSK, EF(x)SK, g(x)
• Ki is a series such that KiW(Ki1) W is one-way
• Ai is defined the same way
• A user gets K29 and A29
• On day tlt30, the user can decrypt SK with Kt
• On day t30, the user can compute F(x) from g(x)
  and an incomplete hint based on At-10A29

At t30, x
At t31, x
19
General Scenario

• Can generalize the previous protocol
• Same idea of using At series to create many
  degradation classes
• But need more attentive distribution of At and
  Kt using revocation protocols this time
• Can be based on any revocation protocol
• Expensive communication only when classes change
  (somebody is degraded/revoked)

20
Final Remarks

• Computational effort may vary on different
  machines
• Then, use in fact the memory-bound functions of
  Dwork-Goldberg-Naor03
• Can guarantee O(2p) memory accesses
• More uniform across platforms
• We adapted memory-bound functions to be
  variably hard

21
Conclusions

• Introduced the notion of service degradation
• Degraded users between privileged and revoked
• Have degraded quality
• Serves as a cue to impending revocation
• Construction based on
• Variably hard functions
• Revocation protocols

22
Interesting Questions

• How much can degradation buy us in terms of user
  storage and communication?
• Is this the right approach to degradation? Are
  there other (better) ones?

23

• Thank you!