graceful service degradation (or, how to know your payment is late) alexandr andoni (mit) jessica...

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

Alexandr Andoni (MIT)

Jessica Staddon (PARC)

Model

Content Distributor(e.g., PayTV)

PrivilegedUser(has key)

? RevokedUser(w/o a key)

When late on payments (e.g.)

Subscription to service

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.)

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]

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

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 parameter p

Computing F(m) takes roughly O(2p) operations

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 =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 xY(p)(x*) until g(x)=g(x*)

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*=

k bits

01001… 11010...

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*=

Hint given to P

Hint given to D

Class of users Hint received

Time to compute SK

P, privileged users

Complete Fast: O(1)

D, degraded users

Partial Moderate: O(2p)

R, revoked users

No hint Impossible: O(2k)

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 PD

Example of revocation protocol: To target P={Alice, Bob},

encrypt with

Cost (communication)=~O(|DR|) (for “reasonable” revocation protocols)

But, maybe can do better P and D receive almost the same information

Alice

Bob Charlie

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

U

in R

in P

Revocation: Step 2 2. secret sharing

Improves on 1st step Can improve because a uP 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)

Towards degradation protocol So far, [KRS’99] establishes:

If uP, then gets s/2 shares of SK If uR, then gets 0 shares

Would like: If uP, then gets s/2 shares of SK If uD, then gets f*s/2 shares (0<f<1) If uR, 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 2p steps

Indeed can modify the [KRS’99] cover-free family: For key kU

If known by R, throw away If known just by P, leave If known by D\R, leave with probability ≈f

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

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

Degradation Protocol 2

Will present: Known degradation schedule Trial period scenario

General scenario (unknown schedule): similar, but need to use revocation protocols

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

timet=0(subscription)

t=30 t=40

normal service degraded revoked

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

At t=30, x=

At t=31, x=

←A19←A20←A21←… ←A29←A30←A31←…

…

At t=29, x= …

?

… ?

?

Legend:← means applicationof a OWF/OWP

…

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

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?

Thank you!