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!