Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
On Thu, 15 Aug 2002, Joseph Ashwood wrote: > This is going to be a very long, and very boring message. But it should > highlight why we have differing opinions about so very many capabilities of > the TCPA system. For the sake of attempting to avoid supplying too little > information, I have simply searched for the term and will make comments on > each location that it appears. I actually read the whole thing. Thanks for the effort. I just want to focus in on one part for now. > Page 183, hints that even the manufacturer is not allowed to known EK public > key, which complicates things no end, because the Privacy CA certainly > cannot at that point be permitted to view it. This would indicate that even > if the EK is shipped with the system, it can never leave the system. This > would limit the ability of the EK to simply certifying the owner, if that is > true then it confuses me even further. Then how can the manufacturer sign the endorsement key? That can't make any sense - is a misprint maybe and they mean the private key? > Page 240, states "This is a dead TPM. It has failed it's startup smoke test. > It should not leave the factory floor." This indicates that the EK must be > created before the TPM leaves the factory. What's the context of the "smoke test"? > Section 9.2, page 261, states that TPM_CreateEndorsementKeyPair can only be > called once, but does not state if this is done by the owner, or by the > plant. Later on the page is a hint that it may be shipped with it. "The > PRIVEK and PUBEK MAY be created by a process other than the use of > TPM_CreateEndorsementKeyPair" and related statements, which indicate rather > well that the endorsement key created before shipping. It also states that > the credential could be stored after "an Owner has taken ownership of the > platform," confusing the matter even more. Of course at the end of this > section they change the mandatory return value for > TPM_CreateEndorsementKeyPair (beginning TCPA_FAIL, end TCPA_DISABLED_CMD). So the spec allows for a one time write option - the manufacturer MAY build a list of keys. But they don't have to. > Result: I have no idea whatsoever about where/when the EK is created, there > are a number of conflicting statements regarding it, and at least once where > they even change the return value of a function. Yeah, that makes discussion difficult. Obviously the spec is flawed!! > > The creation and certification process is 1) create > > endorsement key pair, > > > 2) export public key endorsement key, > > Only to the owner, the manufacturer is not supposed to have a copy Then anyone can create a TPM? What does the manufacturer know about the thing it created? If they know the endorsement key (since they put it in) they can compute the public key. If they don't know either key, then anyone can create TPM's and get them certified!! I guess I can't argue with that :-) > > 3) > > hardware manufacturer signs endorsement public key to create an > > endorsement certificate (to certify that that endorsement public key > > belongs to this TPM), 4) the certificate is stored in the TPM (for > > later use in communications with the privacy CA.) > > The privacy CA never recieves a copy of the PUBEK, the PUBEK is only to be > seen by the owner. If the manufacturer signs the endorsement pubkey, how can they not see it? I think there must be a lot of confusion in the spec about which key does what and where it is used. That's a different kind of flaw, but clearly the spec has a lot of problems. Keep hacking at it guys. Maybe the authors will re-write it so it makes sense (or give up and toss the whole thing in the trash). Patience, persistence, truth, Dr. mike
Schneier on Palladium and the TCPA (was Re: CRYPTO-GRAM, August 15, 2002)
At 3:53 PM -0500 on 8/15/02, Bruce Schneier wrote:
> Palladium and the TCPA
>
>
>
> There's been more written about Microsoft's Palladium security initiative
> than about anything else in computer security in a very long time. My URL
> list of comments, analysis, and opinions goes on for quite a while. Which
> is interesting, because we really don't know anything about the details of
> what it is or how it works. Much of this is based on reading between the
> lines in the various news reports, conversations I've had with Microsoft
> people (none of them under NDA), and conversations with people who've had
> conversations. But since I don't know anything for sure, all of this could
> be wrong.
>
> Palladium (like chemists, Microsoft calls it "Pd" for short) is Microsoft's
> implementation of the TCPA spec, sort of. ("Sort of" depends on who you
> ask. Some say it's related. Some say they do similar things, but are
> unrelated. Some say that Pd is, in fact, Microsoft's attempt to preempt
> the TCPA spec.) TCPA is the Trusted Computing Platform Alliance, an
> organization with just under 200 corporate members (an impressive list,
> actually) trying to build a trusted computer. The TCPA 1.1 spec has been
> published, and you can obtain the 1.2 spec under NDA. Pd doesn't follow
> the spec exactly, but it's along those lines, sort of.
>
> Pd has been in development for a long time, since at least 1997. The best
> technical description is the summary of a meeting with Microsoft engineers
> by Seth Schoen of the EFF (URL below). I'm not going to discuss the
> details, because systems with an initial version of Pd aren't going to ship
> until 2004 -- at least -- andthe details are all likely to change.
>
> Basically, Pd is Microsoft's attempt to build a trusted computer, much as I
> discussed the concept in "Secrets and Lies" (pages 127-130); read it for
> background). The idea is that different users on the system have
> limitations on their abilities, and are walled off from each other. This
> is impossible to achieve using only software; and Pd is a combination
> hardware/software system. In fact, Pd affects the CPU, the chip set on the
> motherboard, the input devices (keyboard, mouse, etc.), and the video
> output devices (graphics processor, etc.). Additionally, a new chip is
> required: a tamper-resistant secure processor.
>
> Microsoft readily acknowledges that Pd will not be secure against hardware
> attacks. They spend some effort making the secure processor annoying to
> pry secrets out of, but not a whole lot of effort. They assume that the
> tamper-resistance will be defeated. It is their intention to design the
> system so that hardware attacks do not result in class breaks: that
> breaking one machine doesn't help you break any others.
>
> Pd provides protection against two broad classes of attacks. Automatic
> software attacks (viruses, Trojans, network-mounted exploits) are contained
> because an exploited flaw in one part of the system can't affect the rest
> of the system. And local software-based attacks (e.g., using debuggers to
> pry things open) are protected because of the separation between parts of
> the system.
>
> There are security features that tie programs and data to CPU and to user,
> and encrypt them for privacy. This is probably necessary to make Pd work,
> but has a side-effect that I'm sure Microsoft is thrilled with. Like books
> and furniture and clothing, the person who currently buys new software can
> resell it when he's done with it. People have a right to do this -- it's
> called the "First Sale Doctrine" in the United States -- but the software
> industry has long claimed that software is not sold, but licensed, and
> cannot be transferred. When someone sells a Pd-equipped computer, he is
> likely to clear his keys so that his identity can't be used or files can't
> be read. This will also serve to erase all the software he purchased. The
> end result might be that people won't be able to resell software, even if
> they wanted to.
>
> Pd is inexorably tied up with Digital Rights Management. Your computer
> will have several partitions, each of which will be able to read and write
> its own data. There's nothing in Pd that prevents someone else (MPAA,
> Disney, Microsoft, your boss) from setting up a partition on your computer
> and putting stuff there that you can't get at. Microsoft has repeatedly
> said that they are not going to mandate DRM, or try to control DRM systems,
> but clearly Pd was designed with DRM in mind.
>
> There seem to be good privacy controls, over and above what I would have
> expected. And Microsoft has claimed that they will make the core code
> public, so that it can be reviewed and evaluated. It's about time they
> realized that lots of people are willing to do their security work for free.
>
> It's hard to sort out the antitrust implications of Pd. Lots of people
> have written about it. Will
Re: Overcoming the potential downside of TCPA
On Thu, 15 Aug 2002, Anonymous wrote: > [Repost] > > Joe Ashwood writes: > > > 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. > > Actually, this is not true for the endoresement key, PUBEK/PRIVEK, which > is the "main" TPM key, the one which gets certified by the "TPM Entity". > That key is generated only once on a TPM, before ownership, and must > exist before anyone can take ownership. For reference, see section 9.2, > "The first call to TPM_CreateEndorsementKeyPair generates the endorsement > key pair. After a successful completion of TPM_CreateEndorsementKeyPair > all subsequent calls return TCPA_FAIL." Also section 9.2.1 shows that > no ownership proof is necessary for this step, which is because there is > no owner at that time. Then look at section 5.11.1, on taking ownership: > "user must encrypt the values using the PUBEK." So the PUBEK must exist > before anyone can take ownership. > > > 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. > > I don't quite follow what you are proposing here, but by the time you > purchase a board with a TPM chip on it, it will have already generated > its PUBEK and had it certified. So you should not be able to transfer > a credential of this type from one board to another one. < ... /> But I think you claimed "No root key.". Is this not a "root key"? oo--JS.
Re: TCPA not virtualizable during ownership change
-- On 15 Aug 2002 at 15:26, AARG! Anonymous wrote: > Basically I agree with Adam's analysis. At this point I > think he understands the spec equally as well as I do. He > has a good point about the Privacy CA key being another > security weakness that could break the whole system. It > would be good to consider how exactly that problem could be > eliminated using more sophisticated crypto. Lucky claims to have pointed this out two years ago, proposed more sophisticated crypto, and received a hostile reception. Which leads me to suspect that the capability of the powerful to break the system is a designed in feature. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG JjoH8U8qZ1eOdT/yGjfV7Xz9andBZPeYWaOLC+NP 2/OJG2MZSnAqcyuvUsNZTsQAcffGGST6LJ7e9vFbK
employment market for applied cryptographers?
On the employment situation... it seems that a lot of applied cryptographers are currently unemployed (Tim Dierks, Joseph, a few ex-colleagues, and friends who asked if I had any leads, the spate of recent "security consultant" .sigs, plus I heard that a straw poll of attenders at the codecon conference earlier this year showed close to 50% out of work). Are there any more definitive security industry stats? Are applied crypto people suffering higher rates of unemployment than general application programmers? (From my statistically too small sample of acquaintances it might appear so.) If this is so, why is it? - you might think the physical security push following the world political instability worries following Sep 11th would be accompanied by a corresponding information security push -- jittery companies improving their disaster recovery and to a lesser extent info sec plans. - governments are still harping on the info-war hype, national information infrastructure protection, and the US Information Security Czar Clarke making grandiose pronouncements about how industry ought to do various things (that the USG spent the last 10 years doing it's best to frustrate industry from doing with it's dumb export laws) - even Microsoft has decided to make a play of cleaning up it's security act (you'd wonder if this was in fact a cover for Palladium which I think is likely a big play for them in terms of future control points and (anti-)competitive strategy -- as well as obviously a play for the home entertainment system space with DRM) However these reasons are perhaps more than cancelled by: - dot-com bubble (though I saw some news reports earlier that though there is lots of churn in programmers in general, that long term unemployment rates were not that elevated in general) - perhaps security infrastructure and software upgrades are the first things to be canned when cash runs short? - software security related contract employees laid off ahead of full-timers? Certainly contracting seems to be flat in general, and especially in crypto software contracts look few and far between. At least in the UK some security people are employed in that way (not familiar with north america). - PKI seems to have fizzled compared to earlier exaggerated expectations, presumably lots of applied crypto jobs went at PKI companies downsizing. (If you ask me over use of ASN.1 and adoption of broken over complex and ill-defined ITU standards X.500, X.509 delayed deployment schedules by order of magnitude over what was strictly necessary and contributed to interoperability problems and I think significantly to the flop of PKI -- if it's that hard because of the broken tech, people will just do something else.) - custom crypto and security related software development is perhaps weighted towards dot-coms that just crashed. - big one probably: lack of measurability of security -- developers with no to limited crypto know-how are probably doing (and bodging) most of the crypto development that gets done in general, certainly contributing to the crappy state of crypto in software. So probably failure to realise this issue or perhaps just not caring, or lack of financial incentives to care on the part of software developers. Microsoft is really good at this one. The number of times they re-used RC4 keys in different protocols is amazing! Other explanations? Statistics? Sample-of-one stories? Adam -- yes, still employed in sofware security industry; and in addition have been doing crypto consulting since 97 (http://www.cypherspace.net/) if you have any interesting applied crypto projects; reference commissions paid.
Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
I think a number of the apparent conflicts go away if you carefully track endorsement key pair vs endorsement certificate (signature on endorsement key by hw manufacturer). For example where it is said that the endorsement _certificate_ could be inserted after ownership has been established (not the endorsement key), so that apparent conflict goes away. (I originally thought this particular one was a conflict also, until I noticed that.) I see anonymous found the same thing. But anyway this extract from the CC PP makes clear the intention and an ST based on this PP is what a given TPM will be evaluated based on: http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-PP-TPM1_9_4.pdf p 20: | The TSF shall restrict the ability to initialize or modify the TSF | data: Endorsement Key Pair [...] to the TPM manufacturer or designee. (if only they could have managed to say that in the spec). Adam -- http://www.cypherspace.org/adam/
Schneier on Arming Airplane Pilots (was Re: CRYPTO-GRAM, August 15, 2002)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My sister-in-law had a brilliantly simple answer to the problem of hijacking which was, close, but, um, no spliff, :-), to Vin Suprynowicz's notorious "Ganja and Guns Airline" column of a few years back. She said, on September 12 or so last year, "Why don't you have a certification on your concealed-carry permit that allows you to carry on an airplane?" That means, like a hazmat certificate on a commercial driver's license, you've been trained. You know how to shoot on a plane: what kinds of frangible bullets to use, who to shoot at :-), and so on. At check-in time, the firearm owner pulls out her concealed-carry license with the cabin-carry certificate, shows someone the frangible ammo she's using, and is checked through to the gate. I figure if even Tim May thinks armed passengers are a bad idea, :-), and Bruce thinks even arming the *pilots* is a bad idea, I'm certainly leaning into the wind a bit here, but, I think it's a *great* idea, myself. It doesn't matter if someone smuggles a *machine gun* onto the plane, they don't know *who* is on the plane, with a gun, and *qualified* to take them out. Think of it as statistical process control for the rest of us. Or evolution in action. Or geodesic warfare. Cheers, RAH PS: I think we're going to *need* counter-attack scenarios on the net. Like Whit Diffie said, "infowar" will be fought between businesses. Governments are too slow, and not, paradoxically, nearly ubiquitous enough to do the job. All we need is bearer cash, :-), and, someday, machines even can handle it themselves... - - At 3:53 PM -0500 on 8/15/02, Bruce Schneier wrote: > Arming Airplane Pilots > > > > It's a quintessentially American solution: our nation's commercial > aircraft are at risk, so let's allow pilots to carry guns. We > have visions of these brave men and women as the last line of > defense on an aircraft, and courageously defending the cockpit > against terrorists at 30,000 feet. I can just imagine the > made-for-TV movie. > > Reality is more complicated than television, though. Sometimes, > security systems cause more problems than they solve. Putting > guns on aircraft will make us more vulnerable to attack, not less. > > When people think of potential problems with an weapons in a > cockpit, they think of accidental shootings in the air, holes in > the fuselage, and possibly even equipment shattered by a stray > bullet. This is a problem, certainly, but not a major one. A > bullet hole is small, and doesn't let a whole lot of air out. And > airplanes are designed to handle equipment failures -- even > serious failures -- and remain in the air. If I ran an airline, I > would worry more about accidents involving passengers, who are > much less able to survive a bullet wound and much more likely to > sue. > > The real dangers, though, involve the complex systems that must be > put in place before the first gun can ride along in the cockpit. > There are major areas of risk. > > One, we need a system for getting the gun on the airplane. How > does the pilot get the gun? Does he carry it through the airport > and onto the plane? Is it issued to him after he's in the cockpit > but before the plane takes off? Is it secured in the cockpit at > all times, even when there is no one there? Any one of these > solutions has its own set of security vulnerabilities. The last > thing we want is for an attacker to exploit one of these systems > in order to get himself a gun. Or maybe the last thing we want is > a shootout in a crowded airport. > > Second, we need a procedure for storing the gun on the airplane. > Does the pilot carry it on his hip? Is it locked in a cabinet? > If so, who has the key? Is there one gun, or do the pilot and > co-pilot each have > one? However the system works, it's ripe for abuse. If the gun is > always at the pilot's hip, an attacker can take it away from him > when he leaves the cockpit. (Don't laugh; policemen get their > guns taken away from them all the time, and they're trained to > prevent that.) If the guns remain in the cockpit when it is > unoccupied, we have a whole new set of problems to worry about. > > Third, we need a system of training pilots in gun handling and > marksmanship. Guns require training to use well; how much training > can we expect our pilots to have? This is different from training > sky > marshals. Security is the primary job of a sky marshal; they're > expected to learn how to use a gun. Flying planes is the primary > job of a pilot. > > Giving pilots guns is a disaster waiting to happen. The current > system spends a lot of time and effort keeping weapons off > airplanes and out of airports; the proposed scheme would inject > thousands of handguns into that system. There are just too many > pilots and too many flights every day; mistakes will happen. > Someone will do an inventory one nigh
Re: TCPA not virtualizable during ownership change
Basically I agree with Adam's analysis. At this point I think he understands the spec equally as well as I do. He has a good point about the Privacy CA key being another security weakness that could break the whole system. It would be good to consider how exactly that problem could be eliminated using more sophisticated crypto. Keep in mind that there is a need to be able to revoke Endorsement Certificates if it is somehow discovered that a TPM has been cracked or is bogus. I'm not sure that would be possible with straight Chaum blinding or Brands credentials. I would perhaps look at Group Signature schemes; there is one with efficient revocation being presented at Crypto 02. These involve a TTP but he can't forge credentials, just link identity keys to endorsement keys (in TCPA terms). Any system which allows for revocation must have such linkability, right? As for Joe Ashwood's analysis, I think he is getting confused between the endorsement key, endorsement certificate, and endorsement credentials. The first is the key pair created on the TPM. The terms PUBEK and PRIVEK are used to refer to the public and private parts of the endorsement key. The endorsement certificate is an X.509 certificate issued on the endorsement key by the manufacturer. The manufacturer is also called the TPM Entity or TPME. The endorsement credential is the same as the endorsement certificate, but considered as an abstract data structure rather than as a specific embodiment. The PRIVEK never leaves the chip. The PUBEK does, but it is considered sensitive because it is a de facto unique identifier for the system, like the Intel processor serial number which caused such controversy a few years ago. The endorsement certificate holds the PUBEK value (in the SubjectPublicKeyInfo field) and so is equally a de facto unique identifier, hence it is also not too widely shown.
Re: status of various projects?
On Wed, Aug 14, at 10:58AM, Miles Fidelman wrote: | It seems like a lot of interesting projects haven't been active for a | while - notably Free Haven and Eternity Usenet. Where is the most active | work, these days, on distributed publishing systems? I forwarded this to Roger Dingledine who heads up the FreeHaven project. His answer is below. >From [EMAIL PROTECTED] Thu Aug 15 16:46:59 2002 Date: Thu, 15 Aug 2002 16:46:59 -0400 From: Roger Dingledine <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: free haven status At this point, Free Haven has 3 major flaws, and I'm putting it on the back burner while I address them: * The reputation system is tricky and won't work. We need to replace the gossip/credibility system with a mechanism for verifiable transactions. See http://freehaven.net/doc/cfp02/cfp02.html for more details. * Retrieval is currently broadcast, which is insane. I'm letting other projects work on solutions here (eg Chord), and I'll pick my favorite when the time comes. * There is no anonymous communications infrastructure. This is the area we're focusing on currently. See http://mixminion.net/minion-design.pdf and http://pdos.lcs.mit.edu/tarzan/ --Roger
Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
This is going to be a very long, and very boring message. But it should highlight why we have differing opinions about so very many capabilities of the TCPA system. For the sake of attempting to avoid supplying too little information, I have simply searched for the term and will make comments on each location that it appears. - Original Message - From: "Adam Back" <[EMAIL PROTECTED]> > Phew... the document is certainly tortuous, and has a large number of > similarly and confusingly named credentials, certificates and keys, > however from what I can tell this is what is going on: I wholeheartedly agree. 332 pages to say 5 pages worth of real information is not helpful. > > Summary: I think the endorsement key and it's hardware manufacturers > certificate is generated at manufacture and is not allowed to be > changed. [Search criteria "endorsement"] While I haven't found any solid evidence either way, they seem to almost deliberately avoid that discussion on Page 22 I found a fatal errorcode TCPA_NO_ENDORSEMENT at TCPA_BASE+35 "The TPM does not a EK installed" attempting to interpret the bad grammar, I believe this should state "The TPM does not [have] an [Endorsement Key] installed" which seems to indicate that the platform may ship without one. On page 35 the endorsement key is listed as persistent data. Which at first would indicate that the endorsement key happens before shipping, but since there is also an RNG state variable stored persistently, my confidence in this is undermined. Adding to the complications, down near the end of the page, in the table it says "This is the TPM's endorsement key pair. See 9.2. The default value is manufacturer-specific" which indicates that it does ship with an endorsement key, but that the key can be changed by the owner. Page 38, the existance of the CBKPUsed flag hints that the endorsement key pair need not always be present. Unfortunately the spec goes on to say "NOTE: This flag has no default value as the key pair MUST be created by one or the other mechanism." Which certainly confuses things. Page 41 "TPM_CreateEndorsementKey may be called before TPM_Startup. This is necessary because TPM_Startup will fail unless an endorsement key exists" is of no help either way. As with all the others, it states that there may exist conditions where the EK may not exist, but does not give any hints whether this is before or after the TPM leaves the plant. On page 79, the EK is metioned twice. The first time if useless for our purpose. The second time states "This SHALL be the TPM endorsement credential" which indicates that an endorsement credential must exist. Other locations though seem to hint that a void endorsement credential may be possible. Starting on Page 84 is section 4.32.1, which seems to be as close to an authority on the EK as possible, but lacks a statement of whether the EK is shipped with or added later. It does however clearly indicate that the creation of the EK occurs before the Privacy CA is contacted, which was already agreed on. [somewhere around here I stopped addressing everyt occurance of the word "endorsement" because most of them are frivolous] Page 135, Section 5.11.1, clearly states "The new owner MUST encrypt the Owner authorization data and the SRK authorization data using the PUBEK." Which clearly indicates that the EK must exist before ownership can be taken. Other places have hinted that ownership may be taken and then the EK updated, which completely contradicts the one-timeness, or this statement. Page 135 "If no EK is present the TPM MUST return TCPA_NO_ENDORSEMENT" which indicates that one can at least attempt to take ownership before an EK is present, which would contradict the requirement that the EK come from the factory. Page 178, Section 7.3 I am only mentioning because it presents a rather interesting possibility. It hints that under some circumstances it may be acceptable for a manufacturer to copy the data from one TCPA to another. This portion begins with "The manufacturer takes the maintainance blob . . ." This may however only be to update an existing one to address flaws or meet new capabilities. Page 183, hints that even the manufacturer is not allowed to known EK public key, which complicates things no end, because the Privacy CA certainly cannot at that point be permitted to view it. This would indicate that even if the EK is shipped with the system, it can never leave the system. This would limit the ability of the EK to simply certifying the owner, if that is true then it confuses me even further. Page 213 section 8.10 clearly states that if the owner clears the TCPA, everthing is cleared "except the endorsement key pair." Which would indicate that this is truly a one-shot deal. Page 240, states "This is a dead TPM. It has failed it's startup smoke test. It should not leave the factory floor." This indicates that the EK must be created before the TPM leaves the factory. Section 9.2, page 261, state
Re: TCPA hack delay appeal
Well, it's probably safer to publish the hack anonymously and see if it withstands counter-hacking. Could be Microsoft is baiting and waiting for just such attacks. The giant might even leak and spread a few itself in order to shoot them down, to boost its eye-mote credibility. Send the hack to Cryptome anonymously if there's no better way to test its effectiveness. Keeping snakeoil secret is a sure way to uncontested success, aka the way of Redmond.
Trei lies to himself again.
>>a misplaced respect for the whims of The Men with Guns. This is not a Good Thing.<< Sure CJ would agree having been arrested at the point of one. >>A freedom to skulk in the shadows, hoping not to be noticed, is not the legacy I wish to leave behind. Peter Trei << So tell us peter,why did you shop CJ? You have been skulking on that point for months now.I've even written you directly about this.Tell me it was a mistake.
Re: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)
Adam Back writes: > So there are practical limits stemming from realities to do with code > complexity being inversely proportional to auditability and security, > but the extra ring -1, remote attestation, sealing and integrity > metrics really do offer some security advantages over the current > situation. You're wearing your programmer's hat when you say that. But the problem isn't programming, but is instead economic. Switch hats. The changes that you list above may or may not offer some security advantages. Who cares? What really matters is whether they increase the cost of copying. I say that the answer is no, for a very simple reason: breaking into your own computer is a "victimless" crime. In a crime there are at least two parties: the victim and the perpetrator. What makes the so-called victimless crime unique is that the victim is not present for the perpetration of the crime. In such a crime, all of the perpetrators have reason to keep silent about the comission of the crime. So it will be with people breaking into their own TCPA-protected computer and application. Nobody with evidence of the crime is interested in reporting the crime, nor in stopping further crimes. Yes, the TCPA hardware introduces difficulties. If there is way around them in software, then someone need only write it once. The whole TCPA house of cards relies on no card ever falling down. Once it falls down, people have unrestricted access to content. And that means that we go back to today's game, where the contents of CDs are open and available for modification. Someone could distribute a pile of "random" bits, which, when xored with the encrypted copy, becomes an unencrypted copy. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
On Thu, 15 Aug 2002, Adam Back wrote: > Summary: I think the endorsement key and it's hardware manufacturers > certificate is generated at manufacture and is not allowed to be > changed. Changing ownership only means (typically) deleting old > identities and creating new ones. Are there 2 certificates? One from the manufacturer and one from the privacy CA? > - endorsement key generation and certification - There is one > endorsement key per TPM which is created and certified during > manufacture. The creation and certification process is 1) create > endorsement key pair, 2) export public key endorsement key, 3) > hardware manufacturer signs endorsement public key to create an > endorsement certificate (to certify that that endorsement public key > belongs to this TPM), 4) the certificate is stored in the TPM (for > later use in communications with the privacy CA.) So finding the manufacturers signature key breaks the whole system right? Once you have that key you can create as many "fake" TPM's as you want. > TPM can be reset back to a state with no current owner. BUT _at no > point_ does the TPM endorsement private key leave the TPM. The > TPM_CreateEndorsementKeyPair function is allowed to be called once > (during manufacture) and is thereafter disabled. But it's easier to manufacture it by burning fuse links so it can't be read back - ala OTP. so the manufacturer could have a list of every private key (just because they aren't supposed to doesn't prevent it.) It still meets the spec - the key never leaves the chip. > - identity keys - Then there is the concept of identity keys. The > current owner can create and delete identities, which can be anonymous > or pseudonymous. Presumably the owner would delete all identity keys > before giving the TPM to a new owner. The identity public key is > certified by the privacy CA. > > - privacy ca - The privacy CA accepts identity key certification > requests which contain a) identity public key b) a proof of possession > (PoP) of identity private key (signature on challenge), c) the > hardware manufacturers endorsement certificate containing the TPM's > endorsement public key. The privacy CA checks whether the endorsement > certificate is signed by a hardware manufacturer it trusts. The > privacy CA sends in response an identity certificate encrypted with > the TPM's endorsement public key. The TPM decrypts the encrypted > identity certifate with the endorsement private key. How does the CA check the endorsement certificate? If it's by checking the signature, then finding the manufacturer's private key is very worthwhile - the entire TCPA for 100's of millions of computers gets compromised. If it's by matching with the manufacturer's list then anonymity is impossible. Thanks for the analysis Adam. It seems like there are a couple of obvious points to attack this system at. I would think it's easy to break for a large enough government. Patience, persistence, truth, Dr. mike
Re: Overcoming the potential downside of TCPA
Joe Ashwood writes: > 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. Actually, this is not true for the endoresement key, PUBEK/PRIVEK, which is the "main" TPM key, the one which gets certified by the "TPM Entity". That key is generated only once on a TPM, before ownership, and must exist before anyone can take ownership. For reference, see section 9.2, "The first call to TPM_CreateEndorsementKeyPair generates the endorsement key pair. After a successful completion of TPM_CreateEndorsementKeyPair all subsequent calls return TCPA_FAIL." Also section 9.2.1 shows that no ownership proof is necessary for this step, which is because there is no owner at that time. Then look at section 5.11.1, on taking ownership: "user must encrypt the values using the PUBEK." So the PUBEK must exist before anyone can take ownership. > 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. I don't quite follow what you are proposing here, but by the time you purchase a board with a TPM chip on it, it will have already generated its PUBEK and had it certified. So you should not be able to transfer a credential of this type from one board to another one. > 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. Actually I don't see a function that will let the owner wipe the PUBEK. He can wipe the rest of the TPM but that field appears to be set once, retained forever. For example, section 8.10: "Clear is the process of returning the TPM to factory defaults." But a couple of paragraphs later: "All TPM volatile and non-volatile data is set to default value except the endorsement key pair." So I don't think your fraud will work. Users will not wipe their endorsement keys, accidentally or otherwise. If a chip is badly enough damaged that the PUBEK is lost, you will need a hardware replacement, as I read the spec. Keep in mind that I only started learning this stuff a few weeks ago, so I am not an expert, but this is how it looks to me.
Re: Overcoming the potential downside of TCPA
[Repost] Joe Ashwood writes: > 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. Actually, this is not true for the endoresement key, PUBEK/PRIVEK, which is the "main" TPM key, the one which gets certified by the "TPM Entity". That key is generated only once on a TPM, before ownership, and must exist before anyone can take ownership. For reference, see section 9.2, "The first call to TPM_CreateEndorsementKeyPair generates the endorsement key pair. After a successful completion of TPM_CreateEndorsementKeyPair all subsequent calls return TCPA_FAIL." Also section 9.2.1 shows that no ownership proof is necessary for this step, which is because there is no owner at that time. Then look at section 5.11.1, on taking ownership: "user must encrypt the values using the PUBEK." So the PUBEK must exist before anyone can take ownership. > 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. I don't quite follow what you are proposing here, but by the time you purchase a board with a TPM chip on it, it will have already generated its PUBEK and had it certified. So you should not be able to transfer a credential of this type from one board to another one. > 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. Actually I don't see a function that will let the owner wipe the PUBEK. He can wipe the rest of the TPM but that field appears to be set once, retained forever. For example, section 8.10: "Clear is the process of returning the TPM to factory defaults." But a couple of paragraphs later: "All TPM volatile and non-volatile data is set to default value except the endorsement key pair." So I don't think your fraud will work. Users will not wipe their endorsement keys, accidentally or otherwise. If a chip is badly enough damaged that the PUBEK is lost, you will need a hardware replacement, as I read the spec. Keep in mind that I only started learning this stuff a few weeks ago, so I am not an expert, but this is how it looks to me.
TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
Phew... the document is certainly tortuous, and has a large number of similarly and confusingly named credentials, certificates and keys, however from what I can tell this is what is going on: Summary: I think the endorsement key and it's hardware manufacturers certificate is generated at manufacture and is not allowed to be changed. Changing ownership only means (typically) deleting old identities and creating new ones. The longer version... - endorsement key generation and certification - There is one endorsement key per TPM which is created and certified during manufacture. The creation and certification process is 1) create endorsement key pair, 2) export public key endorsement key, 3) hardware manufacturer signs endorsement public key to create an endorsement certificate (to certify that that endorsement public key belongs to this TPM), 4) the certificate is stored in the TPM (for later use in communications with the privacy CA.) - ownership - Then there is the concept of ownership. The spec says the TPM MUST ship with no Owner installed. The owner when he wishes to claim ownership choose a authentication token which is sent into the TPM encrypted with the endorsement key. (They give the example of the authentication token being the hash of a password). Physical presence tests apply to claiming ownership (eg think BIOS POST with no networking enabled, or physical pin on motherboard like BIOS flash enable). The authentication token and ownership can be changed. The TPM can be reset back to a state with no current owner. BUT _at no point_ does the TPM endorsement private key leave the TPM. The TPM_CreateEndorsementKeyPair function is allowed to be called once (during manufacture) and is thereafter disabled. - identity keys - Then there is the concept of identity keys. The current owner can create and delete identities, which can be anonymous or pseudonymous. Presumably the owner would delete all identity keys before giving the TPM to a new owner. The identity public key is certified by the privacy CA. - privacy ca - The privacy CA accepts identity key certification requests which contain a) identity public key b) a proof of possession (PoP) of identity private key (signature on challenge), c) the hardware manufacturers endorsement certificate containing the TPM's endorsement public key. The privacy CA checks whether the endorsement certificate is signed by a hardware manufacturer it trusts. The privacy CA sends in response an identity certificate encrypted with the TPM's endorsement public key. The TPM decrypts the encrypted identity certifate with the endorsement private key. - remote attestation - The owner uses the identity keys in the remote attestation functions. Note that the identity private keys are also generated on the TPM, the private key also never leaves the TPM. The identity private key is certified by the privacy CA as having been requested by a certified endorsement key. The last two paragraphs imply something else interesting: the privacy CA can collude with anyone to create a virtualized environment. (This is because the TPM endorsement key is never directly used in remote attestation for privacy reasons.) All that is required to virtualize a TPM is an attestation from the privacy CA in creating an identity certificate. So there are in fact three avenues for FBI et al to go about obtaining covert access to the closed space formed by TCPA applications: (A) get one of the hardware manufacturers to sign an endorsement key generated outside a TPM (or get the endorsement CA's private key), or (B) get a widely used and accepted privacy CA to overlook it's policy of demanding a hardware manufacturer CA endorsed endorsement public key and sign an identity public key created outside of a TPM (or get the privacy CA's private key). (C) create their own privacy CA and persuade an internet server they wish to investigate the users of to accept it. Create themselves a virtualized client using their own privacy CA, look inside. I think to combat problem C) as a user of a service you'd want the remote attestation of software state to auditably include it's accepted privacy CA database to see if there are any strange "Privacy CAs" on there. I think you could set up and use your own privacy CA, but you can be sure the RIAA/MPAA will never trust your CA. A bit like self-signing SSL site keys. If you and your friends add your CA to their trusted root CA database it'll work. In this case however people have to trust your home-brew privacy CA not to issue identity certificates without having seen a valid hardware-endorsement key if they care about preventing virtualization for the privacy or security of some network application. Also, they seem to take explicit steps to prevent you getting multiple privacy CA certificates on the same identity key. (I'm not sure why.) It seems like a bad thing as it forces you to trust just one CA, it prevents web of trust which co
TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
[resend via different node: [EMAIL PROTECTED] seems to be dead -- primary MX refusing connections] Phew... the document is certainly tortuous, and has a large number of similarly and confusingly named credentials, certificates and keys, however from what I can tell this is what is going on: Summary: I think the endorsement key and it's hardware manufacturers certificate is generated at manufacture and is not allowed to be changed. Changing ownership only means (typically) deleting old identities and creating new ones. The longer version... - endorsement key generation and certification - There is one endorsement key per TPM which is created and certified during manufacture. The creation and certification process is 1) create endorsement key pair, 2) export public key endorsement key, 3) hardware manufacturer signs endorsement public key to create an endorsement certificate (to certify that that endorsement public key belongs to this TPM), 4) the certificate is stored in the TPM (for later use in communications with the privacy CA.) - ownership - Then there is the concept of ownership. The spec says the TPM MUST ship with no Owner installed. The owner when he wishes to claim ownership choose a authentication token which is sent into the TPM encrypted with the endorsement key. (They give the example of the authentication token being the hash of a password). Physical presence tests apply to claiming ownership (eg think BIOS POST with no networking enabled, or physical pin on motherboard like BIOS flash enable). The authentication token and ownership can be changed. The TPM can be reset back to a state with no current owner. BUT _at no point_ does the TPM endorsement private key leave the TPM. The TPM_CreateEndorsementKeyPair function is allowed to be called once (during manufacture) and is thereafter disabled. - identity keys - Then there is the concept of identity keys. The current owner can create and delete identities, which can be anonymous or pseudonymous. Presumably the owner would delete all identity keys before giving the TPM to a new owner. The identity public key is certified by the privacy CA. - privacy ca - The privacy CA accepts identity key certification requests which contain a) identity public key b) a proof of possession (PoP) of identity private key (signature on challenge), c) the hardware manufacturers endorsement certificate containing the TPM's endorsement public key. The privacy CA checks whether the endorsement certificate is signed by a hardware manufacturer it trusts. The privacy CA sends in response an identity certificate encrypted with the TPM's endorsement public key. The TPM decrypts the encrypted identity certifate with the endorsement private key. - remote attestation - The owner uses the identity keys in the remote attestation functions. Note that the identity private keys are also generated on the TPM, the private key also never leaves the TPM. The identity private key is certified by the privacy CA as having been requested by a certified endorsement key. The last two paragraphs imply something else interesting: the privacy CA can collude with anyone to create a virtualized environment. (This is because the TPM endorsement key is never directly used in remote attestation for privacy reasons.) All that is required to virtualize a TPM is an attestation from the privacy CA in creating an identity certificate. So there are in fact three avenues for FBI et al to go about obtaining covert access to the closed space formed by TCPA applications: (A) get one of the hardware manufacturers to sign an endorsement key generated outside a TPM (or get the endorsement CA's private key), or (B) get a widely used and accepted privacy CA to overlook it's policy of demanding a hardware manufacturer CA endorsed endorsement public key and sign an identity public key created outside of a TPM (or get the privacy CA's private key). (C) create their own privacy CA and persuade an internet server they wish to investigate the users of to accept it. Create themselves a virtualized client using their own privacy CA, look inside. I think to combat problem C) as a user of a service you'd want the remote attestation of software state to auditably include it's accepted privacy CA database to see if there are any strange "Privacy CAs" on there. I think you could set up and use your own privacy CA, but you can be sure the RIAA/MPAA will never trust your CA. A bit like self-signing SSL site keys. If you and your friends add your CA to their trusted root CA database it'll work. In this case however people have to trust your home-brew privacy CA not to issue identity certificates without having seen a valid hardware-endorsement key if they care about preventing virtualization for the privacy or security of some network application. Also, they seem to take explicit steps to prevent you getting multiple privacy CA certificates on the same identity key. (I'm not sure why.
Re: status of various projects?
On Wed, 2002-08-14 at 10:58, Miles Fidelman wrote: > It seems like a lot of interesting projects haven't been active for a > while - notably Free Haven and Eternity Usenet. Where is the most active > work, these days, on distributed publishing systems? Try Mnet (http://mnet.sf.net/). It's the continuation of the Mojo Nation code base. We are close to a "stable" release (0.5.1), but there are a lot of known bugs that we are leaving in the system (because we are rewriting the code that the bugs are found in). Our main goal for the next release is to make it easier for new coders to understand what's going on under the hood. That and replacing the single point of failure metatracker system with a distributed hash table. The old mojo token based system is no longer in use, but we hope to replace it with an OpenDBS based system, or a stamp based system. myers
TCPA hack delay appeal
It seems that there is (a rather brilliant) way to bypass TCPA (as spec-ed.) I learned about it from two separate sources, looks like two independent slightly different hacks based on the same protocol flaw. Undoubtedly, more people will figure this out. It seems wise to suppress the urge and craving for fame and NOT to publish the findings at this time. Let them build the thing into zillion chips first. If you must, post the encrypted time-stamped solution identifying you as the author but do not release the key before TCPA is in many, many PCs.
CT-RSA 2003 -- preliminary call for papers
[From sci.crypt -pt] From: [EMAIL PROTECTED] (Marc Joye) Newsgroups: sci.crypt.research, sci.crypt Subject: CT-RSA 2003 -- preliminary call for papers Date: Thu, 15 Aug 2002 12:20:39 + (UTC) === Preliminary Call for Papers -- CT-RSA 2003 Submission deadline: Oct. 1, 2002 Cryptographers' Track, RSA Conference 2003 (CT-RSA 2003) April 13-17, 2003, Moscone Center, San Francisco, USA http://reg2.lke.com/rs3/rsa2003/crypto.html (see also http://www.rsaconference.net/) === Following the success of the two previous editions, the Cryptographers' Track of RSA Conference 2003 (CT-RSA 2003) will be run as an anonymously refereed conference with proceedings. The proceedings of CT-RSA 2001 and CT-RSA 2002 were published in Springer-Verlag's Lecture Notes in Computer Science series as LNCS 2020 and LNCS 2271, respectively. Original research papers pertaining to all aspects of cryptography as well as tutorials are solicited. Submissions may present theory, techniques, applications and practical experience on topics including, but not limited to: fast implementations, secure electronic commerce, network security and intrusion detection, formal security models, comparison and assessment, tamper resistance, certification and time-stamping, cryptographic data formats and standards, encryption and signature schemes, public key infrastructure, protocols, elliptic curve cryptography, cryptographic algorithm design and cryptanalysis, discrete logarithms and factorization techniques, lattice reduction, and provable security. IMPORTANT DATES: Submission deadline: Oct. 1, 2002 Acceptance notification: Nov. 1, 2002 Proceedings version: Nov. 17, 2002 INSTRUCTIONS FOR AUTHORS: The program committee invites research contributions and tutorials in the broad area of applications and theory of cryptography. Correspondence, including submissions, will take place entirely via e-mail. All submissions will be blind refereed. To make a submission, please send two separate e-mail messages to [EMAIL PROTECTED] (the first message should contain the paper's title, the names and affiliations of the authors and should identify the contact author, including e-mail and postal addresses; the second message should contain the submission itself in PostScript or in PDF). The paper must be anonymous, with no author names, affiliations, acknowledgements, or obvious references. It should begin with a title, a short abstract, and a list of keywords. The paper should be at most 12 pages (excluding the bibliography and clearly marked appendices), and at most 18 pages in total, using at least 11-point font and reasonable margins. Submissions not meeting these guidelines risk rejection without consideration of their merits. PROCEEDINGS For an accepted paper to be included in the proceedings, the authors of the paper must guarantee that at least one of the co-authors will attend the conference and deliver the talk (registration fees will be waived for the co-author delivering the talk). PROGRAM COMMITTEE: Giuseppe Ateniese Chi-Sung Laih John Black Tatsuaki Okamoto Daniel Bleichenbacher David Pointcheval Rosario GennaroBart Preneel Stuart Haber Jean-Jacques Quisquater Helena Handschuh Tsuyoshi Takagi Markus Jakobsson Gene Tsudik Antoine Joux Serge Vaudenay Marc Joye (Chair) Sung-Ming Yen Kwangjo KimMoti Yung Seungjoo Kim Yuliang Zheng
RE: trade-offs of secure programming with Palladium (Re: Palladiu m: technical limits and implications)
> Russell Nelson[SMTP:[EMAIL PROTECTED]] writes: > > You're wearing your programmer's hat when you say that. But the > problem isn't programming, but is instead economic. Switch hats. The > changes that you list above may or may not offer some security > advantages. Who cares? What really matters is whether they increase > the cost of copying. I say that the answer is no, for a very simple > reason: breaking into your own computer is a "victimless" crime. > > In a crime there are at least two parties: the victim and the > perpetrator. What makes the so-called victimless crime unique is that > the victim is not present for the perpetration of the crime. In such > a crime, all of the perpetrators have reason to keep silent about the > comission of the crime. So it will be with people breaking into their > own TCPA-protected computer and application. Nobody with evidence of > the crime is interested in reporting the crime, nor in stopping > further crimes. > [...] Russ: Take off your economic hat, and try on a law-enforcement one. With DMCA, etal, the tools to get around TCPA's taking of your right to use your property as you please have been criminalized. (Don't argue that TCPA will always be voluntary. I don't beleive that). I have little patience with arguments which say 'Yeah, they can make X against the law, but clever people like me can always get around it, and won't get caught, so I don't care.' Maybe you can, some of the time, but that's not the point. Most people won't, either because it's too hard, they don't know what they've lost, or because of a misplaced respect for the whims of The Men with Guns. This is not a Good Thing. A freedom to skulk in the shadows, hoping not to be noticed, is not the legacy I wish to leave behind. Peter Trei
Re: Spam blocklists?
From: "Sunder" <[EMAIL PROTECTED]> > None of those things work. Most spammers don't give a shit if you don't > receive email. I can attest to this by the slew of spam going to > hostmaster, webmaster, and the like on many networks. What they're really > selling is "ten million addresses" and spam software. Even if 9 million > of those are bullshit, they couldn't care less. The more things with "@" > signs in'em the more money they make off clueless businesses. We talk about different things then :) I don't care that they make money off clueless businesses... I care that they don't send ME spam. If I can solve the second problem, the first one will take care of itself. Mark
Re: Signing as one member of a set of keys
Anonymous User wrote: > This program can be used by anonymous contributors to release partial > information about their identity - they can show that they are someone > from a list of PGP key holders, without revealing which member of the > list they are. Maybe it can help in the recent controvery over the > identity of anonymous posters. It's a fairly low-level program that > should be wrapped in a nicer UI. I'll send a couple of perl scripts > later that make it easier to use. Hmm. So has anyone managed to get the signature to verify? Doesn't work for me! But perhaps things got mangled in the mail? Or I chose the wrong subset of the email to verify (I tried all the obvious ones)? Sending this stuff as attachments instead of inline would work better, of course. 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
Re: A faster way to factor prime numbers found?
On Tuesday, August 13, 2002, at 03:07 PM, Gary Jeffers wrote: > A faster way to factor prime numbers found? > Faster even than the usual algorithm?: The factors of a prime number are 1 and the number itself. --Tim May "That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United States who are peaceable citizens from keeping their own arms." --Samuel Adams
Re: CDR: status of various projects?
It's more than 'distributed publishing', it's distributed everything. Have your grid and eat it too! Use Plan 9: http://plan9.bell-labs.com The Hangar 18 Co-Op: http:[EMAIL PROTECTED] On Wed, 14 Aug 2002, Miles Fidelman wrote: > It seems like a lot of interesting projects haven't been active for a > while - notably Free Haven and Eternity Usenet. Where is the most active > work, these days, on distributed publishing systems? > > > ** > The Center for Civic Networking PO Box 600618 > Miles R. Fidelman, President &Newtonville, MA 02460-0006 > Director, Municipal Telecommunications > Strategies Program617-558-3698 fax: 617-630-8946 > [EMAIL PROTECTED]http://civic.net/ccn.html > > Information Infrastructure: Public Spaces for the 21st Century > Let's Start With: Internet Wall-Plugs Everywhere > Say It Often, Say It Loud: "I Want My Internet!" > ** > -- Conform and be dull..J. Frank Dobie [EMAIL PROTECTED] www.ssz.com [EMAIL PROTECTED] www.open-forge.org
CATO evacuation plans
a)Tell declan and other media whores and shills to stay,"Its just a drill." b) Shred all tobacco documents c) Ditto all wind farming cruft,global warming malarky. d) All donation information must be burned.(and I don't mean on to a dvd,goddamit.) e) Don't run or drive fast,act nonchalant,but get the hell 40k out.AT LEAST. d) Don't go freakin' near RR. e) Don't pick up hitchers.Even if they look like Fawn Hall and are topless.(exceptions may be made if they are waving money,we are free enterprise remember. f) Be glad you invested in a SUV with a bullbar.
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
Re: Overcoming the potential downside of TCPA
Joseph Ashwood wrote: > - 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. If this is true, I'm really happy about it, and I agree it would allow virtualisation. I'm pretty sure it won't be for Palladium, but I don't know about TCPA - certainly it fits the bill for what TCPA is supposed to do. 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
status of various projects?
It seems like a lot of interesting projects haven't been active for a while - notably Free Haven and Eternity Usenet. Where is the most active work, these days, on distributed publishing systems? ** The Center for Civic Networking PO Box 600618 Miles R. Fidelman, President & Newtonville, MA 02460-0006 Director, Municipal Telecommunications Strategies Program 617-558-3698 fax: 617-630-8946 [EMAIL PROTECTED] http://civic.net/ccn.html Information Infrastructure: Public Spaces for the 21st Century Let's Start With: Internet Wall-Plugs Everywhere Say It Often, Say It Loud: "I Want My Internet!" **
Re: Re: Overcoming the potential downside of TCPA
- Original Message - From: "Ben Laurie" <[EMAIL PROTECTED]> > > 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. > > If this is true, I'm really happy about it, and I agree it would allow > virtualisation. I'm pretty sure it won't be for Palladium, but I don't > know about TCPA - certainly it fits the bill for what TCPA is supposed > to do. I certainly don't believe many people to believe me simply because I say it is so. Instead I'll supply a link to the authority of TCPA, the 1.1b specification, it is available at http://www.trustedcomputing.org/docs/main%20v1_1b.pdf . There are other documents, unfortunately the main spec gives substantial leeway, and I haven't had time to read the others (I haven't fully digested the main spec yet either). From that spec, all 332 pages of it, I encourage everyone that wants to decide for themselves to read the spec. If you reach different conclusions than I have, feel free to comment, I'm sure there are many people on these lists that would be interested in justification for either position. Personally, I believe I've processed enough of the spec to state that TCPA is a tool, and like any tool it has both positive and negative aspects. Provided the requirement to be able to turn it off (and for my preference they should add a requirement that the motherboard continue functioning even under the condition that the TCPA module(s) is/are physically removed from the board). The current spec though does seem to have a bend towards being as advertised, being primarily a tool for the user. Whether this will remain in the version 2.0 that is in the works, I cannot say as I have no access to it, although if someone is listening with an NDA nearby, I'd be more than happy to review it. Joe
SSZ Downtime - Schedule Change
Hi, We're facing a last minute change in our scheduled downtime. The current window is from Fri., Aug. 16 through Sun., Aug. 25. This is from tomorrow (Fri.) through Sunday of next weekend. I apologize for the short notice on the change and any inconvenience this might cause. We do not expect to experience such extended downtimes in the (near) future. See you in about a week! -- Conform and be dull..J. Frank Dobie [EMAIL PROTECTED] www.ssz.com [EMAIL PROTECTED] www.open-forge.org
