Secure File SharingSecure File Sharing

Presented byVishal Kher

February 13, 2004

2

ReferencesReferences

E.-J. Goh, et al. SiRiUS: Securing Remote Untrusted Storage. In Proceedings of NDSS 2003.

M. Kallahalla, et al. Plutus scalable secure file sharing on untrusted storage. FAST 2003.

3

OutlineOutline

SiRiUS Plutus Comparison

4

GoalsGoals

System should be easy to install and use No changes to file server Secure file sharing

– Confidentiality and integrity • Data as well as meta-data

– Key management– Read and read-write distinction– Freshness

• Meta-data

5

AssumptionsAssumptions

Untrusted File Server File sharing for small groups Trusted client machine Presence of PKI or similar infrastructure

6

System ComponentsSystem Components

d-file Data File

md-file Meta-data file

FEK File encryption key (symmetric key per file)

FSK File Signing Key (asymmetric)

MEK, MSK File owner’s encryption and signing key (asymmetric)

md-file Meta-data integrity file

PU, SU Public and private key of user

7

File StructureFile Structure

EFEK(D) SIGFSK(H(D))

d-file

EncryptedKey Block

(users)

EncryptedKey Block

[…]

Public Key

for FSK

MetadataLast modified

TS

Filename

SIGMSK

on md-file

md-file

Username

FEKFSK

Username

FEKEPU EPU

Prevent swapping attacks

8

Freshness of md-fileFreshness of md-file

File residing in user’s home dir belong to user Creation

– Hash all md-files and store the final hash in md-file– Concat hash of md-files in a dir to md-file of subdir– Sign the final hash (root level) along with timestamp and

place in root md-file

Update– The owner’s client updates after some time interval

Verification– Walk up the tree

9

WriteWrite

Assume owner updated the access control info Write

– Obtain md-file, verify signature on md-file– Obtain FEK and FSK– Obtain d-file and verify signature using pub key of FSK– Decrypt data– Encrypt modified data with FEK, hash sign using FSK– Rewrite the d-file

Dumb – sequential– Extension talks about random read and write

10

Read and RenameRead and Rename

Assume owner updated the access control info Read

– Obvious from previous description

Rename– Require updating the hash tree and md-file

11

Key Management and RevocationKey Management and Revocation

Key Management– Owner manages keys– User needs MEK and MSK

Revocation– Nothing special– User updates FEK and meta-data– Re-encrypts file

12

PerformancePerformance

13

Discussion (1)Discussion (1)

Roll-back– No data freshness– Replace current d-file with a valid old version

No suitable for large scale file sharing Owner performs all the key management

– Good for P2P

Huge performance overhead– Can further reduce some number of signatures

Storage overhead

14

Discussion (2)Discussion (2)

Change of user’s public keys– Contact the owners of every file

• Keep/ search a list of these files

– Do file owners have to figure this out?

Where should the keys be stored?– Smartcard– Encrypted using pass phrase

• Hassle to user• How can they be accessed seamlessly?

15

ExtensionsExtensions

Random Access– Each block encrypted with AES, CBC with different

random iv

Encrypt pathname using FEK– ls command will require all FEKs + decryption!

Large scale group scaling using NNL

DB1 SIGMSKDBn H(DB)n H(DB)n…. …. ….

16

OutlineOutline

SiRiUS Plutus Comparison

17

GoalsGoals

Low cryptographic overhead in file server File server unaware of user’s identity Secure file sharing

– Decentralized Key management • Completely pushed to users

– Confidentiality and integrity• Data and meta-data

– Authorization• Read and read-write distinction

18

AssumptionsAssumptions

Untrusted storage Trusted client machine User’s authenticate each other before obtaining

keys over a secure channel– Key management is handled by users

Communications are secure

19

File Groups and Lock BoxFile Groups and Lock Box

Filegroup is a group of files with same privileges– Owned by same {owner, group}, have same permissions– Reduce the number of keys

Lock Box– Box with a lock that holds a bunch of keys– Need key to the box to access the stored keys

20

System Overview (1)System Overview (1)

Each file block is encrypted with a different key – fileblock key

Every filegroup has a lockbox– Lockbox stores all file-block keys of files belonging to that

filegroup– Associated with lockbox is a lockbox-key (symmetric)

• Encrypts file-block keys• Owner distributes lockbox-keys to readers and writers

Reader writer distinction– Asymmetric keys: file-sign key, file-verify key

21

System Overview (2)System Overview (2)

Integrity of data file– Writer hashes all data blocks of the file and signs the root

using file-sign key

Confidentiality of meta-data– Encrypt names of files in dir using file-name key– Encrypt filegroup names using file-group key

22

File StructureFile Structure

Efoo-key(foo)

Ebar-key(bar)

Etmp-key(tmp)

header

EB-key(filegroupB)

header

EA-key(filegroupA)

Inode 1block 1

Inode 2block 2

Inode 3block 3

H(block 1)Kfile-block1

H(block 1)Kfile-block1

H(block 1)Kfile-block1

Root hash +

sign

Inode 1 header

Using file-sign key for filegroupB

File foo

23

ReadRead

Reader wants to access foo Browse to obtain name of the owner of foo Contact owner for:

– file-verify key, file-lockbox key– Verify the signature on root using file-verify key– Decrypt lockbox using file-lockbox key and fetch file-block

keys– Decrypt file foo

24

WriteWrite

Reader wants to access foo Contact owner for:

– file-sign and verify key, file-lockbox key– Generates file-block keys– Encrypt blocks– Store lockbox and file blocks– Calculate hash tree, sign root, write the tree with sign

But… How to authenticate writers– Token per file group– Hash(Token, F) is stored in inode– Server verifies tokens before allowing writes

25

RevocationRevocation

Lazy revocation– Changes keys– Owner immediately updates meta-data– Mark file for re-encryption– Re-encrypt only on updated

File-groups– Same key multiple files

On write following revocation– key for re-encrypted file different!

26

Key RotationKey Rotation

Every key has version numbers Readers and writers should check the version

before using the keys

27

DiscussionDiscussion

Total trust on insiders.– No notion of identity on the server– any authorized user can change and sign the data– Will the readers be able to track who changed it?

The owner will have to be online to distribute keys Burden on owners

– Good for P2P– How about enterprise?

28

ComparisonComparison

Role of server Verify writes Store data (unmodified)

Plutus SiRiUS

File sharing Dynamic Static: A user cannot create file

User’s identity Hidden Included in meta-data

Key distribution Done by owner to user Owner puts the appropriate

keys in the meta-data

Hash tree Update by writer

Includes data blocks

Periodic update by ownerOnly includes meta-data

Revocation Lazy + key rotation Nothing special

Number of Keys Less: File groups One per user

Scalability More scalable Less scalable

29

CommentsComments

Thank You