Re: [Xen-devel] vTPM Deep Quote validation

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 03/09/2015 11:58 AM, Emil Condrea wrote:
> On Mon, Mar 9, 2015 at 4:40 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
> wrote:
>
> > On 03/08/2015 07:41 AM, Emil Condrea wrote:
> >
> > > I am trying to validate a Deep Quote request made by domU but I feel that
> > > something is missing. Right now when a domU requests TPM_ORD_DeepQuote:
> > > 1. vTPM:
> > > - unpacks the params: nonce, vTPM PCR selection and physical PCR selection
> > > - packs PCR_INFO_SHORT structure into buf that contains the selected vTPM
> > > PCRs
> > > - computes nonce as a SHA1 of: dquot_hdr, nonce, and previous packed buf
> > > - packs: nonce, physical PCR selection
> > > - receives physical pcr data and signature from manager and returns them
> > > to
> > > DomU
> > > 2. vTPM Manager
> > > - unpacks the params: nonce, PCR selection
> > > - execute TPM_Quote with: externalData = nonce
> > > - returns pcr data and signature to vTPM
> > >
> > > If domU user wants to validate the signature it has to do the exact
> > > process
> > > that the vtpm and manager did  but the virtual PCR values are not included
> > > in response, just physical ones.
> > The virtual machine can use TPM_PCRRead to get the value of the vTPM PCRs.
> > This is the same method that is used by the TPM_Quote2 command.
>
> I thought of using TPM_PCRRead from virtual machine but it was not clear
> for me if it is safe.
> Is it possible for the selected vTPM PCRs values to be different when
> performing
> composite hash on vTPM from the values read with TPM_PCRRead after
> executing DeepQuote?
One way to detect this is by reading the PCRs before and after asking
for a quote.  If the values match, then the quote used those values; if
not, try the quote operation again.  In either case, you should have a
log or other information on what values have been extended into the PCRs
so that a verifier can make sense of them: there is little reason to
include the PCRs in a quote if you can't reconstruct them.
    
As an alternative to retrying, you could try to reconstruct the PCRs
used in the quote by hashing the various possibilities drawn from the
logs.  If the number of extend operations between the pre- and post-read
operations is reasonable, this could end up being faster than asking for
another quote from the (rather slow) hardware TPM.

> The TPM has context management for each application? (eg: when one
> application extends something
> into a PCR and another application extends other thing in the same PCR(at
> the same time moment),
> are they hashed together?)
This depends on the TPM multiplexing daemon (usually trousers in Linux).
I believe it just processes the requests in the order it receives them,
so without external synchronization they would be in an arbitrary order.

I am unsure if this is implemented (and would guess it is currently
not), but it would be possible for trousers to queue up several commands
(such as PCR reads and quote requests) from a single source and
guarantee that they are executed without intervening commands.  In order
to avoid interactions with IMA, this would need an extension to the
Linux TPM character device interface to submit multiple commands for
processing without unlocking the TPM device.

> When I read the standard I understood that the PCRs can never be
> overwritten,
> just reset and extended.
>
> Thanks.
>
> >   We can include the vTPM PCRS in response or the manager must perform
> > > TPM_Quote using the nonce received from domU in order to be able to have a
> > > successful validation on the client side.
> > If you want a quote without any vTPM PCRs, you can specify an empty PCR
> > mask
> > to get something fairly close to this behavior - the nonce will be combined
> > with an empty deep quote structure instead of passed directly.
> >
> >   What do you think? Is there something that I am missing ?
> > >
> > It is useful to be able to ask for the current value of both physical and
> > virtual PCRs in a single atomic operation.  Including the value of all PCRs
> > in the response could make the reply packet too large (which is part of the
> > reason why TPM_Quote2 removed them).
> >
> > --
> > Daniel De Graaf
> > National Security Agency

--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel