Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
From: "Dr. Greg" <greg@enjellic.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	X86 ML <x86@kernel.org>,
	linux-sgx@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Jethro Beekman <jethro@fortanix.com>,
	Darren Kenny <darren.kenny@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	asapek@google.com, Borislav Petkov <bp@alien8.de>,
	"Xing, Cedric" <cedric.xing@intel.com>,
	chenalexchen@google.com, Conrad Parker <conradparker@google.com>,
	cyhanish@google.com, "Huang, Haitao" <haitao.huang@intel.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	"Svahn, Kai" <kai.svahn@intel.com>, Keith Moyer <kmoy@google.com>,
	Christian Ludloff <ludloff@google.com>,
	Neil Horman <nhorman@redhat.com>,
	Nathaniel McCallum <npmccallum@redhat.com>,
	Patrick Uiterwijk <puiterwijk@redhat.com>,
	David Rientjes <rientjes@google.com>,
	"Christopherson, Sean J" <sean.j.christopherson@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	yaozhangx@google.com, Mikko Ylinen <mikko.ylinen@intel.com>
Subject: Re: [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION
Date: Tue, 27 Oct 2020 05:38:40 -0500
Message-ID: <20201027103840.GA12095@wind.enjellic.com> (raw)
In-Reply-To: <20201024194632.GA3642@kernel.org>

On Sat, Oct 24, 2020 at 11:23:11PM +0300, Jarkko Sakkinen wrote:

Good morning, I hope the day is starting well for everyone.

> On Sat, Oct 24, 2020 at 08:47:28AM -0700, Andy Lutomirski wrote:
> > On Sat, Oct 24, 2020 at 4:34 AM Jarkko Sakkinen <kernel.org@kernel.org> wrote:
> > >
> > > On Fri, Oct 23, 2020 at 07:19:05AM -0700, Dave Hansen wrote:
> > > > On 10/23/20 3:17 AM, Jarkko Sakkinen wrote:
> > > > > On Tue, Oct 20, 2020 at 02:19:26PM -0700, Dave Hansen wrote:
> > > > >> On 10/2/20 9:50 PM, Jarkko Sakkinen wrote:
> > > > >>> + * Failure to explicitly request access to a restricted attribute will cause
> > > > >>> + * sgx_ioc_enclave_init() to fail.  Currently, the only restricted attribute
> > > > >>> + * is access to the PROVISION_KEY.
> > > > >> Could we also justify why access is restricted, please?  Maybe:
> > > > >>
> > > > >>    Access is restricted because PROVISION_KEY is burned uniquely
> > > > >>    into each each processor, making it a perfect unique identifier
> > > > >>    with privacy and fingerprinting implications.
> > > > >>
> > > > >> Are there any other reasons for doing it this way?
> > > > > AFAIK, if I interperet the SDM correctl, PROVISION_KEY and
> > > > > PROVISION_SEALING_KEY also have random salt added, i.e. they change
> > > > > every boot cycle.
> > > > >
> > > > > There is "RAND = yes" on those keys in Table 40-64 of Intel SDM volume
> > > > > 3D :-)
> > > >
> > > > Does that mean there are no privacy implications from access to the
> > > > provisioning keys?  If that's true, why do we need a separate permission
> > > > framework for creating provisioning enclaves?
> > >
> > > As I've understood it, the key material for those keys is not even
> > > required in the current SGX architecture, it was used in the legacy EPID
> > > scheme, but the attribute itself is useful.
> > >
> > > Let's assume that we have some sort of quoting enclave Q, which guards a
> > > public key pair, which signs quotes of other enclaves. Let's assume we
> > > have an attestation server A, which will enable some capabilities [*],
> > > if it receives a quote signed with that public key pair.
> > >
> > > 1. E gets the report key with EGETKEY.
> > > 2. E constructs REPORTDATA (37.16) and TARGETINFO (37.17) structures.
> > >    The former describes the enclaves contents and attributes and latter
> > >    the target, i.e. Q in this artitificial example.
> > > 3. E calls EREPORT to generate a structure called REPORT MAC'd with the
> > >    *targets* report key. It knows, which key to usue from REPORTDATA.
> > > 4. The runtime will then pass this to Q.
> > > 5. Q will check if ATTRIBUTE.PROVISION_KEY is set. If it is, Q will
> > >    know that the enclave is allowed to get attested. Then it will
> > >    sign the report with the guarded public key pair and send it to
> > >    the attestation server.
> > 
> > I think you have this a little bit off.  AIUI E won't have
> > ATTRIBUTE.PROVISION_KEY set -- Q will.  Q uses the provisioning key to
> > convince an Intel server that it's running on a genuine Intel CPU, and
> > the Intel server will return a signed certificate that Q can chain off
> > of to generate attestations for E.

