Some are not thieves!

Some are not thieves!

Alexandr Andoni (MIT) (work done while at PARC)

Jessica Staddon (PARC)

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

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

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]

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)

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

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)

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

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

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

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

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)

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

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

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

Practical Degradation Protocols

Will present two:Known degradation schedule: trial period scenario

Unknown degradation schedule: general scenario

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

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

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)

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

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

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?

Thank you!