Security flaws introduced by "other readers" in CMR

At 11:10 AM -0700 10/15/97, Eli Brandt wrote:

>Non-technical point: the NSA (reportedly) has no intention of using
>GAK for classified information.  They know that it weakens security.
>
>Do the privacy of the nation's data and the security of its
>information infrastructure deserve the same consideration as the
>Pentagon's "Confidential" memos?  When you're planning to build in a
>single point of failure, this is a question you have to ask.

This also applies to CMR as well. Whatever the perceived business reasons
for CMR, the fact is that it introduces additional failure points. No
longer will Alice and Bob be secure that at least there are no "other
readers" in the channel between them (what they do with the plaintext after
decryption is of course solvable by no technology).

And, contrary to some of what we've been hearing, even corporations have
continuing needs to know that a communication between Alice and Bob, within
a corporation or crossing the corporate boundary, is not being listened to
by any other person. Merger negotiations are one obvious example.

(There are workarounds, I suppose. CMR could have a "override" switch to
turn off the CMR to a second key. But who decides on this? Maybe a signed
message from a suitable higher-up? Ah, the complexity. And executives
wanting to bypass CMR can and will use other channels. So many of the goals
of CMR are out of reach....)

Instead of choosing an example where CMR apparently "works," such as
Crispin's example of a corporation using CMR to detect (as if it weren't
detectable in other ways!) that an employee is operating a porn ftp site
from company computers, let me throw out some examples where CMR introduces
flaws into a security system.

* Andy Grove sends a PGP 5.5-encrypted message to T.J. Rodgers, CEO of
Cypress Semiconductor, outlining the plans for Cypress to be acquired by
Intel. However, Cypress has implemented CMR, and one of the "second
readers" of Andy's message is the cryptically-named (no pun intended)
"CCCP" (Corporate Crypto Compliance Police), staffed by security guards and
personnel management droids. Major security flaw.

(Sure, one can imagine various levels of "second readers." But I rather
doubt that most of them will be _offices_, with changing staffs. While one
could, for example, designate "Gordon Moore" to be the second reader of all
files encrypted to Andy Grove's key, I rather doubt this is the way CMR
will play out.)

* Craig Livingstone, at whitehouse.gov, is the Key Compliance Officer for
all communications entering or leaving the White House. Enough said?

* Sheep-dipped cutouts in defense companies await their orders from DoD,
but find that other readers in their companies are monitoring them.

And so on.

"Three can keep a secret if two of them are dead." (Ben Franklin)

What will of course happen is that these "security flaws" will be plugged
by subterfuge. People will stop using the corporate mail for many such
tasks, and will use nonwork accounts. With some loss of efficiency, and
even more opportunities for leaks. (If firewalls are in place, on outside
net connections, employees can just dial out. Or use Metricom Ricochet
modems, if conditions are favorable for reception. Or wait until they go
home.)

In fact, CMR will mostly just mean bland, interdepartmental messages get
"recovered." As I said before, this is a pretty crude way to implement a
kind of corporate archiving of information.

Truly sensitive stuff--stuff about takeovers, foreign production plans, new
products, etc.--will be encrypted with channels having no nosy security
guards or Corporate Crypto Compliance Police silently listening in.

Which means we're back to square one. So why does PGP, Inc. bother?

And why should OpenPGP squander efforts worrying about this?

--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 11:29 PM 10/15/1997 +0100, Adam Back wrote:
>From Bill Stewart's report, given the apparent amount of effort PGP
>have put into their CMR based enforcement policy functionality, I
>predict they won't remove CMR whatever we, or Schneier, or anyone else
>says or proves about more secure less GAK-friendly ways of

They've got customers who wanted it; there's some room for making
it less controllable within their current framework (e.g. making
the behaviour for (as-yet unused) multiple CMRKs to be 
session-key-splitting rather than one-copy-per-CMRK, which is
be the more obvious implementation and is far more GAK-friendly.)

Also, the SMTP filter stuff won't go away - even if PGP Inc
dropped the product and dropped the CMRK from PGP 5.5.1 and
all future versions, once there's an API for PGP,
it's a piece of cake to write one; 
you just don't get the visibility that some keys are CMRKers, 
and you've got the inconvenience of sending more bouncegrams to 
senders telling them "to send a copy of PGP-encrypted mail to Bob,
you need to also encrypt it to Eve The PostMistress" or, 
less honestly, "... to the Exchange Gateway".
And at least the PGP SMTP filter only checks for the KeyID and
doesn't actually try to deccrypt the message.

