[PATCH 0/6] Intel Secure Guard Extensions

Andy Lutomirski luto at amacapital.net
Mon May 9 01:32:10 UTC 2016


On May 8, 2016 2:59 AM, "Dr. Greg Wettstein" <greg at enjellic.com> wrote:
>
>
> This now means the security of SGX on 'unlocked' platforms, at least
> from a trust perspective, will be dependent on using TXT so as to
> provide a hardware root of trust on which to base the SGX trust model.

Can you explain what you mean by "trust"?  In particular, what kind of
"trust" would you have with a verified or trusted boot plus verified
SGX launch root key that you would not have in the complete absence of
hardware launch control.

I've heard multiple people say they want launch control but I've never
heard a cogent explanation of a threat model in which it's useful.

> I would assume that everyone is using signed Launch Control Policies
> (LCP) as we are.  This means that TXT/tboot already has access to the
> public key which is used for the LCP data file signature.  It would
> seem logical to have tboot compute the signature on that public key
> and program that signature into the module signature registers.  That
> would tie the hardware root of trust to the SGX root of trust.

Now I'm confused.  TXT, in theory*, lets you establish a good root of
trust for TPM PCR measurements.  So, with TXT, if you had one-shop
launch control MSRs, you could attest that you've locked the launch
control policy.

But what do you gain by doing such a thing?  All you're actually
attesting is that you locked it until the next reboot.  Someone who
subsequently compromises you can reboot you, bypass TXT on the next
boot, and launch any enclave they want.  In any event, SGX is supposed
to make it so that your enclaves remain secure regardless of what
happens to the kernel, so I'm at a loss for what you're trying to do.

* There are some serious concerns about the security of TXT.  SGX is
supposed to be better.

--Andy


More information about the devel mailing list