Re: [Xen-devel] vTPM Deep Quote validation

[Emil Condrea <emilcondrea@xxxxxxxxx>]

I think it is fair to read the PCRs before performing Deep Quote and after andÂ

to retry if something changed.

It is an interesting suggestion to extend the tpm character device driver in order

to obtain atomicity. I will think about it.

Thanks for clarifying.

On Mon, Mar 9, 2015 at 7:26 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:

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