> Right, I was confused by that RAND column, until Jethro corrected me.

The RAND column is probably misnamed, it doesn't really imply random
in the common sense of the meaning.  It implies that a 256 bit nonce
(keyid) can be supplied to the ENCLU[EGETKEY] instruction to perturb
the key derivation process.

The value is actually available in plaintext form as part of the
metadata for sealed data.

If it was really a random value, attestation wouldn't work.

> Actually, quoting enclave (QE) authorizes itself with a provisioning
> certification enclave (PCE), which holds certificates and revocation
> lists for provisioning secrets unique to a CPU. And the sequence that I
> described happens between PCE and QE. It accepts requests from enclaves
> with ATTRIBUTES.PROVISION key bits set to 1 according to:
> 
>   https://software.intel.com/content/dam/develop/external/us/en/documents/intel-sgx-support-for-third-party-attestation-801017.pdf
> 
> The source code for the reference  is available here:
> 
>   https://github.com/intel/SGXDataCenterAttestationPrimitives
> 
> And binaries are here:
> 
>   https://01.org/intel-softwareguard-extensions/downloads/intel-sgx-dcap-1.6-release
>
> They are provided for the inevitable reason that, it is the way bind
> to the hardware, i.e. proof that you are running on a genuine CPU.
>
> The network part is that PCE and QE can certify to an application,
> if an enclave running in a different computer is an enclave.

All of this discussion has lacked a certain amount of precision, as a
result the original issue with respect to Dave's concern regarding the
privacy implications of an enclave posessing the PROVISION_KEY
attribute has been lost.

First of all, it is important to note that two types of attestation
are available, EPID and DCAP/ECDSA.  They differ in their
implementation with respect to which enclaves need to have access to
derivation of the PROVISION_KEY.  What does remain constant is the
role that the PROVISION_KEY plays in all this.

The Platform Certification Enclave (PCE) has two roles:

1.) Generate a Platform Provisioning IDentifier (PPID).

2.) Certification of the fact that an enclave, other then the PCE, is
running on the same platform at a particular Trusted Computing Base
(TCB) level.

Being able to generate a PPID is the most privacy sensitive operation
that an enclave can peform, hence the recommendation to restrict
access to the attribute bit that allows an enclave to create a
derivation of the root provisioning key.

The PPID is a 256 bit symmetric key that is generated with the keyid
and security version values all set to null values.  As a result, any
enclave with a given MRSIGNER value will generate the same key value.
That value is used by Intel, and potentially others, to uniquely
identify the platform as long as it exists.

The PPID can be admixed with other information, such as the platform
security version of an enclave, to create a unique identifier for the
TCB state of enclave based software running on a particular platform.
This is role 2 of the PCE that I noted above.

In DCAP attestation, which is what Jarkko is referring to, both the
Quoting Enclave (QE) and PCE have access to PROVISION_KEY derivation.

In EPID attestation the PCE and the Provisioning Enclave (PVE) have
access to PROVISION_KEY derivation.

I guess it is up to community consensus as to whether or not this is a
privacy/security sensitive issue.  It provides precise enough
identification that Intel uses it to determine whether or not a
platform should be allowed or denied the ability to participate in
EPID attestation.