>I also suspect they won't 
>listen to Tim's earlier argument that they do nothing about recovery

I thought Tim's point was directed to OpenPGP; Jon Callas and others
said things like ~~If you've got features you want done, 
propose it to OpenPGP and get them to adopt it, and that'll
give us a business reason that we ought to adopt it.~~
(I think the context of that was discussing Stealth, which they
still don't have enough business demand for to take time on,
and which by the way puts a major crimp in SMTP filters.)

>This quote should give us clue as to why they will continue with CMR: 
>	"we're a real company with accountants"

That wasn't an exact quote, just a paraphrase from my memory of 
several conversations.  

>Similar arguments would presumably present them with "no choice" but
>to fulfill the order for 100,000 GAK compliant units from the
>government terrorizing the freedom fighters PRZ likes to tell us
>about who are already using PGP GAK compliant software: pgp5.0.

Even if they did that, it wouldn't change the power relationships;
if the government can compel GAK keys by filtering SMTP or
confiscating non-eavesdropping-compatible mail gateways,
it doesn't matter if the Cc: Big Brother was added as a PGP5.5 CMRK
or as a PGP2.6.2i multiple recipient - you can't tell from
the message format (except for DH vs. RSA).


>What can we do about this situation?  Well we could build systems
>which hack around the CMR system.  Easy enough: just put dud
>"recovery" info inside.  We still have deployment problems.

Unless I misunderstood the formats, 
CMRKs are just identified by KeyID, not by fingerprint,
and it's easy to look through the public keyservers to find CMRKs
(though companies may prefer to have their employees mail out
keys to people who need them rather than making all their
keys constantly visible on the outside servers.)
So go find them all, send protest email to the postmasters
and corporate officials at the companies that use CMRKs,
crank up your deadbeef generator to make your own keys
with the same KeyIDs as the CMRKs, and pre-load the public keyservers.
A nice touch would be to burn your copies of the private keys
for the CMRK imitators, but we'll never know if you did, will we?
				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Bill Stewart <stewarts@ix.netcom.com> writes:
> At 11:29 PM 10/15/1997 +0100, Adam Back wrote:
> >From Bill Stewart's report, given the apparent amount of effort PGP
> >have put into their CMR based enforcement policy functionality, I
> >predict they won't remove CMR whatever we, or Schneier, or anyone else
> >says or proves about more secure less GAK-friendly ways of
> 
> They've got customers who wanted it; 

Whoa there Bill.  They have customers who wanted data recovery.  Data
recovery does not require CMR.

Did they admit to customers who wanted human based email screening?
No on list discussions have suggested this is the case.  I think I saw
one PGP employee state that it was not the case.

(I have perfectly good, more secure CDR based human screening designs,
not that I encourage this you understand).

> there's some room for making it less controllable within their
> current framework (e.g. making the behaviour for (as-yet unused)
> multiple CMRKs to be session-key-splitting rather than
> one-copy-per-CMRK, which is be the more obvious implementation and
> is far more GAK-friendly.)

Small difference I think.

> Also, the SMTP filter stuff won't go away - even if PGP Inc
> dropped the product and dropped the CMRK from PGP 5.5.1 and
> all future versions, once there's an API for PGP,
> it's a piece of cake to write one; 

Nothing against SMTP filters, just against the CMR enforcement they
put into theirs.

> you just don't get the visibility that some keys are CMRKers, 
> and you've got the inconvenience of sending more bouncegrams to 
> senders telling them "to send a copy of PGP-encrypted mail to Bob,
> you need to also encrypt it to Eve The PostMistress" or, 
> less honestly, "... to the Exchange Gateway".
> And at least the PGP SMTP filter only checks for the KeyID and
> doesn't actually try to deccrypt the message.

You're using "you can hack around it" and "it is visible" arguments,
these are valid arguments which mitigate the danger, but don't
actually alter Tim and my points that storage recovery is less of a
problem than message recovery.

> >I also suspect they won't 
> >listen to Tim's earlier argument that they do nothing about recovery
> 
> I thought Tim's point was directed to OpenPGP; 

