August 2002 - cypherpunks-legacy

Suggested entry into the TCPA spec
by AARG!Anonymous 05 Aug '02

05 Aug '02

Here is a suggestion for how to appraoch the TCPA spec based on the parts I have found to be relatively good explanations. The spec is available from http://www.trustedcomputing.org/docs/main%20v1_1b.pdf. First read the first few pages up to page 7. This provides an overview and a block diagram, although at this point not all the terms will be familiar. One hint: the "root of trust for measurement" is the set of hardware which has to be working for the boot measurement process to work: the CPU, the TPM, the part of the BIOS that deals with measurements, the motherboard, the secure connections of the chips to the motherboard. If all this stuff is OK then the measurements will be accurate. (Measurements basically are hashes of code and of machine configuration status.) The "root of trust for reporting" is the endorsement key, or more fundamentally the cert on the endorsement key. The cert is issued by the manufacturer, AKA the "TPM Entity" or TPME. That's what makes other people believe your attestations. And the "root of trust for storage" is the storage root key, described in the section on protected storage. There are a few more pages of introduction which aren't too clear, then a long section of data structures which should be skipped until you need to reference them. This brings you to page 97, authorization and ownership. I haven't really studied this part. Probably just read this one page to get an idea of what is involved. I still need to learn more about this. I'd skip on to pages 136-137, on the measurement process and the PCRs which hold the results of the measurement. Then I'd read pages 145-150 on protected storage. This part is pretty well written. It is a reasonably self contained part of the TPM functionality. You just need to know a little bit about the PCRs from the earlier section to understand how data is locked to the specific program which is running. Then I'd read page 261 on the endorsement key, and then 267-269 on how it is used to create a pseudonymous identity. This is the part about communicating with the Privacy CA. BTW an expert told me he has concerns about possible security loopholes in this protocol, but he is communicating with TCPA about them. I think if you just read these selections, about 15 pages, you will have a much better idea of how the spec works. Then you can read some of the specific API descriptions to see more details about the functionality. There is also a glossary at the end which can be helpful for some (but not all) of the terminology. There is another spec, http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100.pdf that describes the specific register and trap binding for implementing the TCPA API on Intel PCs. It is much shorter but it is pretty incomprehensible until you have at least read the basics of the main spec. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

2 1

Re: Other uses of TCPA
by AARG! Anonymous 05 Aug '02

05 Aug '02

Mike Rosing wrote: > :Mike Rosing wrote: > :> Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. > : > :PRIVEK, the TPM's private key, is generated on-chip. It never leaves > :the chip. No one ever learns its value. Given this fact, who would > :you say owns and controls it? > > OK, so why can't any joe hacker create their own PRIVEK? _nobody_ knows > it's value? Then how can anyone know if a chip is "real" or "imitation". > What happens when the motherboard dies again? PRIVEK was copied out of > the chip to some "fob" right? I thought you said the manufacturer put > the keys in at the factory. Maybe I wasn't too clear in my explanation. I assume you know how public key cryptography works. The TPM chip generates an RSA key pair. This key pair is called the Endorsement Key. The private key is called PRIVEK and never leaves the chip. The public key is called PUBEK and although it is "sensitive", it does leave the chip under some circumstances. One of those circumstances is when the chip is manufactured and comes off the line. It is powered up, generates the key pair, and exports PUBEK. At that point the chip manufacturer creates an X.509 certificate that signs PUBEK. It is this cert which proves that the PUBEK is a legitimate Endorsement Key. While the cert is not widely shown (for privacy reasons), it is used in a TCPA protocol, and this is ultimately what makes it impossible for Joe Hacker to create a fake TCPA key. Now, the part about recovering from a dead chip refers to a different key. It's called the "root of trust for storage" key, RTS. This is used for encrypting data on the disk. The PUBEK was used for communicating with third parties to prove that you had a legitimate TPM. So there are two different keys used for two different purposes. Both of them are generated on-chip, and no one ever learns either private key. If your chip dies, you lose the PUBEK but that doesn't matter, nothing is really locked to it. You can just get a new motherboard and start using the new PUBEK from that one's TPM chip. It's the RTS key that is a problem, because if you can't retrieve that, all the data on your disk that was sealed (encrypted) using the TCPA mechanisms could be lost. So they have a system to transfer the RTS key from one machine to another. I've been thinking about writing a few pages summarizing TCPA and how the crypto works, but then I think, why bother? Everyone is already convinced that the system is the spawn of Satan. Nobody cares about the facts. BTW I found a post by Ross Anderson, http://www.chiark.greenend.org.uk/pipermail/ukcrypto/2002-June/019463.html, in which he says that one of the worst claimed feaures from his TCPA FAQ (http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html) censoring objectionable programs/data off people's computers against their will, actually doesn't rely on TCPA at all. In fact he says they could do it with existing Windows OS's just as well. It's such an obviously nasty feature that I can't see them ever actually trying this, but in any case it really doesn't have anything to do with TCPA. Maybe someone could ask Ross why his FAQ blames TCPA for a feature that he admits isn't really related! But no, that would be crazy. Better to believe comfortable falsehoods than to seek the truth.

