Some are not thieves!
-
Upload
aretha-fernandez -
Category
Documents
-
view
28 -
download
0
description
Transcript of Some are not thieves!
![Page 1: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/1.jpg)
Some are not thieves!
Alexandr Andoni (MIT) (work done while at PARC)
Jessica Staddon (PARC)
![Page 2: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/2.jpg)
ModelContent distributorBroadcast channel (accessible to all)
E.g., Pay-TV, Online serviceContent encrypted to limit access
UsersPrivileged – ones that can decrypt the content Revoked – whose privileges where revoked due to non-payment, expiration, etc
Key management protocol (revocation protocol)More on this later
![Page 3: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/3.jpg)
Problem0/1 (/) user hierarchy is too rigid
Ineffective, disruptive when the revocation happened unexpectedly, in error, etc
Imagine unfortunate scenarioUser is late on the monthly payment=> is revoked by the distributor=> misses favorite TV show=> has to ask for reinstatement: high logistical cost
Want:Graceful revocationCues on pending revocation: inherent to the content
![Page 4: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/4.jpg)
Basic SolutionService degradation
Degrade quality of service (e.g., content is delayed or partial)Affects users that are “a little late” on paymentCue of pending revocation: degradation itself
What means “degradation”?Our definition:
• Degraded = it takes more effort to decrypt the content; but all content is decrypted in the end
Other possible definitions (not considered here):• Video is choppy [Abdalla-Shavitt-Wool’03]
![Page 5: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/5.jpg)
How?Enforce user classes via key management protocols (a.k.a. revocation protocols)
Revocation protocol = can target any set P of usersDegradation protocol is a specialization of the revocation protocol, but hope to improve parameters
Effort to decrypt: via variably hard functionsComputing the function incurs computational effortThe amount of computational effort is parametrizableRelated to “pricing functions” [Dwork-Naor’92], “proofs of work” [Jakobsson-Juels’03] (in the context of spam-fighting)
![Page 6: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/6.jpg)
Variably Hard Functions
Inspired from the idea of “proofs of work” proposed mostly 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
For fixed m, F(m) must be the same for all p
![Page 7: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/7.jpg)
Definition: Variably Hard Functions
F is variably hard if:There is some test function g(x) (think g(x)=m)
For each x, there is a collection of hints Hints(x)• A hint is a set Y(p)(x) of size 2p s.t. xY(p)(x)
It takes ≥O(2p) time to compute F(x) given only g(x) and some Y(p)(x) (x is not given)
“Hardness” in not knowing x
Can compute F(x) in 2p given g(x), Y(p)(x):Just try all possible xY(p)(x) and test with g(x)
![Page 8: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/8.jpg)
Construction via OW Permutation
Let P be a one-way permutationDefine test function g(x)=P(x)Define F(x)=xComputing F(x) knowing g(x) is equivalent to inverting PA hint Y(p)(x) is the set of y’s that have same first k-p bits as x
Y(p)(x)=
p bits
01001… *****...
x=
k bits
01001… 11010...
![Page 9: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/9.jpg)
Using Variably Hard FunctionsEncrypt the content with a session key SK=F(x)Broadcast g(x)Distribute hints of x using revocation protocol
Privileged users P: receive complete hint => easy to compute SKDegraded users D: receive partial hint => moderate to computeRevoked users R: receive no hint => impossible to compute
Inefficient: Have to be able to
target only P
More direct approach?
x=
To privileged
To degraded
![Page 10: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/10.jpg)
Revocation Protocols
Non-trivial:If all users have the same key, how do we “take back” the key from a revoked user?
Studied since ’90s:Stateful – users have “state”; but might be fatal if they miss a part of the broadcast
Stateless
Most common (stateless) are based on e.g., Shamir-like secret sharing
![Page 11: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/11.jpg)
Improve RevocationIllustration for revocation based on secret sharingRevocation protocol of [Kumar-Rajagopalan-Sahai’99] in two steps:
1st step: uses cover free families • Let U be a universe of keys• Users get distinct subsets Su U (all Su form cover-free family)• A message SK is broadcasted as:
Ek1[SK], Ek2[SK]… Eks[SK] , for some T={k1…ks}U• If SuT≠, then the user can decrypt SK• Design sets Su such that:
for any Su (privileged user), and S1,S2,…Sr (revoked) |Su\S1\S2\...Sr|≥a|Su|, where a is a constant
![Page 12: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/12.jpg)
Revocation via Secret Sharing (2)2nd step: reduce communication blow-up
• For revoked S1,S2,…Sr, encrypt with all T=U\S1\S2\...Sr
• Parameters so far: User storage: |Su|=O(r log n) keys Communication blow-up: |U|=O(r2 log n)
• Can improve: a privileged user gets a|Su| copies of SK• Use a secret sharing scheme!• Create U shares of SK such that any a|Su| shares are enough to
reconstruct SK
Obtain parameters [KRS99, randomized]:• User storage: O(r*log n)• Communication blowup: O(r)
![Page 13: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/13.jpg)
Secret Sharing for Degradation[KRS’99] establishes:
A privileged user gets a|Su|=O(r log n) shares of SKA revoked user gets 0 shares
Design such that a degraded user gets, e.g., (1-c)*a|Su| shares (0<c<1):
These shares constitute a hint Y(p)(x), p=ca|Su|A degraded user recovers SK in 2ca|Su| steps
Indeed can modify the [KRS’99] cover-free family:
If key kU belongs to D but not R, choose k to be in T with some probability p≈1-c
![Page 14: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/14.jpg)
DeficienciesCan obtain some slightly better bounds, but messyMany parameters (max # revoked, max # degraded)Have to know the parameters in advance (same for KRS’99)Not collusion resistant against degraded users
Several degraded users may get all the necessary sharesNot a big problem
• Degradation mainly serves as a cue• Act of colluding is sufficient to serve as a cue
![Page 15: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/15.jpg)
Towards (more) practical 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 (progressively worse service quality)
• Revoked class R
Known degradation schedule: sometimes we know when somebody will probably be degraded
![Page 16: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/16.jpg)
Practical Degradation Protocols
Will present two:Known degradation schedule: trial period scenario
Unknown degradation schedule: general scenario
![Page 17: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/17.jpg)
Trial Period Scenario: Model
Trial period scenario
In the period [30,40] days, the service is progressively worse
1 degraded class per day: D1,D2,…D10
Each Di has its “hardness” parameter
timet=0subscription
t=30 t=40
normal service degraded revoked
![Page 18: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/18.jpg)
Trial Period Scenario: Construction
Broadcast on day t: EKt[SK], EF(x)[SK], g(x)Ki is a series such that Ki=W(Ki+1); W is one-wayAi is defined the same wayA user gets K29 and A29
On day t<30, the user can decrypt SK with Kt On day t≥30, the user can compute F(x): from g(x) and an incomplete hint based on At-10…A29
At t=30, x=
At t=31, x=
←A19←A20←A21←… ←A29←A30←A31←…
?…
… ? ?
Legend:← means applicationof a one-wayfunction/permutation
![Page 19: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/19.jpg)
General Scenario
Can generalize the previous protocol
Same idea of using At series to create many degradation classes
But need more attentive distribution of At and Kt: using revocation protocols this time
Can be based on any revocation protocol
Expensive communication only when classes change (somebody is degraded/revoked)
![Page 20: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/20.jpg)
Final Remarks
Computational effort may vary on different machines:
Then, use in fact the “memory-bound” functions of [Dwork-Goldberg-Naor’03]
• Can guarantee O(2p) memory accesses
• More uniform across platforms
We adapted “memory-bound” functions to be variably hard
![Page 21: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/21.jpg)
Conclusions
Introduced the notion of service degradation
Degraded users: between privileged and revokedHave degraded qualityServes as a cue to impending revocation
Construction based on:Variably hard functionsRevocation protocols
![Page 22: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/22.jpg)
Interesting Questions
How much can degradation buy us in terms of user storage and communication?
Is this the right approach to degradation? Are there other (better) ones?
![Page 23: Some are not thieves!](https://reader036.fdocuments.us/reader036/viewer/2022062321/56812c34550346895d90bb3c/html5/thumbnails/23.jpg)
Thank you!