Graceful Service Degradation (Or, How To Know Your Payment Is Late)

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

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

3. ? When late on a payment (e.g.) 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

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 <m,F(m)> is valid • We need: • Parametrizable “moderately hard” function F • A degraded user gets “m” and a hardness parameterp • Computing F(m) takes roughly O(2p) operations

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

8. k bits x*= 01001… 11010... *****... Y(p)(x*)= 01001… p bits 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

9. Hint given to P x*= Hint given to D Using Variably Hard Functions • Encrypt the content with a session key SK=F(x*) • Broadcast g(x*) • Distribute hints of x* using revocation protocol

10. Bob Alice Charlie 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

11. in R U in P 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 Su U, |Su|=s • To broadcast message SK to only P: • Take U • Throw away all keys known by R • For each remaining key k, broadcast Ek[SK] • Design sets Su such that: • Each user in P can decrypt at least s/2 copies of SK

12. Revocation: Step 2 • 2. secret sharing • Improves on 1st 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(r2*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/2shares (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 2psteps • 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 D1, D2,… DL (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 30th -> 40th day, the service is progressively worse • 1 degraded class per day: D1,D2,…D10 • Each Di has its “hardness” parameter normal service degraded revoked time t=0 (subscription) t=30 t=40

18. At t=29, x= … … ? Trial Period Scenario: Construction • Broadcast on day t: EF(x)[SK], g(x) • Hints: • Construct Ai , where Ai=W(Ai+1) and W is OWP • Give A29 to user • On day t<30, the user has complete hint x • On day t≥30, the user has partial hint on x ←A19←A20←A21←… ←A29←A30←A31←… Legend: ← means application of a OWF/OWP At t=30, x= At t=31, x= … … ? ?

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!