Re: Security flaws introduced by "other readers" in CMR
Tim May <tcmay@got.net> wrote:
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?
Because they've got customers who will pay for CAKware. Why will customers pay for it? Same reason the FBI wants GAK, even though motivated/well-informed crypto users will superencrypt or otherwise bypass the enforcement mechanisms. If you're the C in CAK or the G in GAK, access to some data is better than access to no data - and the possibility of enforcement radically alters the risk/benefit calculus of even intelligent actors who see their interests as contrary to those of the [C,G]. As Jon Callas confirmed at the recent Cpunks physical meeting, the current CAK/CAM/whatever system has very weak code re policy enforcement - for example, it'll allow otherwise forbidden messages to pass through its filters if even the "--- BEGIN PGP MESSAGE ---" lines are altered or removed. It won't disassemble tar or zip or uuencode packages, or otherwise attempt to discover simple attempts to bypass the enforcement mechanisms. They're not trying to stop determined covert communicators - that's not their threat model. -- Greg Broiles | US crypto export control policy in a nutshell: gbroiles@netbox.com | Export jobs, not crypto. http://www.io.com/~gbroiles | http://www.parrhesia.com
Greg Broiled:
As Jon Callas confirmed at the recent Cpunks physical meeting, the current CAK/CAM/whatever system has very weak code re policy enforcement - for example, it'll allow otherwise forbidden messages to pass through its filters if even the "--- BEGIN PGP MESSAGE ---" lines are altered or removed. It won't disassemble tar or zip or uuencode packages, or otherwise attempt to discover simple attempts to bypass the enforcement mechanisms. They're not trying to stop determined covert communicators - that's not their threat model.
Yes, I am a lunatic, but I'm really not in that bad of shape when compared to the 'normal' people. I once worked with a 'state of the art' alarm security company. They had all the hi-tech toys, including a special 'goo' covering the proprietary computer chip, so that it would be destroyed if anyone messed with it. We installed 'the works' in a Royal Bank in Moose Jaw, Saskatchewan, in my first week of employment, and I was with the head guy when he finished off the job by taking me upstairs and showing me how to tie into the phone line so the system could automatically notify the local gendarmes when the alarms got tripped. As we 'finished the job,' I noticed that there was a door to the outside, beside the power and phone boxes, which did not have a 'trip plate' on it. I mentioned it to Mr. Head Guy, who looked at his work order and said, "Not in the contract." We 'finished the job' and left. If you are ever in Moose Jaw, Saskatchewan, drop by the Royal Bank, climb the fire escape up to the roof, kick the fucking door down and go grab yourself a handful of cash. (It is not *quite* that simple, in case you are wondering.) I also know a man in Tucson, Arizona, who installed a $10,000 home security system and then cut the wire to the alarm bell, because it was too loud. I recognize the dangers inherent in PGP's move toward Corporate Message Recovery, but I also recognize that there will be a thousand Joe Schmoe's adversely affected by it for every CypherPunk who gets backdoored as a result of misuse of the technology. I think that it is admirable that a number of CypherPunks are railing loudly against something which is more likely to bring other people to grief, rather than themselves. I truly believe that PGP has made some serious errors in their current implementation of Corporate security software, but it is something that is indeed coming, like it or not, and I have more confidence that there may be better hope for proper changes in the package in the future, than I would in the 'Pretty Louis Freeh Privacy' software company was the first to develop the technology. My advice? (Thanks for asking...) 1. Help to install/develop the package at companies which are run by decent humans, and truly have good intentions. Explain the pros and cons to them, and what you feel are moral areas to consider before making changes in your suggested modus operandi. Oh yes...and put in a back door, or some such, so that you may have a chance to make necessary changes if the situation changes in the future. 2. Help to install/develop the package at companies which need it and will get some such program in the future, regardless of the ethical functionality of the package. Explain your feelings in regard to the ethics of control versus privacy and try to help them understand that basic human decency is in their long-term interest. Put in *several* back doors, so that you can route around any damage they cause by putting profits ahead of ethics. 3. Help to install/develop the package at companies which have the worst of fascist, evil intentions. Don't bother explaining the ethical issues, as they will only use them as guidelines to do the opposite. Put a time-bomb in the son-of-a-bitch which will explode in a few months time and put them completely out of business. I have put some type of backdoor in *every* product I have developed. I have used the backdoor *once*, in order to rescue a company from their own stupidity. I did not inform them of my 'fix,' but let them believe that the system 'fixed itself.' (Right...it happens all the time...) If I *had* informed them that I had fixed their fuck-up via a backdoor I had built in, I have no doubt they would have thanked me profusely for my foresight, and then demanded that I remove the backdoor. There was one application I developed that had the potential to make me a very rich person if I chose to misuse a backdoor in the future. I had to sit down, recognize the temptation and my own weakness, and decide if it was still in my client's best interest if I installed a back door in the product. The company out-and-out screwed me out of several thousand dollars at the end of the project, and I am rather proud to report that I considered and rejected the use of the backdoor I installed in order to 'enforce' *justice* (and it took less than a minute to decide it was not worth 'taking the chance' of being wrong, and therefore a thief--or being 'right' and still being a thief). I am proud of the CypherPunks who are speaking their mind, even if it means aligning themselves against the Holy Grail of privacy and security. I believe that we should rail loud and long against those things which we perceive to be against the interests of the privacy and security of the individual cogs in the corporate machinery, but should still promote the interests of a company which is probably the best horse to back, even if there are no future guarantees. I also believe that we should search hard and long for ways to throw a serious fuck into said program, just in case... I have already found one exploitable weakness in PGP's CMR implementation, which shall remain my own secret. Any further exploitable weaknesses I find will be shared with others, privately. I wish that Viacrypt had not tied their CMR software to PGP's reputation, since it is a product based on a different concept, but I also wish that I had picked different numbers for last week's million dollar lottery. I am willing to give Viacrypt time to recognize whether or not they have compromised ethics to a certain extent, in return for convenience and market position. I try not to 'Nuke the bastards!' on a whim, but I am always ready and willing to do so if it becomes undeniably clear that it is time to take a stand. I would like to thank those who have spoken out on both sides of the issue involved, particularly in light of their willingness to seek and listen to alternative viewpoints. I hate having to sort through people's righteously held prejudices in order to get to the fruits of their analytic labors. The issues involved in Viacrypt's choice of direction and their chosen implementation of corporate security software is truly a nadir point in encryption development. It is too important an issue for any of us to take a predetermined stance in order to defend our private points of view and predilections. 'Schindler's List' provided an excellent viewpoint of things not always being what they seem, or not ending up the way they started out. At the same time, the film may be a bogus representation of the true facts of life involved in the situation. A different approach by Schindler may have resulted in a better or worse resolution to the events, and we shall never know, but I do believe that the man did the best that he could. I plan on doing the best I can to further the spread of strong encryption, regardless of whether or not any particular product or implementation makes me nervous at a certain stage of its development. However, I truly hope that, if I am in error, someone believing and doing the exact opposite of myself will prevail. Besides death and taxes, there is one other thing that I think is undeniably certain...world events are changing at such an increasingly fast pace that, regardless of the direction the future takes, it is *not* going to be boring. TruthMonger
Greg Broiles <gbroiles@netbox.com> writes:
Tim May <tcmay@got.net> wrote:
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?
Because they've got customers who will pay for CAKware.
I have tried to express this trade off, and to make suggestions of how to work within this frame work to hinder GAK take up: (from http://www.dcs.ex.ac.uk/~aba/grdesign/:) Principle 4: deployment wins. Violating any of principles 1, 2 or 3 whilst still remaining better than GAK-neutral can be justified where deployment is thereby increased to the extent that the reduced GAK resistance of the product can be justified by the overall increase in GAK resistancy in the target jurisdictions. This can be expressed loosely as the equation: introduced resistancy = deployment x resistancy rating Corollary 4: Where a profit function outside the individuals control interferes with GR maximisation of principle 4, continuing in this environment may be justifiable where this tactic helps promote global GAK resistance in the target jursidiction. Examples of novel ways of making the best of this imposed profit function overlayed on the solution space of designs may be: attempts to subvert standardisation processes to make the standards GAK resistant even for GAK neutral developers, or to code GAK resistant implementations for GR-neutral employers without informing them of these coding decisions, or to promote GR implementation and protocol design to contacts in the cryptographic developer community, or to anonymously release useful proprietary GR optimisation technology, or to sabotage ergonomics or reliability functions in implementations of very low GR rated designs.
Why will customers pay for it? Same reason the FBI wants GAK, even though motivated/well-informed crypto users will superencrypt or otherwise bypass the enforcement mechanisms. If you're the C in CAK or the G in GAK, access to some data is better than access to no data - and the possibility of enforcement radically alters the risk/benefit calculus of even intelligent actors who see their interests as contrary to those of the [C,G].
I agree.
As Jon Callas confirmed at the recent Cpunks physical meeting, the current CAK/CAM/whatever system has very weak code re policy enforcement - for example, it'll allow otherwise forbidden messages to pass through its filters if even the "--- BEGIN PGP MESSAGE ---" lines are altered or removed. It won't disassemble tar or zip or uuencode packages, or otherwise attempt to discover simple attempts to bypass the enforcement mechanisms. They're not trying to stop determined covert communicators - that's not their threat model.
It is a property of fielded systems that the majority of users will work within the functionality provided by it. This property can be used by all 3 sides of the debate. It is a politically neutral mechanism. 1. It can be used by PGP Inc (who evaluate the tradeoffs between socially desirable properties and ergonomics and come up with the belief that CMR optimal solution). They point out (rightly) that the fact it is possible to easily hack around demonstrates some GAK resistance. I would argue however that it is not a very great addition. I have been trying to persuade PGP Inc that it is possible to implement more highly GAK resistant products within their profit function and user requirement set using the CDR (corporate data recovery). 2. It can be used by people such as us who consider different tradeoffs to be optimal, in that we can field systems which make it so that the system has to be hacked before it could be used for GAK. The obfuscation can always be hacked around, almost by definition, but a large beaurocratic organisation such as a government will find it difficult logisitically to organise the development of GAK enabling patches, and deploy these, and to persuade people to apply the patches. 3. It can be used by people such as perhaps TIS who have cost functions highly sensitive to not upsetting the government, and therefore field on behalf of government GAK enabled systems. They can make it as hard to hack around as they can. The difficulty of hacking around and the difficulty of widely deploying the cypherpunks "anti-gak patch for TIS mandatory GAKware v1.0" means that they partly succeed. 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 -
Greg Broiles -
TruthMonger