- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Transparently uploading and accessing encrypted files and directories to a Cloud Service
Transparently uploading and accessing encrypted files and directories to a Cloud Service. In this example Ubuntu One. Since the actual encryption process and retrieval is performed on the client computer (Linux) the cloud doesn't matter. This example uses encfs. The idea is to store ones files on a cloud (Ubuntu One), so that they remain private, using encryption, but so that they can be transparently uploaded and downloaded and accessed, as if they are unencrypted files. To do this I chose to use the FUSE filesystem encfs. One of the things I discovered in my experimenting is that when you create an encfs filesystem it creates, inside the root folder a hidden file ".encfs6.xml". This file resides inside the root of the encrypted files system, nad is a plain text xml file, it contains the encryption key and the salt value. This is great as you can copy the encrypted folder, I'll called it "encrypted" anywhere you like and then access the files and folders contained in it by simply mounting the folder using encfs with something like
mkdir ~/viewer Supply the password then add/remove files from the "encryptd" folder. Which meamns that if you drop the "encrypted" folder into the "Ubuntu One" folder, the "encrypted' and its contents, including ".encfs6.xml" are copied to the Ubuntu One cloud, and become available to any other computer you choose to connect to your cloud directory. One can then simply use the steps above to access the files and directories in the 'encrypted' folder. The problem with this is that the encryption key and the salt value are available in the cloud environment, which rather defeats the purpose of encrypting in the first place, namely to ensure that the cloud owners do not under any circumstances have access to your private files. It turns out, the solution to this problem was trivial. I simply removed the hidden file ".encfs6.xml" from the "encrypted" folder, before adding it to the "Ubuntu One" folder. Of course, any other computers one chooses to use to access the contents of the "encrypted" will no longer be able to mount the "viewer" folder, as they will no longer be able to authenticate, the necessary encryption Key and salt, no longer being available. However all one needs to do to make the contents available again is to copy the file ".encfs6.xml" to the other computer by some other means, email, instant messanger, USB key, what ever you feel most comfortable with. So, this is how I ended up doing it. Install encfs (as per http://ubuntuforums.org/showthread.php?t=148600) sudo apt-get install encfs fuse-utils sudo modprobe fuse Add yourself to the fuse group. sudo adduser fuse Or simply open Synaptic, search for encfs, select encfs, and install it. You will be added to the fuse user group automatically. Create the encrypted root mkdir ~/encrypted Create the "viewer" directory mkdir ~/viewer Mount your encrypted directory for the first time, to set up the encryption strength and the password. encfs /home/<Your Home Directory>/encrypted /home/<Your Home Directory>/viewer absolute paths are required. you will be prompted with
Creating new encrypted volume.
Choose your prefered encrytion method and strength. Standard mode will look like the following Standard configuration selected.
Configuration finished. The filesystem to be created has
Now you will need to enter a password for your filesystem. New Encfs Password: Enter your prefered password, and a second time when prompted. You will now have an encrypted folder "encrypted" and a mounted folder "viewer". If you drop files and folders into "viewer" you can see them in "encrypted", but will only be able to access them through the mounted folder "viewer". To unmount "viewer" use fusermount -u /home/<Your Home Directory>/viewer Next you need to remove the hidden file ".encfs6.xml" from "encrypted" mv ~/encrypted/.encfs6.xml ~/.encfs6.xml Should do it. Next create a symbolic link to ~/.encfs6.xml an place it in "encrypted" ln -s .encfs6.xml ~/encrypted/.encfs6.xml Does it for me. Next copy ot move the "encrypted" folder into the "Ubuntu One" folder. If you are currently connected to the cloud, the files and folders in the encrypted folder will be automatically uploaded to the Cloud. Provided you make a copy of the original ".encfs6.xml" file available on on the computers you wish to connect to the cloud, and, and you create a link to that file in the "encrypted" folder, you can mount a viewer on any of those computers with something like the following. encfs "/home/<Your Home Directory>/Ubuntu One/encrypted" /home/<Your Home Directory>/viewer and entering your password when prompted. Where 'Ubuntu One' is the Ubuntu One cloud folder in your home directory, the quotes around "/home/<Your Home Directory>/Ubuntu One/encrypted" are required. tracyanne |
Comments (20)
Not exactly
Quoting:But in the end the amount of trust one gives to 3rd parties is up to you.
Well said. To me that is the crux of the whole cloud computing thing. I am not willing to trust third parties with my data. I've been in IT and seen security mishandled or done poorly by too many corporate entities and government institutions to trust my data to a third party.
Leaving the .encfs6.xml file in the encrypted directory when uploading to the cloud means that any one who has access to your files can use the .encfs6.xml file to extract your password.
removing that file before uploading, and adding a link into the encrypted directory makes it safe.
A "flag file", in this case .encfs6.xml, is a data leakage, whether or not it's encrypted. The facile case is that it's unencrypted. However, if it is encrypted:
In the normal, "not under attack" scenario, the password from the user is used to decrypt the flag file (in this case, .encfs6.xml). A successful decryption of the first N octets means the password was correct; otherwise, a failure is flagged, and the user may try another password.
In an attack scenario, the flag file gives the attacker a known sequence in the first N octets to which a candidate key must decrypt the sequence under attack. This will take some time, but without this precondition, the key search would take much longer.
Quoting:If you don't trust the encryption of the xml data, you shouldn't be trusting encfs' implementation at all, as your files are protected with the same encryption.
Well, "encryption" isn't everything, because you can misuse it horribly, and it's quite difficult to make it right. It only *seems* easy, but Black Hats know better.
Having said that, I don't know the details of the solution at hand. Thus, I won't use it ;)
Quoting: macemoneta, the file .encfs6.xml is not encrypted, it is in plain text and human readable, the Key is is base 64 format, as is the seed.Macemoneta is correct, the key data in base64 format is an encrypted one using the password that is supplied when creating/mounting the encfs filesystem. See the backups section here: http://www.arg0.net/encfsintro
Where macemonet is incorrect is in assuming that it is safe to supply the key, encrypted or not, along with the data.
Both the files and the key are encrypted with the same algorithm and implementation. If you can decrypt the key you don't need it - you can just decrypt the files. If you can decrypt the files, the presence or absence of the xml file is immaterial.
I haven't seen any method proposed for using the xml encrypted key in a way that creates any risk to the integrity of the encrypted data. The presumption that the process would be easier with a few bytes of additional encrypted data is unfounded, and unsupported.
Quoting: Both the files and the key are encrypted with the same algorithm and implementation.No, from what I recall the encryption of files uses the (encrypted) key (and other parameters from the control file) and not just the password directly. So not uploading the control file may be better to avoid dictionary and other offline attacks on the key.
Btw, for those interested in a GUI there is a nice package "cryptkeeper" that sits in the tray and allows creation/mounting of encfs directories.
Quoting: but the algorithm and implementation are the same for both the key and data.Probably you have not much idea of cryptanalysis. The major strength of encryption lies not in its algorithm or implementation but in its key. The best algorithm is useless with a weak key.
Quoting: If you can algorithmically decode one, you can decode the other.No, it depends on the strength of the two keys. Assuming that the generated key is much stronger than the provided password (which will be always the case), there is no comparison of the two.
That must be it. :)
Quoting:The best algorithm is useless with a weak key.And the best key does no good if the algorithm is cryptographically poor. Just ask Jon Lech Johansen.
The cloud keeper
encfs is opensource, the libraries live on the cloud keeper's servers. They can be hacked to pipe any password to a persistent storage !
They don't care about one's cooking receipts, but what about sensitive data ?
Beyond the bounds of the article, cloud computing is about trusting one's personal affairs to a third party and it's fascinating to see how people rush to anything that is served to them. What has happened to the people ? I won't trust my balls to anyone, encrypted or not !
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Sign up and post (it is free) or Log in and post
|
|
The information in the .encfs6.xml is encrypted with the password, as are the files themselves. There is no exposure by leaving the .encfs6.xml file in the directory.