Re: Questions about the usage of the vTPM implemented in Xen 4.3

[Jordi Cucurull Juan <jordi.cucurull@scytl.com>]

[-- Attachment #1.1: Type: text/plain, Size: 7556 bytes --]

Hello Daniel,

On 02/11/2014 04:26 PM, Daniel De Graaf wrote:
> On 02/11/2014 05:01 AM, Jordi Cucurull Juan wrote:
>> Hello Daniel,
>>
>> Thanks for your thorough answer. I have a few comments below.
>>
>> On 02/10/2014 08:40 PM, Daniel De Graaf wrote:
>>> On 02/05/2014 11:52 AM, Jordi Cucurull Juan wrote:
>>>> Dear all,
>>>>
>>>> I have recently configured a Xen 4.3 server with the vTPM enabled
>>>> and a
>>>> guest virtual machine that takes advantage of it. After playing a bit
>>>> with it, I have a few questions:
>>>>
>>>> 1.According to the documentation, to shutdown the vTPM stubdom it is
>>>> only needed to normally shutdown the guest VM. Theoretically, the vTPM
>>>> stubdom automatically shuts down after this. Nevertheless, if I
>>>> shutdown
>>>> the guest the vTPM stubdom continues active and, moreover, I can start
>>>> the machine again and the values of the vTPM are the last ones there
>>>> were in the previous instance of the guest. Is this normal?
>>>
>>> The documentation is in error here; while this was originally how the
>>> vTPM
>>> domain behaved, this automatic shutdown was not reliable: it was not
>>> done
>>> if the peer domain did not use the vTPM, and it was incorrectly
>>> triggered
>>> by pv-grub's use of the vTPM to record guest kernel measurements
>>> (which was
>>> the immediate reason for its removal). The solution now is to either
>>> send a
>>> shutdown request or simply destroy the vTPM upon guest shutdown.
>>>
>>> An alternative that may require less work on your part is to destroy
>>> the vTPM stub domain during a guest's construction, something like:
>>>
>>> #!/bin/sh -e
>>> xl destroy "$1-vtpm" || true
>>> xl create $1-vtpm.cfg
>>> xl create $1-domu.cfg
>>>
>>> Allowing a vTPM to remain active across a guest restart will cause the
>>> PCR values extended by pv-grub to be incorrect, as you observed in your
>>> second email. In order for the vTPM's PCRs to be useful for quotes or
>>> releasing sealed secrets, you need to ensure that a new vTPM is started
>>> if and only if it is paired with a corresponding guest.
>>
>> I see a potential threat due to this behaviour (please correct me if I
>> am wrong).
>>
>> Assume an administrator of Dom0 becomes malicious. Since the hypervisor
>> does not enforce the shut down of the vTPM domain, the malicious
>> administrator could try the following: 1) make a copy of the peer
>> domain, 2) manipulate the copy of the peer domain and disable its
>> measurements, 3) boot the original peer domain, 4) switch it off or
>> pause it, 5) boot the manipulated copy of the peer domain.
>>
>> Then, the shown PCR values of the manipulated copy of the peer domain
>> are the ones measured by the original peer domain during the first boot.
>> But the manipulated copy is the one actually running. Hence, this could
>> not be detected nor by quoting the vTPM neither the pTPM.
>>
>
> A malicious dom0 has a much simpler attack vector: start the domain with
> a custom version of pv-grub that extends arbitrary measurements instead
> of the real kernel's measurements. Then, a user kernel with disabled or
> similarly false measuring capabilities can be booted. Alternatively,
> if XSM polices do not restrict it, a debugger could be attached to the
> guest so that it can be manipulated online.

This is the reason why I wanted to measure Dom0, to detect a possible
manipulation, e.g. of a custom version of pv-grub. Nevertheless, still
the administrator could try to inject a manipulated copy of it into the
system after booting it. Hence, I agree with the solutions you propose
below.

>
>> May be, one possible solution could be to enforce an XSM FLASK policy to
>> prevent any user in Dom0 from destroying, shutting down or pausing a
>> domain. Then, measure the policy when Dom0 starts into a PCR of the
>> phsyical TPM. Nevertheless, on one hand I do not know if this is
>> feasible and, in the other hand, this prevents the system from
>> destroying the vTPM domain when the peer domain shuts down.
>
> The solution to this problem is to disaggregate dom0 and relocate the
> domain building component to a stub domain that is completely measured
> in the pTPM (perhaps by TBOOT). The domain builder could use a static
> library of domains to build (hardware domain and TPM Manager built only
> once; vTPM and pv-grub domain pairs built on request). An XSM policy
> could then restrict vTPM communication so that only correctly built
> guests are allowed to talk to their paired vTPM. In this case, dom0
> would have permission to shut down either VM, but could not start a
> replacement.
>

I understand this cannot be done with the current implementation of Xen.
Are there any plans to do this in the future?


>>>> 2.In the documentation it is recommended to avoid accessing the
>>>> physical
>>>> TPM from Dom0 at the same time than the vTPM Manager stubdom.
>>>> Nevertheless, I currently have the IMA and the Trousers enabled in
>>>> Dom0
>>>> without any apparent issue. Why is not recommended directly accessing
>>>> the physical TPM of Dom0?
>>>
>>> While most of the time it is not a problem to have two entities
>>> talking to
>>> the physical TPM, it is possible for the trousers daemon in dom0 to
>>> interfere
>>> with key handles used by the TPM Manager. There are also certain
>>> operations
>>> of the TPM that may not handle concurrency, although I do not believe
>>> that
>>> trousers uses them - SHA1Start, the DAA commands, and certain audit
>>> logs
>>> come to mind.
>>>
>>> The other reason why it is recommended to avoid pTPM access from
>>> dom0 is
>>> because the ability to send unseal/unbind requests to the physical TPM
>>> makes
>>> it possible for applications running in dom0 to decrypt the TPM
>>> Manager's
>>> data (and thereby access vTPM private keys).
>>>
>>> At present, sharing the physical TPM between dom0 and the TPM
>>> Manager is
>>> the only way to get full integrity checks.
>>
>> OK, I see. Hence leaving the TPM support enabled in Dom0 opens a
>> security problem to the vTPM. But if we do not enable the support, the
>> integrity of Dom0 cannot be proved using the TPM (e.g. by remote
>> attestation).
>
> Right. Since dom0 currently must be trusted (as discussed above) this is
> currently the best way to handle the dom0 attestation problem.
>
>>>
>>>> 3.If it is not recommended to directly accessing the physical TPM in
>>>> Dom0, which is the advisable way to check the integrity of this
>>>> domain?
>>>> With solutions such as TBOOT and IntelTXT?
>>>
>>> While the TPM Manager in Xen 4.3/4.4 does not yet have this
>>> functionality,
>>> an update which I will be submitting for inclusion in Xen 4.5 has the
>>> ability to get physical TPM quotes using a virtual TPM. Combined
>>> with an
>>> early domain builder, the eventual goal is to have dom0 use a vTPM for
>>> its integrity/reporting/sealing operations, and use the physical TPM
>>> only
>>> to secure the secrets of vTPMs and for deep quotes to provide fresh
>>> proofs
>>> of the system's state.
>>
>> This sounds really good. I look forward to try it in Xen 4.5!!
>>
>>
>> Thank you for your answers!
>> Jordi.
>>
>
>


-- 
Jordi Cucurull Juan
Researcher
Scytl Secure Electronic Voting
Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona
Phone:     + 34 934 230 324
Fax        + 34 933 251 028
jordi.cucurull@scytl.com
http://www.scytl.com



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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