CMR paves the road to GAK, and provides no corporate security.
I've been mulling over PGP5's CMR feature for a while, trying to decide what I think of it. It hasn't been easy, but I've come down against it. I'm restricting my discussion to the use of CMR in corporate email. I am not addressing stored data.
Jon Callas (jon@pgp.com) writes:
There are two things I will discuss in this missive:
(1) The assertion that Corporate Message Recovery is "just like Clipper" and why this is not true. (2) The fear a number of people have expressed that Corporate Message Recovery (CMR) could be used by the US government to slide in GAK.
I think we're agreed that CMR isn't itself GAK and I'll talk some about why it isn't with (1).
I think that we're a lot more worried that the presence of features like CMR will make it easier for governments to mandate GAK. It's much tougher to insist on GAK if a switch requires new software to be developed, and for everyone to purchase, install, and use espionage-enabled software. If CMR - like facilities are already in the software, then GAK could be mandated overnight by executive order. The inclusion of CMR drastically lowers the barriers to mandated GAK.
CMR isn't like Clipper:
* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128 bits or more), backed with a full-strength public key.
A word of advice: don't try to discuss Clipper in this forum without checking your facts. Clipper used an 80 bit key.
* Clipper's key was set in hardware by the manufacturer, and users were required to use it.
Actually, the chips left the manufacturer 'blank'. They were to have their unit keys set by some ill-defined process involving government employees. It never really got nailed down, since Clipper was killed before the key escrow agencies and systems were ramped up beyond demonstration levels.
A CMR key is a software-enabled key, no user is ever required to use it.
With a CMR feature in place, a government can say "Starting now, encrypt to this key or we'll throw you in jail." Without CMR, they can't really do this.
There are cases in which a user might "volunteer" to use a CMR because they work for someone who requires it,
[or because the State says it will toss his sorry ass in jail if he does not]
but that's a problem we'll address with the PGP Secure Resume Server which allows headhunters to securely and anonymously find people who've made bad career decisions.
[or bad citizenship decisions?]
* A CMR key can be revoked, reissued, or changed. You can periodically change it as a matter of policy. You can even stop using it. Clipper's was, again, set in hardware, with no option of not using it.
Once again, you're unlikely to do this if the State decides that that would be a good reason to jail you.
* The Clipper symmetric algorithm was secret; CMR keys use publicly available algorithms.
True, but the point is moot - most people beleive that the NSA is perfectly competant to write secure symmetric ciphers without outside review, and since they had given themselves a backdoor, there was no reason to leave the window unlocked as well.
* With Clipper, there was always a concern that an outside agency had the keys. This is true with a number of other systems (the so-called key recovery systems), and is the reason that a number of them are lumped together with the term GAK. Note that the user-organization creates a CMR key, and the end-user enables it. If any government gets access to this key, it is because either (1) they solved the Discrete Logarithm Problem, (2) they broke the public CMR key, (3) they black-bagged your CMR key, or (4) they are using a subpoena, warrant, or discovery to get the key. We're working on a way around (1), we can't do anything about (2) or (3), but these are fine reasons not to use CMR! If you're beset by (4), you need lawyers, not cryptographers.
If the State could do (1), they would not be asking for key recovery in the first place. (2) and (3), are greatly aided by CMR, since CMR provides high value targets; breaking or black-bagging a single key gives you access to a great deal of traffic, and in the case of (4), you lose 5th Amendment protection, since a third party holds a key.
* With Clipper, there was a central repository of all the keys. With CMR, there is not. I discussed that in detail in my message, "Why Corporate Message Recovery isn't Key Escrow."
Once again, you haven't checked the record. Clipper keys were to be split, with different halves going to different government agencies. There were fairly elaborate plans to prevent posession of only one half giving an attacker an advantage. Thus there were *two* repositories, not one. (From the point of view of the paranoid, this was not much of a comfort - both repositories belonged to the same entity.)
I have noticed that a number of people have the tacit assumption that business people and corporations are in cahoots with the FBI, waiting to hand over everyone's secret key. As in all parts of life, there are many, many businesspeople and corporate execs who are not particularly moral. But I don't think that their immorality takes this form. If we could examine the dark, secret thoughts of a corporate scumwaffle -- the ones that he *really* hopes don't hit the papers -- I sincerely doubt that, "Oh, Louis, I love it when you rummage my drawers" is among them.
Here's an alternative interpretation. I think that 'business people and corporations' feel (with considerable justification, I might add) that they have a moral right to control the information which flows in and out of their worksites, just as they have a right to control to flow of material goods on and off of their premises. To control the flow of material goods, companies install security systems, guards, metal detectors, etc. Depending on the type of good and it's value, these more or less work, though they're never perfect; when the marginal cost of improving security exceeds the loss that the improvement would prevent, you stop adding security. In the extreme case, the diamond workers of Namibia have to undergo a full-body X-ray whenever they leave the diamond reserve. Companies would like to be able to able to exercise similar control over data. However, bits behave differently than do atoms. Physical barriers are almost perfectly transparent. An employee can slip a multi-gigabyte DAT tape in a shirt pocket, or transfer stego'd data undetected inside innocent cover data, perhaps with non-CMR'd superencryption. For data, physical barriers - firewalls, passwords, isolated lans, access controls encryption, et al, can work more or less effectively to prevent unauthorized outsiders from acquiring data they should not. However, there is *no* way in which you can prevent a person you have authorized to receive data from making whatever use of it they desire, even if those uses are opposed to your reasons for giving them the data. CMR serves to give corporate executives the illusion that they can control the uncontrollable. It lets them think they can monitor the expression of their employess, while they can not. It lets them beleive that they can use technology to protect corporate proprietary data from theft by disloyal employees, while they can not. The only way to protect data is to make sure that employees share the goals and ends of the corporation; ie, give them a reason to be loyal and trustworthy. Classified agencies know this. In the classified world, there is a huge effort to protect data from outside attack. There is a similarly intense effort to check that only loyal, reliable, trustworthy people get clearances, and strong 'need to know' controls to restrict what data even they can see. However, once a cleared person has acheived properly authorized access to classified data, there is (in my observation) remarkably little done to prevent them from deliberately walking off with it. CMR provides an illusion that this loss can be prevented. It looks good in a chief security officer's report; it gives warm fuzzies to senior management. However, it provides no real security. In fact, it actually weakens security, since anyone with licit or illicit access to the CMR key(s) can read the data.
Now then, the next topic is the fear that CMR will be used in some insidious government plot to slip in GAK everywhere.
I worry about this, too. But I don't think it's feasible that CMR can be a stalking horse for GAK. If the government wants to GAK-enable all PGP, they'll have to have a plan similar to this:
[Strawman GAK plan deleted] Here's a more realistic scenario. 1. OpenPGP with CMR becomes a standard, and is widely accepted and installed. PGP gets rich. (Are you going to claim that this could never happen?) 2. An executive order is signed by the President, ordering that all encrypted email include the FBI public key as a recipient. He notes that this will be no burden to industry, since it's a freebie with the industry standard CMR facility. To summarize: 1. CMR cannot prevent disloyal employees from sending messages that their employers would want to prevent. 2. CMR, widely deployed, would greatly ease a transition to mandated GAK. Given CMR's inability to provide an a desirable goal (improve corporate security), coupled with the severe downside (paving the road to GAK), I have decided that I must oppose it.
Jon Callas jon@pgp.com
Peter Trei trei@ziplink.net
[Padgett, you're Cc'd because I'm quoting something you once claimed on Perry's list, I think] I agree with basically every word Peter Trei wrote. It's not often you agree with a long post like that 100%, but I could not fault a single point. Contrast that to PGP's Jon Callas's recent posts where I found myself disagreeing with a large proportion of both technical and political points. Just a couple of nit-picky comments on various things, and some re-iteration of the technical arguments against GAK compliancy (to supplement Peter's good political arguments):
* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128 bits or more), backed with a full-strength public key.
A word of advice: don't try to discuss Clipper in this forum without checking your facts. Clipper used an 80 bit key.
Clipper was definately advertised as a 80bit key, I agree. But I did once see someone else claim that it was a 64 bit key, and this was by Padgett Peterson, who is usually pretty good with facts, though perhaps his claim was speculation in this case. (I've added him to the Cc). His reasoning was that the 16 bit checksum (which Matt Blaze demonstrated could be brute forced thereby trashing the GAK enforcement) would come out of the 80bit key size, thereby meaning that it was only an effective 64 bit key. I suppose this claim if it is correct would be similar to DES keys being 64 bit, but 8bits being parity (checksum again), and therefor being only 56 bit effective. The DES case would set a precedent for NSA design involvement using larger "keys" than effective keys. If this is true, the clipper / skipjack system was even more flawed than we believed, as not only was it possible to brute force the checksum, but the key space could have been brute forced also, possibly without knowing the algorithm either, just by buying lots of clipper chips (though I think this would require knowledge of the checksum algorithm). But clearly the NSA could have brute forced the traffic in addition to having back doors. Of course, I think it likely that the key was actually a 96 bit key with an effictive key size of 80bits after the 16 bit checksum. Regardless, if Padgett's speculation is correct, I suspect this is not what Jon was thinking.
* With Clipper, there was a central repository of all the keys. With CMR, there is not. I discussed that in detail in my message, "Why Corporate Message Recovery isn't Key Escrow."
Once again, you haven't checked the record. Clipper keys were to be split, with different halves going to different government agencies. There were fairly elaborate plans to prevent posession of only one half giving an attacker an advantage. Thus there were *two* repositories, not one. (From the point of view of the paranoid, this was not much of a comfort - both repositories belonged to the same entity.)
I must defend Jon a little bit here in that it was fairly widely agreed that the wording in some of the Clipper documents (perhaps FOIAed, perhaps released normally, don't know) that the NSA would have an extra access for "national security" (there's that magic root password to the constitution again). The presumtion a lot of people held was that the NSA would have a second unified copy of the split databasee to enable this national security access. I'm not sure of course that this is actually ever explicitly admitted anywhere, and it could be that they would just have direct access to both split databases, but I wouldn't really have thought this was the likely; I suspect the NSA would've wanted access without others even with in special wire-tapping courts knowing their tapping activities. Whether or not this is what Jon was referring to I don't know. I agree with the negative political aspects Peter expressed of PGP's "GAK compliancy" (as I like to call it) in PGP's pgp5.5 & SMTP policy enforcer. I also think there is a purely technical security case to be made against this architecture which I have tried to lay out clearly in my post titled: Subject: negative security aspects of GAK compliancy Peter made some security points about this also. I think we should be able to win the argument about GAK compliancy purely on technical reasons. The only vaguely logical objection I've seen to arguing against GAK compliancy on political grounds was Hal Finney's assertion that OpenPGP should move towards more generalised forms of key assertions in the form of PolicyMaker-like key assertions (Matt Blaze has a paper and system called PolicyMaker). However PolicyMaker I suspect will be a long time coming, and may not be supported by all vendors due to complexity, and in addition even with PolicyMaker, the same political and security arguments against actual use of PGP Inc's GAK compliancy field (or PolicyMaker assertions to the same effect) still forcefully apply. And there are still in particular security and political arguments against implementing corporate access to mail archives, or corporate sent/received mail snooping by using the SMTP GAK compliancy policy enforcer. Lastly I would comment that it is sad that we on cypherpunks are having to expend so much energy trying to persuade PGP Inc with it's supposed pro-privacy stance, and supposedly pro-privacy employees, that they should be working against GAK, and even to get them to acknowledge that what they are doing is pro-GAK, and big brotherish is an uphill struggle. PGP Inc with their poor PR management, and hugely insensitive pro-GAK moves mean that PGP Inc is pissing away Phil Zimmermann's good reputation at a huge rate of knots. Wake up PGP. Look what you are becoming. 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`
-----BEGIN PGP SIGNED MESSAGE----- original message(s) follow my comments: 1. agreed that GAK is awful from a security standpoint. it is just a huge hole open to abuse by supposedly trusted escrow agents and the usual government dishonesty and deceit. on top of that, GAK is an unpardonable sin, with CAK not far behind. 2. CMR does not lead to GAK. let's get the terms correct as to what can be done, versus what will be done. a) there will be companies who start with GAK/CAK since it is simple to issue an order of compliance. b) there will be companies who need to maintain content audit trails a) to prove they either did or did not do as stated, b) development records, etc. for instance for patents, c) historical customer records. hopefully this class will use signature, communications, and individual or group storage keys. the need for encryption is paramount on computer systems --it is the equivalent of the locked file cabinet, sometimes in a locked secure area. c) PGP today can meet the requirements of GAK, CAK, CMR, or just about any format you wish --and make corporate control a reality. I could have a crude, but workable control program which would prevent the use of pgp standalone as well --and I could have it up and running by tonight. secondly, add a few modifications to sendmail, and trying to slip one through the system is history. stating that CMR leads to GAK is the same argument that mary jane starts the victim on the road to horse. -how's that allegorical illusion to blow by keyword scanners? likewise, I still believe I would much rather see PGP, Inc. implement a SNMP system to mandate corporate policy which can be adjusted from zero for the libertarians to GAK for the unpardonable sinners. at least the employees of the latter can protest the ignorance of management; despite the general attitude that all management personnel are the south ends of northbound horses, management is interested in calm, productive employees. if the government does mandate GAK, and really gets serious about enforcing it, there will be a lot of changes, and I for one will trade my computer for something more necessary as I build a bunker to protect myself and children --there will be no government about that time, or at least a government we will recognize. attila out, again -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 Comment: No safety this side of the grave. Never was; never will be iQCVAwUBNEJawL04kQrCC2kFAQHBCQQAqr0jk2wilOVAx83ZBEyU9ZLzFp0WVk9F AoWlZwefOxngL+iCZbalLdrr94CECmLes3ugmbDukQfyminSlFsVVSKMkRD64uRm 91giq52/FUPjH4mE1IJZsj/07F0/slydkDcsBI7awfvl8VFxbAGF0oJDY4fAHlz9 ZBpxvSoPewo= =jdGv -----END PGP SIGNATURE----- on or about 971012:1153 Adam Back <aba@dcs.ex.ac.uk> was purported to have expostulated to perpetuate an opinion: +[Padgett, you're Cc'd because I'm quoting something you once claimed on +Perry's list, I think] +I agree with basically every word Peter Trei wrote. It's not often you +agree with a long post like that 100%, but I could not fault a single +point. +Contrast that to PGP's Jon Callas's recent posts where I found myself +disagreeing with a large proportion of both technical and political +points. +Just a couple of nit-picky comments on various things, and some +re-iteration of the technical arguments against GAK compliancy (to +supplement Peter's good political arguments): +> >* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128 +> >bits or more), backed with a full-strength public key. +> +> A word of advice: don't try to discuss Clipper in this forum without checking +> your facts. Clipper used an 80 bit key. +Clipper was definately advertised as a 80bit key, I agree. +But I did once see someone else claim that it was a 64 bit key, and +this was by Padgett Peterson, who is usually pretty good with facts, +though perhaps his claim was speculation in this case. (I've added him +to the Cc). +His reasoning was that the 16 bit checksum (which Matt Blaze +demonstrated could be brute forced thereby trashing the GAK +enforcement) would come out of the 80bit key size, thereby meaning that +it was only an effective 64 bit key. I suppose this claim if it is +correct would be similar to DES keys being 64 bit, but 8bits being +parity (checksum again), and therefor being only 56 bit effective. The +DES case would set a precedent for NSA design involvement using larger +"keys" than effective keys. If this is true, the clipper / skipjack +system was even more flawed than we believed, as not only was it +possible to brute force the checksum, but the key space could have been +brute forced also, possibly without knowing the algorithm either, just +by buying lots of clipper chips (though I think this would require +knowledge of the checksum algorithm). But clearly the NSA could have +brute forced the traffic in addition to having back doors. +Of course, I think it likely that the key was actually a 96 bit key +with an effictive key size of 80bits after the 16 bit checksum. +Regardless, if Padgett's speculation is correct, I suspect this is not +what Jon was thinking. +> > * With Clipper, there was a central repository of all the keys. With CMR, +> > there is not. I discussed that in detail in my message, "Why Corporate +> > Message Recovery isn't Key Escrow." +> +> Once again, you haven't checked the record. Clipper keys were to be split, +> with different halves going to different government agencies. There were +> fairly elaborate plans to prevent posession of only one half giving an +> attacker an advantage. Thus there were *two* repositories, not one. +> (From the point of view of the paranoid, this was not much of a +> comfort - both repositories belonged to the same entity.) +I must defend Jon a little bit here in that it was fairly widely agreed +that the wording in some of the Clipper documents (perhaps FOIAed, +perhaps released normally, don't know) that the NSA would have an extra +access for "national security" (there's that magic root password to the +constitution again). The presumtion a lot of people held was that the +NSA would have a second unified copy of the split databasee to enable +this national security access. I'm not sure of course that this is +actually ever explicitly admitted anywhere, and it could be that they +would just have direct access to both split databases, but I wouldn't +really have thought this was the likely; I suspect the NSA would've +wanted access without others even with in special wire-tapping courts +knowing their tapping activities. +Whether or not this is what Jon was referring to I don't know. +I agree with the negative political aspects Peter expressed of PGP's +"GAK compliancy" (as I like to call it) in PGP's pgp5.5 & SMTP policy +enforcer. +I also think there is a purely technical security case to be made +against this architecture which I have tried to lay out clearly in my +post titled: + Subject: negative security aspects of GAK compliancy +Peter made some security points about this also. I think we should be +able to win the argument about GAK compliancy purely on technical +reasons. +The only vaguely logical objection I've seen to arguing against GAK +compliancy on political grounds was Hal Finney's assertion that OpenPGP +should move towards more generalised forms of key assertions in the +form of PolicyMaker-like key assertions (Matt Blaze has a paper and +system called PolicyMaker). +However PolicyMaker I suspect will be a long time coming, and may not +be supported by all vendors due to complexity, and in addition even +with PolicyMaker, the same political and security arguments against +actual use of PGP Inc's GAK compliancy field (or PolicyMaker assertions +to the same effect) still forcefully apply. And there are still in +particular security and political arguments against implementing +corporate access to mail archives, or corporate sent/received mail +snooping by using the SMTP GAK compliancy policy enforcer. +Lastly I would comment that it is sad that we on cypherpunks are having +to expend so much energy trying to persuade PGP Inc with it's supposed +pro-privacy stance, and supposedly pro-privacy employees, that they +should be working against GAK, and even to get them to acknowledge that +what they are doing is pro-GAK, and big brotherish is an uphill +struggle. +PGP Inc with their poor PR management, and hugely insensitive pro-GAK +moves mean that PGP Inc is pissing away Phil Zimmermann's good +reputation at a huge rate of knots. +Wake up PGP. Look what you are becoming. +Adam -- "When I die, please cast my ashes upon Bill Gates. For once, let him clean up after me! " "Experience keeps a dear school, but fools will learn in no other." --Benjamin Franklin ______________________________________________________________________ "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0
Attila T. Hun wrote:
c) PGP today can meet the requirements of GAK, CAK, CMR, or just about any format you wish --and make corporate control a reality.
I could have a crude, but workable control program which would prevent the use of pgp standalone as well --and I could have it up and running by tonight.
secondly, add a few modifications to sendmail, and trying to slip one through the system is history.
stating that CMR leads to GAK is the same argument that mary jane starts the victim on the road to horse.
One problem is that Corporations are learning that it is in their best interests, and moreover, *possible*, to computerize access to private employee information both on and off the jobsite. As well, corporations share information amongst themselves that they do not share with even the employee in question. There was the case of a man who tested positive for AIDS when getting a physical, etc., for company health insurance. The health insurer turned him down for coverage, and wouldn't tell him why, although they told his employer and every other health agency in the world. The man's wife contacted AIDS much later and is now going to die, as well. Companies exist who *require* their employees to put in long, unpaid hours, center their life around the company, yet regard all of the employees communications, even during *unpaid* time, to be owned by them. Then they will turn around and fire said employee when they read his/her private email and find out there is a history of cancer in the family, or some such, even if it is in their imagination. There are already cases of people being denied health coverage because of 'pre-existing' conditions, based on the fact that their company communications revealed that their great-grandfather had the same disease, etc. These are just small examples off the top of my head, but I know I see more and more use of private information gleaned from inside and outside companies to determine everything from health coverage to promotions. I personally know of a woman who has been consistently denied promotions because her company's investigation of her revealed that many of her female relatives have a large number of children. When she changed jobs, that information was actually sent to her new employer. (Perhaps she could spend the next ten years of her life suing someone/everyone, but that's no way to live.) The strange shit is already happening, and will increase, as the Corporations feel that what is good for the Government Gander is good for the Corporate Goose. TruthMonger
At 9:54 PM -0700 10/11/97, Trei Family wrote:
Classified agencies know this. In the classified world, there is a huge effort to protect data from outside attack. There is a similarly intense effort to check that only loyal, reliable, trustworthy people get clearances, and strong 'need to know' controls to restrict what data even they can see. However, once a cleared person has acheived properly authorized access to classified data, there is (in my observation) remarkably little done to prevent them from deliberately walking off with it.
There's damn little you can do in a free society. KeyKOS provided a facility where you could give information to a program and ensure it could not communicate it elsewhere. However this facility involved running the program in what amounted to solitary confinement. While you can get away to doing this to programs, people are (rightfully) different. ------------------------------------------------------------------------- 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
participants (5)
-
Adam Back
-
Attila T. Hun
-
Bill Frantz
-
Trei Family
-
TruthMonger