1. Graceful Service Degradation (Or, How To Know Your Payment Is Late) Alexandr Andoni (MIT) Jessica Staddon (PARC)

2. Model Content Distributor (e.g., PayTV) Privileged User (has key) ? Revoked User (w/o a key) When late on payments (e.g.) Subscription to service

3. Problem Transition too rigid: ineffective, disruptive when happened unexpectedly, in error, etc Too much if just a reminder of late payment Example scenario: User forgot to pay the monthly payment (or, is at the end of trial period) => is revoked by the distributor => misses favorite TV show => reinstatement: high logistical cost ? When late on a payment (e.g.)

4. Remedy Cues on pending revocation Graceful, but tied to the content I.e., graceful revocation: Degrade quality of service (e.g., content is delayed or partial) For users that are “a little late” on payment “Degradation”? Degraded = it takes more effort to decrypt the content; but all content is decrypted in the end (our definition) Other possible definitions (not considered here): Video is choppy [Abdalla-Shavitt-Wool’03]

5. How… To impose “effort to decrypt” on degraded users: via variably hard functions Computing the function incurs computational effort The amount of computational effort is parametrizable Inspired by hard functions from spam-fighting, “pricing functions” [Dwork-Naor’92], “proofs of work” [Jakobsson- Juels’03], others To segregate users into classes: via degradation protocols Degradation protocol = variation of revocation protocol Revocation protocol = allows targeting content to any set P of users

6. Variably Hard Functions From “proofs of work” 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 Computing F(m) takes roughly O(2 p ) operations

7. Def: Variably Hard Functions F() is variably hard if: When user receives Test value g(x * ), together with g() Hint: a set Y (p) (x * ) containing x * ; size of the set =2 p Can’t compute F(x * ) in less than ~O(2 p ) operations “Hardness” is in not knowing x * But can compute F(x * ) in O(2 p ): Try all possible x  Y (p) (x * ) until g(x)=g(x * )

8. Example: F based on OWP P = one-way permutation Define g(x)=P(x) F(x)=x Thus, F(x)=P -1 (g(x)) A hint Y (p) (x * ): some bits of x * In paper: memory-bound functions [Dwork-Goldberg-Naor’03] An operation = an access to main memory p bits Y (p) (x*)=01001… *****... x*=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 x*=x*= Hint given to P Hint given to D Class of usersHint receivedTime to compute SK P, privileged usersCompleteFast: O(1) D, degraded usersPartialModerate: O(2 p ) R, revoked usersNo hintImpossible: O(2 k )

10. Distributing hints: Protocols Using a revocation protocol: Distribute keys to users, s.t. Can target content to any set of users P For degradation: “content”=hint Target complete hint to P Target partial hint to P  D Example of revocation protocol: To target P={Alice, Bob}, encrypt with Cost (communication)=~O(|D  R|) (for “reasonable” revocation protocols) But, maybe can do better P and D receive almost the same information Alice Bob Charlie

11. Improved protocol Proof of concept: will modify revocation protocol of [Kumar-Rajagopalan-Sahai’99] 2 steps: 1. cover free families Let U be a universe of keys A user u gets a S u  U, |S u |=s To broadcast message SK to only P: Take U Throw away all keys known by R For each remaining key k, broadcast E k [SK] Design sets S u such that: Each user in P can decrypt at least s/2 copies of SK U in R in P

12. Revocation: Step 2 2. secret sharing Improves on 1 st step Can improve because a u  P gets s/2 copies of SK Use secret sharing scheme Create |U| shares of SK Such that s/2 shares are enough to recover SK Improved parameters [KRS’99, randomized]: Communication blowup: reduced to O(r) from O(r 2 *log n)

13. Towards degradation protocol So far, [KRS’99] establishes: If u  P, then gets s/2 shares of SK If u  R, then gets 0 shares Would like: If u  P, then gets s/2 shares of SK If u  D, then gets f*s/2 shares (0<f<1) If u  R, then gets 0 shares With f*s/2 shares: Have a hint Y (p) (x), p=(1-f)*Length_Of_Key Can recover SK in 2 p steps Indeed can modify the [KRS’99] cover-free family: For key k  U If known by R, throw away If known just by P, leave If known by D\R, leave with probability ≈f

14. Degradation protocol: Result Can improve bounds (over those of the revocation protocol) But messy: many parameters (max # revoked, max # degraded, hardness parameter) Have to know all the parameters in advance (as for KRS’99) Not collusion resistant against degraded users Several degraded users may have sufficient # of shares However, practical argument: not a “serious” problem Degradation mainly serves as a cue Act of colluding is sufficient to serve as a cue

15. More degradation 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 (with progressively worse service quality) Revoked class R Known degradation schedule: we may know when a user will be degraded

16. Degradation Protocol 2 Will present: Known degradation schedule Trial period scenario General scenario (unknown schedule): similar, but need to use revocation protocols

17. Trial Period Scenario: Model In the period 30 th -> 40 th day, 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 F(x) [SK], g(x) Hints: Construct A i, where A i =W(A i+1 ) and W is OWP Give A 29 to user On day t<30, the user has complete hint x On day t≥30, the user has partial hint on x At t=30, x= At t=31, x= ← A 19 ←A 20 ←A 21 ←… ←A 29 ←A 30 ←A 31 ←… … At t=29, x=… ? …? ? Legend: ← means application of a OWF/OWP …

19. Conclusions Introduced the notion of service degradation Degraded users: between privileged and revoked (service-wise) Have degraded service quality Serves as a cue to impending revocation Construction based on: Variably hard functions Revocation protocols

20. Questions (for Lunch-Break) Degradation: How much can it buy us in terms of user storage and communication? (over revocation) We define “degradation”=delay. Is this the right approach? Are there other (better) ones that we can provably impose on degraded users, without losing in performance?

21. Thank you!