CAK as a really bad form of corporate networking

I've been scratching my head, trying to figure out what the market for
PGP's new recovery program is for. After all, if employees have local disks
and these disks are on a company network or backup plan, then the
corporation has access to the plaintext of memos, reports, and plaintext
sent and received e-mail. (The purpose of Alice encrypting to Bob being
_in-transit_ security, and nothing more.)

It seems to me that the CAK (Corporate Access to Keys) approach being
talked about, where Alice encrypts to Bob and _also_ encrypts to Eve, is a
poor solution to the "archiving" problem.

As Adam Back and others have noted, if Alice stores her Eudora or whatever
e-mail files on her systems, presumably in plaintext (as the purpose of
encrypting with Bob is for _in-transit_ security, not storage security),
then the corporation can insist that she make her plaintext files
archivable on the company's backup system.

One way to look at the market for CAK is that a company is too flaky to
have a corporate network or backup strategy and is using CAK as a kind of
crude networking scheme. E-mail, with cc:ing of the company crypto czar, is
a way to archive or pool company traffic. A rather back-assed approach, it
seems to me.

Meaning no insult to PGP, Inc. or its fine programmers, it's as if this
message was sent out:

--begin internal Giant Corporation memorandum--

From: Cakbert, Evil PR and Security Administrator
To: All Droids
Subject: Mandatory Voluntary CAK System

It has come to my attention that our attempts to get a corporate-wide
network working have failed, and that we are using a mishmash of intranets,
local LANs, and direct dial-out systems. This is thwarting our efforts to
read what you people are writing to each other.

Henceforth, to solve this network problem we must insist that you adopt a
mandatory voluntary system of cc:ing me, Cakbert, on all of your messages.
Encrypted messages must be voluntarily encrypted with PPP (Pretty Poor
Privacy).

Thank you for your attention.

--end internal Giant Corporation memorandum--

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

At 10:28 AM -0700 10/10/97, Tim May wrote:
>One way to look at the market for CAK is that a company is too flaky to
>have a corporate network or backup strategy and is using CAK as a kind of
>crude networking scheme. E-mail, with cc:ing of the company crypto czar, is
>a way to archive or pool company traffic. A rather back-assed approach, it
>seems to me.

Another way to look at it is:  Large corporations aren't much different
from governments.  Their management doesn't know what is going on down in
the trenches, and they are scared.


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA

At 10:28 AM -0700 10/10/97, Tim May wrote:

>As Adam Back and others have noted, if Alice stores her Eudora or whatever
>e-mail files on her systems, presumably in plaintext (as the purpose of
>encrypting with Bob is for _in-transit_ security, not storage security),
>then the corporation can insist that she make her plaintext files
>archivable on the company's backup system.

I should add that Alice may have encrypted files on her local hard disk.
Nothing in PGP for Business, as I understand it, stops Alice from storing
files without also encrypting to Cakbert's key. That is, Alice can store
encrypted files to her heart's content.

(If in fact PGP for Business even requires a corporate encryption for
stored files, then I missed this in the description. My apologies.
Actually, to close this glaring loophole, I would expect PGP for Business
to insist on a corporate key being used even for private files. Of course,
without communicating those files to the corporate data center, all Alice
has to do is corrupt the stored file a little, or delete it, and she's back
to encrypting in ways only she can use.)

A tree chart is really needed to see where PGP for Business works and where
it doesn't work.

The charting of the permulations, of who encrypts, who keeps the plaintext
versions around, etc. is complicated, but instructive to do. (Does Alice
encryp to Bob? Does Alice store the plaintext or leave things encrypted?
Does Alice make her local disk archivable by corporate backup systems? Etc.)

My conclusion is that PGP for Business does very little for real corporate
access in "hit by a truck" situations, as most of these critical files
(fill in the blanks, but think of chip design files, source code for
programs, lab notebooks, etc.) are simply NOT ever e-mailed. And if they
are e-mailed, this is completely a tertiary issue.

To put it simply, if Joe the Programmer is hit by a truck, reconstruction
of his project files will come almost entirely from what he has on his hard
disk, on backups he or the company made, on his papers, etc. Almost none of
it will come from the e-mail he sent to others. And, in any case, his
recipients presumably have copies of the e-mail he sent them. Maybe they
don't, but if this is a function of PGP for Business, then it says that
file archiving is really one of the main functions. Which is possible, but
there are better ways to archives records!

