180 likes | 297 Vues
This document provides a comprehensive overview of the Multi-User Cryptographic File System (CFS), outlining its primary goals, interface features, and notable shortcomings. CFS ensures transparency to programs within the system, uses encrypted data and file names, and operates with the principle of not trusting the server. The interface includes commands for creating and managing encrypted directories while emphasizing user access control through public and private keys. It highlights major improvements in security and file sharing, while also discussing ongoing vulnerabilities and the implications of unauthorized access and potential data corruption.
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