As Ron said, the problem you're describing is a little bit different from the one the man page talks about.
> The most intrusive attacks, where an attacker has complete control of > the user's machine (and can therefor modify EncFS, or FUSE, or the > kernel itself) are not guarded against. Do not assume that encrypted > files will protect your sensitive data if you enter your password into a > compromised computer. How you determine that the computer is safe to > use is beyond the scope of this documentation. Seems to me that the man page is talking about two situations: #1. Someone has rooted your box. In this case, your encryption can be bypassed, because unless your secret passphrase is actually an entire RSA key, the password is just a gatekeeper and everything needed to decrypt the fs is on the box. A (sufficiently clever) attacker with root (and enough time) could modify the EncFS program itself to bypass the password check and just decrypt your files. #2. Your box is keylogged, or (for some unknown reason) you put in your decryption password on a compromised/keylogged other box. This isn't strictly an offline attack, it could happen remotely if the password is compromised. I suppose you could get around this by automating the way your fs password is input (although if it's automated input over stdin, couldn't a properly designed keylogger still eavesdrop on it?), but that's kind of missing the point, which is if situation #2 happens, you will soon find yourself in situation #1. There, the real questions to ask are "how do I avoid getting a keylogger" and "how do I catch a user account compromise before the attacker can gain root." Taking steps in response to those questions will make you much more secure across the board. If you're simply worried about protecting your filesystem from offline attacks, i.e. someone has physical access to your computer without having rooted it or whatever, then (as always with security) it becomes a question of how good is good enough. How long can someone sit at your computer trying to log in before it locks out for half an hour? How long before you (or someone else) comes back to stop them? Having logged in, how long before they manage to decrypt the filesystem without using EncFS? Etc. We're starting to talk about a very dedicated attacker at this point, who must have a compelling motivation for attacking your box specifically; these aren't government secrets, right? At any rate, in this kind of situation, other security considerations and means of attack (http://xkcd.com/538/) start to come into play. In fact, the main scenarios I can imagine are either that you're trying to keep personal files secret from a prying but technically skilled family member, or that you're protecting a corporate environment from some kind of industrial espionage (although again, in the latter case I think you're more vulnerable to social engineering attacks than strictly technological ones). Though I would wonder if, in those scenarios, having the password automatically input from an SD card or something might actually decrease your security. If you're talking about offline attacks, that's someone with access to the computer's physical environment (and who may even have seen you put in the SD card while you mount encrypted FSs). A non-compromised, keyed-in password would actually provide more protection in that case than an SD card that's sitting on your desk somewhere and that any joe could plug in. After all that, if this problem still seems compelling to you, then I suppose the best situation would be for you to have an SD card or whatever, kept secure and separate from the box, that feeds the actual encryption key into the system, with that key not being stored locally at all. Ideally you would also have some kind of second password check required to get the program to actually use the RSA key, so you can depend on both something you have and something you know. I've no idea how to implement this technically; I don't see a facility in EncFS to do anything like this. Also, this setup makes your data brittle; if your SD card gets wet or zapped, your filesystem is gone. There's always compromises between security and convenience, and security and resilience of data. And, joy of joys, make sure you store your backups somewhere nice and secure. With your EncFS setup you probably want to store the backups of the encrypted filesystem away from all the others, so that someone getting ahold of them has to crack the actual encryption rather than just hunt around for the key. On Sat, Feb 21, 2009 at 11:16 AM, Javier <javu...@gmail.com> wrote: > Sorry for my ignorance in this respect, I hope you can help me. > > I'm actually using encfs to protect my sensitive data, but this is what > is said in the manual: > > """The most intrusive attacks, where an attacker has complete control of > the user's machine (and can therefor modify EncFS, or FUSE, or the > kernel itself) are not guarded against. Do not assume that encrypted > files will protect your sensitive data if you enter your password into a > compromised computer. How you determine that the computer is safe to > use is beyond the scope of this documentation.""" > > So my question is: how can I truly protect a filesystem against offline > attacks? > > I have thinking of using an SD card for storing the passwords in, and > some kind of script or program to automatically retrive password from > the card when needed. Then, if I retire the card, then my filesystem is > secure. > > But I also have more questions... is the AES encoder that encfs uses by > default secure enough? If not, is there another way to use another one, > for example, GnuPG? > > Thank you. > > > > -- > gpg --keyserver pool.sks-keyservers.net --recv-keys AFC23C68 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
