ietf-openpgp
[Top] [All Lists]

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

1997-10-18 14:15:13

Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)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(_at_)nsa(_dot_)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(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`