From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jordi Cucurull Juan Subject: Re: Questions about the usage of the vTPM implemented in Xen 4.3 Date: Wed, 12 Feb 2014 10:38:24 +0100 Message-ID: <52FB4110.8090005@scytl.com> References: <52F26C40.2060901@scytl.com> <52F92B4A.3010805@tycho.nsa.gov> <52F9F514.8040907@scytl.com> <52FA413F.1040608@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4738565846614668823==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDWGz-0005rN-9F for xen-devel@lists.xenproject.org; Wed, 12 Feb 2014 09:38:29 +0000 In-Reply-To: <52FA413F.1040608@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: xen-devel@lists.xenproject.org, Jordi Cucurull Juan List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============4738565846614668823== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JN7dVRjllhTlUQnvvNi2voXf5eWDtAbMQ" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JN7dVRjllhTlUQnvvNi2voXf5eWDtAbMQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 bi= t >>>> 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 vT= PM >>>> stubdom automatically shuts down after this. Nevertheless, if I >>>> shutdown >>>> the guest the vTPM stubdom continues active and, moreover, I can sta= rt >>>> 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 th= e >>> PCR values extended by pv-grub to be incorrect, as you observed in yo= ur >>> 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 start= ed >>> 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 hyperviso= r >> 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 boo= t. >> But the manipulated copy is the one actually running. Hence, this coul= d >> not be detected nor by quoting the vTPM neither the pTPM. >> > > A malicious dom0 has a much simpler attack vector: start the domain wit= h > 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 accessin= g >>>> 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 TP= M >>> 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 i= s > 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 fo= r >>> 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. >> > > --=20 Jordi Cucurull Juan Researcher Scytl Secure Electronic Voting Pla=E7a Gal=B7la Placidia, 1-3, 1st floor =B7 08006 Barcelona Phone: + 34 934 230 324 Fax + 34 933 251 028 jordi.cucurull@scytl.com http://www.scytl.com --JN7dVRjllhTlUQnvvNi2voXf5eWDtAbMQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS+0EQAAoJEI3Hup7P+VY6J7oIAIZHQMFxKwaVcFa2SDWcG64F jndIsOxy9kcTMA8uNOyq11y9LCurBLHf9EqIy/8xyFsaweI/ACYoY1kkx47AIstw Gt0DqKnfkh2L5ivrGuIIJnPisOWo+mzG7XY3e1+toYsu92qs68vFKXnqMQkHfmfq AVxkmzD2c/zJzGTNjnYmZwtS+mBqyc7LkjOB+1fCLQFy/V9yyseRZcFOlf7asIBi /Yteqjh1x2XpD506dA0FcrgiM44x8mOog7nX0WMYlkiDH61ofKTnY8dUHZVyS+RW u7IiwwXzmtvBN60wYlkN9eUF/S08ATO8vmXe/owfou+2lcdZ/0FjNJ/UnIi1U2s= =PLqe -----END PGP SIGNATURE----- --JN7dVRjllhTlUQnvvNi2voXf5eWDtAbMQ-- --===============4738565846614668823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4738565846614668823==--