[Rats] vTPMs and remote attestation and VMs

[Michael Richardson <[e-mail]>]

Hi, thanks for your questions about UEFI variables and signatures.
I've started a new thread because my queries to you are related, but
having nothing to do with your questions (for which I have few answers)

I'm particularly interested in how (virtual) TPMs can get initialized with
anchors and enrolled private keys for virtual machines.   I ultimately care
about IDevIDs for virtual appliances, and how that can help support HTTPS
everywhere.  (Imagine an HTTPS admin interface for an on-prem virtual
appliance that comes with a valid certificate)

I don't know really know a lot about how the various VM hypervisors are
dealing with virtual TPMs.  I'd like to know more.

In some cases (laptpos?), I'm aware that a trusted execution enironment is
not available to a VM if the physical machine does not initialize it
correctly.   This has an effect on availability of fTPMs.

Effectively, there are roots of trust (along with Evidence)
that the hypervisor can provide that are significantly more interesting for
measured boot than a physical machine could/would have.
(Is this evidence tied in any way to the physical TPM on the hypervisor?)

But there seems to be a number of hurdles.  And maybe these belong in the CCC
or some other fora, but I don't know.

Some questions:

1) if I snapshot a VM, does it snapshot the TPM?

2) if I clone a VM from a snapshot, what does that mean for the TPM?

3) does snapshot of a vTPM imply that the keys might be exportable?

4) what happens if I migrate (live or stopped) a VM to another hypervisor,
   what does this mean for any evidence that might have been signed by the
   other hypervisor?

5) if I time-travel a VM back to a snapshot, what does this do to the TPM?
   What if there was a hash-based signature system involved!
   Arguably, that's really just a clone from snapshot, along with killing
   of the "current" VM... but if it's actually clearly separate, then maybe
   the TPM state is affected in a different way.

6) it seems to me that fTPMs (in TEEs) would be cheaper for VMs to support
   rather than emulating an i2C bus. OTH, that separation might be feature.

6) cloud-init. while the guest side of things is an OS-level activity, rather
   than a firmware thing, the fundamental interface seems like it might be
   useful for initializing certificates into TPMs.  My efforts to come up
   with a way to provision HTTPS certificates via cloud-init are stillborn
   because, while the cloud-init client is easy to extend, the hypervisor
   side code is largely cloud-private code. (The cloud-init people experience
   the same challenges with testing their code!!)






--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide