Key Regression

Fu, Kamara, Kohno

Divya Muthukumaran

Content Distribution Content publishers -> Content

distribution Outsourcing storage and distribution

Content distribution Networks: Akamai SpeedEra MirrorImage..

Access Control ?

Storage System Players Possible attacks?

Owners

Readers Writers

r w

Storage Server

Storage System Players Possible attacks?

On the stored data On the wire

Kinds of attacks Leak attacks Change Destroy

Owners

Readers Writers

r w

Storage Server

Storage System Players Enrypt-on-the-wire

Trust the server Encrypt-on-disk

Store encrypted Untrusted Server

Owners

Readers Writers

r w

Storage Server

Storage System Players

Security Primitives Authentication Authorization Securing data on disk Securing data on the

wire Key distribution Revocation

Owners

Readers Writers

r w

Storage Server

PLUTUS

Untrusted server Trusted client Decentralized key distribution

Client based – customizable Encrypt-on-disk Server verifies writes Integrity + Prevent readers from Writing

Asymmetric Encryption

System Overview

WritersReaders

FileOwners

System Overview

LockboxWritersReaders

File

+ File Verify key (e,N)

+ File Sign Key (d,N)

Owners

System Overview

WritersReaders

File Group

+ File Verify key (e,N)

+ File Sign Key (d,N)

Owners

Revocation: Get out andStay out! Expensive for Encrypt-on-disk system.

Why?

Re-encryptionall content with new key

Re-Distribute new keys to all the readers and writers

Lazy Revocation

Delay the encryptionBecause revoked users could have cached

the data available earlier

For the clientsToo many keys to be maintainedA new key after each revocation

File Groups:Multiple keys associated with a single file

group

13

File Group

Key Rotation

Wind and Unwind keysOnly owners can wind keys (Forward)Readers can unwind keys(Backward)

How? RSAOwners : Readers:

14

Appears in the Proceedings of the 2nd Conference on File and Storage Technologies (FAST’03). pp. 29–42 (31 Mar –

2 Apr 2003, San Francisco, CA). Published by USENIX, Berkeley, CA

Plutus, re-computing block hashes and re-signing root

hashes as well) of the affected files. Revocation also in-

troduces an additional overhead as owners now need to

distribute new keys to users. Though the security seman-

tics of revocation need to be guaranteed, they should be

implemented with minimal overhead to the regular users

sharing those files.

To make revocation less expensive, one can delay re-

encryption until a file is updated. This notion of lazy re-

vocation was first proposed in Cepheus [13]. The idea is

that there is no significant loss in security if revoked read-

ers can still read unchanged files. This is equivalent to the

access the user had during the time that they were autho-

rized (when they could have copied the data onto floppy

disks, for example). Expensive re-encryption occurs only

when new data is created. The meta-data still needs to be

immediately changed to prevent further writes by revoked

writers. We discuss subtle attacks that are still possible in

Section 4.

A revoked reader who has access to the server will still

have read access to the files not changed since the user’s

revocation, but will never be able to read data updated

since their revocation.

Lazy revocation, however, is complicated when multi-

ple files are encrypted with the same key, as is the case

when using filegroups. In this case, whenever a file gets

updated, it gets encrypted with a new key. This causes

filegroups to get fragmented (meaning a filegroup could

have more than one key), which is undesirable. The next

section describes how we mitigate this problem; briefly,

we show how readers and writers can generate all the pre-

vious keys of a fragmented filegroup from the current key.

3.5 Key rotation

The natural way of doing lazy revocation is to generate a

new filegroup for all the files that are modified following

a revocation and then move files to this new filegroup as

files get re-encrypted. This raises two issues: a) there is

an increase in the number of keys in the system following

each revocation; and b) because the sets of files that are

re-encrypted following successive revocations are not re-

ally contained within each other, it becomes increasingly

hard to determine which filegroup a file should be moved

to when it is re-encrypted. We address the first issue by

relating the keys of the involved filegroups. To address

the second issue, we set up the keys so that files are al-

ways (re)encrypted with the keys of the latest filegroup;

then since keys are related users need to just remember

the latest keys and derive previous ones when necessary.

We call the latter process key rotation.

There are two aspects of rotating the keys of a filegroup

a) rotating file-lockbox keys, and b) rotating file-sign and

file-verify keys. In either case, to make the revocation se-

cure, the sequence of keys must have the following prop-

erties:

a) Only the owner should be able to generate the next

version of the key from the current version. This is

to prevent anyone from undoing the revocation.

b) An authorized reader should be able to generate all

previous versions of the key from the current ver-

sion. Then readers maintain access to the files not

yet re-encrypted, and readers may discard previous

versions of the key.

In Plutus, each reader has only the latest set of keys.

Writers are directly given the newest version of the keys,

since all file encryptions always occur with the newest set

of keys. The owners could also do the new-key distribu-

tion non-interactively [14], without making point-to-point

connections to users.

To assist users in deciding which keys to use, each key

has a version number and an owner associated with it.

Each file has the owner information, and the version num-

ber of the encryption key embedded in the inode. Note

that this serves only as a hint to readers and is not required

for correctness. Readers can still detect stale keys when

the block fails to pass the integrity test.

Next we will describe how we achieve key rotation for

file-lockbox keys and file-sign/file-verify keys.

3.5.1 Rotating file-lockbox keys

Whenever a user’s access is revoked, the file owner gener-

ates a new version of the file-lockbox key. For this discus-

sion, let v denote the version of the file-lockbox key. Theowner generates the next version file-lockbox key from

the current key by exponentiating the current key with the

owner’s private key (d,N): Kv+1 = Kdv mod N . This

way only the owner can generate valid new file-lockbox

keys.

Authorized readers get the appropriate version of the

file-lockbox key as follows. (Figure 2 illustrates the rela-

tion between the different file-lockbox key versions.) Let

w be the current version of the file-lockbox key that a userhas.

• If w = v then the reader has the right file-lockboxkey to access the file.

• If w < v then the reader has an older version of thekey and needs to request the latest file-lockbox key

from the owner.

• If w > v then the reader needs to generate the olderversion of the file-lockbox key using the following

recursion. If Kw is the file-lockbox key associated

with version w, then Kw!1 = Kew mod N , where

(e,N) is the owner’s public key. Readers can recur-sively generate all previous file-lockbox key from the

current key.

Appears in the Proceedings of the 2nd Conference on File and Storage Technologies (FAST’03). pp. 29–42 (31 Mar –

2 Apr 2003, San Francisco, CA). Published by USENIX, Berkeley, CA

Plutus, re-computing block hashes and re-signing root

hashes as well) of the affected files. Revocation also in-

troduces an additional overhead as owners now need to

distribute new keys to users. Though the security seman-

tics of revocation need to be guaranteed, they should be

implemented with minimal overhead to the regular users

sharing those files.

To make revocation less expensive, one can delay re-

encryption until a file is updated. This notion of lazy re-

vocation was first proposed in Cepheus [13]. The idea is

that there is no significant loss in security if revoked read-

ers can still read unchanged files. This is equivalent to the

access the user had during the time that they were autho-

rized (when they could have copied the data onto floppy

disks, for example). Expensive re-encryption occurs only

when new data is created. The meta-data still needs to be

immediately changed to prevent further writes by revoked

writers. We discuss subtle attacks that are still possible in

Section 4.

A revoked reader who has access to the server will still

have read access to the files not changed since the user’s

revocation, but will never be able to read data updated

since their revocation.

Lazy revocation, however, is complicated when multi-

ple files are encrypted with the same key, as is the case

when using filegroups. In this case, whenever a file gets

updated, it gets encrypted with a new key. This causes

filegroups to get fragmented (meaning a filegroup could

have more than one key), which is undesirable. The next

section describes how we mitigate this problem; briefly,

we show how readers and writers can generate all the pre-

vious keys of a fragmented filegroup from the current key.

3.5 Key rotation

The natural way of doing lazy revocation is to generate a

new filegroup for all the files that are modified following

a revocation and then move files to this new filegroup as

files get re-encrypted. This raises two issues: a) there is

an increase in the number of keys in the system following

each revocation; and b) because the sets of files that are

re-encrypted following successive revocations are not re-

ally contained within each other, it becomes increasingly

hard to determine which filegroup a file should be moved

to when it is re-encrypted. We address the first issue by

relating the keys of the involved filegroups. To address

the second issue, we set up the keys so that files are al-

ways (re)encrypted with the keys of the latest filegroup;

then since keys are related users need to just remember

the latest keys and derive previous ones when necessary.

We call the latter process key rotation.

There are two aspects of rotating the keys of a filegroup

a) rotating file-lockbox keys, and b) rotating file-sign and

file-verify keys. In either case, to make the revocation se-

cure, the sequence of keys must have the following prop-

erties:

a) Only the owner should be able to generate the next

version of the key from the current version. This is

to prevent anyone from undoing the revocation.

b) An authorized reader should be able to generate all

previous versions of the key from the current ver-

sion. Then readers maintain access to the files not

yet re-encrypted, and readers may discard previous

versions of the key.

In Plutus, each reader has only the latest set of keys.

Writers are directly given the newest version of the keys,

since all file encryptions always occur with the newest set

of keys. The owners could also do the new-key distribu-

tion non-interactively [14], without making point-to-point

connections to users.

To assist users in deciding which keys to use, each key

has a version number and an owner associated with it.

Each file has the owner information, and the version num-

ber of the encryption key embedded in the inode. Note

that this serves only as a hint to readers and is not required

for correctness. Readers can still detect stale keys when

the block fails to pass the integrity test.

Next we will describe how we achieve key rotation for

file-lockbox keys and file-sign/file-verify keys.

3.5.1 Rotating file-lockbox keys

Whenever a user’s access is revoked, the file owner gener-

ates a new version of the file-lockbox key. For this discus-

sion, let v denote the version of the file-lockbox key. Theowner generates the next version file-lockbox key from

the current key by exponentiating the current key with the

owner’s private key (d,N): Kv+1 = Kdv mod N . This

way only the owner can generate valid new file-lockbox

keys.

Authorized readers get the appropriate version of the

file-lockbox key as follows. (Figure 2 illustrates the rela-

tion between the different file-lockbox key versions.) Let

w be the current version of the file-lockbox key that a userhas.

• If w = v then the reader has the right file-lockboxkey to access the file.

• If w < v then the reader has an older version of thekey and needs to request the latest file-lockbox key

from the owner.

• If w > v then the reader needs to generate the olderversion of the file-lockbox key using the following

recursion. If Kw is the file-lockbox key associated

with version w, then Kw!1 = Kew mod N , where

(e,N) is the owner’s public key. Readers can recur-sively generate all previous file-lockbox key from the

current key.

Key Rotation

15

Ki Kj Kl Km

Kid mod N Kld mod NKjd mod N

Kle mod NKje mod NKie mod N

What is wrong with this?

Pseudo Randomness!! Given Kl can you say anything about it? If you are a revoked user , you have Ki

UnWind Kl If you get Ki you have the current key Kl Else Ki’ is not Ki. So what you have is not the current

key Kl.

Pseudo randomness Vs Predictability.

16

Why is Pseudo-randomness Important? How can you attack the system? Cannot use these keys output by key

rotation to key other crypto constructs like symmetric encryption schemes and MACs

17

The Fi

Member states : stmi

Do not give key directly Ki derived from stmi

18Figure 1: Key regression overview; stpi and stmi respectively represent the i-th publisher andmember states.

scheme) result in a system that fails to provide even a weak form of privacy.1

Fixing key rotation with key regression. While the above counter example does not implythat all systems employing key rotation will fail just as drastically, it does motivate finding akey rotation-like object that still achieves property (1) (or something similar) but (property (2!))produces future keys that are pseudorandom to evicted members (as opposed to just unpredictable).Assuming the new object achieves pseudorandomness, one could use it as a black box to key othercryptographic constructs without worrying about the resulting system failing as drastically as theone described above. A key regression scheme is such a key rotation-like object.

To describe key regression, we must enact a paradigm shift: rather than give a new member thei-th key Ki directly, the content publisher would give the member a member state stmi. From themember state, the member could derive the encryption key Ki for the i-th time period, as well as allprevious member states stmj, j < i. By transitivity, a member given the i-th member state couldalso derive all previous keys Kj. By separating the member states from the keys, we can build keyregression schemes where the keys Kl, l > i, are pseudorandom to evicted members possessing onlythe i-th member state stmi. Intuitively, the trick that we use in our constructions to make the keysKl pseudorandom is to ensure that given both Kl and stmi, it is still computationally infeasible forthe evicted member to compute the l-th member state stml. Viewed another way, there is no pathfrom Kl to stmi in Figure 1 and vice-versa.

Our constructions. We refer to our three preferred key regression schemes as KR-RSA, KR-SHA1,and KR-AES. Rather than rely solely on potentially error-prone heuristic methods for analyzingthe security of our constructions, we prove under reasonable assumptions that all three are securekey regression schemes. Our security proofs use the reduction-based provable security approachpioneered by Goldwasser and Micali [28] and lifted to the concrete setting by Bellare, Kilian, andRogaway [8]. For KR-RSA, our proof is based on the assumption that RSA is one-way. For theproof of both KR-RSA and KR-SHA1, we assume that SHA1 is a random oracle [9]. For the proofof KR-AES, we assume that AES is a secure pseudorandom permutation [8, 36].

Implementation and evaluation. We integrated key regression into a secure file system to mea-sure the performance characteristics of key regression in a real application. Our measurements showthat key regression can significantly reduce the bandwidth requirements of a publisher distributing

1We stress that the novelty here is in identifying the design flaw with key rotation, not in presenting a specificcounter example. Indeed, the counter example follows naturally from our observation that a key rotation schemedoes not produce pseudorandom keys.

4

No path from Kl to stmi !! Can distinguish future member states from random.

Key Rotation Vs Regression

19

Figure 1: Key regression overview; stpi and stmi respectively represent the i-th publisher andmember states.

scheme) result in a system that fails to provide even a weak form of privacy.1

Fixing key rotation with key regression. While the above counter example does not implythat all systems employing key rotation will fail just as drastically, it does motivate finding akey rotation-like object that still achieves property (1) (or something similar) but (property (2!))produces future keys that are pseudorandom to evicted members (as opposed to just unpredictable).Assuming the new object achieves pseudorandomness, one could use it as a black box to key othercryptographic constructs without worrying about the resulting system failing as drastically as theone described above. A key regression scheme is such a key rotation-like object.

To describe key regression, we must enact a paradigm shift: rather than give a new member thei-th key Ki directly, the content publisher would give the member a member state stmi. From themember state, the member could derive the encryption key Ki for the i-th time period, as well as allprevious member states stmj, j < i. By transitivity, a member given the i-th member state couldalso derive all previous keys Kj. By separating the member states from the keys, we can build keyregression schemes where the keys Kl, l > i, are pseudorandom to evicted members possessing onlythe i-th member state stmi. Intuitively, the trick that we use in our constructions to make the keysKl pseudorandom is to ensure that given both Kl and stmi, it is still computationally infeasible forthe evicted member to compute the l-th member state stml. Viewed another way, there is no pathfrom Kl to stmi in Figure 1 and vice-versa.

Our constructions. We refer to our three preferred key regression schemes as KR-RSA, KR-SHA1,and KR-AES. Rather than rely solely on potentially error-prone heuristic methods for analyzingthe security of our constructions, we prove under reasonable assumptions that all three are securekey regression schemes. Our security proofs use the reduction-based provable security approachpioneered by Goldwasser and Micali [28] and lifted to the concrete setting by Bellare, Kilian, andRogaway [8]. For KR-RSA, our proof is based on the assumption that RSA is one-way. For theproof of both KR-RSA and KR-SHA1, we assume that SHA1 is a random oracle [9]. For the proofof KR-AES, we assume that AES is a secure pseudorandom permutation [8, 36].

Implementation and evaluation. We integrated key regression into a secure file system to mea-sure the performance characteristics of key regression in a real application. Our measurements showthat key regression can significantly reduce the bandwidth requirements of a publisher distributing

1We stress that the novelty here is in identifying the design flaw with key rotation, not in presenting a specificcounter example. Indeed, the counter example follows naturally from our observation that a key rotation schemedoes not produce pseudorandom keys.

4

Ki Kj Kl Km

Kid mod N Kld mod NKjd mod N

Construction

Four algorithmsSetup - Random oracle H,publisher state stpWind - stp, <stp’, stmi>Unwind - stmi, stmi-1

Key derivation - stmi, Ki

ConstructsKR-SHAKR-AESKR-RSA 20

Proving Hardness

Theorem: Key regression scheme built with a secure PRG(pseudo-random bit generator) is KR-Secure

Reduce each of the KR-AES,KR-SHA, KR-RSA to a KR-PRGQED

21

Implementation & Evaluation

Integrated key regression into a secure file system

Key regression significantly reduces the bandwidth requirements of the publisher while distributing keys

KR-AES can perform more than four times as many unwinds/sec than KR-SHA1

22

Real-World applications

Efficient Low cost subscription modelsPlenty of multimedia content distributed over

p2pDistributing software

23

Take Away ? Your Idea can be described in 2 lines. But

if you can formally prove it you got yourself a 39 page paper!

24