If a company is worried that an employee will forget his passphrases, or be
hit by a truck, or leave on bad terms, or whatever, then the obvious
solution is to have him carefully make a backup of his passphrases and
secret keys and place them in a safe and accessible place, e.g., in the
safe of the company attorney. This is what all prudent persons do with
their keys, right?

Such precautions are standard for crypto work, and have nothing to do with
what PGP for Business is apparently doing.

Further, I would argue that PGP for Business gives a false sense of
security. What real use is access to some bullshit e-mail if the prudent
steps outlined above have been ignored?

We know that the push for GAK is for access to _communications_ keys. We
know that Alice and Bob have no need to GAK their _communications_. The
real customer for GAK is an eavesdropper, not Alice or Bob.

So who is the real customer for PGP for Business and its form of plaintext
recovery?

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Tim May <tcmay@got.net> writes:
> I've been scratching my head, trying to figure out what the market
> for PGP's new recovery program is for. After all, if employees have
> local disks and these disks are on a company network or backup plan,
> then the corporation has access to the plaintext of memos, reports,
> and plaintext sent and received e-mail. (The purpose of Alice
> encrypting to Bob being _in-transit_ security, and nothing more.)
>
> It seems to me that the CAK (Corporate Access to Keys) approach
> being talked about, where Alice encrypts to Bob and _also_ encrypts
> to Eve, is a poor solution to the "archiving" problem.

I'm finding this whole thing is surrounded by euphemisms, and
newspeak.  For example PGP's Jon Callas claiming that the main
motivation for the system is to ensure availability of messages.  As
you point out this is bunk.

This leaves as the only excuse for pgp5.5's existance corporate
snooping of sent and received emails.  PGP Inc is encouraging little
brother and doing it in a way that provides tools for big brother, and
is thereby paving the way for mandatory GAK.

(Also Jon's flimsly claim that it isn't a "key escrow" system, I
consider mere word play, whatever PGP Inc cares to call it, it's
clearly a CAK system).

> As Adam Back and others have noted, if Alice stores her Eudora or
> whatever e-mail files on her systems, presumably in plaintext (as
> the purpose of encrypting with Bob is for _in-transit_ security, not
> storage security), then the corporation can insist that she make her
> plaintext files archivable on the company's backup system.

Perhaps my arguments of how you can build encrypted corporate snooping
email archive systems without being GAK friendly are too complex.
Just storing the data in the clear is easier to understand, and is
probably what most corporates are doing anyway.  I don't think most
corporates are using storage encryption widely internal to their
networks, and rely on a decent firewall, or an air gap.

The obvious objection to the argument that you store your email
folders in the clear, as I'm sure one of our anonymous PGP employees
will point out again, is that:

	What if the email is archived encrypted in the eudora folder,
	or the netscape, or other MUA folder.  The corporate snoop
	won't be able to read it without the employees co-operation.

A similar objection applies to IMAP mailboxes, (IMAP being a POP3 like
thing, but with the added functionality that the mailbox archive is
kept on the server).


If you're using PGP mail client software too, it can archive it in
plain text, or encrypted with a corporate escrowed storage key as I
was describing.  Mostly mega-important email is going to be copies of
stuff on disk anyway, as Tim points out.

(Also I'd like to ask those who use other email clients than I how encrypted
email is treated: with emacs mailcrypt, I have the option of archiving the
decrypted email, or keeping the encrypted mail as is in the archive, so that
you have to go back and decrypt it again to read old encrypted emails.  How
does the eudora plug in work?  How does pgp5.0 work, and how does netscape
with pgp plug in work.)


To me a corporate snooping policy is not a good thing to encourage.
I wonder if PGP Inc claim that corporate snooping is demanded by the
industry.

Another way to implement corporate message snooping is for the company
to retain copies of users private decryption keys.  (Plus to have the
second crypto recipient on sent mail of the company snoop, but strip
it off before it goes outside the LAN in the SMTP policy enforcer.)
Still that's more GAKware, as if you remove the policy enforcer it's
useful for GAKkers also.

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`