2 1

Fw:questionnaire
by security 05 Aug '02

05 Aug '02

****************************************************** POZNAMKA: priloha s menom 65535).bat bola odstranena, nakolko sa jedna o potencionalne nebezpecny subor, ktory umoznuje sirenie virusov. ********************************************************

1 0

Re: Other uses of TCPA
by AARG! Anonymous 05 Aug '02

05 Aug '02

Eugen Leitl writes: > On Sat, 3 Aug 2002, AARG! Anonymous wrote: > > > But you won't now say that TCPA is OK, will you? You just learned > > some information which objectively should make you feel less bad about > > it, and yet you either don't feel that way, or you won't admit it. I > > am coming to doubt that people's feelings and beliefs about TCPA are > > based on facts at all. No matter how much I correct negative > > misconceptions about these systems, no one will admit to having any > > more positive feelings about it. > > Whoa there. Hold the horses. You're completely inverting the burden of > proof here. You're *trusting* a preliminary spec fielded by *whom* again? > Were you on the design team? Are you on implementers' team? Have you > reverse engineered the function from tracing the structures on the die? > Will you continue doing this, sampling every batch being shipped? I am judging the proposal on the basis of the spec. I think that is the correct way to do the analysis. Then, you can extend your analysis on the basis of ways you think the spec might change. But surely the spec ought to be a starting point for any judgement. Otherwise there is no factual basis for the analysis. Yet no one here has said that now that they understand the spec better, they don't think TCPA as specified would be as bad as they thought. Some people, like James Donald and Ryan Lackey, have said that they don't think TCPA would be all that bad if it weren't for government, copyright laws, etc. But no one has suggested that my many postings have changed their opinion about TCPA in and of itself. > Consider the source. It is bogged down with enough bad mana to last for > centuries. The Alliance consists of Compaq, Intel, IBM, HP, and Microsoft. (Since then HP has bought Compaq.) Even if you hate Microsoft, you probably don't hate all of these companies, do you? > Consider the motivations. They're certainly not there to > enhance end user's privacy and anonymitity. In fact, one of the design > specs must have been minimizing the latter as long as it not hurts the > prime design incentives. These are all facts you won't find in the specs. I think the spec directly contradicts this claim! If they cared so little about user privacy, why would they use an elaborate system with a Privacy CA to make sure no user-identifiable information leaks onto the net? Surely the simpler approach would be what James Donald suggested, to send out the TPM's public key and let people use that. But it is a per-user identifier and so they went to great lengths to conceal it. Furthermore, if their motivations were so bad, wouldn't it have been better for them for TCPA to work the way most people assume, to only load software which has been signed by some authority? Instead they are careful to let any software load, and to report its status to third parties, so the third parties can make their own judgements about what to trust. Why do you think they did it like this, if they were so determined to minimize the control of the end user? > It boggles my mind I have to explain this, especially to a member of this > particular community. Are you really sure you're not a TCPA troll? Who cares what I am? It's facts that count! I could be Satan Incarnate and it wouldn't matter. I am giving you facts about TCPA based on my personal investment of time to study the system. Tell me this: if you care about this standard, why not get it and learn it yourself? Not one person here has done this! Everyone prefers to believe falsehoods than to learn the truth for themself. Do you think that is a good strategy for survival in a potentially hostile and dangerous world? > If they manage to slip that particular toad into high volume production, > hackers will of course use it, inasmuch possible thwarting the original > intent. But you seem to ask for blanket endorsement based merely on spec, > which is a rather tall order. All I am really asking for is someone to acknowledge that I have provided information to them which makes them see TCPA as less dangerous and damaging than they had thought based on the false information which has been circulating. I don't see how anyone can deny this. The caricature of TCPA that most people believe is very bad. The truth is not so bad. Logically, you *have* to believe that TCPA is not as bad as you thought, when you are provided with the truth. Let me ask you, Eugen: isn't a TCPA which is open, which will run all software, which does not prevent any software from running, better than a TCPA which will only run signed software? I know you are a person who is willing to think for himself and defy the conventional wisdom. Please respond to this message and explain to me how this logic strikes you.

