Re: How to protect an encrypted file system for off-line attack?

Jeff Soules escribió:
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.


Ok, thank you for your help. I've read it carefully.

Now imagine the worst situation, that a friend wants to protect his data
from his corrupt dictatorial government, and he doesn't want to directly
make the question here, because he is afraid.
For email, there is PGP, I suppose it is good enough, right?
But he uses a computer for writing those emails, for writing papers
which may be compromised, he has some forbidden digital books like the
Universal Declaration of Human Rights (or whatever it is speelled in
english), etc.
Imagine that he is actually in the risk of having the police to enter
into his house and get his computer.
Then my question is: is EncFS good enough to protect his data?
I think the SD with stored password is a good solution. While he is not
in the house, he can carry the SD or have it hidden somewhere. While he
is in the house, and police enter, he might have enough time to probably
destroy the SD and turn off the computer.

What would you recommend in this imaginary case?

Also, I have seen that encfs support up to 2048 characters for the pass
phrase. Is it better to have a very large random pass, or it is
irrelevant at some point?
And which is better, Blowfish or AES?

Thank you.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Relevant Pages