WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

RE: [Xense-devel] Run vTPM in its own VM?

To: "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>
Subject: RE: [Xense-devel] Run vTPM in its own VM?
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Fri, 15 Sep 2006 13:03:57 -0400
Cc: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx, Xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 15 Sep 2006 10:04:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D936D925018D154694D8A362EEB089209E2D22@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx

"Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx> wrote on 09/15/2006 12:53:39 PM:

>  
>
> >________________________________
> >
> >From: Stefan Berger [mailto:stefanb@xxxxxxxxxx]
> >Sent: Friday, September 15, 2006 9:34 AM
> >To: Scarlata, Vincent R
> >Cc: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx;
> xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xense-devel] Run vTPM in its own VM?
> >
> >
> >
> > xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/15/2006 12:18:12
> PM:
> >
> > > This is already supported, even in the single VM model. At any time,
> a
> >> vtpm can issue a request to the manager (similar to the way you
> request
> >> save/load state) to access the TPM below. On one of my configurations
> >> (not submitted but available upon request) that have the vtpm's copy
> >> certain hwpcrs during its initialization steps. Note, however, on
>
> >You will also have to clone the logs related to those PCRs and carry
> them with you when you migrate.
> >Now if you copy the PCRs upon creation, what do you do with the PCR
> register values after migration? Do they still
> >reflect the old environment?
>
> The code I mentioned is being used for a very specific environment where
> not all of the functions in xen are used. I meant it more as an
> illustrative statement that not only is calling the tpm from a vtpm
> supported, there exist code that is using it. The code hasn't been
> checked in to the tree, because as you point out, it is not necessarily
> a general purpose approach to vPCR usage.
>
> >> commands that use authorization digests, it won't be as simple has
> >> forwarding the commands down from vtpm to manager to tpm, you'll need
> to
> >> be more careful to ensure the auth sessions are maintained as the
> client
> >> expects.
> >
> >Which commands are you for example forwarding to the hardware TPM? Are
> you rooting your key tree to the SRK of
> >the hardware TPM?
>
> The current implementation does not forward any commands to the TPM,
> however, if one wanted too, you could write the TPM code such that
> rather than using openssl for generating key, you called the TPM to
> generate keys. Now, my comment about forwarding was that you will not be
> able to just forward commands to use these keys down to the TPM. Rather
> the vtpm would share an OIAP session with the application in the guest.
> The vtpms handles checking that the TPM_Unbind for example is ok. Then
> the vtpm makes a separate request down to the TPM to request that the
> key owned by the vtpm that resides in the tpm be used to decrypt some
> data (that happened to originate from a guest).


.. as long as you never let the hardware TPM create AIKs or non-migrateable(!) keys on behalf of the vTPM. So you have to treat those types of keys separately because if they are in the TPM they will not migrate with the vTPM. That makes it a little harder for handling non-migrateable keys that a children of the SRK. What SRK password would a user use inside the VM using the vTPM? Would he use the SRK password of the HWTPM or of the vTPM? At least once you send the CreateWrapKey command to the HWTPM you would have to make sure that the authorization inside the TPM request is using the HWTPM's SRK password.

Whose EK certificate would you use to have your AIKs certified?

   Stefan
>
> -Vinnie
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
<Prev in Thread] Current Thread [Next in Thread>