He made the same point in both respects.  I agree with his point about
openPGP.

I fully agree with Tim's points and Bill Frantz's example that old
email messages come back to haunt people and are a nightmare waiting
for a discovery process in a messy lawsuit for companies.  I nearly
got sucked into such a thing myself last year (some one gave back a
laptop to a company they just quit on bad terms from, tried to wipe it
but left some messages on it; the messages looked _bad_, the idiot who
did that sent the _bad_ message to me, my response was to phone him up
and say `what _are_ you talking about, I can't do that'.).

This to me argues that PGP Inc should make email archives user
controllable.  So that users decide which emails to archive and which
to just let naturally disappear, in the same way that phone calls, or
chats in a restaurant aren't transcibed and digitally signed.  Much
harder to prove.  I would also argue for "official statement" vs "chit
chat" distinction on emails -- don't archive, and certainly don't have
recovery of chit chat, use non-transferable sigs for chit chat, the
only person who cares about authenticity is the recipient, not the
legal system.  So I think this aspect belongs in coding in ways which
are beneficial to companies.

> Jon Callas and others
> said things like ~~If you've got features you want done, 
> propose it to OpenPGP and get them to adopt it, and that'll
> give us a business reason that we ought to adopt it.~~
> (I think the context of that was discussing Stealth, which they
> still don't have enough business demand for to take time on,
> and which by the way puts a major crimp in SMTP filters.)

I guess the smtp filters leave stuff alone if they can't figure out
who it's to?  ie do default email thang -- which is probably what you
want if it's some privacy nut who is sending a "chit chat" class
message to one of your set of sales people.  don't do the explode to
all feature.

> >This quote should give us clue as to why they will continue with CMR: 
> >	"we're a real company with accountants"
> 
> That wasn't an exact quote, just a paraphrase from my memory of 
> several conversations.  

Sure.  It's also completely understandable that they do have financial
restrictions, my main argument was that they could build more GAK
resistant systems within those restrictions.

> >Similar arguments would presumably present them with "no choice" but
> >to fulfill the order for 100,000 GAK compliant units from the
> >government terrorizing the freedom fighters PRZ likes to tell us
> >about who are already using PGP GAK compliant software: pgp5.0.
> 
> Even if they did that, it wouldn't change the power relationships;
> if the government can compel GAK keys by filtering SMTP or
> confiscating non-eavesdropping-compatible mail gateways,
> it doesn't matter if the Cc: Big Brother was added as a PGP5.5 CMRK
> or as a PGP2.6.2i multiple recipient - you can't tell from
> the message format (except for DH vs. RSA).

Yes, but you are in the US.  The recipient is in tinpotdictatorsville.
With pgp5.0 your software will by default honour the military police's
demand in tinpotdictatorsville.

This is why I am arguing that the system as a whole be considered --
you are trying to build GAK resistance into the deployed code base you
have to think long term and you have to think in terms of sabotaging
the system to make it unuseful to governments.

Consider also that software gets used in it's default configuration
95% of the time.  Not everyone is a information architect :-)

> >What can we do about this situation?  Well we could build systems
> >which hack around the CMR system.  Easy enough: just put dud
> >"recovery" info inside.  We still have deployment problems.
> 
> Unless I misunderstood the formats, 
> CMRKs are just identified by KeyID, not by fingerprint,
> and it's easy to look through the public keyservers to find CMRKs
> (though companies may prefer to have their employees mail out
> keys to people who need them rather than making all their
> keys constantly visible on the outside servers.)
> So go find them all, send protest email to the postmasters
> and corporate officials at the companies that use CMRKs,
> crank up your deadbeef generator to make your own keys
> with the same KeyIDs as the CMRKs, and pre-load the public keyservers.
> A nice touch would be to burn your copies of the private keys
> for the CMRK imitators, but we'll never know if you did, will we?

OK, well that's some monkeywrenching, but I guess that could be
prevented with some design reviews.  I won't be helping with those
design reviews -- any company who wants to improve enforcement of CMR
type designs can figure them out for themselves.

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`

The 3 main GAK-hostile design principles are also independently good
security principles in protecting communications traffic.  There are
ways to acheive data recovery functionality without CMR.  I think I
have demonstrated amply what these methods are, and have given a
design methodology for designing such systems.  PGPers are just not
interested to hear.

>From Bill Stewart's report, given the apparent amount of effort PGP
have put into their CMR based enforcement policy functionality, I
predict they won't remove CMR whatever we, or Schneier, or anyone else
says or proves about more secure less GAK-friendly ways of
implementing corporate data recovery.  I also suspect they won't
listen to Tim's earlier argument that they do nothing about recovery
of messages rather than implement GAK.

This quote should give us clue as to why they will continue with CMR: 

	"we're a real company with accountants"

So they are not willing to follow through the anti-GAK design process
where this could hinder bottom lines.

Similar arguments would presumably present them with "no choice" but
to fulfill the order for 100,000 GAK compliant units from the
government terrorizing the freedom fighters PRZ likes to tell us
about who are already using PGP GAK compliant software: pgp5.0.

Tim May <tcmay@got.net> writes:
> let me throw out some examples where CMR introduces flaws into a
> security system.
> 
> [snip]

I think Tim's points are very valid.  CMR functionality if put into
the OpenPGP standard _will_ be used by PGP competitors to implement
message screening and snooping by company security guards etc.  It
will I am almost positive in due course be used to field such software
in countries with poor civil rights records.

Maybe PGP is not fielding systems they are "advising" their clients to
use for GAK, or for message screening, but this is what is going to
happen.  Their good advice isn't as much comfort as an OpenPGP
standard which is as hostile to this practice as possible, and a pgp
data recovery implementation which is also hostile to this.

PGP do not want to hear this.  It will cost development time.

The many people who have expressed to me off list that PGP has sold
out, are I think correct.

> Which means we're back to square one. So why does PGP, Inc. bother?
> 
> And why should OpenPGP squander efforts worrying about this?

I think that except for carefully worded statements by PGP Inc
employees all those who have spoken on the topic in the OpenPGP forum
have agreed.  The CMR field should not go in OpenPGP.  This means that
the PGP SMTP policy enforcer will not meet the OpenPGP standard: it
will bounce mail from compliant implementations which ignore the CMR
field.

I think this means that the person who suggested this:

	OpenPGP is unlikely to continue to be supported by PGP Inc

to me in email made a good prediction.


What can we do about this situation?  Well we could build systems
which hack around the CMR system.  Easy enough: just put dud
"recovery" info inside.  We still have deployment problems.

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`

At 8:42 AM -0700 10/16/97, Bill Stewart wrote:
>At 11:29 PM 10/15/1997 +0100, Adam Back wrote:

>>I also suspect they won't
>>listen to Tim's earlier argument that they do nothing about recovery
>
>I thought Tim's point was directed to OpenPGP; Jon Callas and others
>said things like ~~If you've got features you want done,
>propose it to OpenPGP and get them to adopt it, and that'll
>give us a business reason that we ought to adopt it.~~
>(I think the context of that was discussing Stealth, which they
>still don't have enough business demand for to take time on,
>and which by the way puts a major crimp in SMTP filters.)

Yes, the thrust of my comments was about OpenPGP.

The OpenPGPers were fretting about how to incorporate GAK and CAK and GMR
and CMR into their "open," and (presumably) international, standard, and I
said:  Keep it Simple, Stupid.

With luck, OpenPGP will displace PGP for Corporate Controllers and PGP,
Inc. will have to back pedal to remain compliant.

(Meaning no ill will toward PGP, Inc., but if they see their economic
future lies in compromising key security by building in CAK and CMR....get
my drift?)

--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:
> Yes, the thrust of my comments was about OpenPGP.
> 
> The OpenPGPers were fretting about how to incorporate GAK and CAK and GMR
> and CMR into their "open," and (presumably) international, standard, and I
> said:  Keep it Simple, Stupid.

To be clear: my efforts in CDR (data recovery) design alternatives, and GAK
resistant design principles are not because care one way or the other about
CDR going into the OpenPGP standard at this point, they were soley to
persuade PGP Inc that there are more GAK resistant ways to achieve same
functionality, which then negates need for CMR extensions.

The CDR proposal is about data recovery which means that it could be
argued to be outside the scope of OpenPGP; it is about how to
implement recovery within mail archives in a MUA, such as pgp5.x mail
client.

Also re. subject line, I now think that it is not a sell out, just a
design mistake; they have good intentions, and have not sold those
out, but have failed to optimally transfer those intentions into the
protocol design.

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`