Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
I arrived at that decision over four years ago ... TCPA possibly didn't decide on it until two years ago. In the assurance session in the TCPA track at spring 2001 intel developer's conference I claimed my chip was much more KISS, more secure, and could reasonably meet the TCPA requirements at the time w/o additional modifications. One of the TCPA guys in the audience grossed that I didn't have to contend with the committees of hundreds helping me with my design. There are actually significant similarities between my chip and the TPM chips. I'm doing key gen at very first, initial power-on/test of wafer off the line (somewhere in dim past it was drilled into me that everytime something has to be handled it increases the cost). Also, because of extreme effort at KISS, the standard PP evaluation stuff gets much simpler and easier because most (possibly 90 percent) of the stuff is N/A or doesn't exist early ref: http://www.garlic.com/~lynn/aadsm2.htm#staw or refs at (under subject aads chip strawman): http://www.garlic.com/~lynn/index.html#aads brand & other misc. stuff: http://www.asuretee.com/ random evauation refs: http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa? http://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation [EMAIL PROTECTED] on 8/15/2002 6:44 pm wrote: 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/
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
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 (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/
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 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: 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
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
Re: Overcoming the potential downside of TCPA
Joseph Ashwood wrote: > Lately on both of these lists there has been quite some discussion about > TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :) > However there is something that is very much worth noting, at least about > TCPA. > > There is nothing stopping a virtualized version being created. > > There is nothing that stops say VMWare from synthesizing a system view that > includes a virtual TCPA component. This makes it possible to (if desired) > remove all cryptographic protection. > > Of course such a software would need to be sold as a "development tool" but > we all know what would happen. Tools like VMWare have been developed by > others, and as I recall didn't take all that long to do. As such they can be > anonymously distributed, and can almost certainly be stored entirely on a > boot CD, using the floppy drive to store the keys (although floppy drives > are no longer a "cool" thing to have in a system), boot from the CD, it runs > a small kernel that virtualizes and allows debugging of the TPM/TSS which > allows the viewing, copying and replacement of private keys on demand. > > Of course this is likely to quickly become illegal, or may already, but that > doesn't stop the possibility of creating such a system. For details on how > to create this virtualized TCPA please refer to the TCPA spec. What prevents this from being useful is the lack of an appropriate certificate for the private key in the TPM. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Overcoming the potential downside of TCPA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 10:58 PM 8/13/2002 -0700, Joseph Ashwood wrote: >Lately on both of these lists there has been quite some discussion >about TCPA and Palladium, the good, the bad, the ugly, and the >anonymous. :) However there is something that is very much worth >noting, at least about TCPA. > >There is nothing stopping a virtualized version being created. The only thing to stop that is the certificate on the TCPA's built-in key. You would have to shave one TCPA chip and use its key in the virtualized version. If you distributed that shaved key publicly or just to too many people, then its compromise would likely be detected and its power to attest to S/W configuration would be revoked. However, if you kept the key yourself and used it only at the same frequency you normally would (for the normal set of actions), then the compromise could not be detected and you should be able to run virtualized very happily. That's one of the main problems with TCPA, IMHO, as a security mechanism: that its security depends on hardware tamper resistance -- but at the same time, the TPM needs to be a cheap part, so it can't be very tamper resistant. - Carl -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPVpb2XPxfjyW5ytxEQIaAgCgh72smP3W6qclzgRbNiWt5prdpk4AmwWw aKNdDfQbHWxRVJ3yQ02FxtJb =eEI+ -END PGP SIGNATURE- +--+ |Carl M. Ellison [EMAIL PROTECTED] http://world.std.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+
