On 27 May 2006, at 12:01 PM, John Pettitt wrote:
I think the underlying point is that many users, not understanding the
difference between the bulk key used to encrypt the data and the
passphrase used to protect that bulk key would assume, incorrectly
that
changing the passphrase would lock out prior users.
Clearly a users with a backup copy of an encrypted disk for which they
know the passphrase can use the technique described to decode a more
recent image of the same encrypted disk even though the owner of the
disk may think it safe because the passphrase was changed. In this
situation the old user gain access to newer data that they were not
supposed to be able to access. This is different from the described
restored backup situation in that the user is using a partial
restore to
circumvent a security mechanism.
The re-encyrpt button obviously defeats this attack however it's not
clear that real world users actually understand the need to re-encrypt
to make pass phrase changes meaningful when backup copies exist. I
think this is mostly a documentation issue and perhaps a user
interface
design issue in that users should be strongly advised to re-encrypt
when
they change the passphrase.
You bring up an excellent point. As I said in my previous post, we
are considering a change to the way we're doing things.
Unfortunately, there's no one thing that's clear the the right thing
to do. Let me examine some of them.
We could make a documentation change. I don't like documentation
changes like this because it's a cover-your-ass solution. Let's face
it, no one reads the documentation. If we put in something there, we
can answer any further objection with saying "this is a documented
situation," but it doesn't *solve* anything. It is in my opinion, a
cop out. We're better off doing nothing or making a code change.
Now then, we could make a code change. But what code change?
Security is a strange business, because you quickly go from things
that a absolute dos and don'ts into things upon which gentlepersons
can disagree. Part of this is because doing the right thing for the
user is a good design principle, but so is less is more. Simplicity
makes for better security, and that means doing less.
We could put a dialog box up warning the user. This is a reasonable
thing to do. The Truecrypt folks do that. One can argue on the other
side that is is just one step forward from a documentation change,
that it is a CYA move that doesn't really solve the problem, it just
allows you to wash your hands of the situation. I have to think about
it for a while. I can see both sides of it. I lean towards less is
more, particularly because there are lots of moving parts here. My
main PGP disk is not passphase-based, it is public-key-based. If I
change the passphrase on my key, does that mean that the PGP program
should grovel over my disk looking for virtual disk volumes that are
encrypted to that public key? If not, why not? Extend this to virtual
volumes that are managed by a smart card or security token, and you
can see it gets very hard very quickly.
Automatically re-encrypting the disk has much peril to it. Any time
you re-encrypt the disk, you expose the user to the chance of the
complete loss of their data. If you want to make it safer, you make
it slower. If you want to make it faster, you chew up more resources
on the user's computer It's a relatively easy task when it's a
megabyte. What happens when it's a hundred gigabytes?
Right now, we not only do virtual disks, but also whole disk
encryption. The core of what we do is the same across the board (if
not exactly the same code). We have to make tradeoffs. You will also
also see the architecture extend to some *very* cool storage
encryption very soon. The re-encryption problem is something we take
very seriously, and we have seriously discussed whether we should
have a re-encryption daemon that runs in the background and works
like a garbage collector, re-encrypting objects that need re-
encrypting, based on some security policy describing when things will
need to be re-encrypted. It is a garbage collector, but one that is
tied to a two-phase-commit, zero loss database update system. Is that
cool, or is it frightening? Or both? The CYA answer of putting a note
in the manual can start looking attractive when you seriously start
designing one of these.
I'm open to discussion about the larger issues. But let us not forget
that this started out with a bug report that itself says to first get
a brain. It was high-handed and insulting. You're right, there is in
the core of this, there is a very complex issue. We're discussing if
we should do something in response to the real issue here. But the
base issue, that there is some flaw in PGP and Truecrypt and other
software that only an idiot could have let out is flat out false.
Jon
--
Jon Callas
CTO, CSO
PGP Corporation Tel: +1 (650) 319-9016
3460 West Bayshore Fax: +1 (650) 319-9001
Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3
USA 28b6 52bf 5a46 bc98 e63d
PGP.sig
Description: PGP signature
