Is distributed IAS possible in the future?

Wu__Cheney — Thu, 05 Jul 2018 02:34:16 GMT

Hi there,

I am currently working on a project trying to leverage the Intel SGX. My only concern is the Remote Attestation service has to contact to Intel's centralized IAS. It really makes us concern about our customers' privacy and our services are totally dependent on Intel side. I am wondering if some kind of distributed IASs are possible in the future? Is it possible that my company can hold an IAS-like service to verify the hardware ourself? I guess most of you have already thought about that. Hope someone could give me more details here.

I would appreciate any help!

Regards

I see Local Attestation is

Wu__Cheney — Thu, 05 Jul 2018 02:44:49 GMT

I see Local Attestation is only for two enclave in one SGX. I am wondering if someone already built a secure channel between two SGX and how?

Appreciate any help!

If you read through the

ChrisMcConnell — Fri, 06 Jul 2018 01:05:14 GMT

If you read through the Remote Attestation documentation that was updated in 2016 https://software.intel.com/sites/default/files/managed/57/0e/ww10-2016-sgx-provisioning-and-attestation-final.pdf you will see that the process uses EPID (Enhanced Privacy ID) which only identifies that the device is in a group of many devices, but cannot uniquely identify the device. In other words, if a system performed remote attestation 10 times, Intel sees 10 unique remote attestation sessions, and since these sessions go through a service provider, not directly to Intel, even the IP address of the device is unknown to Intel.

The same document also identifies all the information received by Intel, all of which support the detection of the SGX subsystem being up to date or not.

There is a bit more complexity around linkable quotes, and the paper explains it nicely.

Good morning, I hope the week

Dr__Greg — Fri, 26 Oct 2018 09:39:52 GMT

Good morning, I hope the week has gone well for everyone.

This thread caught our eye when it originally went past and we were
meaning to comment on it, given the importance of the issues involved.
Unfortunately, development deadlines precluded us from responding but
we now have a few spare cycles and thought these issues were important
enough to resurrect and in the process take a whack at the 'Best
Reply' moniker... :-)

With respect to Wu's second message above regarding developing a
secure channel between two SGX enclaves. We were actually completing
development of our POSSUM protocol at the time the post was authored.
POSSUM is designed to implement direct secure enclave<->enclave
communication with no intermediaries.

By direct, we mean the participating enclaves implement all of the
quote generation and verification steps needed to interact with Intel
Attestation Services (IAS) without using a Service Provider (SP)
intermediary. The enclaves implement OCALL's to request the
generation of the platform quote for transmission to the communication
counter-party since, obviously, an enclave cannot execute an enclave.

The secured communications conduit is about as self-contained and
independent as can be designed. So what Wu asks about is certainly
doable.

We also ended up designing an independent implementation of the EPID
provisioning process which gave us some interesting background
experience, which we thought was relevant with respect to
Christopher's reply regarding the privacy guarantees of SGX
attestation.

Ernie Brickell did a masterful job with designing the security and
anonymity guarantees that Enhanced Privacy ID (EPID) technology
enjoys. It is, however, one element of a complex eco-system of
cryptography and protocols that make up the SGX architecture in its
totality.

Christopher comments that the IP address of a device requesting quote
verification isn't known, since the request transits through a Service
Provider (SP). Obviously this is not the case in our architecture,
since the devices themselves implement the IAS transactions. In
addition there are potential issues with adversarial SP's that privacy
papers have already been authored on.

So ultimately, from a privacy perspective, the issue comes down to
whether or not Intel is able to reliably link the EPID secret key,
provisioned to an SGX capable platform, to a physical processor and by
extension the surrounding platform. As noted above, this is not as
simple as suggesting that a private EPID key only identifies a device
within a cohort of devices in a group.

The linkage of a platform to a private key is secondary to the EPID
provisioning process that is triggered inside of the AESM the first
time a remote attestation request is received. On a 'virgin'
platform, this involves a four step protocol that internally
implements the EPID 'join' protocol that generates a private key
paired against the group public key of the processor family.

Of interest is that the fact that Intel is able to detect previously
provisioned platforms and 'short-circuit' the provisioning process
after step 2 is complete. In this case the message reply from step 2
can be fed to the step 4 completion process that extracts the member
credential from the message and seals it to the current platform TCB.

All of this is implemented as part of a 'key escrow' program by Intel
in order to avoid generating a new private key pairing if a previously
provisioned and sealed EPID blob has been lost. This of course
engenders the operative question of how does Intel 'know' which key
belongs to which platform.

