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."
From Bill Stewart's report, given the apparent amount of effort PGP have put into their CMR based enforcement policy functionality, I
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. 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`
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`
participants (3)
-
Adam Back -
Bill Stewart -
Tim May