Re: anti-GAK design principles: worked example #1

[Adam Back <aba@dcs.ex.ac.uk>]

Bill Stewart <stewarts@ix.netcom.com> writes:
> > [separate signing and encryption keys]
> 
> On the other hand, if the keys are separate, Louis Freeh
> can tell the Congress that it's not a big problem,
> he'd NEVER dream of GAKing your signature keys,

Valid argument with some value yes.  Actually now that you bring it up
I dimly remember this aspect being raised on cypherpunks some time
back.  Perhaps it was you who raised it even.  Or perhaps it was Phil
Karn, or someone.

> Similarly, your corporate security bureaucrats can understand
> the concept that if they CAK your privacy keys,
> they're risking having official company signatures get forged,
> and they'll often do the right thing and desist,
> but with separate keys that won't stop them.

Hmmm.  I think that if companies start encrypting anything, they're
going to need recovery of some sort.  Else they just won't use it at
all.

Most of them aren't using storage encryption right now anyway, which
is why Tim May's suggestion to store emails after decrypt in the clear
makes a lot of sense as a simple interim way out of this problem until
the issues have been explored more.

This largely avoids company requirement to recover emails.

One valid objection to this approach is that if the employee forgets
their password whilst there are lots of emails queued up to receive
that those emails will be lost.  Or if the employee gets hit by a
truck.

However I'm not so sure this is a big deal for a number of reasons:

1. how often do employees get hit by trucks?
2. how often do employees forget passwords? (all the time unfortunately)
3. things which are important the sender is likely able to resend because
   he has in clear on disk
4. senders using the same software can have archives of what they have sent
   and easily able to resend.

> >Does pgp5.0 reply encrypting to just me as individual, or two crypto
> >recipients me, and Mega Corp recovery key?
> Just you.

If you are right, it will bounce when it hits an enforcer with the
strict setting turned on.

Is this what will happen?

