Slashdot Mirror
GBDE-GEOM Based Disk Encryption on FreeBSD
BSD Forums writes "The ever increasing mobility of computers has made protection of data on digital storage media an important requirement in a number of applications and situations. GBDE is a strong cryptographic facility for denying unauthorised access to data stored on a 'cold' disk for decades and longer. GBDE operates on the disk(-partition) level allowing any type of file system or database to be protected. A significant focus has been put on the practical aspects in order to make it possible to deploy GBDE in the real world. FreeBSD's Poul-Henning Kamp says in an email to freebsd-current that he has uploaded this paper and slides which he presented at BSDcon 2003, California, USA."
For those of you who do not know. FileVault is data encryption for Panther (Mac OS X.3).
FileVault is an encrypted disc image that is automatically mounted when you login.
It uses AES encryption (128 bit)
Its been written within Apple, using existing Apple technologies.
Using Disc Utility you can do the same on Jaguar, except Panther and FileVault make it very easy to do....
OpenBSD does not support SMP either.
BOO! TERRO
If you read the article, you'd notice several things:
a) this is completely different from OpenBSD's implementation
b) it's portable across filesystems
c) you wouldn't have written this idiotic post.
Additionally, you obviously know nothing about cryptography, otherwise you'd not make such a stupid assumption about Rijndael, an OPEN algorithm developed outside the United States. It's been out for years and many people have failed miserably when trying to cryptanalyze it.
Additionally, it's also interesting to note that *NO* algorithms available in the mcrypt library are authorized for encryption of 'classified' data, by the NSA. Rijndael is authorized for encryption of 'highly sensitive' and some forms of 'classified' data.
Actually, the NIST and NSA are quite open with information about these algorithms.
Think before you speak.
www.sitetronics.com/wordpress
Ceren doesn't wear latex anymore. :(
nooooo
She also used to read Slashdot, but when I last time talked with her, she said that she doesn't do that anymore because she's sick of the open sauce zealots.
WHAT... HAVE... YOU... DONE!!!
I have over 70 freaks, do you?
One of the cooler features that come with GBDE is the fact that you can encrypt CD-ROM images. This makes for a very secure way of getting someone a lot of sensitive data. A patch was recently posted on the current@ mailing list to allow this.
I suggest you actually read the paper and you'll see that this is not exactly the same. GBDE has far more security levels, is easier to setup and use and can be considered safer too. Again, read the paper to see what I'm talking about.
This is great news for all those M16/CIA/etc agents how leave their laptops in the back of taxis!
There are some nice ideas and good thinking here, but does anyone have a link to more interesting performance numbers? I'm curious how well this would work on a workload that was both intense and non-sequential.
This is not a new idea.
OpenBSD (vn* devices) and Linux (crypto-loop) have this for years. NetBSD also has it. Windows XP also has it.
Now FreeBSD introduces yet another implementation of the same thing.
This is great, but what about interoperability?
Right now, all operating systems I can use encrypted partitions, but the way they do it is different on every system.
If I encrypt my USB memory key on FreeBSD, I won't be able to use it on Linux. Even if the actual file system is the same, even if the encryption algorithm is the same.
This is illogical. Encrypted partitions are nice for small, portable devices, that you can plug on various hosts running various operating systems. That's the theory. But because everyone reinvents the wheel, you can't do that. It won't work.
Now that we have filesystems that almost any operating system out there has support for (ext2/ext3 and vfat), maybe it would be nice to use a common format for the encryption layer.
{{.sig}}
I have been working on article on disk encryption though it is not quite ready to be published yet. I didn't know anybody else was working seriously on this. I know about cryptoloop in Linux. It is bad, but not the worst I have seen described. It is nice to finally see somebody but me realizing that disk encryption is not as simple as those implementing it think. I don't know how the more "professional" products work. What I have realized is, that good disk encryption has an overhead on disk usage. Those "professional" products I have seen just a few details about doesn't have for too litle overhead for good crypto. The system described by the article only protects cold disks, no protection at all for hot disks. What I describe in my own article actually has some protection for hot disks, not much protection though, because the hot disk naturally limits the protection that is possible.
Do you care about the security of your wireless mouse?
How is this like rubberhose?
AFAIK rubberhouse works on the filesystem layer, while what is described here work on the block layer. That actually means you can easilly use the two on top of each other (assuming they are available for the same OS). Some of the security properties rubberhose aims for are impossible to do on the block layer. OTOH doing encryption on the block layer is simpler than doing it on the filesystem layer, and you are free to put whatever filesystem you prefer on top of that. Of course even encryption on the block layer can get complicated if you want to make it as secure as possible. Maybe performance can be improved by doing encryption in the filesystem, but proving security gets really tricky.
Do you care about the security of your wireless mouse?
(Full disclosure: I've been involved with the Win32 Scramdisk project in the past)
Hhhm, this is pretty interesting. I am not aware of any other disk encryption program (Scramdisk, DriveCrypt, LoopAES, PGPDisk, BestCrypt etc) that offers sector remapping. It's useful because it prevents standard disk structures from being exploited in a known plaintext attack (note: with current knowledge, this is only a theoretical weakness with AES anyway).
Apart from that it looks a pretty standard On-The-Fly-Encryption (OTFE) system. It does appear to be slightly more complex than most programs, but this is offset by the peer review from (at least...) two very well respected cryptographers - Dr David Wagner and Lucky Green. I am not aware of any of the other OTFE systems being reviewed by anyone half this competent.
Last paragraph of 6 says "RSA2/512" should read SHA2/512.
I'd personally be worried about the use of a static (zero!) IV. I know the key is random, but.....Oh well, if Dr Wagner has peer reviewed it then this can't be much of an issue.
From the paper: "A truly paranoid setup would leave the computer con- figured to boot the Windows system by default, and locate the GBDE data in such a way that it would be destroyed by the act of doing so."
It's likely this wouldn't work - the first thing a half-competent adversary would do is image all disks in a system before booting....It's forensic 101.
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
I thought this was a bad idea, since RSA is non probabilistic.
A hash function is not supposed to be probabilistic, a hash function must be deterministic, otherwise it wouldn't work. Of course using RSA for hashing is a bad idea not only because of performance, but also because RSA is not a hash function.
When used as a hash, you've got neither semantic security nor indistinguishability.
Semantic security is a concept used about encryptions not hashes. To get semantic security an encryption needs to be probabilistic. RSA is not probabilistic, neither is any symetric block cipher. But they can be used as building blocks in semantic secure encryptions.
Do you care about the security of your wireless mouse?
Nah, that's a typo. Read further into the paper and you can see they mean SHA2/512 rather than RSA2/512.
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
Is this encryption deniable?
Yep - as per the paper, this encryption is deniable (that's to say there is no way of showing that the container file or partition is an encrypted volume without having the passphrase). Thinking of a good reason why you've got a very high entropy 2.5Gb file/partition when the cops kick the door down could be interesting though ;)
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
Is it possible to do that (instead of just keeping parts of the key on an usb storage device) with freebsd/GBDE?
I think some ibm thinkpad T30 come with TCPA chip which could (at least theoretically) work as such a token, too.
While it is certainly possible to easily implement file encryption at the user/application layer, I disagree that it should be. Matt Blaze pointed out a number of reasons why in his CFS paper back in 1993.
StegFS is a neat concept; the only drawback there is the huge performance hit -- besides, the goal of stegFS isn't necessarily to support encryption; it is meant to support plausible deniability of file ownership, and those two goals are very different.
I bootleg Fizzy Lifting Drinks.
What product for current versions of Windows are you referring to that offers disk at a time encryption. Note that that means being able to operate from an encrypted boot drive, not just being able to take a big file, call it a volume, and have it be encrypted.
Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.
The paper explains this at length (but I guess that the respondent didn't actually read the paper). The primary focus in GBDE was usability and deployability. Most of the prior art in this space cannot even change the pass-phrase without reencrypting the entire disk (which can easily take an entire day).
I wanted to do better than that, and I think I did. By a wide margin.
RSA vs. SHA.
Correct, that is a typo, it is SHA2 which is used.
AES, zero IV etc.
An important part of GBDE is that there is no two-way leverage on any crypto component. This is realized by the use of single-use random bit sector keys. With no two-way leverage and single-use keys, the IV is no longer important.
The comment about the "plausible denial" setup being useless because an intelligent adversary would always take a mirror copy first: That does not affect the plausible denial aspect.
I'll be more than happy to discuss any aspect of GBDE, and would very much like to hear peoples experience and ideas. But I would prefer email (if need be by setting up a mailing list)
Poul-Henning Kamp -- FreeBSD since before it was called that...
Poul-Henning Kamp -- FreeBSD since before it was called that...
As to your first point, I'm not sure what the distinction is...I'm saying that the behavior is too complex and not transparent enough if provided at the application level.
An application can use its own code (in userland) to encrypt files. Fine. Or, an application can use kernel code (via whatever syscalls/hooks are provided). Fine.
The problem is that the application is complicated by the need to provided cryptographic services -- file encryption is either too difficult to get done properly at the application layer or not transparent enough at the application level. The filesystem is part of the kernel, and any encryption should be transparent to a process using the file.
I bootleg Fizzy Lifting Drinks.