Re: Palladium: technical limits and implications

2002-08-12 Thread Ben Laurie
AARG!Anonymous wrote: Adam Back writes: I have one gap in the picture: In a previous message in this Peter Biddle said: In Palladium, SW can actually know that it is running on a given platform and not being lied to by software. [...] (Pd can always be lied to by HW - we move the problem

Washington DC evacuation plan... for federal employees

2002-08-12 Thread Declan McCullagh
1. Government creates new Washington evacuation plan By Jason Peckenpaugh The federal government has created a new procedure for evacuating federal employees in Washington in the case of possible terrorist attacks on the nation's capital. The protocol, which took effect in May, tells who can

Re: On the outright laughability of internet democracy

2002-08-12 Thread R. A. Hettinga
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 4:20 PM +0200 on 8/12/02, Nomen Nescio wrote, in excruciating, hilarious and even elegant detail: ...all about how I was trolled. :-). Good fish. Thank you for playing. LOL... You're welcome. Guilty as charged. I admit to being absolutely

Re: dangers of TCPA/palladium

2002-08-12 Thread Ben Laurie
David Wagner wrote: Ben Laurie wrote: Mike Rosing wrote: The purpose of TCPA as spec'ed is to remove my control and make the platform trusted to one entity. That entity has the master key to the TPM. Now, if the spec says I can install my own key into the TPM, then yes, it is a very useful

Re: Challenge to David Wagner on TCPA

2002-08-12 Thread Brian A. LaMacchia
I just want to point out that, as far as Palladium is concerned, we really don't care how the keys got onto the machine. Certain *applications* written on top of Palladium will probably care, but all the hardware the security kernel really care about is making sure that secrets are only divulged

Re: Palladium: technical limits and implications

2002-08-12 Thread Adam Back
On Mon, Aug 12, 2002 at 01:52:39PM +0100, Ben Laurie wrote: AARG!Anonymous wrote: [...] What Palladium can do, though, is arrange that the app can't get at previously sealed data if the OS has meddled with it. The sealing is done by hardware based on the app's hash. So if the OS has

Re: responding to claims about TCPA

2002-08-12 Thread AARG! Anonymous
David Wagner wrote: To respond to your remark about bias: No, bringing up Document Revocation Lists has nothing to do with bias. It is only right to seek to understand the risks in advance. I don't understand why you seem to insinuate that bringing up the topic of Document Revocation Lists

Re: Palladium: technical limits and implications

2002-08-12 Thread AARG! Anonymous
Adam Back writes: +---++ | trusted-agent | user mode | |space | app space | |(code ++ | compartment) | supervisor | | | mode / OS | +---++ | ring -1 / TOR |

Re: Palladium: technical limits and implications

2002-08-12 Thread Adam Back
Peter Biddle, Brian LaMacchia or other Microsoft employees could short-cut this guessing game at any point by coughing up some details. Feel free guys... enciphering minds want to know how it works. (Tim Dierks: read the earlier posts about ring -1 to find the answer to your question about

Re: Thanks, Lucky, for helping to kill gnutella

2002-08-12 Thread Sunder
Ok Mr. Smarty Pants Aarg! Anonymous remailer user, you come up with such a method. Cypherpunsk write code, yes? So write some code. Meanwhile, this is why it can't be done: If you have a client that sends a signature of it's binary back to it's mommy, you can also have a rogue client that

Re: dangers of TCPA/palladium

2002-08-12 Thread AARG! Anonymous
Mike Rosing wrote: The difference is fundamental: I can change every bit of flash in my BIOS. I can not change *anything* in the TPM. *I* control my BIOS. IF, and only IF, I can control the TPM will I trust it to extend my trust to others. The purpose of TCPA as spec'ed is to remove my

trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-12 Thread Adam Back
I think you are making incorrect presumptions about how you would use Palladium hardware to implement a secure DRM system. If used as you suggest it would indeed suffer the vulnerabilities you describe. The difference between an insecure DRM application such as you describe and a secure DRM

Re: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-12 Thread Adam Back
At this point we largely agree, security is improved, but the limit remains assuring security of over-complex software. To sum up: The limit of what is securely buildable now becomes what is securely auditable. Before, without the Palladium the limit was the security of the OS, so this makes a

Re: Seth on TCPA at Defcon/Usenix

2002-08-12 Thread Mike Rosing
On Mon, 12 Aug 2002, AARG! Anonymous wrote: 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. Anyone doing security had better assume software can and will be broken. That's where you *start*.

Re: CDR: Re: Seth on TCPA at Defcon/Usenix

2002-08-12 Thread Jamie Lawrence
On Mon, 12 Aug 2002, AARG! Anonymous wrote: 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