Graceful Service Degradation(Or, How To Know Your Payment Is Late)
Alexandr Andoni (MIT)
Jessica Staddon (PARC)
ModelContent 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!