Graceful Service Degradation (Or, How To Know Your Payment Is Late)
description
Transcript of Graceful Service Degradation (Or, How To Know Your Payment Is Late)
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!