You said, "CGD also provides a mechanism for 2-factor authentication where additional key material can be stored on a USB device." How does it work?
RD: When setting up a CGD device, one creates a parameters file. This file contains all sorts of information, including the encryption types, the key lengths, and the methods for generating keys. Most of the time, one will generate a key from a pass phrase using PKCS#5 PBKDF2, but one can specify more than one key generation method. If multiple methods are specified, then the results of each will be XORed together to produce the final key. So, to use 2-factor authentication, what one does is specify two key generation methods; one will be a pass phrase based method such as PKCS#5 PBKDF2, and the other will be a simple key, which is just stored in the parameters file. Now, you just put the parameters file on a USB device. And without the USB device, knowledge of the pass phrase does not yield the resulting key.
What happens if I lose my key? What if I forget my pass phrase?
RD: If you lose your key or forget your pass phrase, then you have lost your data. You are in the same position as the person who stole your laptop. If this is a concern, then you should back up your data (securely, of course.)
cgdconfig provides multiple methods to verify the pass phrase. It can scan for a valid disklabel or a valid FFS filesystem. I'm wondering how many probabilities are there that an invalid password would generate a valid disklabel/filesystem?
RD: The probabilities that an invalid password would verify correctly are actually quite small. Let's consider the disklabel. Currently, we validate four things: the 32-bit magic number, which is repeated twice; the 32-bit checksum; and the number of partitions. The number of partitions is stored in a 16-bit integer but is limited, depending on the architecture, to a maximum of 22. This means that the upper 11 bits are zeros. So, we validate the values of 32 + 32 + 32 + 11 = 107 bits.
If we assume that typing the wrong pass phrase will result in an essentially random block, then the chances that the disklabel will pass the sanity test is 1/2^107. This is a reasonably small number, approximately
We could validate many more bits in the disklabel to get even more certainty; e.g., the sector size, the number of sectors per track, the partition placements, etc. There is more than enough known data in a disklabel that it is unlikely that there exists an incorrect pass phrase that would generate a sane and valid disklabel.
A similar analysis could be performed for the FFS superblock.
Is the code easily portable to other OSes?
RD: Most of the CGD code is in the userland configuration utility, which should be quite easy to port. Kernels tend to have larger differences in APIs and behaviors, so the kernel code would be slightly more difficult to port. CGD has been ported to OpenBSD 3.2 by Ted Unangst, but it was not integrated into the main OpenBSD tree.
Do you know any alternative software that you consider better or that includes features missing in cgd?
RD: CGD and encrypted pseudo disks in general such as OpenBSD's svnd, FreeBSD's GBDE, or Linux's Loop-AES address a particular threat model. Encrypted filesystems offer an answer to a different threat model and contain different trade-offs. For some use cases, the use of an encrypted filesystem such as CFS or nCryptfs might be a better choice. But that said, it is important to understand what the trade-offs are. With CFS and nCryptfs, you gain the ability to have different keys for different users at the expense of exposing a fair amount of the filesystem metadata. Per-user encryption can be important over NFS, but on a laptop it is not important. Even on a server with locally connected disks, one must keep in mind that root can just read any user's keys out of memory--so an encrypted filesystem will not protect you from root, at least while you are logged in.
OpenBSD didn't import CGD even if Ted Unangst wrote a port some time ago. Do you think OpenBSD's
svnd is already offering the same features?
RD: In a sense, OpenBSD's
svnd appears to offer some of the same features as CGD. Before I developed CGD, I examined
svnd and determined that it has a number of deficiencies.
The biggest drawback of
svnd is its lack of security in the
general use case. It is vulnerable to an offline dictionary attack. That is,
you can generate a database mapping known ciphertext blocks on the disk back
into pass phrases that can be accessed in O(1) without even being in possession
of the disk. What's even worse is that the same database will work on any
svnd disk. It is possible--and perhaps even likely--that large
agencies such as the NSA have constructed such a database and can crack a
majority of the
svnds in the world in less than a second. The way
that one prevents an offline dictionary attack is to use a salt in conjunction
with the pass phrase, and this is what I did when I wrote CGD by using PKCS#5
PBKDF2. Offline dictionary attacks have been well-known since at least the
'70s, and salting the pass phrase has been standard practice for over
OpenBSD's solution only supports Blowfish, whereas I wanted to ensure that CGD had the flexibility to support a small range of ciphers. This is important for a number of reasons, but mainly we want to provide our users with the ability to make cost-versus-risk decisions. Blowfish is fast, but probably less secure than AES. In some situations, users will decide that speed is more important than security, and in others the reverse will be true. Also, if security issues are discovered in one cipher that we support, then users can change their CGDs to use one of the other ciphers without needing to upgrade to a new version of the operating system. Blowfish also has a cipherblock size of 64 bits, which for sufficiently large disks might be small enough to allow some level of structural analysis.