This will mean that the users will have to manually figure out how to
solve (get enforcer key, multiple encrypt to that key, possibly by
cc'ing to enforcer email address/userID even if this bounces).

> >It is evil.  But it is not _as_ evil.
> >
> >The reason for this is that government access to storage keys is not
> >as evil as government access to communications keys, because the
> >government has to come and capture the ciphertext (take your disk),
> >whereas with communications they can grab them via an arrangement with
> >your ISP.
> 
> First of all, the only reason for having a CMRK attached to your key
> is that either your mail service will reject mail to you that doesn't
> contain it, or your employer insists on it.  In either case,
> it can be done without a special CMRK field on your key --
> PGP multiple recipients are enough to do that, and the sender
> just has to remember to include the (no longer automagically attached) CMRK.
> So leaving out the CMRK doesn't protect you.

Lack of automation is some weak protection.  What are users to do?
Send Cc: <thoughtpolice@nsa.gov>.  What if they forget?  Much more
plausible to forget.  Makes strict penalties for forgetting difficult
in western countries.  5 years jail time for forgetting?  Don't think
so.

What about the traffic?  If you make it an invalid address, just to
pick up the key it'll flood email systems with bounces; every single
encrypted mail will get a bounce.

Not an overwhelming protection, but may mean more people will more
resist it, and more people will forget often with the current email
MUA deployed base.

With many people using CMR based pgp5.5, forgetting will be much less
plausible.

Putting in CMR encourages adoption of this kind of filtering/bouncing
approach.

I am interested in analysis and discussion of the level of
significance this difference makes to user uptake of GAK in say the US
as an example (say some time in 1998 when many more businesses and
individuals have upgraded to pgp5.x).  What differences are there in
resistance between a pgp5.5 using CMR and with a pgp5.6 using CDR (or
storage-CAK as Bill terms the approach)?

> Second, if the government is coming to get your disk anyway,
> they can get themselves a court order to have you reveal the key,
> and you can argue with the judge about whether you should be
> compelled to reveal it, and at least in the US there's a 
> Fifth Amendment backing up your arguments (though like the
> other amendments, it's weakened by the "except for drugs" clause...)

Yes.  This is the kind of reason I argue that storage recovery is less
dangerous than communications recovery.  They've got to get the disk
first.  And they can't tell if you have used GAK until they get it;
when they get it if you're suspecting they will try this, you will
ensure there is no GAK access, you will use other software, as you
have nothing to lose.

> GAK asserts that the government has the right to your keys
> before you get to court.  

Well that is the scenario that Freeh is arguing for yes.  Faced with a
choice of giving him your comms keys or your storage keys, I'd go for
storage keys anyday.  I can lie to him, and give him some random
numbers and he'll never know.  The point at which he will know will be
after the dawn raid; if it gets to dawn raids you are indendently in
trouble anyway.

> On yet another hand, while it may be obvious when the government
> steals your disk and uses Storage-GAK, companies using Storage-CAK
> or Storage-CMR can use it just as well on the backup tapes without
> your notice as on your disk drive.  Furthermore, you can think of
> the data backup process as communications from you to the
> backupmeister, so Storage-CAK _is_ Message-CAK, and Storage-CMR is
> Message-CMR.

Technically yes.  Practically no, there is a large difference.  The
extra protection of Storage-CAK method is the extra GAK resistance due
to the fact that availability of access to communications is patchy,
and more expensive for the government to achieve, and enforcement is
patchy, even detection is patchy.  This patchiness is good.  Mass
keyword scanning is impossible on a wide scale.  The government can
keyword scan some of you, but they can do that already at similar cost
levels: they can plant bugs, have undercover federal investigator
inflitrate your company in guise of employee etc.  The aim of the game
is to make the cost higher than existing physical attacks, or at least
as high as possible.

> But CAKing the disk doesn't protect the company's information,
> and there's therefore no excuse for using it.  

Surely it does?

If you are in ACME Corp and they want all disks encrypted as a
security policy.  They provide smart cards to employees, and
workstations data is inaccessible until correct smart card is
inserted.  Employee lets dog chew on smart card.  No recovery implies
that this data is irretrievably lost.

> Superencryption is always possible, in messages as well as files,
> but with message encryption the eavesdropping-prone corporation can
> detect superencrypted messages going by (though not stego'd), while
> PGP-encrypted files on your disk only show up _after_ you've been
> hit by the bus on your way to the headhunter's.

This is good.  Both systems are hackable from all three directions.
(individuals can hack around system to increase privacy; corporations
can hack around to decrease privacy (keyboard sniffer); governments
can too by walking in and taking disks and threatening people fail
time for not handing over keys.)  Many aspects of this are better with
storage data recovery than they are with communications recovery.
Especially government aspects.  Company aspects are almost neutral
non-issue in my mind due to ease with which company can remove your
privacy as they own machines, and can do all sorts of things to your
software, hardware, video cam, bug phone, keyboard sniffer, keyboard
log, etc.,etc.

> BTW, PGP5.5 CMR _is_ CMR'd storage encryption.  
> It's not as convenient as encrypted file systems 
> like PGPdisk and Secdev, 
> but people are using it to encrypt stored data,
> including email and non-email files.

Yes.  pgp5.0 which I looked at windows version (available on
ftp://ftp.replay.com/ (netherlands) somewhere for other non-US
people), does file and email encryption.  As does linux version.

> On a technical note, GAK for storage can be made less dangerous,
> though not less offensive, by adding a layer of indirection -
> use your public key to encrypt a symmetric key, store the encrypted
> symmetric key on your disk, and then use the symmetric key for
> encrypting the storage (or as a master key for encrypting the
> per-file or per-block storage keys, if you're doing that, 
> which you probably should.)  This means that a search warrant
> which is required to itemize the things it's looking for can be
> more effectively restricted to specific files rather than
> cracking the whole disk and every other disk that uses the
> same encryption keys.

Good point.

> >The point though is that storage recovery is a completely separable
> >issue from communications "recovery" which is a euphamism for allowing
> >companies to read, or snoop, employees email, unless it is being used
> >soley for data recovery of mail stored in mail folders (which seems to
> >be what PGP Inc means by CMR term), in which case it is not necessary
> >functionality, and can be better acheived by encrypting the mail
> >archive with a user symmetric key with company storage recovery on
> >that key.
> 
> Trust me - you _really_ don't want mailboxes encrypted,
> recovery key or no recovery key, unless it's implemented very very well.

PGP Inc does use this otherwise there would be no argument about need
for recovery information -- you don't need recovery information for
plaintext.

> [100Mb mail folder corruption nightmares]

Your example of corruption problems with large mail boxes is one
argument against this practice.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`