1 / 21

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

This paper discusses the problem of late payments in a subscription-based content distribution model and proposes a solution called graceful service degradation. It explores the use of variably hard functions and degradation protocols to ensure a smooth transition for users who are late on their payments.

csharon
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related