Secure File Sharing

Firefox Add-on

This page contains the Secure File Sharing plugin as described in our submission to LEET 2011. You can download the plugin from here (Save-as and then drag the file in your browser).

Architecture

Note: This text is a superset of the text present in our submission to LEET 2010.

Our system, SecureFS, is deployed in the user's browser as a browser extension where it is constantly monitoring his actions with regard to file uploads and downloads.When SecureFS detects that the user is about to upload a file from his system it creates a copy of that file and encrypts it using a random key. A separate file with fake information is renamed to match the original file's name and added to a ZIP archive. These two files are then combined with a SecureFS file signature and the size of the original file in the following structure:

SecureFS(file) = SecureFS_signature + sizeof(file) + ENC(file,random_key) + ZIP(fake_file)

The reason that we chose the above structure is because ZIP files contain their metadata at the end of the file instead at the beginning. If an attacker downloads the above file without knowing its internal structure, the file will appear to be a normal ZIP file which decompress to the fake file without any errors, thus misleading the naive attacker that he got access to the data that he was promised. Even if the attacker notices that something is wrong (e.g., by noticing the size difference between the ZIP file and the resulting file) the user's file is still encrypted and thus protected.
Once this process is done, the resulting file is uploaded to the FHS instead of the user's original file. In order to facilitate the sharing of files between users, the random key that is used to encrypt each file is added to the resulting URI that the FHS provides to the user. E.g., If a FHS provides the link http://www.myfhs.com/fileid/[ID]/ for a file that the user uploads our extension rewrites this URI to http://www.myfhs.com/fileid/[ID]/sfs_key/[RANDOM_KEY]/. When the above link is visited, SecureFS will detect the sfs_key argument in the URI and will use it to decrypt the next SecureFS file (recognizable by the SecureFS signature). The embedding of the key in the URI allows the user to share the link to his file using the usual Copy-Paste approach without any extra actions necessary. When the file is downloaded, the process is reversed and the original file is decrypted and made available to the user.
All of the above process is automatic, transparent and is performed without the user's assistance except of the rewriting of the download URI to include the random encryption key. Due to the diversity of the ways a link is provided to the user, we decided to design our extension as generic as possible and thus we require the user's assistance to show us, by highlighting, the download link. Once this is done, SecureFS can locate the link in the DOM tree of the page and add the random key field to it.

Usage

After the plugin is installed and your browser is restarted a new menu is added in the Tools menu of Firefox. The new menu is titled "Secure File Sharing" and it contains three options. The only one that the user will need to know is the first one, "Show secure link".
The process is best described with an example. Uploadmb.com is a file hosting service that implements their token generation algorithm in an insecure way. Specifically, when a file is uploaded, the link to the file is the time of which the upload request reached their server, in an epoch format. We contacted them and their response was to change their Terms of Service to "all files can be downloaded by everyone". Thus, users who use them without reading the EULA (which is most probably all users) do not necessarily know that their files are out in the open.

Figure 1
We visit uploadmb.com with our plugin activated and immediately we can see that the usual browse field of the HTML form, contains "SFS ON". This just shows that "Secure File Sharing" is "ON" and it has correctly detected the upload form (Figure 1). When the user chooses a file to upload, the process of securing the file begins (as explained in our paper). The reason for protecting the file at selection and not at "Submit" is because many websites of FHS have just buttons (not Submit-type buttons) that perform the necessary actions when clicked, through JavaScript. Thus, by protecting the file at select time we become compatible with many more FHS. A limitation of the current prototype is that the process of securing the file is done by the UI's thread thus, if the file is a bit large then the UI appears to hang. We are considering to implement a separate thread that will do the securing part so that the user may continue to use his browser, while the securing of his file is performed.
Once this is done, everything appears to be unchanged for the user, however the file that will be uploaded to the FHS is not the file that he requested, but a secured version of that file. Once the user uploads the file, the FHS will store it on its cloud and then return the file identifier back to the user in the form of a URI.
The encryption key that was used by our plugin to encrypt the file needs to be communicated to the user so that it can be downloaded and decrypted successfully in the future. For this reason, our plugin (with the help of the user) will locate the file link in the DOM tree of the page and overwrite it to add the encrypting key as an extra parameter. All the user needs to do is highlight the URL and then go to "Tools -> Secure File Sharing -> Show secure link" (Fig. 2)


Figure 2
Once the user clicks on the "Show secure link" menu item, the DOM is re-written and the URL now contains the encryption key (Figure 3).

Figure 3
Now the user can copy his new link and store it or send it to his friends. On a request of that URL, the plugin will recognize the sfs_key parameter and will decrypt the next file downloaded with it. Every file that is secured using our plugin, contains a file magic number so that the plugin doesn't "decrypt" non-secured files that the user may download.

Limitations

Our plugin detects a file upload form by the standard file input element of HTML. Some FHS however employ Flash to upload files to their servers. In these cases, our plugin cannot recognize the upload and thus cannot secure it. From our experience, most of these services also provide a standard HTML menu (for compatibility reasons) that the user can utilize and that our plugin will detect.

Authors
Nick Nikiforakis, Katholieke Universiteit Leuven
Marco Balduzzi, Institute Eurecom, Sophia Antipolis
Steven Van Acker, Katholieke Universiteit Leuven
Wouter Joosen, Katholieke Universiteit Leuven
Davide Balzarotti, Institute Eurecom, Sophia Antipolis

[EOF]