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 <[email protected]>
> I made some guesses about what your questions were aiming at; if I missed,
> please feel free to clarify.
>
> chloé Fouquet [[email protected]] 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
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
TrouSerS-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-users
