Re: [PATCH 0/6] Intel Secure Guard Extensions

[Dr. Greg Wettstein]

Hi, I hope the weekend is going well for everyone.

On Fri, May 06, 2016 at 02:39:44PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > It would be helpful and instructive for anyone involved in this debate
> > to review the following URL which details Intel's SGX licening
> > program:
> > 
> > https://software.intel.com/en-us/articles/intel-sgx-product-licensing

> I think it would be good to note that the licensing process is
> available only for Windows. For Linux you can only use debug
> enclaves at the moment. The default LE has "allow-all" policy for
> debug enclaves.

As others have noted, unfortunately, this renders the technology
largely useless on Linux, at least for anything beyond
experimentation.  That is somewhat strange given that one of the
primary intentions of the technology is to push applications into
untrusted cloud environments, particularly given the use of Linux in
the 'cloud'.  So I guess Azure is the only security beneficiary at
this time... :-)

I assume that Intel will be releasing a launch enclave with its
upcoming Linux SDK?

> > I think the only way forward to make all of this palatable is to
> > embrace something similar to what has been done with Secure Boot.  The
> > Root Enclave Key will need to be something which can be reconfigured
> > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > off the hook from a security perspective and establish the notion of
> > platform trust to be a bilateral relationship between a service
> > provider and client.

> This concern has been raised many times now. Sadly this did not make
> into Skyle but in future we will have one shot MSRs (can be set only
> once per boot cycle) for defining your own root of trust.

It is encouraging to hear that Intel will be implementing one shot
MSR's for the identity modulus signature.  That would be consistent
with what we would advocate for.

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.
I was out walking with Izzy our Golden Retriever last night and as I
thought about the implicatioins of all this I think the solution, at
least as we would implement it, will tie together rather nicely.

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.

If that is undesirable the other alternative would be to pass a custom
LCP policy element into tboot which would define the desired SGX
trust signature.

It is unfortunate that SGX took the path it did on Linux.  We actually
have application for the technology now in our security supervisor.

When you say that unlocked SGX did not make it into Skylake does this
mean we need to wait for a new micro-architecture or a die shrink?
Given that tick/tock is now expanding in time it would be useful to
have unlocked SGX be one of the extension features of Skylake.
Otherwise there is certainly no rush for the Linux driver... :-)

> /Jarkko

Have a good week.

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"If you get to thinkin' you're a person of some influence, try
 orderin' somebody else's dog around."
                                -- Cowboy Wisdom