To accomplish this the initial step in the platform provisioning
process is to implement an 'Endpoint Selection' (ES) procedure that
generates a Platform Provisioning ID (PPID) that uniquely identifies
the platform or more specifically the processor die that generates it.
This process takes advantage of the unique Provisioning Key (PK) that
is fused into the processor die when it is manufactured.

The ES procedure is implemented by the Platform Certification Enclave
(PCE) which is one of the prebuilt enclaves supplied by Intel. It and
the ProVisioning Enclave (PVE) have access to the PK by virtue of
having the SGX_FLAGS_PROVISION_KEY bit set in their attributes flag.

The PPID is created by using a 'null' derivation of the PK. This is
done by setting both the CPU and ENCLAVE security versions (SVN's) to
null in the key derivation request structure. Since the provisioning
key derivation process is not dependent on the platform owner epoch
key this results in a key that will be unique and invariant over the
lifetime of the processor.

The actual PPID is created by using this processor invariant key to
generate an AES128_CMAC based message authentication code over an
input block of sixteen null bytes, ie:

PPID = AES128_CMAC_pk(0{16})

This effectively cloaks the value of the key but retains the
characteristic of having a unique 128 bit identification key for the
lifetime of the processor.

As noted above Intel implements a key escrow service for protecting a
platform's private member group credential (private key). The provisioning
enclave encrypts the join request proof elements using a derived
PROVISION_SEAL key and returns that material to the Intel provisioning
service. It would be a reasonable assumption that the PPID would be
used as the database index key for the escrowed material.

It is important to note that the PROVISION_SEAL key is derived from
the platform unique root seal key that is fused into the processor at
the time of manufacture and which Intel has no visibility to. This
results in the tenable assertion that Intel has no access to the
platform's key and by extension an inability to determine which
platform is generating an attestation quote.

There is one additional level of security that may be imposed on this
process and that is the notion of whether or not Intel is implementing
a 'blinded' join process in the EPID issuance code. The Intel SGX SDK
includes a copy of their open-source implementation of the member and
verifier portions of the EPID code but the issuer code is not
currently available in any form.

For those following along at home the canonical reference for how EPID
works is Brickell and Li's reference paper:

https://eprint.iacr.org/2009/095.pdf

That paper does not contain the word 'blind' but in a presentation to
NIST by Brickell and Li that is summarized in the following slides:

https://csrc.nist.gov/csrc/media/events/meeting-on-privacy-enhancing-cryptography/documents/brickell.pdf

Page six makes reference to the fact that; 'EPID key issuing can be
blinded'. It would be helpful if there was a cryptographic summary available which discussed the computational
barriers that are implemented in the blinding process to disclosure of
sensitive material.

Intel accedes to the notion of the sensitivity of the join process in
their document discussing EPID provisioning and attestation services
which is available at the following URL:

https://software.intel.com/sites/default/files/managed/57/0e/ww10-2016-sgx-provisioning-and-attestation-final.pdf

Section 4.4.4 on page 8 describes provisioning step 4 that implements
the blind join and key certification process with the following:

"As these operations are very security sensitive, the processing takes
place inside a secure environment".

Given this, the availability of a cryptographic description of the
blinding process would be positive with respect to assisting SGX
architects in their evaluation of the overall security and privacy
posture of the SGX EPID architecture.

As was noted at the outset, privacy is a complex subject, particularly
in the face of a persistent and unique indexing element. Hopefully
the above summary is helpful with respect to assisting the community
in understanding and evaluating the architectural elements they are
working with.

In closing, the above analysis suggests a positive response to Wu's
first question on whether or not an IAS-like service can be built. If
there is interest we can provide additional dialog on how this could
be possibly implemented.

Best wishes for a pleasant weekend to everyone.

Dr. Greg

Dr. Greg, et al.

Scott_R_Intel — Wed, 12 Dec 2018 19:19:04 GMT

Dr. Greg, et al.

I made a note of a few attestation questions posted on the forums in the past so I could come back to them at the right time...

I just wanted to make you all aware of some new 3rd party attestation primitives that were recently announced and released, in case you hadn't already seen them. Our new Data Center Attestation Primitives (DCAP) help large enterprises and service providers provide a way to build out their own attestation capabilities.

A new whitepaper was just recently published with info and lots of links on DCAP:

https://software.intel.com/en-us/blogs/2018/12/09/an-update-on-3rd-party-attestation

Regards.

Scott

topic I see Local Attestation is in Intel® Software Guard Extensions (Intel® SGX)

Is distributed IAS possible in the future?

I see Local Attestation is

If you read through the

Good morning, I hope the week

Dr. Greg, et al.