I believe that this is being used to to force the cloud based
platforms to use DCAP rather then EPID based attestation.  The
provision keys for these SKU's are not included in the Intel
Attestation Service (IAS) database so they cannot identify themselves
for provisioning of an EPID private key.

Since Intel has access to the root provisioning keys it can identify a
platform a-priori.  Other entities can use this infrastructure for
uniquely identifying platforms but it has to be done via an enrollment
process for a given signing key.

> /Jarkko

Hopefully the above clarifications are helpful.

Have a good day.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"I suppose that could could happen but he wouldn't know a Galois Field
 if it kicked him in the nuts."
                                -- Anonymous mathematician
                                   Resurrection.

  reply index

Thread overview: 117+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03  4:50 [PATCH v39 00/24] Intel SGX foundations Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 01/24] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
2020-10-19 14:10   ` Dave Hansen
2020-10-19 17:49     ` Sean Christopherson
2020-10-03  4:50 ` [PATCH v39 02/24] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control " Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 04/24] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 05/24] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2020-10-19 14:30   ` Dave Hansen
2020-10-19 17:38     ` Sean Christopherson
2020-10-19 17:48       ` Dave Hansen
2020-10-19 17:53         ` Sean Christopherson
2020-10-19 17:58           ` Dave Hansen
2020-10-03  4:50 ` [PATCH v39 06/24] x86/cpu/intel: Detect SGX support Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 07/24] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 08/24] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections Jarkko Sakkinen
2020-10-19  8:45   ` Jarkko Sakkinen
2020-10-19 12:39     ` Borislav Petkov
2020-10-23  9:01       ` Jarkko Sakkinen
2020-10-19 13:40     ` Dave Hansen
2020-10-23  9:03       ` Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 09/24] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page() Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 11/24] x86/sgx: Add SGX enclave driver Jarkko Sakkinen
2020-10-03 14:39   ` Greg KH
2020-10-04 14:32     ` Jarkko Sakkinen
2020-10-04 15:01       ` Jarkko Sakkinen
2020-10-05  9:42       ` Greg KH
2020-10-05 12:42         ` Jarkko Sakkinen
2020-10-07 18:09           ` Haitao Huang
2020-10-07 19:26             ` Greg KH
2020-10-09  6:44               ` Jarkko Sakkinen
2020-10-14 20:16                 ` Dave Hansen
2020-10-05  8:45     ` Christoph Hellwig
2020-10-05 11:42       ` Jarkko Sakkinen
2020-10-05 11:50         ` Greg KH
2020-10-05 14:23           ` Jarkko Sakkinen
2020-10-05 15:02             ` Greg KH
2020-10-05 16:40               ` Dave Hansen
2020-10-05 20:02                 ` Jarkko Sakkinen
2020-10-09  7:10     ` Pavel Machek
2020-10-09  7:21       ` Greg KH
2020-10-09  8:21         ` Pavel Machek
2020-10-03 19:54   ` Matthew Wilcox
2020-10-04 21:50     ` Jarkko Sakkinen
2020-10-04 22:02       ` Jarkko Sakkinen
2020-10-04 22:27       ` Matthew Wilcox
2020-10-04 23:41         ` Jarkko Sakkinen
2020-10-05  1:30           ` Matthew Wilcox
2020-10-05  3:06             ` Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE Jarkko Sakkinen
2020-10-16 17:07   ` Dave Hansen
2020-10-18  4:26     ` Jarkko Sakkinen
2020-10-19 20:21       ` Dave Hansen
2020-10-19 20:48         ` Sean Christopherson
2020-10-03  4:50 ` [PATCH v39 13/24] x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES Jarkko Sakkinen
2020-10-16 21:25   ` Dave Hansen
2020-10-18  5:03     ` Jarkko Sakkinen
2020-10-19  7:03       ` Jarkko Sakkinen
2020-10-19 20:48       ` Dave Hansen
2020-10-19 21:15         ` Sean Christopherson
2020-10-19 21:44           ` Dave Hansen
2020-10-23 10:11             ` Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 14/24] x86/sgx: Add SGX_IOC_ENCLAVE_INIT Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 15/24] x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION Jarkko Sakkinen
2020-10-20 15:48   ` Dave Hansen
2020-10-23 10:14     ` Jarkko Sakkinen
2020-10-20 21:19   ` Dave Hansen
2020-10-23 10:17     ` Jarkko Sakkinen
2020-10-23 14:19       ` Dave Hansen
2020-10-24 11:34         ` Jarkko Sakkinen
2020-10-24 15:47           ` Andy Lutomirski
2020-10-24 20:23             ` Jarkko Sakkinen
2020-10-27 10:38               ` Dr. Greg [this message]
2020-10-23 14:23       ` Jethro Beekman
2020-10-24 11:40         ` Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 16/24] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2020-10-03  5:22   ` Haitao Huang
2020-10-03 13:32     ` Jarkko Sakkinen
2020-10-03 18:23       ` Haitao Huang
2020-10-04 22:39         ` Jarkko Sakkinen
2020-10-07 17:25           ` Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 17/24] x86/sgx: Add ptrace() support for the SGX driver Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 18/24] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 19/24] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 20/24] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
2020-10-06  2:57   ` Sean Christopherson
2020-10-06  8:30     ` Jethro Beekman
2020-10-06 15:15       ` Sean Christopherson
2020-10-06 17:28         ` Jarkko Sakkinen
2020-10-06 23:21           ` Sean Christopherson
2020-10-07  0:22             ` Jarkko Sakkinen
2020-10-07  1:17               ` Sean Christopherson
2020-10-07  3:14                 ` Jarkko Sakkinen
2020-10-07  4:34                   ` Sean Christopherson
2020-10-07  7:39                     ` Jarkko Sakkinen
2020-10-07  8:04                       ` Jarkko Sakkinen
2020-10-07 15:25                       ` Sean Christopherson
2020-10-07 17:08                         ` Jarkko Sakkinen
2020-10-07 17:13                           ` Jarkko Sakkinen
2020-10-06 15:49       ` Jarkko Sakkinen
2020-10-06 15:36     ` Jarkko Sakkinen
2020-10-06 21:39     ` Jarkko Sakkinen
2020-10-07  0:23       ` Jarkko Sakkinen
2020-10-17  1:48   ` Andy Lutomirski
2020-10-17 21:02     ` Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 22/24] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2020-10-12 16:50   ` Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 23/24] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen
2020-10-03  4:50 ` [PATCH v39 24/24] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2020-10-16 21:04   ` Dave Hansen
2020-10-18  4:27     ` Jarkko Sakkinen
2020-10-03 14:32 ` [PATCH v39 00/24] Intel SGX foundations Greg KH
2020-10-03 14:53   ` Jarkko Sakkinen
2020-10-15 19:06 ` Dave Hansen
2020-10-17 20:43   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201027103840.GA12095@wind.enjellic.com \
    --to=greg@enjellic.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=asapek@google.com \
    --cc=bp@alien8.de \
    --cc=cedric.xing@intel.com \
    --cc=chenalexchen@google.com \
    --cc=conradparker@google.com \
    --cc=cyhanish@google.com \
    --cc=darren.kenny@oracle.com \
    --cc=dave.hansen@intel.com \
    --cc=haitao.huang@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jarkko@kernel.org \
    --cc=jethro@fortanix.com \
    --cc=kai.huang@intel.com \
    --cc=kai.svahn@intel.com \
    --cc=kmoy@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=ludloff@google.com \
    --cc=luto@kernel.org \
    --cc=mikko.ylinen@intel.com \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=puiterwijk@redhat.com \
    --cc=rientjes@google.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yaozhangx@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Sgx Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \
		linux-sgx@vger.kernel.org
	public-inbox-index linux-sgx

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git