Re: dangers of TCPA/palladium
Adam Shostack [EMAIL PROTECTED] wrote: On Mon, Aug 12, 2002 at 12:38:42AM -0700, Brian A. LaMacchia wrote: There are two parts to answering the first question: 1) People (many people, the more the merrier) need to understand the code and what it does, and thus be in a position to be able to make an informed decision about whether or not they trust it. 2) People reviewing the code, finding security flaws, and then reporting them so that we can fix them These are two very different things. I don't think that anyone should count on the goodwill of the general populace to make their code proveably secure. I think that paying people who are experts at securing code to find exploits in it must be part of the development process. How are these different? If I'm understanding the code to decide if I trust it (item 1), it seems to me that I must do at least 2A and 2B: 2C is optional :) Or are you saying that (2) is done by internal folks, and thus is a smaller set than (1)? Yeah, I wasn't very clear here, was I? What I was trying to say was that there's a difference between understanding how a system behaves technically (and deciding whether that behavior is correct from a technical perspective) and understanding how a system behaves from a policy perspective (e.g. social process impact). Those are two completely different questions. 2) is all about verifying that Palladium hardware and software components technically operates as it is spec'd to. 1) is about the larger issue of how Palladium systems interact with service providers (CAs, TTPs), what processes one goes through to secure PII, etc. The two groups of people looking at 1) and 2) have non-zero intersection but are not equal. And, just to be clear, 2) is *not* done only by internal folks, but I expect that the size of the set of people competent to do 2) is significantly smaller than the size of the set of people who need to think about 1). :-) --bal - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
MS White Paper Says Palladium not DRM
http://www.theregister.co.uk/content/4/26231.html MS white paper says Palladium open, clean, not DRM By John Lettice Posted: 17/07/2002 at 09:25 GMT A final draft of Microsoft's Palladium consultation white paper appears to have escaped, and is currently being hosted by Neowin.net. Microsoft intends to open Palladium up for discussion, but it's not as yet clear to us whether this means it will be distributing the white paper to all and sundry, or whether it envisages a more restricted distribution list. In any event we haven't been able to nail down anywhere on the Microsoft site you can get it,* or any mention of the Microsoft Content Security Business Unit, which authored it. There's much in the paper that's interesting, and it's even interesting that it's in PDF format, rather than Word - the authors are clearly having a bash at being ecumenical. Palladium, it stresses, is not an operating system, but a collection of trusted subsystems and components that are opt-in. You will not get the advantages of Palladium if you don't opt in, of course, but you don't have to. It's als some years off, but one of the objectives is to make a Windows-based device a trustworthy environment for any data. Which is a tall order. Software will have to be rewritten or specially developed to take advantage of Palladium, and software of this class is referred to as a Trusted Agent. Users will be able to separate their data into realms, which are analogous to vaults and can have varying access and security criteria. The system does not need to know who you are, indeed doesn't really want to know who you are, because it's about verifying the identity of machines. So a company could identify an employee's home machine for secure operation remotely on the corporate network. Then it gets really interesting. Palladium will not require Digital Rights Management (DRM) technology, and DRM will not require Palladium... They are separate technologies. Now, we know they don't need to be separate technologies, we know that Palladium could enhance DRM considerably, and we suspect that at least some people at Microsoft would take this route if they thought they could get away with it. But the authors here seem to have concluded that Palladium will not fly if it has a whiff of DRM about it, and are determined to distance themselves. This is good, people, if we all keep shouting 'DRM bad!' they stand a chance of not having their minds changed for them. Deeper into the Department of Bizarre Revolutions we have: A Palladium system will be open at all levels. The hardware will run any TOR (Trusted Operating Root), the TOR will run trusted agents from any publisher, will work with any trusted service provider, (the authors envisage this as a new service category) and it'll all be independently verified. TOR source code will be published, Palladium will be regularly examined by a credible security auditor and anyone can certify Palladium hardware or software, and we expect that many companies and organizations will offer this service. Of course, right now these are only words, the terms and conditions for publication, verification and auditing haven't been revealed, and Microsoft has a long and inglorious record in Untrustworthy Industry Leadership to overcome before we entirely buy the Trustworthy Computing pitch. However, as far as it goes, this little lot sounds plausible. If it were any other company, you might even be inclined to take it at face value. Keep talking, people, and prove you mean it. ® * We have, bizarrely, found an entirely unconnected Palladium white paper on an entirely different Palladium from Templar Corporation. You're probably not interested (we're not), but it's here. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Overcoming the potential downside of TCPA
Joseph Ashwood wrote: Lately on both of these lists there has been quite some discussion about TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :) However there is something that is very much worth noting, at least about TCPA. There is nothing stopping a virtualized version being created. There is nothing that stops say VMWare from synthesizing a system view that includes a virtual TCPA component. This makes it possible to (if desired) remove all cryptographic protection. Of course such a software would need to be sold as a development tool but we all know what would happen. Tools like VMWare have been developed by others, and as I recall didn't take all that long to do. As such they can be anonymously distributed, and can almost certainly be stored entirely on a boot CD, using the floppy drive to store the keys (although floppy drives are no longer a cool thing to have in a system), boot from the CD, it runs a small kernel that virtualizes and allows debugging of the TPM/TSS which allows the viewing, copying and replacement of private keys on demand. Of course this is likely to quickly become illegal, or may already, but that doesn't stop the possibility of creating such a system. For details on how to create this virtualized TCPA please refer to the TCPA spec. What prevents this from being useful is the lack of an appropriate certificate for the private key in the TPM. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Overcoming the potential downside of TCPA
At 10:58 PM 8/13/2002 -0700, Joseph Ashwood wrote: Lately on both of these lists there has been quite some discussion about TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :) However there is something that is very much worth noting, at least about TCPA. There is nothing stopping a virtualized version being created. The only thing to stop that is the certificate on the TCPA's built-in key. You would have to shave one TCPA chip and use its key in the virtualized version. If you distributed that shaved key publicly or just to too many people, then its compromise would likely be detected and its power to attest to S/W configuration would be revoked. However, if you kept the key yourself and used it only at the same frequency you normally would (for the normal set of actions), then the compromise could not be detected and you should be able to run virtualized very happily. That's one of the main problems with TCPA, IMHO, as a security mechanism: that its security depends on hardware tamper resistance -- but at the same time, the TPM needs to be a cheap part, so it can't be very tamper resistant. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://world.std.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Overcoming the potential downside of TCPA
On Tue, 13 Aug 2002, Joseph Ashwood wrote: However there is something that is very much worth noting, at least about TCPA. There is nothing stopping a virtualized version being created. There is nothing that stops say VMWare from synthesizing a system view that includes a virtual TCPA component. This makes it possible to (if desired) remove all cryptographic protection. ... The problem with this idea is that TCPA is useless. For all the *useful* things you are thinking of, you need TCPA plus an approved key. The only way you are going to get an approved key is inside a tamper-resistant chunk of hardware. If you should manage to extract the key, then yes, you'll be able to create that CD. But the idea is that you, the hardware owner, are not authorized to extract the information contained in your own hardware. I find the idea of owning something without having the legal right to open it up and look inside legally dubious at best, but I'm no lawyer The idea is that you shouldn't get anywhere without hardware hacking. The people doing this have decided hardware hacks are acceptable risks because they only want to protect cheap data -- movies, songs, commercial software, whatever. They are sticking to stuff that's not expensive enough to justify hardware hacks. However, if this infrastructure does in fact become trusted and somebody tries to use it to protect more valuable data, God help them. They'll get their asses handed to them on a platter. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
TCPA/Palladium user interst vs third party interest (Re: responding to claims about TCPA)
The remote attesation is the feature which is in the interests of third parties. I think if this feature were removed the worst of the issues the complaints are around would go away because the remaining features would be under the control of the user, and there would be no way for third parties to discriminate against users who did not use them, or configured them in given ways. The remaining features of note being sealing, and integrity metric based security boot-strapping. However the remote attestation is clearly the feature that TCPA, and Microsoft place most value on (it being the main feature allowing DRM, and allowing remote influence and control to be exerted on users configuration and software choices). So the remote attesation feature is useful for _servers_ that want to convince clients of their trust-worthiness (that they won't look at content, tamper with the algorithm, or anonymity or privacy properties etc). So you could imagine that feature being a part of server machines, but not part of client machines -- there already exists some distinctions between client and server platforms -- for example high end Intel chips with larger cache etc intended for server market by their pricing. You could imagine the TCPA/Palladium support being available at extra cost for this market. But the remaining problem is that the remote attesation is kind of dual-use (of utility to both user desktop machines and servers). This is because with peer-to-peer applications, user desktop machines are also servers. So the issue has become entangled. It would be useful for individual liberties for remote-attestation features to be widely deployed on desktop class machines to build peer-to-peer systems and anonymity and privacy enhancing systems. However the remote-attestation feature is also against the users interests because it's wide-spread deployment is the main DRM enabling feature and general tool for remote control descrimination against user software and configuration choices. I don't see any way to have the benefits without the negatives, unless anyone has any bright ideas. The remaining questions are: - do the negatives out-weigh the positives (lose ability to reverse-engineer and virtualize applications, and trade software-hacking based BORA for hardware-hacking based ROCA); - are there ways to make remote-attestation not useful for DRM, eg. limited deployment, other; - would the user-positive aspects of remote-attestation still be largely available with only limited-deployment -- eg could interesting peer-to-peer and privacy systems be built with a mixture of remote-attestation able and non-remote-attestation able nodes. Adam -- http://www.cypherspace.org/adam/ On Sat, Aug 10, 2002 at 04:02:36AM -0700, John Gilmore wrote: One of the things I told them years ago was that they should draw clean lines between things that are designed to protect YOU, the computer owner, from third parties; versus things that are designed to protect THIRD PARTIES from you, the computer owner. This is so consumers can accept the first category and reject the second, which, if well-informed, they will do. If it's all a mishmash, then consumers will have to reject all of it, and Intel can't even improve the security of their machines FOR THE OWNER, because of their history of security projects that work against the buyer's interest, such as the Pentium serial number and HDCP. [...] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: MS recruits for Palladium microkernel and/or DRM platform
-- On 14 Aug 2002 at 9:31, Seth Johns Some voices within the company (and we currently believe these voices to be right and sensible) hold the view that Palladium has to be about users' security if it's to stand any chance of winning hearts and minds, and that associating it with protecting the music business' IP will be the kiss of death. So they'll probably not be best pleased by the Microsoft job ad that seeks a group program manager interested in being part of Microsoft's effort to build the Digital Rights Management (DRM) and trusted platforms of the future (Palladium). I am entertained, but unsurprised, that those who would sell us trust technology start out by lying to us. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG yskEcGKmAuiCv/g0O+62LwywX9uJukk5ZLrVsrC6 2ZU13khZebdH4MNBSUqlk9RvmNnSMpBBwGK/aor7q - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Overcoming the potential downside of TCPA
- Original Message - From: Ben Laurie [EMAIL PROTECTED] Joseph Ashwood wrote: There is nothing stopping a virtualized version being created. What prevents this from being useful is the lack of an appropriate certificate for the private key in the TPM. Actually that does nothing to stop it. Because of the construction of TCPA, the private keys are registered _after_ the owner receives the computer, this is the window of opportunity against that as well. The worst case for cost of this is to purchase an additional motherboard (IIRC Fry's has them as low as $50), giving the ability to present a purchase. The virtual-private key is then created, and registered using the credentials borrowed from the second motherboard. Since TCPA doesn't allow for direct remote queries against the hardware, the virtual system will actually have first shot at the incoming data. That's the worst case. The expected case; you pay a small registration fee claiming that you accidentally wiped your TCPA. The best case, you claim you accidentally wiped your TCPA, they charge you nothing to remove the record of your old TCPA, and replace it with your new (virtualized) TCPA. So at worst this will cost $50. Once you've got a virtual setup, that virtual setup (with all its associated purchased rights) can be replicated across an unlimited number of computers. The important part for this, is that TCPA has no key until it has an owner, and the owner can wipe the TCPA at any time. From what I can tell this was designed for resale of components, but is perfectly suitable as a point of attack. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
