comments wanted on gbde

[Perry E. Metzger]

Charlie asked me to forward this.

From: "Charlie Kaufman" <charliek at microsoft.com>
Sent: Tuesday, March 08, 2005 12:46 PM
To: cryptography at metzdowd.com
Subject: Re: comments wanted on gbde

Steve Bellovin writes:
>A "discussion" -- I'll be polite and call it that -- has erupted on 
>some mailing lists about gbde -- geometry-based disk encryption.  With 
>the author's consent, I'm soliciting opinions from this group about it:
>http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

My biggest complaint with the cryptographic design is that it is overly
complex for no good reason. Adding extraneous complexity is much more
likely to introduce security problems than to mask them, but it seems
unlikely that it did so in this case.

This design is likely plenty secure for realistically expected uses.

The paper acknowledges the "cleaning lady copy attack", where periodic
copies are made and differences noted. In this case, the attacker can
identify the sectors that were updated. With these patterns, it is
likely no security is gained by the complex rearranging of sectors in
the algorithm. But this was only a backup mechanism anyway.

The three most serious "room for improvement" areas I could find are:

1) There is no integrity check on the encrypted sectors. An attacker can
therefore make modifications to the data that the user will not detect
cryptographically. Since CBC mode is used on individual sectors, an
attacker can make a predictable change to a chosen block if he accepts a
random change to the following block. One can imagine (with a good
imagination) the ability to patch a block of a program to behave in an
insecure way.

2) The paper notes that someone who knows an old passphrase (and has
access to a small amount of old data) will be able to read the disk.
This largely negates the value of periodically changing the passphrase.
The straightforward solution of decrypting and reencrypting the entire
disk when the passphrase changes is noted as having unacceptable
performance. An alternative whose performance might be acceptable is to
encrypt the old key under the new key, keep that in the header, and
encrypt newly encrypted sectors with the new key. A background task
could decrypt and reencrypt all sectors over time.

3) Attention should be paid to failure modes. One can imagine disk
failures - possibly even a sector written without its corresponding key
sector written -that would render much or all of the disk inaccessible.
Understanding the transaction semantics of the disk controller is
required to get this right (in the worst case, writing multiple copies
of critical data where the second write is not initiated until the first
completes). My reading of the document is that the master record is
written on the disk in four places for redundancy against corruption,
but the locations of those master records is kept in only one place.

	--Charlie Kaufman

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com