4 6

RE: Challenge to David Wagner on TCPA
by Wall, Kevin 05 Aug '02

05 Aug '02

I'm resending this because I never saw it appear on the cypherpunks(a)lne.com mailing list. Appologies if it has already been through and I just missed it. -kevin wall -----Original Message----- >From: Wall, Kevin Sent: Friday, August 02, 2002 1:27 AM To: 'ericm(a)lne.com '; 'cypherpunks(a)lne.com '; 'cryptography(a)wasabisystems.com '; 'ptrei(a)rsasecurity.com' Subject: RE: Challenge to David Wagner on TCPA Mr AARG! writes... > Eric Murray writes: > > Yes, the spec says that it can be turned off. At that point you > > can run anything that doesn't need any of the protected data or > > other TCPA services. But, why would a software vendor that wants > > the protection that TCPA provides allow his software to run > > without TCPA as well, abandoning those protections? > > That's true; in fact if you ran it earlier under TCPA and sealed some > data, you will have to run under TCPA to unseal it later. The question > is whether the advantages of running under TCPA (potentially greater > security) outweigh the disadvantages (greater potential for loss of > data, less flexibility, etc.). and in another reply to Peter Trei, Mr. AARG! also writes... > Now, there is an optional function which does use the manufacturer's key, > but it is intended only to be used rarely. That is for when you need to > transfer your sealed data from one machine to another (either because you > have bought a new machine, or because your old one crashed). In this > case you go through a complicated procedure that includes encrypting > some data to the TPME key (the TPM manufacturer's key) and sending it > to the manufacturer, who massages the data such that it can be loaded > into the new machine's TPM chip. > > So this function does require pre-loading a manufacturer key into the > TPM, but first, it is optional, and second, it frankly appears to be so > cumbersome that it is questionable whether manufacturers will want to > get involved with it. OTOH it is apparently the only way to recover > if your system crashes. This may indicate that TCPA is not feasible, > because there is too much risk of losing locked data on a machine crash, > and the recovery procedure is too cumbersome. That would be a valid > basis on which to criticize TCPA, but it doesn't change the fact that > many of the other claims which have been made about it are not correct. Correct me if I'm wrong (I'm sure you all will :), but wouldn't you also have to possibly go through this exercise with the TPME key and sending your system to the manufacturer when you wanted to, say, upgrade your operating system or switch to a completely different OS? That will go over like a lead balloon. (Gee... must be getting late. I almost wrote "like a bag of dirt". Duh! Can't even remember cliches at my age.) -kevin wall P.S.- Please excuse the sh*t formating. We use Lookout! and MS Exstrange where I work. --- Kevin W. Wall Qwest Information Technology, Inc. Kevin.Wall(a)qwest.com Phone: 614.932.5542 "Wipe Info uses hexadecimal values to wipe files. This provides more security than wiping with decimal values." -- Norton System Works 2002 manual, pg 160

1 0

Personal Mind Control Devices
by Wilfred L. Guerin 05 Aug '02

05 Aug '02

Looks like these could be the gateway to personalized mind control devices... http://www.voodoomachine.com/?wid=1048&bid=0 We all know about the various pattern components of neural cognition, however, to have a personal device with such capabilities could not only serve the psychostimulative purposes as suggested, but also prove as a gateway accessor to lower-level cognition modifiers... http://www.voodoomachine.com/?wid=1048&bid=0 <a href="http://www.voodoomachine.com/?wid=1048&bid=0">VoodooMachine</a> Impressions? -Wilfred L. Guerin Wilfred(a)Cryogen.com AIM/MSN/YP: "WilfredGuerin" (New Orleans)

1 0

Magic Money
by Sebastian Horzela 05 Aug '02

05 Aug '02

Hi all, just a question: where can I get a copy of Magic Money? Have tried a while googling around and never found something that points me to a file and it doens't appear anymore on csn.org. Okay, thanks ;) Bye, jules

1 0

Dewine needs spilling,chuck shumer off dabridge.
by Matthew X 05 Aug '02

05 Aug '02

"The Ohio Republican, a former county prosecutor" Why am I not surprised? http://www.politechbot.com/p-03847.html Jim bell quoting anarchist contest mention on sept 11.No admissions,no evidence,no plea bargains,just another cascading APster extravaganza.Who wants to participate to help form what will be the LAST revolution on earth, the one that'll take down ALL the governments? James Dalton Bell.

1 0

RE: Challenge to David Wagner on TCPA
by Trei, Peter 05 Aug '02

05 Aug '02

> Jon Callas[SMTP:jon@callas.org] > > > On 8/1/02 1:14 PM, "Trei, Peter" <ptrei(a)rsasecurity.com> wrote: > > > So my question is: What is your reason for shielding your identity? > > You do so at the cost of people assuming the worst about your > > motives. > > Is this a tacit way to suggest that the only people who need anonymity or > pseudonymity are those with something to hide? > > Jon > Not really. However, in todays actual environment, this is frequently true that those with something to hide use anonymity. While some people have maintained nyms for many years (I can't think of anyone maintaining explicit stong anonymity right now, actually - remember Sue D. Nym? ), and used them to talk about a variety of issues, it's pretty rare. It's rare enough that when a new anononym appears, we know that the poster made a considered decision to be anonymous. The current poster seems to have parachuted in from nowhere, to argue a specific position on a single topic. It's therefore reasonable to infer that the nature of that position and topic has some bearing on the decision to be anonymous. Since the position argued involves nothing which would invoke the malign interest of government powers or corporate legal departments, it's not that. I can only think of two reasons why our corrospondent may have decided to go undercover... 1. If we know who he/she/them were, it would weaken the argument (for example, by making it clear that the poster has a vested interest in the position maintained, or that 'AARGH! is the group effort of an astroturf campaign). 2. If the true identity of the poster became known, he/she/them fears some kind of retribution: * The ostracism and detestation of his peers. * The boycotting of his employer. * His employer objecting to his wasting company time on Internet mailing lists. Our corrospondent has not given us any reason not to infer the worst motives. This is, after all, a discipline where paranoia and suspicion are job requirements. Peter Trei Disclaimer: The above represents my private , personal opinions only; do not misconstrue them to represent the opinions of others. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

4 3

The Klez excuse
by Matthew X 05 Aug '02

05 Aug '02

Working as a telephone tech support person for a non-tech sector company, Klez was particularly annoying as we would get angry telephone calls from our own corporate executives about how our server based antivirus program wasn't working, as they were getting angry emails from people at other companies telling them to stop sending them the Klez virus. All because the damn thing sent false header information and someone outside both companies had been infected, people would continue to blame the wrong parties when their own antivirus program would point them at the wrong culprit, despite all the media stories explaining the damn thing in clear detail. We had a number of execs refuse to believe us when we told them their machine was clean, as "obviously" we were wrong according to the people at the other company. Even had one high up try to install her own antivirus program because she didn't trust ours and ended up trashing her computer. Did I tell you my new trial 'contest mention' is on sept 11.Anniversary of Chile coup.

1 0