From: chloé F. <fou...@gm...> - 2010-06-11 11:00:49
|
Thank you very much Ariel, it clarifies a lot but just to be sure I would like to take an example and tell me what you think of it : Let's suppose I have a linux version running on my computer. I want to be sure that your TPM is trusted and your Microsoft Word too so that I can send you a document. So I will need you to send me PCR values resulting from a Quote "operation" on your computer. So I will need to check your kernel image, your boot loader, your operating system and your Microsoft Word application. As I have linux, I can't compare with me own PCR values so I have to have a set of trusted hash values corresponding to the image of each of them somewhere ? So do I have to tell you first which PCR values I won't so you can program you trusted boot to calculate the right PCR values ? And once I have the bits you sent me resulting from the "Quote", how do I know which bit is the PCR values representing the kernel image of your computer ? I have another questions that are not related to that but anyway : what is exactly the "object" policy ? It is only to put a secret on it and after assign it to an other object, let's say a data, and we will need that secret to be able to read the data after ? But if we encrypt the data or seal it with a key, do we really need a policy and a secret in it ? What is the difference between getting the default policy and changing it or create a new policy and assign it to an object ? I'm starting with the TPM and TSS so I have a lot of questions, it is not straight forward ! Chloe 2010/6/10 Segall, Ariel E <as...@mi...> > I made some guesses about what your questions were aiming at; if I missed, > please feel free to clarify. > > chloé Fouquet [fou...@gm...] wrote: > > >How can we attest that a TPM is genuine and that it is a good TPM and that > the applications it has are good too ? > >Can we do the following for example : > >- ask for a AIK key that will assure that the tpm has good credentials > > Yes, with a caveat. You'll need some kind of PKI support, with an authority > that has some good reason to believe that a particular EK or AIK belongs to > a genuine TPM. If you have a manufacturer-issued Endorsement Credential > (EC), you can use that and the AIK certification protocol to establish > Attestation Identity Credentials (AICs). Or, if you're on a really small > scale and don't want any infrastructure, you can just create an AIK or > signing key and establish trust in it using whatever your preferred system > is. > > There is, however, a big warning here: If you're in a high-security > scenario, the creation and certification of this first key (which will be > your Root of Trust for Reporting) is your highest-risk operation. If your > system doesn't come with an Endorsement Key and Credential from the factory, > malware on your system can masquerade as the TPM and provide you with false > keys while you think you're creating or certifying the TPM's RTR. On systems > that you really care about, you should make sure that this provisioning > stage has as minimal and trusted a set of software running as you can > manage. (We use a minimal Linux boot CD.) > > In other words, you need to make sure that your *key* has credentials that > assure others that it belongs to a good *TPM*, and that those are accurate. > You can use whatever credetial mechanism is most convenient for you. > > >- use this key and the Quote function to encrypt some pcr values of our > tpm > > Sign, rather than encrypt, but yes. You can use that key to prove that some > set of PCR values were present in the TPM at the time the quote was created. > (The freshness of the random nonce is very important to prevent replay.) > > > > But after, to open theses values and compare the PCR value to know if > they are good it is quite complicated isn't it ? > > Well, with a basic TPM Quote, the returned PCR Composite structure does > contain the full set of PCR values. It's a little trickier to verify the PCR > values from a Quote2; you need to pull them from the TPM separately and > assemble the composite to compare with the Quote2 signature.. Determining > whether a given quote has "good" values, not just values accurately > reflecting what's in the TPM, is an entirely local decision, and gets to > your next question. > > > How do we choose witch PCR values are needed ? > > That depends entirely on your application! There is one set of PCRs filled > in by most TPM-aware BIOSes reflecting the boot loader; Trusted Grub will > fill in PCRs for the kernel and kernel arguments, and optionally some files > on your system; SINIT or SKINIT will use other PCRs for dynamically executed > code; and you can write your own programs that extend PCRs with values of > your choice. > > If your real question is "How do I know if this boot loader measurement is > good or bad?", that's a much harder problem. In general, the measurements > put into PCRs today are hashes of binaries; usually, people will select some > acceptable set of binaries and declare the associated hashes to be good, or > set up some reference machine in a desired configuration and use the PCR > values in that TPM as the standard for comparison. How to get more general > "goodness" metrics out of PCR values-- "Is this system up to date?", etc-- > is an area of open research. > > >How do we know how they have been calculated on another tpm ? > > A TPM will *only* create a Quote using the values stored in its own PCRs. > Although a TPM can sign arbitrary user data, it wraps that data in another > data structure so it's easily distinguished from a Quote. So, if you get a > Quote signed by TPM A, the values in it really were in TPM A's PCRs. > > If you mean "How do I know how measurements stored in another TPM were > calculated?", you need to look at the chain of trust. In your normal > BIOS-rooted boot, you'll want to first verify whether the BIOS is one you > trust; part of trusting the BIOS is deciding whether it will accurately > measure the next component. If it will, then you look at the next > component's measurement, and decide whether it's one you trust both to > behave well and to measure the next higher component properly, and so forth. > > > Because for example if we use a trusted boot it will write some values in > the pcr at the boot but we can configure > what need to be monitor so it > will be different on different PC.... > > Predictability of PCR values (or more to the point, the lack of > predictability) is a bit of a pain, yes. That said, if you have identical > software on two different machines, you should have identical PCR values. > > >Is the GRUB TCG Patch to support Trusted Boot working ? With a tpm > emulator too ? > > tGRUB works. I can't speak for the TPM emulator, and I don't know if the > tGRUB modifications are being integrated into GRUB proper. > > > I made some guesses about what your questions were aiming at; if I missed, > please feel free to clarify. > > > Ariel |