Solved [Solved]Make encrypted ZFS partition undeleteable?

Re: Make encrypted ZFS partition undeleteable?

You may be looking for the hold subcommand of the zfs() utility?

Code:
zfs hold [-r] tag snapshot...

Adds a single reference, named with the tag argument, to the specified snapshot or snapshots. Each snapshot has its own tag namespace, and tags must be unique within that space.

If a hold exists on a snapshot, attempts to destroy that snapshot by using the zfs destroy command return EBUSY.
 
Re: Make encrypted ZFS partition undeleteable?

I don't know what a snapshot is, but I think that isn't what I'm looking for... In fact, I've never used ZFS, but I'm planning to re-format the system partition with ZFS and re-install FreeBSD 10.0-RELEASE, so I can use the option to have it entirely encrypted (I didn't know you could do that until I read this: http://www.bsdnow.tv/tutorials/fde, if I did I wouldn't have used UFS).
What I'm looking for is a way to make the partition impossible to delete using, for example, cfdisk or any other partition manager. If the HDD is stolen, I'd like the thief to not be able to read the system partition (I can do that encrypting it), and also to be unable to delete that encrypted partition (That's what I don't know if it's possible or not).
 
Re: Make encrypted ZFS partition undeleteable?

No, as far as an attacker has write access to the disk, you are not able to protect data stored there, because he can at least overwrite the sectors containing informations about disk partitioning etc.
 
Re: Make encrypted ZFS partition undeleteable?

Ok. I understand. But at least it's still almost impossible to read the data contained in a ZFS encrypted partition without knowing the password, right?
 
Re: Make encrypted ZFS partition undeleteable?

Of course if the attacker has access to the disk he can read all of the encrypted data on it and can probably make out the external structure of the data if there is any. That much is assumed when cryptographic systems are designed, in other words assume the worst case. Whether the access to the encrypted data helps in attempts to decrypt the data without knowing the secret key is another matter and is best answered by someone who knows more about the algorithms used in geli(8) (I'm assuming that's what we are talking about here) than I do.

To answer your original question, once the disk is taken out of the system anything can be done to it because any locking mechanisms that would prevent deletion of partitions (for example) exists only in software. There's nothing to prevent the disk being wiped clean if it's connected to another system that does not understand the partitioning on the disk, for example a machine that doesn't know about GPT partioning and the disk contains a GPT partition table.
 
Re: Make encrypted ZFS partition undeleteable?

c083d4 said:
Ok. I understand. But at least it's still almost impossible to read the data contained in a ZFS encrypted partition without knowing the password, right?
If the server is booted and the attacker came in from the network the attacker can read all the data.

File system encryption only protects the data in case your entire server (or just the disk) is stolen.
 
Re: Make encrypted ZFS partition undeleteable?

Yeah, that's what I'm interested in: Protecting the data from people who have physical access.
Thank you very much.
 
Protect the data against what? With all computer security questions, you have to consider different threats, and different effects.

A. Prevent them from reading it? There are two questions here. First: Is the encryption good enough that an attacked needs the key, or can the key be bypassed? For most modern encryption algorithms, if implemented carefully, without explicit back doors, the answer is that the attacker will need the key (the NSA and such may be capable of bypassing encryption by brute-force attacks, but let's not worry about that, as it is unlikely that your disk will attract the full force of such agencies). Second: where is the encryption key stored, and how long does it live in use? If the encryption key is only stored in the brain of the human user, who types it in when mounting the encrypted disk, and then the computer is powered down after we are done using the disk, then the only way to read the disk is either to get the human to divulge the key (for example by pointing a gun at them), or to get into the system while the disk is mounted. In this scenario, the most likely attack is (as SirDice said) someone logging into your system (authorized or unauthorized), and just reading the mounted file system. So the thing you really need to guard against are for example ssh brute force attacks on the root account.

If they key is stored on any form of media, then the real danger lies in attack on the media. For example, you may have a piece of paper with the key (or the equivalent pass phrase) taped to the bottom of your keyboard in the office. Then anyone who can flip your keyboard over can read the disk, either before or after removing the disk from your system. A really stupid version of this would be to store the key in a world-readable file on the unencrypted root disk of your system, and have a little script that automatically mounts the encrypted disk every time you boot. At that point, you don't even have to bother encrypting any more: anyone who can log into your system (or exploit it, for example by using a mis-configured web browser to fetch http://your.server.com/~root/secret_key.txt) has access to the data.

So to protect the data from being read, the most important thing is to protect the key, and to protect the system on which the disk is mounted.

B. Prevent them from modifying the data, or destroying it? To begin with, there are in-band modifications of the data, for example writing to the file system. I'm sure you wouldn't consider the superuser logging in, mounting the encrypted disk, and rm'ing a file to be destroying the data, but you would rather think of it as a normal file system operation. But what if the superuser hacked in, and did rm -Rf /mnt/encrypted_disk? That goes back to what we said above: protect the system against unauthorized access.

That leaves access to the physical disk. You worry that someone might come in with a screwdriver, physically take the disk out, and connect it to his server and overwrite the data. Well, there is nothing you can do about that, except by using hardware encryption (which is offered by many disk drives). But protecting against a guy with a screwdriver and his own server is silly, because once the attacker has physical access to the disk, he can destroy the data much more easily: Using a hammer. And no encryption in the world will protect the data against a person who simply smashes the disk. If you want to deal with such attacks, you need physical security. My wife used to work at one of these US federal government labs, where they have soldiers with machine guns posted at the door to the computer room. This is a bit expensive, but very effective.

So, can you be more specific: What types of attack are you really worried about? And what caliber of ammunition are you intending to use against the guy with a small hammer? (That last question is meant as a joke)

Personally, I have a 1TB external USB disk, which I keep in my office. It is encrypted (although not using geli and ZFS, but Macintosh encryption). The key is stored in my head (and on a piece of paper I keep in my safe at home, and my wife knows the combination to the safe). I think my Mac is pretty secure against attack; the best protection is that there are hundreds of other Macs in the office, our network is managed by competent people, and I try to not make enemies. I only mount the disk for an hour or so, perhaps once a week or so. If someone steals the disk from my office, they won't be able to read the data, but they will be able to reformat the drive and use it, and I will have to recreate the data (big pain). Since there is lots of other nicer computer stuff in my office, I don't think anyone would bother stealing a 3-year-old generic external disk, not interesting enough.
 
Brute force cracking of symmetric ciphers is provably out of reach for NSA or any other spy organization. This assuming a 128-bit or longer key is used and there are no weaknesses in the cipher algorithm itself that make it less "hard" to brute force the key space than when the size of the key space would make you expect. This is a good layman understandable presentation about how big the key space in a 128-bit symmetric cipher really is:

http://www.codinghorror.com/blog/2006/07/brute-force-key-attacks-are-for-dummies.html

Of course this is not proof of any kind that encryption are secure, there a dozens and dozens of other considerations. Most often cryptographic systems are broken by simple social engineering, it's very hard to protect against those since the encryption systems are usually all or nothing, once you gain the password all doors are open.
 
Thanks for the explanation :p
ralphbsz said:
Protect the data against what? With all computer security questions, you have to consider different threats, and different effects.
So, can you be more specific: What types of attack are you really worried about? And what caliber of ammunition are you intending to use against the guy with a small hammer? (That last question is meant as a joke)
I'm principally worried about people bypassing the encryption of the ZFS partition (As I said before, I was thinking about re-installing FreeBSD in a ZFS partition to use the 10.0 encrypt option that is mentioned at the end of this article: http://www.bsdnow.tv/tutorials/fde) and being able to read the data without knowing the password.

I was also interested in knowing if a partition can be made undeleteable, but from what all of you told me, I understand this isn't possible.
 
With the hardware the NSA and similar agencies have been buying, we have to assume that shorter key sizes can now cracked by brute force attack. Note that the above article is from 2006, and since 9/11 much has happened in this field (as some of the scandal around the NSA indicates). 4096 bit keys are commonly available now, and encrypting with them is pretty fast enough for the amount of data amateurs typically have. Rumor has it that 8192 bit keys make the common gpgp program run pretty slow.
 
ralphbsz said:
With the hardware the NSA and similar agencies have been buying, we have to assume that shorter key sizes can now cracked by brute force attack. Note that the above article is from 2006, and since 9/11 much has happened in this field (as some of the scandal around the NSA indicates). 4096 bit keys are commonly available now, and encrypting with them is pretty fast enough for the amount of data amateurs typically have. Rumor has it that 8192 bit keys make the common gpgp program run pretty slow.

Please don't confuse key sizes of public key (asymmetric) cryptography with the key sizes used in secret key (symmetric) cryptograhphy. There are various different reasons why the keys of public key ciphers have to be longer to be secure. 128 bit keys are more than enough for the symmetric case and it's still doubtful that they will be compromised with the conventional methods ever.
 
You're right ... the multi-KB keys are for public key, and symmetric uses much shorter keys. I got confused. Still, using 4096 bit PGP is a much better idea (as is AES-192 or -256 rather than AES-128 in the symmetric domain). Sorry about spreading misinformation.
 
Back
Top