180 likes | 286 Views
Multi-User Cryptographic File System. Gabe Black Mike Nettleman. Overview of CFS. Goals Interface Shortcomings. Overview of CFS: Goals. Transparent to Programs in the system Access time Access semantics Standard NFS once mounted Data encrypted File Names encrypted
E N D
Multi-User Cryptographic File System Gabe Black Mike Nettleman
Overview of CFS • Goals • Interface • Shortcomings
Overview of CFS: Goals • Transparent to Programs in the system • Access time • Access semantics • Standard NFS once mounted • Data encrypted • File Names encrypted • Do not trust the server
Overview of CFS: Interface • cmkdir • Make an encrypted directory • cattach • Reveal the encrypted directory • cdetach • Remove the encrypted directory
Overview of CFS: Shortcomings • Keys are for the entire directory • All files are encrypted with the same key • Keys are for only a directory • Must manually add all directories • Sharing requires sharing the pass phrase • To share a single file, a new directory must be created • To give the pass phrase may be inconvenient
Multi-user CFS • Users have globally accessible public keys • System is mounted with Private Key • Each visible file has multiple files • Directory information • If have permission, can decrypt names. • Added commands to add or remove users from files
Files used in Multi-user CFS • Key-file • List of users and encrypted file keys • File keys encrypted with the user’s public key • Data-file • What normally is stored in CFS • Hash-file • Integrity checking information
Major changes to CFS functions • Keyof • Read • Files • Directories • Write
Keyof • Takes cfs_fileid pointer as argument • Original CFS • #defined access to internal data • Multi-user CFS • Uses fileid to find relevant key file • Searches for user name in key file • More likely to fail (user not in list) • Would be better to find on open, but NFS has no open command.
Read • Read file • Changed to use the integrity checking file • Read directory • Used in ls • Changed so ignores hash and key files
Write / Create • Write • Changed so reads first • Prevents verifying modified code • Updates integrity file at the same time • Create • Creates all 3 types of files • Chooses random file-key • Sets attributes on hidden files appropriately
Added functions • ReKey • Verify entries in key-file • Change the key used for the file • Add user • ReKey • Add another username and key in the key-file • Remove user • Remove username from key-file • Rekey
Comparison to Original CFS • Transparent to Programs in the system • Access time • No key stream cached • Multiple files • Still reasonable performance • Access semantics • Remained the same • Added files are “hidden” from user
Fixed Shortcomings of CFS • Separated login-keys from file-keys • Fixes problems of files sharing the same key • Pattern analysis • Partial substitution • Allows fine granularity sharing without user inconvenience • Sharing of keys does not require secure communication • Uses Public keys.
Attacks Prevented • Replace key-file • Writes check integrity before writing • Network sniffing • Only encrypted data is transmitted • Server is not trusted, so anything going to server is could be viewed by anyone • Add self to list of users in key-file • Rekey checks that entry is valid first.
Attacks Prevented • Partial file substitution • Each file will have different keys • Block reordering • Implicit in hash is block location
Vulnerabilities • Authorized users • Can modify files or add and delete users maliciously • Denial of Service • Files can be corrupted or deleted without access rights. • No read / write separation • Would require all files to have data encrypted with public keys, too time consuming
Vulnerabilities, continued • Complete replacement of files • Create new file • Semi-prevented by name encryption • Copy file from somewhere else • In process of adding path checking • Attacks within client machine while directory is mounted • All programs can access the files