Cihula, Joseph wrote:
> Thanks to Vinnie for getting into more background on why the vTPM
> Manager isn't using a gneral TSS. This fills-in the background on my
> previous answer to this same question:
> http://lists.xensource.com/archives/html/xen-devel/2007-07/msg00812.html
> .
>
> In your (Luke's) original reply to this, you stated that you wanted to:
> My goal is to be able to do all of the following, though no two
> need to occur simultaneously
> 1) Run vtpm_managerd
> 2) create tpm keys in the dom0
> 3) create vtpm keys in the domu
> and then later that you had gotten 1) and 3) working.
>
> As Vinnie explained, if you have a need for a somewhat privileged domain
> to use keys, it would be preferable to do that within a secure domU.
>
> It has long been a goal of the Xen security community to disaggregate
> dom0, and in such a case, the vTPM Manager would most likely end up in a
> small domain to itself. So a forward-looking design would be to use a
> secure domU for any TPM operations.
>
> Is your intended use something that cannot work in such a model and
> requires access to the hardware TPM?
>
Yes - both the VTPM and actual TPM in dom0 must be accessible
simultaneously.
The end goal is to "fully" attest to the state of a VM.
vtpm_managerd would run in a dom0 that has nothing except an attestation
server, to attest to the dom0, bios, bootloader, etc. A VM would run a
similar service. A remote party then should be able to query both VM
and dom0 for attestations.
In this way, a remote party can verify that no compromise of the VMM,
bootloader, dom0, or VM has taken place.
See the publications on
http://domino.research.ibm.com/comm/research_projects.nsf/pages/ssd_shype.index.html
for more extensive information, particularly those including the title
"Shamon"
It sounds like I need to modify this to work with Trousers then, or a
different TSS stack.
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
Home