Post on 02-Feb-2016
description
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