August 2002 - cypherpunks-legacy

Re: Seth on TCPA at Defcon/Usenix
by James A. Donald 13 Aug '02

13 Aug '02

-- On 12 Aug 2002 at 20:38, Mike Rosing wrote: > I'm actually really confused about the whole DRM business > anyway. It seems to me that any data available to human > perceptions can be duplicated. Period. The idea of DRM (as I > understand it) is that you can hand out data to people you don't > trust, and they can't copy it. To me, DRM seems fundamentally > impossible. To me DRM seems possible to the extent that computers themselves are rendered tamper resistant -- that is to say rendered set top boxes not computers, to the extent that unauthorized personnel are prohibited from accessing general purpose computers. To me, TCPA only makes sense as a step towards some of the more monstrous outcomes that have been suggested by myself and others on this list. It does not make sense as a final destination, but only as a first step on a path. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG xnGldvXqRQB8PKwYfVNs7FqNlzHkJtffm/JPsWY9 2NZkA77opkyGpXY+3+uMUIXDusHs6+ZgOeCu7YXgJ

1 0

Free Porno Movies
by free＠sex.com 13 Aug '02

13 Aug '02

1 0

TCPA and Open Source
by AARG! Anonymous 13 Aug '02

13 Aug '02

One of the many charges which has been tossed at TCPA is that it will harm free software. Here is what Ross Anderson writes in the TCPA FAQ at http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html (question 18): > TCPA will undermine the General Public License (GPL), under which > many free and open source software products are distributed.... > > At least two companies have started work on a TCPA-enhanced version of > GNU/linux. This will involve tidying up the code and removing a number > of features. To get a certificate from the TCPA corsortium, the sponsor > will then have to submit the pruned code to an evaluation lab, together > with a mass of documentation showing why various known attacks on the code > don't work. First we have to deal with this certificate business. Most readers probably assume that you need this cert to use the TCPA system, and even that you would not be able to boot into this Linux OS without such a cert. This is part of the longstanding claim that TCPA will only boot signed code. I have refuted this claim many times, and asked for those who disagree to point to where in the spec it says this, without anyone doing so. I can only hope that interested readers may be beginning to believe my claim since if it were false, somebody would have pointed to chapter and verse in the TCPA spec just to shut me up about it if for no better reason. However, Ross is actually right that TCPA does support a concept for a certificate that signs code. It's called a Validation Certificate. The system can hold a number of these VC's, which represent the "presumed correct" results of the measurement (hashing) process on various software and hardware components. In the case of OS code, then, there could be VC's representing specific OS's which could boot. The point is that while this is a form of signed code, it's not something which gives the TPM control over what OS can boot. Instead, the VCs are used to report to third party challengers (on remote systems) what the system configuration of this system is "supposed" to be, along with what it actually is. It's up to the remote challenger to decide if he trusts the issuer of the VC, and if so, he will want to see that the actual measurement (i.e. the hash of the OS) matches the value in the VC. So what Ross says above could potentially be true, if and when TCPA compliant operating systems begin to be developed. Assuming that there will be some consortium which will issue VC's for operating systems, and assuming that third parties will typically trust that consortium and only that one, then you will need to get a VC from that group in order to effectively participate in the TCPA network. This doesn't mean that your PC won't boot the OS without such a cert; it just means that if most people choose to trust the cert issuer, then you will need to get a cert from them to get other people to trust your OS. It's much like the power Verisign has today with X.509; most people's software trusts certs from Verisign, so in practice you pretty much need to get a cert from them to participate in the X.509 PKI. So does this mean that Ross is right, that free software is doomed under TCPA? No, for several reasons, not least being a big mistake he makes: > (The evaluation is at level E3 - expensive enough to keep out > the free software community, yet lax enough for most commercial software > vendors to have a chance to get their lousy code through.) Although the > modified program will be covered by the GPL, and the source code will > be free to everyone, it will not make full use of the TCPA features > unless you have a certificate for it that is specific to the Fritz chip > on your own machine. That is what will cost you money (if not at first, > then eventually). The big mistake is the belief that the cert is specific to the "Fritz" chip (Ross's cute name for the TPM). Actually the VC data structure is not specific to any one PC. It is intentionally designed not to have any identifying information in it that will represent a particular system. This is because the VC cert has to be shown to remote third parties in order to get them to trust the local system, and TCPA tries very hard to protect user privacy (believe it or not!). If the VC had computer-identifying information in it, then it would be a linkable identifier for all TCPA interactions on the net, which would defeat all of the work TCPA does with Privacy CAs and whatnot to try to protect user privacy. If you understand this, you will see that the whole TCPA concept requires VC's not to be machine specific. People always complain when I point to the spec, as if the use of facts were somehow unfair in this dispute. But if you are willing, you can look at section 9.5.4 of http://www.trustedcomputing.org/docs/main%20v1_1b.pdf, which is the data structure for the validation certificate. It is an X.509 attribute certificate, which is a type of cert that would normally be expected to point back at the machine-specific endorsement cert. But in this case they have altered the Holder field, which normally performs this function, to instead hold the measurement result that the certificate asserts is correct (i.e. in this context, the hash of the OS). As a result, no data in the VC is machine specific. The bottom line is that VCs are not machine specific and are designed not to be. Therefore if HP or anyone else gets a cert on their version of Linux, anyone will be able to use that same cert and prove to remote users that they are running a TCPA compliant OS. This contradicts one of Ross's main claims above. In fact, with Microsoft now apparently commited to Palladium, it appears that if TCPA survives at all, it may be solely as a Linux phenomenon! Reports are that both HP and IBM are working on Linux compatible versions of TCPA. Ironically, not only is Ross's claim wrong about TCPA undermining open source, it could conceivably turn out that TCPA will be completely reliant on open source operating systems. At the same time I think it is fair to say that there is an inherent conflict between the usual development techniques for open source code, and the requirements for security certification. Once an OS has been certified by some respected body as being secure and trusted along TCPA lines, then changes to the code will invalidate the certification. This makes sense on two levels. Logically, if the code has changed from what was inspected and certified, we can no longer have the same guarantees that the security properties have been preserved. And in terms of syntax, with the TCPA Validation Certificate holding a hash of the certified code, making any change will change the hash and so the certificate will be invalid. The result is that any modification to the code, no matter how slight, will change the hash and keep it from being usable with the old VC. Of course, the same thing happens with commercial code. But GPL tends to rely more on frequent, small, incremental changes - "release early and often". This practice will not work well with a hash-based security certification concept. There may be some creative workarounds possible for "trusted Linux" developers. They could set up their own certification infrastructure and allow core Linux kernel team members to issue certs. Especially if TCPA is not used on Windows systems, as seems likely to be the case now, Linux kernel developers will have considerable leverage in working out the best way to tackle this problem. Keep in mind, too, that one can make a strong case that open source code in general is a far better fit for the general concept of remote trust that TCPA/Palladium attempt to build. If your trusted system is running code whose source you can inspect, code which you might even be able to build yourself from source, you can have much greater confidence and peace of mind when you allow it to run on your system. I would be much more likely to trust a piece of software that was going to lock up its data, if I could be confident of exactly what it was doing. Adam Back wrote earlier about ideas to let the user inspect the data stream into or out of a Palladium application. I responded that this would invalidate the security guarantees for a large and interesting class of apps, such as the secure P2P enhancements I have sketched. But you can achieve much of what Adam wanted simply by choosing to run open source Palladium apps. Those are the ones where you know exactly what you are trusting the system to do. They are the ones that you know have no backdoor, spyware, or other objectionable, secret features. And note that in the context of application programs, there is no need for the OS certification described above. Trust in these programs would be handled on a completely decentralized basis, with each distributed application handling its own trust decisions. There would be no centralized certification system. Rather, the software would decide for itself which versions to trust. Summing up, it is at best a vast oversimplification to say that TCPA is a GPL-killer. It may cause some problems specifically for Linux due to the need to get certifications that are widely accepted. But it sounds like HP and possibly IBM are going to at least get the ball rolling with these certifications, so we can expect a TCPA compliant Linux in some form. And Linux developers may be able to come up with mechanisms that will allow them to continue making frequent Linux releases while still being able to support TCPA features. For general applications, TCPA/Palladium could be a tremendous marketing opportunity for open source. Transparency and trust go together like hand in glove. In the long run I think the open source community will thrive and benefit from TCPA and Palladium.

2 1

test mail-(pls ignore)
by gfgs pedo 13 Aug '02

13 Aug '02

test. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com

1 0

Another application for trusted computing
by AARG! Anonymous 13 Aug '02

13 Aug '02

I thought of another interesting application for trusted computing systems: mobile agents. These are pieces of software which get transferred from computer to computer, running on each system, communicating with the local system and other visiting agents, before migrating elsewhere. This was a hot technology from a couple of years ago, but it never really went anywhere (so to speak). Part of the reason was that there wasn't that much functionality for agents which couldn't be done better in other ways. But a big part of it was problems with security. One issue was protecting the host from malicious agents, and much work was done in that direction. This was one of the early selling points of Java, and other sandbox systems were developed as well. Likewise the E language is designed to solve this problem. But the much harder problem was protecting the agent from malicious hosts. Once an agent transferred into a host machine, it was essentially at the mercy of that system. The host could lie to the agent, and even manipulate its memory and program, to make it do anything it desired. Without the ability to maintain its own integrity, the agent was relatively useless in many ecommerce applications. Various techniques were suggested to partially address this, such as splitting the agent functionality among multiple agents which would run on different machines, or using cryptographic methods for computing with encrypted instances and the like. But these were inherently so inefficient that any advantages mobile agents might have had were eliminated compared to such things as web services. Ideally you'd like your agent to truly be autonomous, with its own data, its own code, all protected from the host and other agents. It could even carry a store of electronic cash which it could use to fund its activities on the host machine. It could remember its interactions on earlier machines in an uncorruptable way. And you'd like it to run efficiently, without the enormous overheads of the cryptographic techniques. Superficially such a capability seems impossible. Agents can't have that kind of autonomy. But trusted computing can change this. It can give agents good protection as they move through the net. Imagine that host computers run a special program, an Agent Virtual Machine or AVM. This program runs the agents in their object language, and it respects each agent's code and data. It does not corrupt the agents, it does not manipulate or copy their memory without authorization from the agent itself. It allows the agents to act in the autonomous fashion we would desire. Without trusted computing, the problem of course is that there is no way to be sure that a potential host is running a legitimate version of the AVM. It could have a hacked AVM that would allow it to steal cash from the agents, change their memory, and worse. This is where trusted computing can solve the problem. It allows agents to verify that a remote system is running a legitimate AVM before transferring over. Hacked AVMs will have a different hash and this will be detected via the trusted computing mechanisms. Knowing that the remote machine is running a correct implementation of the AVM allows the agent to move about without being molested. In this way, trusted computing can solve one of the biggest problems with effective use of mobile agents. Trusted computing finally allows mobile agent technology to work right. This is just one of what I expect to be thousands of applications which can take advantage of the trusted computing concept. Once you have a whole world of people trying to think creatively about how to use this technology, rather than just a handful, there will be an explosion of new applications which today we would never dream are possible.

2 1

Chrissies been working for the drug squad.
by Matthew X 13 Aug '02

13 Aug '02

Its Damaging;police chief.by andrew Webster. Public confidence in the Victorian police was being damaged by continuing allegations of corruption in the force,Chief Commissioner Christine Nixon said yesterday.(sat) Confirming reports that ongoing investigations into the drug squad had spread to suburban and regional stations,Ms Nixon said increased resources were being deployed to try and bring them to a rapid conclusion. The Commissioner said investigators were looking at individuals who had previously worked for the drug squad and had moved to other parts of the Victoria police,some of whom had left the force. But she said officers would not be suspended immediately allegations were made against them."When we have sufficient evidence we will take that step," she said. Problems with Victorias drug squad extend back many years.One former drug squad senior detective was jailed for five years in May 2000 for stealing seized chemicals;another serving officer has been charged with dealing in ecstasy;a former drug squad detective has been charged with drug trafficking;and in June last year one officer died from a drug overdose. (I was raided and robbed on June 1 last June btw.Some stuff of mine went missing.) Commissioner Nixon said major changes had been made to the drug squad but some of the recommendations by Police Ombudsman Dr Barry Perry had not yet been implemented because of continuing negotiations with the Victorian police association.Ms Nixon said she hoped to have an agreements in place by next month. But police Association secretary Paul Mullet denied the public had lost faith in drug investigators.He said the Association was at an early stage of discussions over drugs policy and had not yet been presented with the chief commissioner's detailed position on negotiations. Problems with corruption were also a matter of funding,according to Mr Mullet,which could best be tackled by bringing the Ethical standards Dept. up to strength. Dr Perry is due to present a report to parliament detailing the extent of current inquiry into drug squad corruption. He said last week the reforms so far included renaming and restructuring the Dept. but had not gone far enough.Dr Perry said the drug squad may have to be disbanded.

1 0

FAQ: How will Microsoft respond to Lucky's patent application?
by Lucky Green 13 Aug '02

13 Aug '02

I have received numerous questions in conversations and interviews over the last few days as to what I believe Microsoft's response will be to my recent patent application for methods that utilize Palladium and operating systems built on top of TCPA to assist in the fight against software piracy. Rather than continuing to repeat the same answers in conversations, I will simply make the answers available to the lists. Obviously, the following is my personal opinion. I don't profess to speak for Microsoft. Allow me to first outline some principles of how patents work in the U.S. Note that I am not a member of the federal Patent Bar and as such the following is simply my limited understanding of the process and should not be construed as legal advice. For a patent to be valid in the U.S., the idea to be patented must offer utility, be novel, and be non-obvious. I will address the three requirements as I believe they apply to my patent application in turn: Utility: According to the Business Software Alliance's website, in the financial loss to U.S. society due to software piracy in the year 2000 alone amounted to a staggering USD 7.2 billion. I therefore don't believe it can be reasonably argued that methods that may help reduce the level of software piracy lack utility. In particular, I don't anticipate Microsoft to argue that protections against software piracy that assist in the enforcement of licensing agreements lack utility. Novelty: As I mentioned in my earlier post, Peter Biddle, Product Unit Manager for Palladium, very publicly and unambiguously stated during Wednesday's panel at the USENIX Security conference that the Palladium team, despite having been asked by Microsoft's anti-piracy groups for methods by which Palladium could assist in the fight against software piracy, knows of no way in which Palladium can be utilized to assist this end. Peter after the panel asked Brian LaMacchia, a well-known security expert with Microsoft, who was present but not on the panel, if he knew of a way to utilize Palladium to assist in the enforcement of software licenses. Brian did not respond with a solution. (At that time I briefly mentioned to both one of the methods in which I believe Palladium can be used to assist in the fight against software piracy). Peter, who obviously would have been aware of all such methods were they known to the Palladium team, struck me as a forthcoming guy. While I will readily admit that the impression I gained of the person over the two hours I interacted with Peter may carry little weight with those that consider the words Microsoft and honesty to be mutually exclusive, I would like to point out the following: If Microsoft, after so publicly denying any knowledge of ways to use Palladium to assist in the enforcement of application software licenses to an audience representing a veritable who's who of computer security and related public policy (the attendees ranged from Whit Diffie to Pam Samuelson), were to - after my filing for a patent - suddenly assert prior art, neither the attendees, nor the press, nor the public would take kindly to having been so deliberately misled by Microsoft. The likely result would be that Palladium will lose what limited support the initiative may have at this time. I suspect that even somebody that may have a low opinion of Microsoft will agree that Microsoft is not as stupid as to play such a dangerous and losing game. I was asked the next day at USENIX if Microsoft could not simply claim prior art when in fact they had none at the time my invention was made. I would like to reiterate my points made above and add that such claims would need to be filed under oath. Whatever one's opinion of Microsoft may be, I doubt that the salaries paid in Redmond are sufficiently large to goad a mid-level employee into committing perjury. Lastly, it does not matter for the above analysis if any supposed prior art were to be claimed to be created by Microsoft or third parties. It is simply inconceivable that the scientific members of the Palladium team would have been unaware of any such prior art given the their many years on the project and the thorough research they engaged in as evidenced by the lengthy DRM OS patent. If prior art existed, the Palladium team would unquestionably have known about it and thus been able to tell their anti-piracy group and the attendees at USENIX about methods to utilize Palladium as a tool in the fight against software piracy. Since they did not, the reasonable conclusion is that no such prior art exists. Obviousness: In the interest of brevity, I will simply state that if the Palladium team has not thought of such methods in the years they worked the project every day, the methods mentioned in my patent application cannot conceivably be considered obvious. In summary, at this time I am not aware of any grounds on which Microsoft could challenge my patent once/if it will be issued. I therefore currently do not anticipate that Microsoft will challenge the patent. Lastly, I feel obliged to mention that it is quite irrelevant what I, Microsoft, or the subscribers to this list believe to be the case with respect to my patent application. All that matters is what the patent examiner at the USPTO believes. Unless one of the subscribers to this list happens to work as a patent examiner. --Lucky Green --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

2 1

Re: *Buddy* *Lists*!!~ (it's soooo cool)!!~
by OoAmBiGuOuSQToO＠msn.com 13 Aug '02

13 Aug '02

Below is the result of your feedback form. It was submitted by (OoAmBiGuOuSQToO(a)msn.com) on Tuesday, August 13, 2002 at 05:59:32 --------------------------------------------------------------------------- message: Hey!! What's Up? I'm *Monica* 20/F/Arizona/Webcam & Pics. I'm *LIVE* on my *FREE* Webcam mostly 24/7 so if you wanna come in and chat or see a couple of my pics on my website please go to my Personal Homepage at http://www.freelivewebcamchicks.net and hopefully i'll talk to you in a bit hun! If you join and the webchat is already full im sorry, just wait like 5 minutes and then you'll be able to see me LIVE!! If you don't have a webcam of your own its okay!! You can still watch and chat with me then!! *Remember* this is my Personal Homepage so of course its *FREE*!!! *ByE* <333 Monica <333 ---------------------------------------------------------------------------

1 0

Re: Seth on TCPA at Defcon/Usenix
by AARG! Anonymous 13 Aug '02

13 Aug '02

In discussing how TCPA would help enforce a document revocation list (DRL) Joseph Ashwood contrasted the situation with and without TCPA style hardware, below. I just want to point out that his analysis of the hardware vs software situation says nothing about DRL's specifically; in fact it doesn't even mention them. His analysis actually applies to a wide range of security features, such as the examples given earlier: secure games, improved P2P, distributed computing as Adam Back suggested, DRM of course, etc.. TCPA is a potentially very powerful security enhancement, so it does make sense that it can strengthen all of these things, and DRLs as well. But I don't see that it is fair to therefore link TCPA specifically with DRLs, when there are any number of other security capabilities that are also strengthened by TCPA. Joseph Ashwood wrote: > Actually it does, in order to make it valuable. Without a hardware assist, > the attack works like this: > Hack your software (which is in many ways almost trivial) to reveal it's > private key. > Watch the protocol. > Decrypt protocol > Grab decryption key > use decryption key > problem solved It's not always as easy as you make it sound here. Adam Back wrote Saturday about the interesting history of the giFT project, which reverse-engineered the Kazaa file-sharing protocol. That was a terrific effort that required considerable cryptographic know-how as well as supreme software reverse engineering skills. But then Kazaa changed the protocol, and giFT never managed to become compatible with the new one. I'm not sure whether it was lack of interest or just too difficult, but in any case the project failed (as far as creating an open Kazaa compatible client). It is clear that software hacking is far from "almost trivial" and you can't assume that every software-security feature can and will be broken. Furthermore, even when there is a break, it won't be available to everyone. Ordinary people aren't clued in to the hacker community and don't download all the latest patches and hacks to disable security features in their software. Likewise for business customers. In practice, if Microsoft wanted to implement a global, facist DRL, while some people might be able to patch around it, probably 95%+ of ordinary users would be stuck with it. Therefore a DRL in software would be far from useless, and if there truly was a strong commercial need for such a solution then chances are it would be there today. I might mention BTW that for email there is such a product, disappearingink.com, which works along the lines Seth suggested, I believe. It encrypts email with a centralized key, and when that email needs to be deleted, the key is destroyed. This allows corporations to implement a "document retention policy" (which is of course a euphemism for a document destruction policy) to help reduce their vulnerability to lawsuits and fishing expeditions. I don't recall anyone getting up in arms over the disappearingink.com technology or claiming that it was a threat, in the same way that DRLs and SNRLs are being presented in the context of Palladium. > With hardware assist, trusted software, and a trusted execution environment > it (doesn't) work like this: > Hack you software. > DOH!!!!! the software won't run > revert back to the stored software. > Hack the hardware (extremely difficult). > Virtualize the hardware at a second layer, using the grabbed private key > Hack the software > Watch the protocol. > Decrypt protocol > Grab decryption key > use decryption key > Once the file is released the server revokes all trust in your client, > effectively removing all files from your computer that you have not > decrypted yet > problem solved? only for valuable files First, as far as this last point, you acknowledge that if they can't tell where it came from, your hacked hardware can be an ongoing source of un-DRL'd documents. But watermarking technology so far has been largely a huge failure, so it is likely that someone clueful enough to hack his TPM could also strip away any identifying markings. Second, given that you do hack the hardware, you may not actually need to do that much in terms of protocol hacking. If you can watch the data going to and from the TPM you can extract keys directly, and that may be enough to let you decrypt the "sealed" data. (The TPM does only public key operations; the symmetric crypto is all done by the app. I don't know if Palladium will work that way or not.) Third, if a document is "liberated" via this kind of hack, it can then be distributed everywhere, outside the "secure trust perimeter" enforced by TCPA/Palladium. We are still in a "break once read anywhere" situation with documents, and any attempt to make one disappear is not going to be very successful, even with TCPA in existence. In short, while TCPA could increase the effectiveness of global DRLs, they wouldn't be *that* much more effective. Most users will neither hack their software nor their hardware, so the hardware doesn't make any difference for them. Hackers will be able to liberate documents completely from DRL controls, whether they use hardware or software to do it. The only difference is that there will be fewer hackers, if hardware is used, because it is more difficult. Depending on the rate at which important documents go on DRLs, that may not make any difference at all. > Now about the claim that MS Word would not have this "feature." It almost > certainly would. The reason being that business customers are of particular > interest to MS, since they supply a large portion of the money for Word (and > everything else). Businesses would want to be able to configure their > network in such a way that critical business information couldn't be leaked > to the outside world. Of course this removes the advertising path of > conveniently leaking carefully constructed documents to the world, but for > many companies that is a trivial loss. I agree that providing an option to store documents in restricted form could be a desirable feature for businesses. And having the ability to delete documents on a company-wide basis, a la disappearingink.com, could make sense as well. I don't know that there is a huge market for this capability, or I suspect we'd see it already. But it does make sense as an auxiliary part of a business document product. But to me this points to a localized DRL, part of a document-management library that is used solely for documents within the company. The company would want to control the administration of its documents. I don't see this leading to the kind of centralized, global system which I think opponents of TCPA are attempting to invoke when they talk about it allowing DRLs, and which is the kind of thing I was talking about above.

2 1

RE: Lead Generation
by Lead Generation 12 Aug '02

12 Aug '02

1 0