chloé Fouquet [[email protected]] wrote:
> 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 ?
Yes; you need to know what you're looking for.
> 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 ?
I'm going to distinguish here between PCR values-- the contents of a Platform
Control Register, usually produced by taking a hash of some program and
extending the PCR with it-- and the PCR index-- the identifier for a particular
register.
When you send a Quote request, it includes the PCR mask, a list of the indexes
you would like to receive a report about. You do *not* need to send any
information about expected values: you just want to know the values that are
actually in the registers.
However, you and your target *do* need to agree on what the *meaning* of each
register is. Some agreement is easy: a good TPM-aware PC BIOS will launch boot
processes that use the low PCRs specified in the PC client spec. tGRUB's
documentation clearly lists which PCRs it uses, and for what, so if the early
boot measurements correspond to a good tGRUB installation, you can be confident
of which PCR contains the kernel measurement. Other agreement is harder: there
is no PCR that I'm aware of that is commonly used for any user-level app
measurements, so you will need to make sure that your target has some software
*you* trust to measure Word into a particular PCR, and that the measurement
software is itself measured in an identifiable PCR, and so forth down into the
standard chain.
(You can get around some of the chain and PCR unpredictability with the Dynamic
Root of Trust for Measurement, where the hardware is acting as a root of trust;
how to do that properly is a bit more complicated, but it's a very powerful
tool. If you're interested, I suggest you look into the Flickr research from
Carnegie Mellon; they even have prototype software you can use.)
>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 ?
As above, you need to verify each step in the boot chain and make sure that the
low-level software corresponds to something you trust; ideally, that will tell
you which PCR it will use for the next measurement up.
> <TSS policy question>
I'll have to look some things up to answer your policy question, so I'm going
to hold off for now. Hopefully some other TSS expert who can answer more
quickly will jump in.
> I'm starting with the TPM and TSS so I have a lot of questions, it is not
> straight forward !
That is an understatement. :)
Ariel
2010/6/10 Segall, Ariel E <[email protected]<mailto:[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]<mailto:[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
