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 => is revoked by the distributor => misses favorite TV show => 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-Wool’03]

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-Naor’92], “proofs of work” [Jakobsson-Juels’03] (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 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 2 p s.t. x  Y (p) (x) It takes ≥O(2 p ) 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 2 p 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 y’s that have same first k-p bits as x Y (p )(x)= p bits 01001…*****... x= k bits 01001…11010...

9. Using Variably Hard Functions Encrypt the content with a session key SK=F(x) Broadcast g(x) Distribute hints of x using revocation protocol Privileged users P: receive complete hint => easy to compute SK Degraded users D: receive partial hint => moderate to compute Revoked users R: receive no hint => impossible to compute Inefficient: Have to be able to target only P More direct approach? x= To privileged To degraded

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- Sahai’99] in two steps: 1 st step: uses cover free families Let U be a universe of keys Users get distinct subsets S u  U (all S u form cover-free family) A message SK is broadcasted as:  E k1 [SK], E k2 [SK]… E ks [SK], for some T={k1…ks}  U If S u  T≠ , then the user can decrypt SK Design sets S u such that:  for any S u (privileged user), and S 1,S 2,…S r (revoked)  |S u \S 1 \S 2 \...S r |≥a|S u |, where a is a constant

12. Revocation via Secret Sharing (2) 2 nd step: reduce communication blow-up For revoked S 1,S 2,…S r, encrypt with all T=U\S 1 \S 2 \...S r Parameters so far:  User storage: |S u |=O(r log n) keys  Communication blow-up: |U|=O(r 2 log n) Can improve: a privileged user gets a|S u | copies of SK Use a secret sharing scheme! Create U shares of SK such that any a|S u | shares are enough to reconstruct SK Obtain parameters [KRS99, randomized]: User storage: O(r*log n) Communication blowup: O(r)

13. Secret Sharing for Degradation [KRS’99] establishes: A privileged user gets a|S u |=O(r log n) shares of SK A revoked user gets 0 shares Design such that a degraded user gets, e.g., (1-c)*a|S u | shares (0<c<1): These shares constitute a hint Y (p) (x), p=ca|S u | A degraded user recovers SK in 2 ca|Su| steps Indeed can modify the [KRS’99] cover-free family: If key k  U belongs to D but not R, choose k to be in T with some probability p≈1-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 KRS’99) 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 don’t change Want finer division into classes: Privileged class P Degraded classes D 1, D 2,… D L (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: D 1,D 2,…D 10 Each D i has its “hardness” parameter time t=0 subscription t=30 t=40 normal servicedegradedrevoked

18. Trial Period Scenario: Construction Broadcast on day t: E Kt [SK], E F(x) [SK], g(x) K i is a series such that K i =W(K i+1 ); W is one-way A i is defined the same way A user gets K 29 and A 29 On day t<30, the user can decrypt SK with K t On day t≥30, the user can compute F(x): from g(x) and an incomplete hint based on A t-10 …A 29 At t=30, x= At t=31, x= ← A 19 ←A 20 ←A 21 ←… ←A 29 ←A 30 ←A 31 ←… ?… …?? Legend: ← means application of a one-way function/permutation

19. General Scenario Can generalize the previous protocol Same idea of using A t series to create many degradation classes But need more attentive distribution of A t and K t : 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-Naor’03] Can guarantee O(2 p ) 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!